A short AI-narrated film with English captions. Pressing play loads the YouTube player. Watch on YouTube
Overlay: USA Federal Civilian Community Overlay | ArcKit Version: [VERSION]
/arckit:us-sbom-eo-14028 produces the dual artefact required under Executive Order 14028 and OMB M-22-18 / M-23-16: (1) the CISA Secure Software Development Attestation Form completion, and (2) the Software Bill of Materials (SBOM) covering the agency-acquired software. The artefact aligns to NIST SP 800-218 (SSDF) for the secure-development practices being attested to, and to the NTIA Minimum Elements for an SBOM for the SBOM payload.
This is the software supply-chain evidence artefact. Agencies cannot use a vendor's software for federal use without the vendor having attested to SSDF conformance; SBOM is required as supporting evidence at the agency's discretion (and increasingly as a hard requirement). Weak provenance attestations are a finding pattern that ripples through every downstream contract.
Reviewed by the agency software supply-chain security function, the System Owner, the procurement / contracts team, and (for the attestation form) the vendor's senior executive who signs the attestation.
Inputs
| Artefact | Purpose |
|---|---|
Tailored Control Set (ARC-<id>-NIST-v1.0.md) |
SR (Supply Chain Risk Management) family cross-reference |
Requirements (ARC-<id>-REQ-v1.0.md) |
Software components in scope, integration points |
Output
- Doc-type:
SBOM - Filename:
ARC-<PID>-SBOM-v1.0.md(project root, single-instance)
Process Overview
- Inventory the software components in scope (vendor product + dependencies).
- Complete the CISA Secure Software Development Attestation Form for each in-scope product line.
- Generate the SBOM in a single agreed format (CycloneDX or SPDX — pick one, do not mix).
- Verify the SBOM minimum elements per NTIA guidance — supplier name, component name, version, unique identifier, dependency relationship, author of SBOM data, timestamp.
- Sign provenance attestations; the verifier (agency or downstream consumer) must validate signatures.
Regulatory Anchors
- EO 14028 — https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- OMB M-22-18 — https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
- OMB M-23-16 — https://www.whitehouse.gov/wp-content/uploads/2023/06/M-23-16-Update-to-M-22-18-Enhancing-Software-Security-.pdf
- CISA Secure Software Development Attestation Form — https://www.cisa.gov/secure-software-attestation-form
- NTIA Minimum Elements for an SBOM — https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
- NIST SP 800-218 (SSDF) — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
Example Usage
/arckit:us-sbom-eo-14028 001-citizen-benefits-portal
Common Pitfalls
- Incomplete SBOM minimum elements. Missing any of the seven NTIA minimum elements invalidates the SBOM. Verify before publishing.
- Mixing CycloneDX and SPDX. Pick one format and stay with it; downstream tooling does not seamlessly merge the two.
- Weak provenance attestations. "We follow secure development practices" is not an attestation; the CISA form has specific clauses to be signed by a senior executive.
- Signing without verifying. A signed SBOM whose signature is never validated by the consumer is theatre. Validate at acquisition and at every update.
Handoffs
us-nist-800-53— SR family controls cross-reference the attestation and SBOMadr— SBOM format choice (CycloneDX vs. SPDX) is architecturally significantrisk— vulnerable components surfaced in the SBOM flow into the risk register