CISA Secure Software Attestation in 90 days.
If you sell software to US federal agencies, you sign the CISA Secure Software Attestation form. The form is short. The substrate behind it — NIST SSDF (SP 800-218), SLSA v1.0, signed provenance, SBOM owner-loop — takes a quarter to land right. This playbook gets you there.
Map the gaps.
The first month is honest inventory. Most teams discover they're further from SSDF / SLSA than they thought; honest baseline beats optimistic claim every time.
Baseline against SSDF + SLSA — for real.
- Read NIST SP 800-218 tasks PO/PS/PW/RV. Tick each one with evidence, not intent.
- Read SLSA v1.0 levels. Score honestly: L0 (no provenance) · L1 (provenance exists) · L2 (signed provenance) · L3 (hardened builder).
- Run the DevSecOps Maturity diagnostic to score the broader substrate.
Single artefact with current state per SSDF task + SLSA level. Owners assigned to each gap.
Pick the one critical pipeline to land first.
Don't try to lift all pipelines at once. Pick the one whose attestation matters most (federal-customer-facing usually).
- Document the pipeline: source repo → build env → artefact registry → deploy target. Every step.
- Identify the trust gaps: shared build agents · static creds · unsigned artefacts · floating dependencies
- Identify the people: who has write access to source · build · registry · production
Engineering + security + product agree on which pipeline gets the work first.
Lock dependency versions across the repo tree.
Reproducible, auditable builds start here. Floating tags break supply-chain claims.
- Replace
:latest/^1.x/~2.3in production paths with pinned versions + lockfiles committed - Tooling: npm shrinkwrap · pip-tools / uv lock · Bazel maven_install with shas · Renovate or Dependabot for managed updates
- CI rejects: builds whose lockfile is stale beyond N weeks (forces refresh-or-justify)
Source-tree scan finds none. CI guard blocks new ones.
Workload identity rollout begins on the critical pipeline.
Static credentials in the build/deploy path is the single biggest CISA SSA gap most teams have.
- Migrate CI → cloud authentication from static keys to OIDC: GitHub Actions OIDC + AWS IRSA / GCP WLI / Azure Federated Credentials
- Migrate production workloads from static service-account keys to workload identity
- Inventory and rotate any remaining static creds. Trend to zero in 30 days; rotate aggressively in the meantime
CI authenticates to cloud via OIDC. Static keys deleted, not just unused. Vault Theatre gap closed for this pipeline.
Provenance, signing, SLSA L2.
The build-integrity work. You're moving from 'we built it' to 'we can prove we built it from the source we say we built it from'.
Emit signed build provenance (Sigstore).
- Sigstore: cosign + Rekor (transparency log) + Fulcio (keyless signing via OIDC identity)
- GitHub Actions: built-in actions/attest-build-provenance (writes in-toto SLSA provenance)
- GitLab: built-in build attestations
- Tekton: Tekton Chains for K8s-native CI
Rekor transparency-log entry per artefact. Provenance attestation attached.
Verify signatures at deploy — not at scan time.
The deploy gate is where signature verification becomes a control, not a check.
- Kubernetes: Kyverno verifyImages · Sigstore Policy Controller · Connaisseur
- Serverless / VM: AWS Signer + ECR · custom admission via deploy pipeline
- Test workload with bad signature must fail deploy. Drill it.
Test deploy of unsigned image fails. Policy distributed via GitOps. Exception list (with owner + expiry) for any temporary opt-outs.
SBOM per artefact + KEV-driven owner-alert loop.
- Emit: Syft (SPDX/CycloneDX) on every build, stored alongside the artefact
- Centralise: OWASP Dependency-Track or GUAC graph store
- Wire: CISA KEV catalogue as a feed → on match → alert the service owner (not central security inbox)
- SLA: KEV-listed CVEs patched within 14 days (E8 ML2 / SSDF expectations)
Drill it: pick a recent KEV addition, verify your alert pipeline fired and the owner ack'd. SBOM Shelfware gap closed.
Secret scanning + auto-revocation, retroactive sweep.
- Pre-commit + push-time + retroactive: GitGuardian · GitHub Advanced Security · Trufflehog (each at a different point)
- Retroactive scan of all repos including git history. Address findings, not just future detections
- Auto-revocation pipeline: detected → vendor-API revoke → notify owner. MTTR for leaked secrets measured
Findings tracked. Auto-revoke tested against a deliberate test secret. The "leaked-secret-rotated-in-30-days-is-a-breach" risk is closed.
Hardened builds, attestation defence.
Phase 3 turns SLSA L2 into SLSA L3 where it matters, builds the attestation defensibility, and rolls the pattern beyond the first pipeline.
Hardened builder — isolated, ephemeral.
The SLSA L3 control: build runs on an isolated, ephemeral, audited environment, not a long-running shared runner.
- GitHub: larger runners + ephemeral · or self-hosted with one-shot VMs
- Self-hosted alternative: actions-runner-controller on K8s with ephemeral pods
- GitLab: per-job VM runners
- Verify isolation: build artefact cannot tamper with subsequent build's environment
Documented isolation. Test attack (intentional malicious step) cannot persist or affect the next build.
Vulnerability disclosure programme + security.txt.
SSDF PS.1 / RV.2 want a known route for researchers to report vulnerabilities to you. Most companies don't publish one.
- Publish
/.well-known/security.txtper RFC 9116 - Policy doc: scope · safe harbour for good-faith research · response SLA · disclosure timeline
- Internal: triage process · CVE numbering (CNA registration or via a sponsor) · advisory format
- Optional: bug-bounty platform (HackerOne · Bugcrowd · Intigriti) once mature
Test report (internal red-team or friendly researcher) routed through the process end-to-end.
Roll the pattern to pipelines 2 and 3.
The substrate you built for pipeline 1 (OIDC · signed provenance · SBOM owner-loop · verified deploy) becomes the paved-path scaffold for the rest.
- Templatise: reusable workflow / shared GitHub Actions / shared GitLab CI components
- Documentation: "how to onboard a new pipeline to the secure-build paved path" in your developer portal
- Onboard 2 more pipelines using the paved path. Time the onboarding; target <1 day per pipeline
Onboarding time tracked. Resistance points logged for remediation.
Sign the attestation. Defensibly.
The attestation form asks specific yes/no questions tied to SSDF tasks. For each one you can now point at the substrate that backs it.
- Build an evidence pack alongside the form: per attestation question, the specific control + tool + artefact that demonstrates it
- Internal counsel + security leadership sign off on the evidence pack before the form is signed
- Schedule an external assurance review (or independent internal audit) within 6 months. Annual cadence thereafter
If a federal agency or DOJ asks you to substantiate the attestation, you have a binder ready in <48h.
End of week 13.
If you've completed the gates honestly, the attestation form is a 30-minute exercise — you're attesting to a substrate that demonstrably exists. Without this work, the form is either a lie or a deferred problem.