A Federal Buyer Asked for a Software Attestation. Which Release Does It Cover?
Join the federal request, CISA attestation, product version and release evidence before scoping secure-software assurance work.
Signals to watch
- A federal buyer or prime contractor names a software product and requests a current CISA secure-software attestation before a release or award event
- The producer has a corporate secure-development policy but cannot map the attestation scope to the exact product and version being delivered
- An agency separately asks for an SBOM, assessment or other artifact and the sales record incorrectly treats it as part of the attestation form
A federal request for a secure-software attestation is scopeable only when it can be joined to one requesting agency, one producer, one product or product line, and the release being delivered. A corporate secure-development policy, a software bill of materials (SBOM) or an old form for another product is not that join. In August 2026, the agency’s current assurance policy and contract language also matter: CISA says agencies may use the common form rather than presenting it as an automatic requirement for every purchase.
That answer matters to a software-supply-chain assurance provider’s business-development lead monitoring authorised federal-contractor, software-vendor and security-assurance Telegram groups. The useful Signal is not “federal attestation needed.” It is a named product, a named buyer or prime, an unresolved version boundary and a dated release, proposal or acceptance event. Seeing it tomorrow may be too late to join the meeting where engineering, legal and the producer’s authorised signer decide what the statement covers.
The form is a statement about development practice, not a release certificate
The CISA Secure Software Development Attestation Form page says the form is based on National Institute of Standards and Technology Special Publication 800-218, the Secure Software Development Framework (SSDF) version 1.1. The common form lets a producer identify the software covered and attest to the listed secure-development practices or identify practices for which it cannot attest.
The form does not certify that a release has no vulnerability. It does not turn CISA into the assessor of the product. It also does not contain every artifact an agency might request. The statement, product scope and any supporting evidence must remain separate objects in the sales record.
The policy history explains why old messages can mislead. OMB M-22-18, issued 14 September 2022, directed agencies to obtain self-attestation for specified software and grounded that work in NIST secure-development practices. M-23-16, issued 9 June 2023, updated the implementation timetable and common-form process. CISA’s current page now points to OMB M-26-05: agencies must maintain software and hardware inventories and set assurance policies aligned to risk and mission; they may use resources created under M-22-18, including the form, and may contract for a current SBOM.
The practical rule for sales is simple: date the request. A 2023 memo explains the origin of the form. The current agency policy, solicitation, contract clause or acceptance instruction determines what the buyer asks for now.
Build the attestation-to-release join
Use one short record with six fields. It is smaller than an assessment checklist because its purpose is to locate the commercial task, not perform the assurance review.
- Requester: agency, contracting office or prime contractor, plus the source of the request.
- Producer: the legal entity responsible for the software, not merely the reseller sending the file.
- Covered software: product or product line as stated on the form.
- Release: exact version, build, delivery image or release family the buyer will receive.
- Statement: form date, attesting individual and the practices to which the producer attests or does not attest.
- Separate artifacts: SBOM, vulnerability report, third-party assessment, plan of action or other item expressly requested outside the form.
The fourth field is the original contribution of this article. The common form can cover a product or product line, while procurement and engineering operate on releases. Joining those layers prevents a valid-looking form from being attached to a version it never supported.
For example, a policy document may say that the company reviews source code and protects build environments. That is useful background. It does not establish which repository, build service, signing identity or release branch produced the application delivered to an agency. Conversely, a release-specific SBOM lists components but does not itself attest that the producer follows all practices named on the form.
Example: three files, still no covered release
Consider this illustrative composite, not a customer message:
“Prime needs the CISA attestation before Friday’s image cut. We have last year’s form and an SBOM from 4.8. Legal says policy hasn’t changed. Is that enough?”
The fragment contains a prime-contractor request, a Friday event, a previous form and an SBOM for version 4.8. It does not identify the agency, the product name on the old form, the release planned for Friday, the signer, whether the current request still uses the common form, or whether the SBOM corresponds to the delivery image.
Do not answer yes or no from the group. Write the join with blanks:
Requester: named prime, agency unconfirmed; producer: unconfirmed legal entity; covered software on prior form: not yet read; delivery release: unconfirmed; statement date and signer: not yet verified; separate artifact: SBOM labelled 4.8, relationship to Friday’s image unknown.
Now the service route becomes visible. If the old form covers the same product line but the evidence owner cannot connect it to the new release, the work may be release-evidence mapping. If the producer cannot make one of the statements, the common form includes a path for identifying that gap rather than hiding it. If the only missing item is an agency-requested SBOM for the final image, route the request to component-inventory production or validation—not to “renewing a certificate.”
Ask for evidence without collecting secrets in a public group
A first conversation needs the request text, form scope and release identifier. It does not need source code, credentials, vulnerability details or a federal customer’s private records in Telegram. Move permitted evidence into the buyer’s authorised channel and record who may inspect it.
Useful follow-up questions are concrete:
- Which agency or prime sent the request, and where is the current instruction?
- What producer name and product or product line appear on the proposed form?
- Which version or delivery image is being accepted, and when is the decision?
- Who is authorised to attest for the producer?
- Which statements need supporting review, and which cannot currently be made?
- Is an SBOM or assessment separately required by contract, and for which release?
When the problem is branch-control evidence rather than the federal form, use the branch-protection supplier-risk evidence record. For the adjacent problem of proving what dependencies entered a release, use the dependency-lockfile supplier-risk evidence record.
TOP Prospect can filter and combine incomplete fragments from Telegram groups a user deliberately connects and is authorised to access. It can preserve source and time, remove obvious duplicates and explain why a product name, “CISA form,” version and Friday release appeared together. It cannot read private repositories, determine agency policy, sign an attestation, audit the SSDF practices, contact participants or promise acceptance. Pricing and access options describe the discovery layer, not an assurance opinion.
Key facts
- CISA says the common form is based on NIST SP 800-218, SSDF version 1.1.
- The common form identifies the producer, covered software or product line and attesting individual.
- M-22-18 created the federal self-attestation direction in September 2022; M-23-16 updated implementation in June 2023.
- CISA’s page accessed 14 August 2026 says agencies may use the form under their risk-based assurance policies and may separately request a current SBOM.
- An SBOM is a component inventory; it is not the producer’s secure-development attestation.
- The release join—product scope plus exact version or delivery image—must be verified rather than inferred.
FAQ
Is the CISA secure-software attestation form mandatory for every federal software purchase?
No universal claim is safe in August 2026. CISA now says OMB M-26-05 requires agencies to maintain inventories and risk-based assurance policies; agencies may choose government-wide resources created under M-22-18, including the form, and may set contractual requirements. Check the requesting agency and contract.
What does the attestation need to identify?
The common form identifies the software producer, the software or product line covered and the attesting person. A useful sales record should add the exact release or version, requesting agency, delivery and the evidence owner supporting the statement.
Is an SBOM the same as the secure-software attestation?
No. An SBOM is a component inventory. The attestation is a producer statement about secure-development practices. An agency may request both, but one does not replace the other.
Can a reseller sign for the software producer?
Do not infer that from the sales channel. The form concerns the software producer and an authorised attesting individual. Verify the producer, covered product and signer authority for the actual submission.
The commercial handoff is complete when the team can point to the buyer’s current request, the producer’s statement and the exact release on the same line—without pretending that one file proves the other two.
Frequently asked questions
Is the CISA secure-software attestation form mandatory for every federal software purchase?
No universal claim is safe in August 2026. CISA now says OMB M-26-05 requires agencies to maintain inventories and risk-based assurance policies; agencies may choose government-wide resources created under M-22-18, including the form, and may set contractual requirements. The requesting agency and contract must be checked.
What does the attestation need to identify?
The common form identifies the software producer, the software or product line covered and the attesting person. A useful sales record should add the exact release or version, requesting agency, delivery and the evidence owner supporting the statement.
Is an SBOM the same as the secure-software attestation?
No. A software bill of materials is a component inventory. The attestation is a producer statement about secure-development practices. An agency may request both, but one does not replace the other.
Can a reseller sign for the software producer?
Do not infer that from the sales channel. The form concerns the software producer and an authorised attesting individual. The producer, covered product and signer authority must be verified for the actual submission.
Sources and further reading
- CISA, Secure Software Development Attestation Form and current policy note, accessed 14 August 2026
- CISA, Secure Software Development Attestation Common Form, April 2024
- OMB Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, 14 September 2022
- OMB Memorandum M-23-16, Update to M-22-18, 9 June 2023
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
