NIST NCCoE DevSecOps Live Document: What Does the Attestation Attest?

Date: August 29, 2026 · Author: Dmitrii Zatona  · Updated: September 29, 2026

TL;DR

• A 2023 Federal Register notice invited companies into a NIST NCCoE DevSecOps demonstration whose objective is artifacts that support an organization’s self-attestation; the word “verification” does not occur in it (Sections 1 and 2).
• The project’s live document names signatures, provenance, attestations, and evidence passed between pipeline phases, but selects no model that turns them into one claim a downstream party can check (Section 2).
• Its only attestation definition gives SLSA as an example, with no statement format or digest-based subject binding, and no identity policy stands behind the signatures its Build phase verifies (Section 4).
• The released in-toto v1.0.0 layout composes signed per-step evidence into one verdict; neither NCCoE text selects it or any other signed cross-stage policy (Sections 4 and 8).
• The September 24, 2026 update adds a second example implementation that fills the four component rows left empty in the first, plus functional demonstrations, and leaves the three decisions open (Sections 4 and 7).
• The article does not measure the project against an obligation or claim that no organization has built such a composition; it claims only that the texts reviewed do not select one (Section 8).

The NIST NCCoE DevSecOps project is a demonstration, not a mandate. Its 2023 Federal Register notice invited companies to show how an organization can generate artifacts “as a byproduct of its DevSecOps practices” to support its own self-attestation of secure development. The project’s guidance is now a web-hosted live document, last updated on September 24, 2026. Its vocabulary covers signatures, provenance, attestations, and evidence passed downstream between pipeline phases. What the texts do not select is the model that would make those words one checkable claim: what an attestation binds to, whose keys sign the technical evidence, and who signs the policy under which per-stage evidence composes into one verdict.

A released mechanism for the last of those exists in the in-toto  layout, so the open point is a missing choice among existing options. This article takes the texts apart into a ladder of four binding constructs and three design decisions that the documents leave with the organization implementing them. The notice’s own verbs are “demonstrate,” “strive to demonstrate,” and “inform,” and nothing below measures the project against an obligation it never took on.

1. What was published

The record starts with Federal Register notice 2023-10221  (88 FR 30947), published May 15, 2023. It invited letters of interest for the “Software Supply Chain and DevOps Security Practices” project, which is the entry mechanism the notice states. On March 6, 2025, NIST announced  nine technology collaborators. On July 30, 2025, the project published NIST SP 1800-44A , an 18-page “High-Level Document, Volume A” marked FIRST PRELIMINARY DRAFT. The NCCoE’s project portfolio  of January 21, 2026, marked DRAFT on the first ten of its fourteen pages, lists the project as active.

On March 24, 2026, the CSRC record for SP 1800-44A  acquired the banner “Obsoleted on March 24, 2026.” The successor is a live document  at pages.nist.gov, built from the public GitHub repository usnistgov/nccoe-devsecops , whose March text is the launch commit 9c48916. CSRC catalogs it as an initial preliminary draft in the category Other, and its cover carries no SP number. NIST’s announcement  says the document “will be updated on a rolling basis.” A CSRC search for “1800-44” on September 29, 2026 lists only the withdrawn Volume A, with no volume B or C and no later SP-numbered iteration.

The first update came on September 24, 2026, as commit 4ac39f6. Its change log lists addressed public comments, an updated section on artificial intelligence, a mapping of the SSDF to the reference model, a second example implementation, functional demonstrations, and an SSDF analysis appendix.

The comment periods for the draft (July 30 to September 14, 2025) and for the March version (March 24 to April 24, 2026) are closed. A NIST news item of July 30, 2025 gave September 12 as the draft’s deadline; the CSRC record and the PDF’s front matter say September 14. The September version opened a third comment period, from September 24 to November 9, 2026.

On participation, the notice provides that “there may be continuing opportunity to participate even after initial activity commences.” It also commits NIST to announce on the project page when letters of interest are no longer accepted. That page returned HTTP 403 to automated retrieval on August 28 and again on September 29, 2026, so the closure status is not established here. The 2023 notice names Paul Watrobski as the contact, at [email protected]. The January 2026 portfolio names Alper Kerman and Michael Ogata, at the same address. The live document takes comments at [email protected], and no reviewed document names the person behind that address as of September 29, 2026.

This is the fifth teardown in a series; the previous one, FBI CJIS Data Mesh RFI: What Its Traceability Requirement Does Not Specify, found five choices that a data-mesh traceability sentence leaves unmade.

2. What the requirement says

The central sentence is the notice’s Project Objective, quoted in full because each part of its evidence vocabulary matters:

“The project intends to demonstrate how an organization can generate artifacts as a byproduct of its DevSecOps practices to support and inform the organization’s self-attestation and declaration of conformance to applicable NIST and industry-recommended practices for secure software development and cybersecurity supply chain risk management.”

The same sentence recurs under Project Activities with two changes. It opens with “Additionally,” and “the project will demonstrate” replaces “intends to demonstrate.”

Three observations follow from the wording. First, the artifacts are a byproduct: the practices come first, and the evidence falls out of them. Second, the artifacts support and inform a self-attestation and a declaration. They feed a claim the organization makes, and the sentence does not say that they are the claim or that anyone verifies them. Third, the word “verification” occurs nowhere in the notice. Its vocabulary is “self-attestation,” “declaration of conformance,” “security and compliance artifacts,” and “assurance of management of identified risks.” The notice names the purpose of the artifacts and leaves their binding unstated: what a given artifact is about, and who would check it against what.

The March 2026 live document supplies the technical vocabulary. Its Build-phase narrative has the most specific verification sentence in the document. Build-time analysis “examines the provenance of source code and software dependencies” and verifies “cryptographic signatures generated by people and services” for authorization and integrity. The Operate-phase narrative states the delivery end. Automated processes give stakeholders “documented evidence of application and system component integrity, SBOM, and attestations.”

The Appendix B glossary holds the document’s only definition of an attestation. The entry for the Attestation Signing and Verification Tool says the tool generates and verifies “the digitally signed artifact (e.g., SLSA)” that provides provenance information. The example points to SLSA , a specification of supply-chain security levels whose provenance format Section 4.1 reads against this definition. The listed ingredients are “artifacts produced, processes, and any included dependencies,” plus information captured during generation, such as the CI/CD components used and source code changes.

Between these passages, the CI/CD section describes movement. Artifacts and evidence generated during the build are “passed downstream to the next phases of automation.” The section’s fullest statement of use reads: “Automated processes and teams review evidence generated in each phase.” That evidence is used to verify changes. The concept of verification is therefore present: evidence is reviewed, control gates sit between stages, and the component lists name a policy-verification tool.

What the passages do not select, alone or together, is a model. There is no schema for the attestation and its subject. There is no identity policy for the “people and services” whose signatures get verified. And there is no composition rule under which evidence passed downstream becomes one claim a downstream party can check. Section 4 takes these three decisions one at a time.

3. The binding ladder

The evidence vocabulary of the two texts (declaration, signature, provenance, attestation, evidence passed downstream) spans four binding constructs. They differ in what is bound, who signs, and who can check. The ladder below is assembled from the cited specifications as an organizing abstraction; no reviewed document draws it.

The diagram’s four rungs and two layers are an inference from the CISA form, the SLSA v1.2 provenance format, and the in-toto specification v1.0.0, not something the NCCoE texts define.

Two layers in this ladder differ in kind, and the texts read clearly only when they are kept apart. The top rung is an organizational declaration: a human signature binding a company to statements about its practices. The lower three rungs are technical evidence: cryptographic bindings between bytes, keys, and process metadata, checkable by machine. Which person, service, or role a key stands for is still an assertion that a verifier accepts only under a chosen identity policy.

The CISA form belongs to the first kind. It requires no technical artifacts: its attachments field specifies no content beyond a title and a description for each addendum, and the form maps its practice statements to SSDF v1.1 practices rather than to any evidence format. The notice’s objective sentence sits between the layers: technical artifacts that support and inform an organizational self-attestation and declaration.

The live document’s vocabulary also moves between rungs. Signatures by “people and services” belong to rung 2, an attestation given as “e.g., SLSA” to rung 3, and evidence reviewed at gates and passed downstream to the territory of rung 4. The document names component categories for rungs 2 and 3 (an artifact-signing tool, an attestation tool, a provenance tool), each with a high-level verify function. It does not state the format, the signer policy, or the verification criteria and root of trust behind each category, and it has no composition model for the fourth rung. The notice’s objective does not ask the document to make these choices, and they remain the choices a reader implementing the model would have to make.

4. Three unchosen design decisions

Each decision below is stated against the March 2026 text, with the document’s own words as the boundary.

4.1 What the attestation binds

The Appendix B definition quoted in Section 2 is the whole of what the document says an attestation is. Read against the released formats, it leaves the subject side of the binding open.

In the mechanism the definition points to, a SLSA v1.2  provenance attestation, the binding is explicit. The attestation is an in-toto Statement whose subject field carries the digests of the artifacts it is about. The predicate ties those subjects to builder.id, buildType, and external parameters, complete at Build L3, and to resolved dependencies where that optional field is populated.

The glossary definition names ingredients but specifies no statement format, no envelope, and no digest-based subject binding. SLSA appears as “e.g.,” an example rather than a selection. The definition also calls the attestation “the digitally signed artifact,” so the attestation is the artifact. The released formats distinguish a signed statement about an artifact from the artifact itself, and the text does not say whether its phrasing is shorthand or a model.

An implementing organization must therefore decide which statement format, which envelope, and which subject-binding discipline to use. Every verification property that relates evidence to a particular artifact depends on that decision. The March text also deferred its SSDF mapping, stating that future versions would “document and justify the concrete connections between technologies and activities.”

4.2 Whose keys sign the evidence

The Build-phase sentence verifies “cryptographic signatures generated by people and services” for proper authorization and overall integrity. Authorization implies a policy: which people and which services, holding which keys, count as authorized. The text does not name them for the signatures its Build phase verifies.

The NCCoE-authored text defines no signer-identity model. It has no key-holding policy, no role catalog, and no statement of how proper authorization is determined. Machinery of that kind appears only in Appendix C (Appendix D in the September version), the collaborator-authored product descriptions of key custody in hardware modules and workload identity issuance. Those are vendor texts describing products, not the project’s model. In Example Implementation 1, the HSM row and the Runtime Signature Verification Tool row are both marked N/A, for the reason quoted in Section 7.

The layer distinction from Section 3 matters here. The U.S. federal record has fully specified one signature: the CISA form’s, where the signer is the CEO or a designee with authority to bind the corporation. It is tempting to read that as the missing identity model. It is the organizational rung instead, a human signature over practice statements, with no machine-verifiable evidence required behind it.

The unchosen decision sits on the technical rungs. The text does not define the identity regime behind the signatures its Build phase verifies. Whatever attestation mechanism an implementation selects under Section 4.1, the signer-identity question arises again, and the reviewed text does not answer it. No reviewed document connects the organizational signature to the technical ones in either direction.

4.3 Who signs the composition, and who checks it

The released mechanism comes first, because it shows the choice is available. The in-toto specification v1.0.0 , dated June 2, 2023, defines end-to-end composition of per-step supply-chain evidence. Its layout is a signed policy object. The project owner signs it, and that signing key is the verifier’s root of trust.

The layout enumerates the steps of a supply chain, the functionaries authorized to perform each step, signature thresholds, and artifact rules that chain the products of one step to the materials of the next. Functionaries sign per-step link metadata. A verifier checks the layout signature, the per-step signatures and thresholds, and the artifact rules, and returns one end-to-end pass or fail.

The boundaries are released too. The v1.0.0 layout semantics are defined over link metadata, meaning a command plus material and product hashes. Composition over typed attestation predicates, such as a SLSA provenance in one step and a test result in another, is the subject of ITE-10 , which has the status Draft as of September 29, 2026 and is not part of the tagged specification.

Against that background, the live document’s composition language reads differently. Evidence is generated throughout the pipeline stages and “passed downstream to the next phases of automation.” Teams review the evidence generated in each phase, and control gates apply before changes proceed. The concept of cross-stage verification is present. The text does not choose a signed policy object, in-toto or any other, and it names no verifier role, root of trust, policy format, or conformance procedure for checking the evidence of all stages as one claim.

The nearest named component is the CI/CD Execution, Test and Security Policy Verification Tool. The glossary defines it as verifying “that actions and results meet the CI/CD and test and security policies.” That definition works at the level of pipeline policies, and the text does not say whether the tool would also verify the accumulated evidence bundle as one claim. In Example Implementation 1 the component’s row is N/A. The names in-toto, Sigstore, cosign, SCITT, and CycloneDX do not occur anywhere in the March text.

For the implementing reader the consequence is concrete. The pipeline hands stakeholders “documented evidence of application and system component integrity, SBOM, and attestations.” The reviewed text does not decide how a recipient of that bundle could verify it as a whole.

The diagram’s placement of the three decisions on the phase sequence is an inference from the Build, Operate, and CI/CD passages and the Appendix B glossary, not something the live document defines.

4.4 What changed between the draft and the March version

The withdrawn draft and the March 2026 live document differ in their integrity language, in both directions. The table records the textual differences without interpretation. The withdrawn draft is the July 2025 SP 1800-44A, preserved under a withdrawal notice at its original URL.

The table is the record. The three decisions of Sections 4.1 to 4.3 concern language that, as the table shows, first appears in the March 2026 version.

4.5 The September 2026 update

Apart from copy edits, the September 24, 2026 text keeps the passages that Sections 2 to 4.3 quote, with three substantive changes. The Build-phase summary now adds that the build processes create provenance and attestation information “signed with trusted certificates.” Control gates now provide “the necessary conditions (success or failure)” as well as feedback. And the future-mapping sentence of Section 4.1 gives way to a new Section 3 that maps SSDF practices to the reference model, with the analysis in a new Appendix C; the collaborator descriptions move to Appendix D. The glossary’s attestation entry still reads “the digitally signed artifact (e.g., SLSA).”

The larger addition is evidence of use. A second example implementation, E2, builds on the Azure foundation of E1 with components from GitLab, CyberArk, NextLabs, Resilience Cyber Security, and other collaborators. In E2 all four rows that are N/A in E1 are filled: the attestation tool, the runtime signature verification tool, the HSM, and the CI/CD policy-verification tool. Its functional demonstration results report a Resilience tool generating and verifying SLSA provenance records with signing material from CyberArk Machine Identity Security. They also report an attestation store that helps identify attestations failing policy requirements, and container signing with Sigstore’s cosign under an identity issued by GitLab CI.

These are demonstrated instances of rungs 2 and 3, and of policy checks over stored attestations. They do not change the three findings for the NCCoE-authored model. The scenario tables state expected outcomes per artifact, such as a SLSA attestation “successfully created.” A gate’s success or failure condition is a decision at one gate. “Trusted certificates” names a credential type, not a policy stating whose certificates count for which step. A search of the September source files on September 29, 2026 found no occurrence of in-toto, SCITT, or a layout, and no passage defining a signed policy that checks the evidence of all phases as one claim.

5. Scale

The figures below come from agency documents and peer-reviewed measurement. They describe the ecosystems in which software signing, dependency intake, and attestation collection operate. Each is given with its own attribution, and no arithmetic is performed on top of them.

Signing adoption has been measured directly. Schorlemmer et al. (IEEE S&P 2024)  studied four public registries across 2023. Maven Central, the only one of the four that mandates signing, had 97.1% of artifacts signed in that period. Docker Hub had 1.0% of tags signed, PyPI 0.2% of artifacts, and Hugging Face 0.1%. Of the signatures that did exist, the paper reports 24.0% invalid on Maven Central, 53.1% on PyPI, and 76.1% on Hugging Face, where 296 of 1.24K signed artifacts (23.9%) were valid.

The trust surface behind one artifact has been measured too. Zimmermann et al. , published at USENIX Security 2019, measured the 2018 npm graph. Installing an average npm package introduces implicit trust in “79 third-party packages and 39 maintainers.”

Incident response has an agency-scale figure. The Cyber Safety Review Board’s 2022 Log4j report  records that one federal cabinet department reported 33,000 hours of Log4j vulnerability response. The report describes a worldwide effort to identify and mitigate hundreds of millions of potentially affected devices. Citing Sonatype data, it puts Log4j at 28.6 million downloads in a three-month period between August and November 2021.

Provenance publication is smaller still. Schorlemmer et al. (IEEE Security & Privacy 23(2), 2025)  searched GitHub repositories by keyword. They found 896 repositories publishing npm packages with the --provenance flag, against 26,255 carrying the workflow indicator. The paper frames its study by noting that “concrete measurements of adoption of these technologies are lacking.”

The policy machinery reports progress rather than volumes. GAO-24-106343  (April 18, 2024) reports that agencies “fully completed 49” of the 55 leadership and oversight requirements of Executive Order 14028 . Its row for enhancing software supply chain security shows 16 fully complete and 1 partially complete. CISA’s Repository for Software Attestation and Artifacts  went live on March 18, 2024 as the place where software producers upload their attestation forms. As of September 29, 2026, no published count of collected attestations appears in the agency and peer-reviewed sources reviewed here.

None of these figures measures the NCCoE project or its example implementations, none establishes a cause for any other, and no reviewed source connects any of them to the decisions in Section 4.

6. The attestation regime’s document chain

The document chain around the project is stated here with only the connections the documents themselves draw. Executive Order 14028, Section 4(e), is the root that the attestation regime cites. The CISA attestation form  cites OMB memorandum M-22-18 , as amended by M-23-16 , as its authority. The form sets out the requirements a producer must meet and attest to before covered software may be used by federal agencies. It also provides a fallback: an agency that cannot obtain a completed attestation may still use the software if the producer identifies the practices it cannot attest to, documents its mitigations, and submits a plan of actions and milestones (POA&M).

The form, OMB control number 1670-0052, was released on March 11, 2024 with an expiration date of March 31, 2027. Its signer is the CEO or a designee. It requires no technical artifacts. The form states that all of its fields must be completed, but its attachments field specifies no content beyond a title and a description for each addendum. An assessment by a third-party assessor organization, FedRAMP-certified or approved by an agency official, is an alternative path, attached to the form in place of the producer’s signature. Its appendix maps each of its four practice statements to subsections of Section 4(e) and to specific SSDF v1.1 practices.

NIST SP 800-218 v1.1  (February 2022) is the SSDF the form points into. Its practices are stated as outcomes, and several name integrity machinery without mandating a format for it. PS.2.1 makes integrity verification information available to acquirers, PS.3.2 keeps provenance data for release components, and PO.3 asks for toolchains that document and demonstrate the use of the practices.

The notice draws its own link to that framework. It asks respondents to support a demonstration consistent with “the most recent version of” SP 800-161 , the Cybersecurity Framework , and SP 800-218. The project’s later records add one more citation. Both the CSRC record for the draft and the January 2026 portfolio place the project under Executive Order 14306 . The portfolio states that, per that order, the project is demonstrating practices aligned with NIST’s SSDF. The March text deferred the mapping between its technologies and the SSDF, and the September text supplies it as Section 3. No causal claims beyond these documented references are made here.

7. Who would build it

The March 6, 2025 announcement names nine collaborators: Black Duck, Dell Technologies, DigiCert, Endor Labs, GitLab, Google, IBM, Microsoft, and Scribe Security. The January 21, 2026 portfolio lists fourteen in its appendix of project collaborators, one of the four pages without the DRAFT marking. It adds AMI, CyberArk, NextLabs, Palo Alto Networks, and Sagittal AI. The same fourteen appear as author affiliations on the March live document and as the sections of its Appendix C. The growth is consistent with the notice’s continuing-opportunity clause, and no reviewed primary source establishes the join dates of the five later collaborators.

The September version lists fourteen collaborators with Resilience Cyber Security in place of Scribe Security. Its E2 section describes Resilience as “formerly Scribe Security,” and its cover lists under Resilience the two authors that the March cover listed under Scribe.

No reviewed document distributes roles across a composition model. The one build documented in March, Example Implementation 1, is a table fact. Its artifact-signing rows and SBOM rows name collaborator products and an open-source signing project. Four component rows are N/A in every phase where they appear: the Attestation Signing and Verification Tool, the Runtime Signature Verification Tool, the HSM, and the CI/CD policy-verification tool.

The March document gives one pooled reason for N/A rows: “the product being unavailable from the collaborator or project time constraints.” It assigns neither cause to any specific row or collaborator. It also states that subsequent implementations “will be introduced and numbered sequentially in future publications.” The September text does that with E2, whose rows for the same four components name products from CyberArk, Resilience Cyber Security, GitLab, and NextLabs. Neither table has a row for a cross-stage policy role.

8. What does not exist as a standard

The survey below goes version by version: what each released specification defines, and the specific element it does not.

The positive result comes first. Within this survey, the in-toto specification v1.0.0 is the released mechanism that defines an externally verifiable composition of per-step evidence: a project owner signs the policy, functionaries sign the steps, and a verifier returns one verdict.

The bounded negation is its boundary. The released specifications reviewed here, as of September 29, 2026, are SLSA v1.2, in-toto v1.0.0 and its Attestation Framework v1.2.0, SCITT RFC 9943 with RFC 9942, SP 800-204D, SSDF v1.1 and 218A, the CISA form, SPDX 3.0.1, CycloneDX 1.7, and TUF v1.0.36. None of them defines a standardized composition of an arbitrary set of typed attestations that the live document’s reader could adopt without an additional design choice. in-toto defines it for link metadata in released form, and ITE-10 extends it to typed predicates as a Draft.

The consequence for the NCCoE texts is narrow. They name the properties and, among the released options this survey lists, do not select one. What an attestation binds, whose keys sign it, and under whose policy the stages compose remain design choices the implementing organization makes for itself. The September 2026 update shows products that sign, attest, and check policies in two example implementations, and it leaves those three choices where the March text left them.

The objective sentence of 2023 asked for artifacts, generated as a byproduct, that support and inform an attestation. In the NCCoE texts reviewed here, the reader decides what the attestation attests and against whose signed policy the answer is verified. This article does not claim that the project has fallen short of an obligation, or that no organization has built such a composition; the demonstrations may show more than their text states.

I work on verifiable data structures for evidence chains in exactly this area, and that work is separate from this analysis. More write-ups are on the engineering blog.

If a software supply chain has to hand its customers attestations they can verify as one claim, designing the signed policy and the verifier behind it is contract work I take on.