M-22-18 said agencies could ask for an SBOM, artifacts from automated tools that check source integrity and known vulnerabilities, and evidence of a vulnerability disclosure program. Those were options, not automatic. M-26-05 left agencies free to use similar requests. Keep a ready set so you can answer within days.
What the memo listed
Under the heading "Agencies may obtain from software producers artifacts that demonstrate conformance to secure software development practices, as needed," M-22-18 named these:
- An SBOM, which an agency could require in a solicitation based on the criticality of the software. If required, the agency keeps it unless the producer posts it publicly and shares the link.
- Other artifacts, "e.g., from the use of automated tools and processes which validate the integrity of the source code and check for known or potential vulnerabilities."
- Evidence of a vulnerability disclosure program.
It also told agencies to consider reciprocity: artifacts held by other agencies might be reused, based on "direct applicability and currency."
EO 14028 section 4(e)(ii) and (v) is the root: artifacts that demonstrate conformance, and artifacts of the execution of tools, provided "when requested by a purchaser."
A ready set
| Artifact | What it shows | Refresh when |
|---|---|---|
| SBOM per release | What components are in the product | Each build or release |
| Scan run records | That vulnerability checks ran before release | Continuously, keep a sample |
| Exception log | How findings were handled when a release shipped with one | On each exception |
| Disclosure policy and report log | That reports are accepted, reviewed and addressed | On each report |
| Access and MFA settings export | Secure environment controls | Quarterly |
| Branch protection and review settings | Code review and change control | Quarterly |
| Build pipeline definition | How builds are produced | When changed |
How to organize them
Use the same structure as the attestation form: environments, trusted source code, provenance and vulnerability checks. One folder per product, one subfolder per item, one index file that links each claim to an artifact and shows the last checked date. A related guide is how to build an attestation evidence index.
Handling requests safely
- Log each request and who made it.
- Redact what is not needed. Internal host names and secrets do not belong in an artifact.
- Share through an access controlled channel, not by public posting.
- Offer a short cover note that says what the artifact is and what period it covers.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice which records a vulnerability workflow produces as a by product, since those are the artifacts a buyer is likely to ask for.
Where Safeguard fits
Safeguard includes compliance and evidence automation alongside SBOM and dependency scanning, so scan records and SBOMs can be collected as part of normal work. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Must we hand over scan results whenever asked?
Not by default. M-22-18 said agencies may ask for artifacts as needed, so look at your contract terms and share what the agreement supports.
Can we post these artifacts on our website?
An SBOM can be posted if you choose, per the memo. Treat POA&Ms, assessments and detailed scan output as confidential unless you decide otherwise with counsel.
Sources
Last reviewed: 19 October 2026.
