Why supply chain security is now a federal acquisition gate
The combination of SolarWinds, Log4j, and a steady stream of npm and PyPI malicious packages convinced the federal government that the software supply chain is a national security concern. Executive Order 14028 (May 2021) and OMB Memorandum M-22-18 (September 2022) and its successor M-23-16 made it concrete: any software a federal agency procures or uses must come with a signed self-attestation that the producer follows secure development practices defined in NIST 800-218 (the Secure Software Development Framework). For internal federal builds, the same standards now apply.
This is no longer optional. Software publishers without a CISA self-attestation on file cannot sell to federal agencies. Internal federal development organizations must produce equivalent evidence. Precision Federal helps both sides — federal agencies running their own builds, and small federal software vendors needing to attest — implement these controls in production CI/CD systems.
EO 14028 and the CISA self-attestation
The CISA Secure Software Development Attestation Form is the operative artifact. Any company supplying software to a federal agency must sign it, attesting that for each piece of software delivered, the company:
- Develops and produces software in secure environments separated from internet access where appropriate, with multi-factor authentication and least privilege.
- Uses automated tools or comparable processes to maintain trusted source code supply chains.
- Maintains provenance data for internal code and third-party components incorporated into the software.
- Uses automated tools or comparable processes to check for security vulnerabilities, with results addressed before release.
The attestation must be signed by a senior company executive. Federal agencies collect attestations through a CISA-operated repository and may request extension forms or additional artifacts (a SBOM, a third-party assessment) for high-impact systems. We help vendors and internal federal teams produce the underlying evidence the attestation rests on.
NIST 800-218 SSDF as concrete pipeline controls
NIST SP 800-218, the Secure Software Development Framework, decomposes secure development into four practice groups, each with concrete tasks. We translate every SSDF practice into a CI/CD pipeline control with measurable evidence:
- PO (Prepare the Organization): Documented SDLC, role definitions, security training records, toolchain inventory.
- PS (Protect the Software): Source code in protected repositories with branch protection, signed commits via GPG or Sigstore gitsign, code review enforcement, secret scanning at commit and at build, immutable build logs.
- PW (Produce Well-Secured Software): Threat modeling, secure design review, hardened base images, dependency pinning with hash verification, SAST (Semgrep, CodeQL), SCA (Trivy, Grype, Snyk), DAST where applicable, fuzzing for high-risk surfaces, code-signing of release artifacts.
- RV (Respond to Vulnerabilities): Coordinated vulnerability disclosure policy (per ISO 29147), VEX/VDR generation for downstream notification, patch SLA tied to severity, customer-facing security advisory process.
SLSA build provenance
SLSA (Supply-chain Levels for Software Artifacts) is the OpenSSF framework for build integrity. The four levels articulate increasing guarantees:
- SLSA L1: Build process produces provenance.
- SLSA L2: Hosted build platform generates provenance with cryptographic signature.
- SLSA L3: Hardened build platform with isolation between builds, non-falsifiable provenance.
For internal federal builds we target SLSA L3 by default. Concrete implementation paths:
- GitHub Actions with OIDC-issued provenance using the SLSA GitHub Generator. The provenance is signed by Sigstore Fulcio with a short-lived certificate and recorded in the Rekor transparency log.
- GitLab CI with the same OIDC provenance pattern. Self-hosted runners isolated per build to meet L3.
- Tekton Chains for Kubernetes-native builds, generating in-toto attestations from TaskRun and PipelineRun results.
SBOMs in CycloneDX and SPDX
The SBOM (Software Bill of Materials) lists every component used to build a piece of software. NTIA defined minimum elements in 2021. CISA built on those with formats and use cases. Federal acquirers increasingly require SBOMs at contract delivery. We generate both major SBOM formats from every build:
- CycloneDX (OWASP, ECMA-424) — strong in security tooling, native VEX (Vulnerability Exploitability eXchange) integration, container-aware.
- SPDX (Linux Foundation, ISO/IEC 5962:2021) — strong in license compliance, broad ecosystem support, mature.
Tooling we deploy: Syft for generation (both formats from one tool), Grype or Trivy for vulnerability matching against the SBOM, Dependency-Track or GUAC for fleet-wide SBOM management. Every release artifact gets an SBOM published as an attached attestation, signed with Cosign, and referenced in the build provenance.
In-toto attestations as the unifying format
In-toto attestations are signed claims about software artifacts. The SLSA provenance, the SBOM, the SAST scan result, the SCA result, the test report, the code review approval — all can be expressed as in-toto attestations with standardized predicate types. This is the unifying format we use to bind evidence to artifacts:
- Each attestation references the artifact by digest.
- Each attestation is signed by an identity (Sigstore-issued or pre-provisioned key).
- Each attestation is published to a transparency log (Rekor) and bundled with the artifact.
- Verification is performed at deployment time by a policy engine that checks for required attestation types and signers.
Sigstore for keyless signing
Sigstore is the OpenSSF project that solves the historical pain of code signing — managing long-lived signing keys. Three components: Fulcio (a certificate authority that issues short-lived certificates against an OIDC identity), Cosign (the signer and verifier), and Rekor (the transparency log). We deploy Sigstore patterns federally:
- Public Sigstore — appropriate for federally-funded open source where transparency is desirable.
- Private Sigstore — Fulcio and Rekor self-hosted inside the agency authorization boundary, federated with the agency identity provider. Required for sensitive or classified work.
- Cosign verification at admission time via Kyverno or OPA Gatekeeper policies in Kubernetes.
Federal-specific patterns
- Iron Bank consumption: When pulling base images from the DoD Iron Bank, verify the Cosign signature against Iron Bank's public key as part of the build.
- Vulnerability response SLA: Critical vulnerabilities patched within 15 days per CISA BOD 22-01 KEV cadence. High vulnerabilities within 30 days. Documented evidence per release.
- Air-gapped build provenance: Self-hosted Fulcio and Rekor instances inside disconnected enclaves. Pre-provisioned signing identities tied to PIV/CAC.
- FedRAMP integration: Supply chain controls map to NIST 800-53 SR family (Supply Chain Risk Management), SA-15 (Development Process), SI-7 (Software Integrity).
For federal software vendors
Small software companies selling to federal agencies need to produce the CISA self-attestation evidence without building a security organization. We deliver a turnkey package: hardened CI/CD pipeline, SBOM generation, SLSA L3 provenance, attestation collection, and the documentation an executive needs to confidently sign the CISA form. Our offering is designed for companies in the 10-100 engineer range that have a federal contract and a deadline.
For federal agencies
Internal federal development teams need to produce equivalent evidence for software they build themselves. We integrate supply chain controls into existing pipelines (GitHub Enterprise, GitLab Federal, Azure DevOps Government) and into platform-engineered IDPs so that every service that ships from the platform produces SBOMs, signed provenance, and inheritable evidence.
Who we build supply chain security for
- DoD — Iron Bank-aligned supply chain controls, SLSA L3 builds for IL4/IL5 workloads.
- CISA — supply chain instrumentation for federal civilian agencies.
- VA — SBOM and attestation collection for the VA software portfolio.
- HHS — SSDF rollout for CMS and component agencies.
- NIST — reference implementations of 800-218 controls.