No. NIST SP 800-218 says no example, or combination of examples, is required, and the stated examples are not the only feasible options. They are notional ideas for how a task might be done. The SSDF says its intention "is not to create a checklist to follow."
How the table is built
Each SSDF practice in the table has four parts: the practice, the tasks, notional implementation examples and references. NIST describes the examples as "One or more notional examples of types of tools, processes, or other methods that could be used to help implement a task. No examples or combination of examples are required, and the stated examples are not the only feasible options. Some examples may not be applicable to certain organizations and situations."
The framework also says the order of practices, tasks and examples "is not intended to imply the sequence of implementation or the relative importance of any practice, task, or example." And any frequency it mentions for a practice is notional.
Task versus example
| Layer | Meaning | Required? |
|---|---|---|
| Practice | An outcome, such as protecting all forms of code from unauthorized access | The outcome is what you aim for |
| Task | An action that may be needed to perform the practice | Consider each, with a risk based view |
| Example | One way someone might do the task | Never required |
| Reference | A pointer to another framework or document and its mapping | Optional reading |
NIST also says the SSDF "does not prescribe how to implement each practice" and focuses on outcomes, so organizations of any size can use it.
Why this matters in buyer conversations
A buyer or auditor may paste an example into a questionnaire as if it were a control: "Do you use a software composition analysis tool?" That is an example under a task, not a mandate. A fair answer describes how you meet the task, which might use a different approach.
A useful reply pattern is:
- State the task in the SSDF's wording.
- Describe what you do, in one or two sentences.
- Point to evidence.
- If your method differs from the example, say so without apology. NIST built in that flexibility.
How to avoid turning it into a checklist
- Start from the practice outcome and ask what would show it is met in your team.
- Pick the lightest method that works for your risk and size. NIST names risk, cost, feasibility and applicability as factors, plus automatability for scale.
- Write down why you chose it. That record helps when someone asks why you did not use the example.
- Revisit when risk changes, such as a new product line or a new hosting model.
Where to go next
For which tasks you may skip entirely and how to record that, see how to document SSDF practices that do not apply.
Quick check
If we use a different tool than the example, are we non-conformant?
No. NIST says the examples are not the only feasible options and none is required.
Do the frequencies in the table bind us?
NIST says any stated frequency for performing practices is notional.
Sources
Last reviewed: 19 October 2026.
