· ReadyStack
Worked example
Real numbers from this tool, line by line.
8 of 14 attestation rules fail on one AI-written GitHub Actions deploy workflow - the same pipeline a US federal software vendor stands behind when a chief executive signs the CISA Secure Software Development Attestation Common Form. The hardened release workflow sitting next to it, same audit, same day: 0 findings.
Under OMB memoranda M-22-18 and M-23-16, a federal agency may use your software only once that form has been signed by a chief executive or a designated employee. The form is short. It carries four attestation sections: the software is developed and built in secure environments; trusted source code supply chains are maintained in good faith; provenance data is kept for internal and third-party code; and automated tooling checks for vulnerabilities on an ongoing basis. Three of those four are answered by your build pipeline, not by a policy document in a shared drive.
That is where the gap opens: a policy document is written knowing an auditor will read it, while a workflow file is written by whoever needed the release out. Here is what the sample AI-written deploy workflow in this extension's fixtures actually contains.
It triggers on pull_request_target, so fork code runs next to repository secrets - SSDF PO.5.1, section 1. It sets permissions: write-all, handing the job token everything - PO.5.1 again. It pins the code-fetch action to a moving tag instead of a 40-character commit SHA - PW.4.4, section 2. It runs npm install rather than a lockfile install, so the build is not reproducible - PW.4.1. It interpolates a pull request title straight into a shell command - PO.5.1. It echoes a publish token into the build log - PO.5.2. And two sections stay empty by omission: no SBOM anywhere, and no automated vulnerability check anywhere - PS.3.2 and RV.1.1, sections 3 and 4. Eight findings, three sections.
Ask a general assistant to harden that file and you get back confident YAML. What you do not get is the sentence that matters: section 3 is still empty. It pins one action and moves on, leaving no line number tied to PS.3.1 that someone else can follow six months later. A false attestation is not a lint warning - it is a statement made to the United States government, and the Department of Justice has pursued cybersecurity misrepresentations in federal contracts under the False Claims Act.
The audit takes two inputs: a workflow file and a date. The date is not decoration. Findings that come from an absent control - no SBOM, no provenance step, no scan - also report how many days remain to the 30 September federal fiscal-year end, the boundary where new awards and renewals land. Run the same file on 2026-09-21 and you get 9 days; run it in November and the clock points at the following year.
The free audit reads the workflow file you have open and lists every attestation gap with its practice ID and form section. All 14 rules, all four sections, offline. That job finishes on its own: open a file, learn what your signature would rest on, fix the lines.
The full version changes one axis only - scope. It audits every workflow in the repository at once and exports a single dated evidence table mapped to all four attestation sections, which is the artefact the person signing the form asks for. 29 once, one licence key per person or team seat. A US application-security contractor bills roughly 150 to 250 an hour for the same review by hand.
Attestation is a signature on top of a build system. This makes the build system readable.
15 seconds — what it actually does
Questions people ask
What does the SSDF Attestation Audit actually do?
It reads a GitHub Actions workflow file and marks every line that contradicts the CISA Secure Software Development Attestation Common Form, naming the NIST SSDF (SP 800-218) practice ID and the form section behind each mark. It ships 14 rules across the four attestation sections. On the bundled AI-written deploy workflow it returns 8 findings; on the hardened release workflow it returns 0.
Who is this for?
Software vendors that sell to United States federal agencies, and the platform or release engineers who own their GitHub Actions pipelines. Under OMB M-22-18 and M-23-16 an agency may use your software only after a chief executive or a designated employee signs the attestation form. Those engineers are the people who have to produce the evidence under that signature.
Why can't I just ask a chatbot to harden my workflow?
A general assistant rewrites YAML confidently but does not tell you which attestation section is still empty afterwards. It will pin one action and leave provenance and SBOM missing, and it gives you no line number tied to PS.3.1 that an auditor can follow. This audit is a fixed, readable rule table, not a generated opinion that changes between prompts.
What is free and what does the full version add?
Free: audit the workflow file you have open and list every attestation gap with its practice ID and form section, all 14 rules, all four sections. That job finishes on its own. The full version changes the scope: it audits every workflow in the repository at once and exports one dated evidence table mapped to all four attestation sections.
What would this cost done by hand?
A United States application-security contractor bills roughly 150 to 250 an hour to review a release pipeline, re-pin actions to commit SHAs and map each control back to an SSDF practice. The full version is 29 once, one licence key per person or team seat,. The free audit costs nothing.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. SSDF Attestation Audit for GitHub Actions checks the file you open against 14 rules from a rule set dated 2026-09-21, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.