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

Date: August 29, 2026 · Author: Dmitrii Zatona 

In May 2023, NIST’s National Cybersecurity Center of Excellence published a Federal Register notice inviting companies into a DevSecOps demonstration project whose objective sentence is about evidence: to show 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.” Three years on, the project’s guidance text — an SP 1800-series preliminary draft, withdrawn in March 2026 and replaced by a web-hosted “live document” — names the properties it discusses for such artifacts: integrity of artifacts, provenance, attestations, evidence “passed downstream” through the pipeline. What neither text selects is the machine-verifiable model that would make those properties one checkable claim: what exactly an attestation binds to, whose keys sign the technical evidence, and who signs the policy under which per-stage evidence composes into a single verdict. A released mechanism for that last step exists on the shelf — the in-toto layout — which makes the interesting question the absence of a choice, not the absence of an option. This article reads the two texts closely, lays out the binding ladder their vocabulary spans, and identifies the three design decisions the documents leave with the organization that would implement what they describe.

One caveat governs everything below. This is a demonstration project, not a mandate: the notice’s own verbs are “demonstrate,” “strive to demonstrate,” and “inform,” and the live document is a preliminary draft that promises its SSDF mapping in future updates. Nothing here measures the project against an obligation it never took on. The subject is what the published texts choose, what they leave open, and what an implementing reader would have to decide.

1. What was published

The record is a chain with two published anchors. Federal Register notice 2023-10221  (88 FR 30947, published May 15, 2023) invited letters of interest for the “Software Supply Chain and DevOps Security Practices” project — the notice’s stated entry mechanism. 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 January 21, 2026 project portfolio  — itself marked DRAFT on every page — lists the project as active with fourteen collaborators. On March 24, 2026, the CSRC record for SP 1800-44A acquired the banner “Obsoleted on March 24, 2026,” and the successor appeared: a Live Document  at pages.nist.gov, built from a public GitHub repository (usnistgov/nccoe-devsecops , launch commit 9c48916), catalogued on CSRC as “Other (Initial Preliminary Draft)” and described in NIST’s announcement as a document that “will be updated on a rolling basis.” Its cover carries no SP number. A CSRC search for “1800-44” on August 29, 2026 returns exactly one record — the withdrawn Volume A; no volume B or C and no later SP-numbered iteration of 1800-44 appears on CSRC as of that date.

The comment periods are closed at both ends: July 30 through September 14, 2025 for the draft (the publication record and the PDF’s own front matter say September 14; a NIST news article of July 30, 2025 says “NIST is soliciting comments from the public on the draft until Sept. 12” — the two dates are both NIST’s, and the publication record’s is the one this article uses), and March 24 through April 24, 2026 for the live document. Since launch day, the live document’s Appendix D change log records no update after March 2026, and the repository’s post-launch activity consists of automated dependency updates, with no content change recorded; the text read for this article is the text published on March 24.

On participation status: the notice provides that “there may be continuing opportunity to participate even after initial activity commences,” and commits NIST to announce the close of letter-of-interest acceptance on the project page. No closure announcement was confirmed in the corpus reviewed for this article — a bounded statement, because the designated venue itself was inaccessible to direct retrieval on August 28, 2026 (Cloudflare 403 on both the original and the renamed project URL; the one archived snapshot found was rate-limited at HTTP 429). Contacts are a matter of dated records, not currency: the 2023 notice names Paul Watrobski as the further-information contact; the January 2026 portfolio names Alper Kerman and Michael Ogata as POCs, with the shared address devsecops-nist@nist.gov; the live document’s feedback channel is nccoe-devsecops@list.nist.gov. No reviewed document states who the route contact is today.

Method note: this is the fifth teardown in a series — the first  asked whether a named primitive exists on the shelf, the second  which assurance tier a notice’s words select, the third  where a platform boundary sits, the fourth  which operational choices a traceability sentence leaves open; this one asks who chooses the signed cross-stage policy, and how conformance to it is checked.

2. What the requirement says

The load-bearing sentence appears in the notice’s Project Objective, and it is quoted here in full because every word 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 in Project Activities with two changes — it opens with “Additionally,” and “intends to demonstrate” becomes “the project will demonstrate.” Three observations before going further. First, the artifacts are a byproduct: the practices come first, the evidence falls out of them. Second, the artifacts support and inform a self-attestation and a declaration — they feed a claim made by the organization; the sentence does not say the artifacts are the claim or that anyone verifies them. Third, the word “verification” does not occur anywhere in the notice; its vocabulary is “self-attestation,” “declaration of conformance,” “security and compliance artifacts,” and “assurance of management of identified risks.” That is the underdetermination this article is about, visible already in the first paragraph of the requirement: the notice names the artifacts’ purpose but not their binding — what a given artifact is about, cryptographically or otherwise, and who would check it against what.

The March 2026 live document is where the technical vocabulary arrives. Its Build-phase narrative contains the document’s most specific verification sentence: build-time analysis, alongside secret detection, “examines the provenance of source code and software dependencies” and verifies “cryptographic signatures generated by people and services” to ensure authorization and overall integrity. Its Operate-phase narrative states the delivery end: automated processes provide stakeholders with “documented evidence of application and system component integrity, SBOM, and attestations.” And its Appendix B glossary contains the document’s only definition of what an attestation is — the entry for the “Attestation Signing and Verification Tool,” which generates and verifies “the digitally signed artifact (e.g., SLSA)” providing provenance information; the entry’s ingredient list is “artifacts produced, processes, and any included dependencies,” plus information captured during the artifact’s generation, such as CI/CD components used and source code changes.

Between these passages, the CI/CD section describes movement: artifacts and evidence are generated in the continuous build process and “passed downstream to the next phases of automation”; in the section’s fullest statement of use, “automated processes and teams review evidence generated in each phase,” and that evidence is used to verify the requirements of source code, software asset, or configuration changes. So the concept of verification is present in the document — reviewed evidence, gates applied between stages, a policy-verification tool named in its component lists. What the passages do not select, individually or together, is a model: a schema for the attestation and its subject, an identity policy for the “people and services” whose signatures get verified, and a composition rule under which the evidence “passed downstream” becomes one claim a downstream party can check. Three unchosen decisions; Section 4 takes them one at a time.

A note on standing and quotation. The Federal Register notice is a U.S. Government work in the public domain and is block-quoted on that basis. The live document’s author list carries fourteen collaborator affiliations, and its repository’s licensing statement addresses NIST-developed software rather than the document’s prose; absent a rights notice specific to the text, this article confines live-document quotation to short attributed fragments. Its Appendix C consists of collaborator-authored product descriptions; those are paraphrased throughout.

3. The binding ladder

The two documents’ evidence vocabulary — declaration, signature, provenance, attestation, evidence passed downstream — spans four distinct binding constructs. They differ in what is bound, who signs, and who can check. The ladder below is this article’s organizing abstraction, assembled from the cited specifications; no reviewed document draws it.

Two layers in this ladder are different in kind, and keeping them apart is the precondition for reading the project’s texts precisely. 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 an assertion a verifier accepts only under a chosen identity policy. The CISA form is the first kind — it requires no technical artifacts (an attachments field is optional), and it maps its practice statements to SSDF v1.1 practices rather than to any evidence format. The Federal Register notice’s objective sentence lives exactly between the layers: artifacts (technical) that support and inform a self-attestation and declaration (organizational). The live document’s vocabulary likewise moves between rungs — signatures by “people and services” (rung 2), an attestation “e.g., SLSA” (rung 3), evidence reviewed at gates and passed downstream (rung 4’s territory) — and it does name technical component categories (an artifact-signing tool, an attestation tool, a provenance tool — the territory of rungs 2 and 3), each described with a high-level verify function. What it does not state is the format, the signer policy, and the verification criteria and root of trust behind each category, or a composition model for the fourth rung. That is not a defect of a demonstration text; it is precisely the set of choices a reader implementing the model would have to make. The next section itemizes them.

4. Three unchosen design decisions

4.1 What the attestation binds

The live document’s Appendix B definition, quoted in Section 2, is the whole of what the document says an attestation is. Read against the shelf, it leaves the subject side of the binding open. In the released mechanism the definition gestures at — a SLSA v1.2 provenance attestation, an in-toto Statement carrying the SLSA provenance predicate — the binding is explicit: the Statement’s subject field carries the digests of the artifacts the attestation is about, and the predicate ties those subjects to builder.id, buildType, external parameters — complete at Build L3 — and, where populated, resolved dependencies (an optional field). The glossary definition names the ingredients (“artifacts produced, processes, and any included dependencies”) but specifies no statement format, no envelope, no digest-based subject binding; SLSA appears as “e.g.”, an example rather than a selection. The definition also reads as “the digitally signed artifact” — the attestation is the artifact — where the shelf formats distinguish the signed statement about an artifact from the artifact itself; whether that phrasing is shorthand or a model is something the text does not say. An implementing organization must therefore decide: which statement format, which envelope, which subject-binding discipline — and every verification property that relates evidence to a particular artifact depends on that decision. Separately, the document defers its SSDF mapping: it states that future versions will “document and justify the concrete connections between technologies and activities” in the example implementations and the SSDF proper.

4.2 Whose keys sign the evidence

The Build-phase sentence verifies “cryptographic signatures generated by people and services to ensure proper authorization and overall integrity.” Authorization implies a policy: which people and which services, holding which keys, count as properly authorized — and for the signatures the Build phase verifies, the text does not say. The NCCoE-authored text does not define a signer-identity model — no key-holding policy, no role catalog, no statement of how “proper authorization” is determined. Machinery of that kind appears in the document only in Appendix C, the collaborator-authored product descriptions (key custody in hardware modules, workload identity issuance), which are vendor text describing products, not the project’s model; and in Example Implementation 1, the HSM row and the Runtime Signature Verification Tool row are both marked N/A, with the document’s stated reason quoted in Section 7.

The layer distinction from Section 3 does the work here. There is a signature the U.S. federal record has fully specified: the CISA form’s, where the signer is the CEO or designee with authority to bind the corporation. It is tempting to read that as the missing identity model, and it is not — it is the organizational rung, 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 — and for whatever attestation mechanism an implementation selects under the decision of Section 4.1, the signer-identity question arises again, unanswered by the reviewed text. No reviewed document connects the organizational signature to the technical ones in either direction.

4.3 Who signs the composition — and who checks it

This is the decision the series test in Section 1 named, and it is worth stating what exists before stating what is absent. A released, end-to-end composition mechanism for per-step supply chain evidence has been on the shelf since 2023: the in-toto specification v1.0.0. Its layout is a signed policy object — signed by the project owner, whose key is the verifier’s root of trust — enumerating 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 a single end-to-end pass/fail. The boundaries are equally released: v1.0.0’s layout semantics are defined over link metadata — command plus material/product hashes — and composition over typed attestation predicates (a SLSA provenance here, a test-result attestation there) is the subject of ITE-10, which is a Draft as of August 29, 2026, not part of the tagged specification.

Against that background, read the live document’s composition language again. Evidence is “generated … throughout the various pipeline stages” and “passed downstream to the next phases of automation”; “Automated processes and teams review evidence generated in each phase”; control gates “are applied before software changes are permitted to proceed.” The concept of cross-stage verification is present. What the text does not choose: a signed policy object (in-toto layout or any other), a verifier role, a root of trust, a policy format, or a conformance procedure by which the accumulated evidence of all stages is checked as one claim. The nearest named component — the “CI/CD Execution, Test and Security Policy Verification Tool,” defined in the glossary as verifying “that actions and results meet the CI/CD and test and security policies” — is defined at the level of pipeline policies; whether it would also verify the accumulated evidence bundle as one claim is not something the text states. (In Example Implementation 1 that component’s row is N/A, with the document’s stated reason — a separate table fact.) The names in-toto, Sigstore, cosign, SCITT, and CycloneDX do not occur anywhere in the live document’s text. For the implementing reader, the consequence is concrete: the document’s pipeline hands its stakeholders “documented evidence of … integrity, SBOM, and attestations,” and the model by which a recipient of that bundle could verify it as a whole is a design decision the reviewed text does not make.

4.4 What changed between the versions

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 ipd, preserved under a withdrawal notice at its original URL.

The table is the record; the three decisions of Sections 4.1–4.3 concern language that, as the table shows, is present in the March 2026 version.

5. Scale

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

Signing adoption, measured. Schorlemmer et al. (IEEE S&P 2024) , measuring four public registries across 2023: Maven Central — the study’s only registry with mandated signing — had “97.1% of artifacts signed” in that period; Docker Hub had 1.0% of tags signed; PyPI 0.2% and Hugging Face 0.1% of artifacts. Of the signatures that did exist, the paper reports fractions failing verification: 24.0% invalid on Maven Central, 53.1% on PyPI, 76.1% on Hugging Face — on the latter, 296 of 1.24K signed artifacts (23.9%) were valid.

The trust surface per artifact, measured. Zimmermann et al. (USENIX Security 2019) , measuring the 2018 npm graph: installing an average npm package introduces implicit trust on “79 third-party packages and 39 maintainers.”

Incident response, at agency scale. The Cyber Safety Review Board’s 2022 Log4j report  records that “one federal cabinet department reported dedicating 33,000 hours to Log4j vulnerability response,” and describes a worldwide response effort to identify and mitigate what the report counts in the hundreds of millions of potentially affected devices. The report — citing Sonatype data — puts Log4j at 28.6 million downloads in the three months before disclosure.

Provenance publication, measured. Schorlemmer et al. (IEEE Security & Privacy 23(2), 2025) , from a keyword search of GitHub repositories: 896 repositories publishing npm packages with the --provenance flag, against 26,255 carrying the workflow indicator — the paper’s framing being that “concrete measurements of adoption of these technologies are lacking.”

The policy machinery reports progress, not volumes. GAO-24-106343  (April 2024) reports that of EO 14028’s 55 leadership and oversight requirements, agencies “fully completed 49,” and its supply-chain row — “Enhancing Software Supply Chain Security” — shows 16 fully complete and 1 partially complete as of March 2024. CISA’s Repository for Software Attestation and Artifacts  went live in March 2024 as the government-wide collection point for the Section 6 form; no published count of collected attestations was found in the agency and peer-reviewed sources reviewed for this article.

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

6. The record

The document chain around the project, stated with only the connections the documents themselves draw. Executive Order 14028’s Section 4e is the root the attestation regime cites. OMB M-22-18, as amended by M-23-16, made collection of producer attestations a condition for federal use of covered software. CISA’s Secure Software Development Attestation Form (OMB control number 1670-0052, finalized March 11, 2024, expiring March 31, 2027) is the instrument: its appendix maps each of its four practice statements to EO 14028 §4e subsections and to specific SSDF v1.1 practices, its signer is the CEO or designee, and it requires no technical artifacts — an optional attachments field, and a third-party FedRAMP 3PAO assessment as an alternative path. NIST SP 800-218 v1.1 (February 2022) is the SSDF the form points into — outcome-oriented practices, several of which name integrity machinery (PS.2.1 release-integrity verification, PS.3.2 provenance data for components, PO.3 toolchain evidence) without mandating any format for it. The Federal Register notice, for its part, requires letter-of-interest respondents to support demonstration “consistent with the most recent version of” SP 800-161, the Cybersecurity Framework, and SSDF SP 800-218 — that is the link the notice itself draws to the framework the form attests against. The project’s current records add one more citation: both the CSRC announcement and the January 2026 portfolio place the project under Executive Order 14306 (“Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity…”), the portfolio stating the project “is demonstrating secure software development practices aligned with NIST’s SSDF” per that order. Where the mapping between the project’s artifacts and the SSDF will land is stated by the live document as future work, quoted in Section 4.1. 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 — with its DRAFT marking noted — lists fourteen, adding AMI, CyberArk, NextLabs, Palo Alto Networks, and Sagittal AI; the same fourteen appear as author affiliations on the live document and as sections C.1 through C.14 of its Appendix C. The growth is consistent with the notice’s continuing-opportunity clause; the join dates of the five later collaborators are not established by any reviewed primary source.

What no reviewed document does is distribute roles, and this article does not either. The one build documented so far, Example Implementation 1, is a table fact: its artifact-signing rows and SBOM rows are populated with named collaborator products and an open-source signing project, while 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 — with the document’s stated reason: N/A products were not included due to “the product being unavailable from the collaborator or project time constraints” at the NCCoE — a pooled explanation; the document assigns neither cause to any specific row or collaborator. The document states that subsequent implementations “will be introduced and numbered sequentially in future publications.” Which collaborator would fill which row, and whether the N/A rows fill at all, is answered by no reviewed document.

8. What does not exist as a standard

The survey, 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 does define an externally verifiable composition of per-step evidence — a project owner signs the policy, functionaries sign the steps, a verifier returns one verdict. The bounded negation is its boundary: across the released specifications reviewed here — 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, TUF v1.0.36 — none defines a standardized composition of an arbitrary set of typed attestations that the live document’s reader could adopt without making an additional design choice; in-toto defines it for link metadata in released form, with typed-predicate composition in ITE-10, a Draft as of August 29, 2026. The consequence for the two NCCoE texts is narrow and precise: 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. I work on verifiable data structures for evidence chains in exactly this area, and that work is separate from this analysis.

The sentence has been on the page since May 2023: artifacts, generated as a byproduct, to support and inform an attestation. The live document now names component categories a concrete implementation could use to support checking those artifacts; in its first example implementation, four verification-related component rows are marked N/A for the reasons the document states. What the attestation attests — and against whose signed policy the answer is verified — is, in the two NCCoE texts reviewed here, the reader’s decision.

If you are building a response to this document and the provenance or attestation piece has to be designed and built, that is contract work I take on.