In NIST SSDF, an artifact is a piece of evidence, a record that a secure development practice happened. Task PO.3.3 asks you to configure your tools to generate those artifacts, keep an audit trail, set retention rules, and assign anyone to create artifacts the tools cannot.
The definition
SP 800-218 version 1.1 says an artifact is "a piece of evidence" and, citing another NIST publication, that evidence is grounds for belief or disbelief. Artifacts provide records of secure software development practices. That makes the SSDF a framework where proof is built into the method.
What PO.3.3 asks
The task is to configure tools to generate artifacts supporting secure development practices as you define them. The examples suggest:
- Use existing tooling, such as workflow and issue tracking, to build an audit trail of secure development actions.
- Decide how often the collected information is audited, and run that process.
- Set and enforce security and retention policies for artifact data.
- Assign responsibility for any artifacts tools cannot generate.
Which artifacts, from which tool
| Practice area | Typical artifact | Usual source |
|---|---|---|
| Code review | Review record with reviewer and date | Source host |
| Code analysis | Findings and triage decisions | Scanner, issue tracker |
| Component checks | Inventory with versions | Dependency tool or SBOM |
| Release | Approval and provenance data | Pipeline |
| Vulnerability handling | Ticket with risk decision | Issue tracker |
Artifacts people create by hand
Some evidence has no tool: a threat model review, a training plan, a tabletop exercise note. PO.3.3 expects an owner for these. Put them in the same place as tool output so one search finds everything.
Good habits
- Name artifacts the same way every time.
- Keep timestamps and author or system identity.
- Store them read only or version controlled.
- Check once a quarter that each practice still produces output.
Who looks at the trail
An audit trail nobody reads is only storage. PO.3.3 says to decide how often the collected information is audited. Pick an owner and a rhythm, perhaps monthly, and write down what they look for: gaps, missing approvals, practices that stopped producing records. Keep a short note of each check. That note proves the trail is used, which is a stronger story than a large archive.
Quick check
Is a screenshot an artifact?
It can be, but system generated records with timestamps and identity are stronger and easier to repeat.
How long should artifacts be kept?
PO.3.3 says to set and enforce retention policies. The document gives no fixed period, so choose one that fits your contracts and release cycle.
Where tooling helps
Safeguard offers compliance and evidence automation, SBOM and dependency scanning and policy gates that leave dated records. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
