Secure Software and AI Supply-Chain Crosswalk

Version: 1.0.1
Date: 2026-07-16
Status: Informative

Purpose

Map OAIES artifacts to NIST SSDF SP 800-218, applicable NIST SP 800-53 Rev. 5 controls, SLSA, and OpenSSF practices.

Why

AI releases contain software plus models, prompts, datasets, evaluation suites, tools, and remote protocol servers. Conventional build provenance remains necessary, but it does not describe model behavior, data rights, prompt risk, delegated authority, or runtime context.

NIST SSDF crosswalk

SSDF practice group	OAIES evidence	Relationship	Limit
PO — Prepare the Organization	Control Catalog, Statement of Applicability, AI System Manifest, owners	`partial`	Secure-development roles, training, and environment governance need SDLC evidence
PS — Protect the Software	Digest-addressed Prompt/Model/Tool/Agent records; Evidence Bundle signatures; access controls	`partial`	Repository, build service, and signing-key controls are external
PW — Produce Well-Secured Software	Strict schemas, threat reviews, evaluations, approval gates, provenance	`partial`	Source review, compiler/build hardening, and complete verification require software controls
RV — Respond to Vulnerabilities	Incident, Risk Register, Exception, component versions, rollback references	`partial`	Vulnerability disclosure and remediation SLAs require program evidence

NIST SP 800-53 Rev. 5 crosswalk

Control family / example controls	OAIES evidence	Relationship
AC / AC-2, AC-3, AC-6	Agent/Tool/MCP authorization, least-privilege review, user delegation, status/revocation	`partial`
AU / AU-2, AU-3, AU-6, AU-9	Tool audit contract, trace/evidence references, tamper-evident Evidence Bundle	`partial`
CA / CA-2, CA-5, CA-7	Evaluation Result, Statement of Applicability, Risk Register, continuous evidence	`partial`
CM / CM-2, CM-3, CM-8	Versioned component records, manifest inventory, immutable release artifacts	`evidence-supports`
IA / IA-2, IA-5	Human, workload, and agent identities; credential mode; token restrictions	`partial`
IR / IR-4, IR-5, IR-6, IR-8	AI Incident lifecycle, notification assessment, evidence, corrective actions	`partial`
RA / RA-3, RA-5, RA-7	Risk Register, adversarial evaluations, risk response	`partial`
SA / SA-4, SA-8, SA-9, SA-11, SA-15	Supplier/model/tool records, security requirements, evaluation, provenance	`partial`
SC / SC-7, SC-8, SC-12, SC-23	Trust boundaries, transports, encryption/signature metadata, session controls	`partial`
SI / SI-2, SI-3, SI-4, SI-7, SI-10	Component status, monitoring, digest integrity, strict input validation	`partial`
SR / SR-3, SR-4, SR-6, SR-11	Supplier records, provenance, component authenticity and integrity	`partial`

SP 800-53 applicability, baselines, parameters, and assessment objectives come from the organization’s authorization process; this table does not assign a baseline.

SLSA and OpenSSF crosswalk

Source concern	OAIES evidence	Relationship	Required external evidence
SLSA build provenance	Evidence Bundle item with artifact URI/digest and signed provenance	`partial`	SLSA provenance predicate generated by the build platform
SLSA build isolation and hardened platform	Model/prompt/tool release references	`no-mapping`	Build platform controls and SLSA build level evidence
SLSA source provenance	Component source URI/digest	`partial`	Version-control and source attestation
OpenSSF Scorecard: branch protection, review, CI tests, token permissions	Evidence references	`no-mapping`	Repository-native Scorecard output
OpenSSF Scorecard: pinned dependencies, signed releases, maintained dependencies	Version/digest inventory and Evidence Bundle	`partial`	Package, repository, and release metadata
OpenSSF best practices	Control Catalog and SDLC evidence	`no-mapping`	Project badge criteria and project-level verification

How

Generate conventional SBOM and SLSA provenance for deployable software.
Add AI component records for every model, prompt, dataset/context source, evaluation suite, agent, tool, and MCP server.
Bind records to immutable digests; never use a mutable model alias or branch name as release identity.
Run OpenSSF Scorecard on source repositories and preserve the result in an Evidence Bundle.
Assess applicable SP 800-53 controls using organization-defined parameters and formal assessment procedures.
On vulnerability or compromise, identify every affected AI system by component digest, revoke releases, and record the incident.

Equivalence limits

OAIES does not assign SLSA levels, issue OpenSSF badges, implement NIST control baselines, or establish SSDF conformance. A digest alone is not provenance; a provenance statement alone does not establish a trustworthy builder. NIST publications are not certification schemes, and OpenSSF/SLSA project marks have their own rules.

Tradeoffs

Benefit	Cost
Extends software provenance to AI-specific artifacts	More registries and attestations must be synchronized
Digest-based inventory accelerates response	Remote API models may expose limited provenance
Reuses evidence across security programs	SP 800-53 assessment remains organization-specific

Anti-patterns

SBOM-only inventory: omitting prompts, models, datasets, tools, and remote servers.
Mutable identity: approving latest, a model family alias, or an unpinned URL.
Digest equals trust: verifying bytes without verifying producer, source, or build process.
Self-assigned SLSA level: claiming a level without satisfying the versioned SLSA requirements.
Control-family claim: citing “AC” or “SA” without control, enhancement, parameter, scope, and evidence.

Enterprise considerations

Integrate AI component records with CMDB, vulnerability management, procurement, IAM, code signing, legal/license review, and incident response. Require contractual provenance and notification obligations from model and tool suppliers. Protect signing keys in managed hardware-backed systems.

Authoritative sources

Sources accessed 2026-07-16. Pin the exact SLSA and Scorecard versions in each assessment.

Checklist

Software and AI-specific components are inventoried by immutable digest
Build provenance is generated by the build platform, not hand-authored
SP 800-53 control identifiers, parameters, scope, and assessment evidence are explicit
OpenSSF results are preserved with repository commit and tool version
Supplier notification, revocation, and rollback paths are tested
No SLSA level, OpenSSF badge, or NIST certification is claimed without basis

Changelog

1.0.1 — 2026-07-16

Narrowed relationship claims to evidence support, partial coverage, or no mapping.

1.0.0 — 2026-07-16

Added SSDF, SP 800-53, SLSA, and OpenSSF evidence mappings.