A NIST SSDF assessment when you are a team of four
SSDF is about how software gets built. Almost every other thing on this site is about what a built system does when you poke it, and those two are related without being the same, so the honest version of this page has to start by saying where the join is weak. What follows is which practices the controls here provide evidence toward, what that evidence is worth, and the part nobody can hand you.
Where technical evidence meets a process framework
SSDF asks what a producer does. A validation run sees what a producer left behind, in a repository and in a deployment. The overlap is real and partial, and reading the layers below with that in mind is the difference between using this well and overstating it.
Repository validation
E2The layer closest to what SSDF is about, because the framework describes production and this reads what production left behind. Where credential material sits, and whether any of it is in the history, is evidence toward PS.1 and PW.5. How queries are assembled, and whether a protected lookup checks ownership, is evidence toward PW.5 and PW.1. The dependency manifests and their lockfiles are evidence toward PW.4. Each finding cites its file, which matters more here than elsewhere: a practice is an assertion about habit, and a citation is the only thing that turns it into a fact.
Runtime validation
E4Builds and runs the application and probes it. SSDF does not ask for this, which is exactly why it is worth having: PW.9 asks that software ship with secure settings by default, and the only honest way to know whether a setting survived the journey from repository to deployment is to look at the deployment. A configuration file is a statement of intent, and a response header read off the running service is not.
Public URL scan
E4Needs only the address, and on this framework it speaks to one practice. What the deployed service enforces about transport and what it returns in its headers is evidence toward PW.9, observed rather than declared. It reaches nothing about how the software was written, so on this page it is the narrowest of the three, and every control it cannot reach is reported uncovered rather than assumed.
The practices these controls provide evidence toward
Eleven of the thirteen controls reference an SSDF practice. Seven practices are named across them: PO.4, PO.5, PS.1, PW.1, PW.4, PW.5 and PW.9. Each row is the practice, what the evidence actually is, and how strong it is. Two of the rows are held up by something you tell us rather than by something we measured, and they say so rather than being averaged in with the rest.
Six things to be clear about before quoting SSDF at anyone
Most SSDF material is written for organisations with someone whose job this is. Read as a small team, the framework is still useful, but only after these are straight.
It describes production, not a running system
The practices are about what a producer does: how requirements are set, how code is protected, how source is written, how software is configured for release. Nothing in the framework asks what happens when a request arrives. That is why the join to technical evidence is indirect here in a way it is not for a verification standard, and why every claim on this page is worded as evidence toward a practice rather than as a result against a clause.
Evidence toward a practice is not conformance with the framework
Conformance is a claim about an organisation: its people, its process, its records, and whether the practice is followed rather than merely possible. No scan can establish that, and no tool that tells you otherwise is describing SSDF. What technical evidence does is make part of that claim checkable, which is genuinely useful and is a smaller thing than it is usually sold as.
A practice is an outcome, and it deliberately does not tell you how
SSDF names what should be true and leaves the implementation to you, which is the source of most of the frustration teams have with it. There is no list of tools to install and no configuration that satisfies a practice. This is a strength when you are choosing how to work and an obstacle when someone has asked you to demonstrate it, because demonstration is left entirely as an exercise.
It assumes a function a small team does not have
The framework is written for producers with defined roles, a toolchain someone owns, and criteria somebody maintains. A team of four has none of those as separate things, because the same person does all of them between other work. The half that translates is the technical half: what is in the source, what shipped, what the deployment enforces. The organisational half is real work that a tool cannot do and should not pretend to have done.
Two of our mappings rest on what you tell us
Backups and the rollback path are settled by attestation, not measurement. Source can show a pipeline exists and that migrations are reversible; it cannot show anyone has ever restored a backup or rehearsed a rollback under pressure. Those are recorded as attestations and graded as attestations, and a report that presented them as probe results would be lying about the two controls most likely to matter on the worst day.
NIST publishes it and does not accredit anyone against it
SSDF is guidance NIST puts out for anyone to use. There is no NIST certification for a product, and none for a tool that assesses one. Where SSDF turns up commercially it is usually because a buyer's own procurement process references it and has asked you to describe your practices, which is a conversation you are having with the buyer rather than with NIST.
What to actually do with it
Four steps, in this order, sized for a team that has no compliance function and is not going to acquire one this quarter.
Separate the practices you can evidence from the ones you have to describe
The source-and-deployment practices leave artefacts, so they can be evidenced and rechecked. The organisational ones are described in your own words and stand on your say-so. Sorting them takes an hour and stops you from either overstating the first group or panicking about the second.
Automate the evidence half and let it rerun
Secrets, dependency state, transport and header configuration, injection-safe data access, and how authorisation behaves are all things a run establishes and re-establishes. The value is not the first report. It is that the answer stays current without anybody remembering to check.
Write the organisational half down once, plainly
A page describing how you set security requirements, who reviews changes, and what your release criteria are is worth having before somebody asks. It does not need to be long or impressive, it needs to be true, and writing it usually surfaces one decision nobody has actually made.
Keep the two apart in anything you send a buyer
Measured evidence and stated practice are different strengths of claim and a reader can tell. Presenting them together as one number is the move that makes a careful buyer distrust the whole document, which costs more than the weaker half ever would have.
What the result looks like
An illustrative extract, not a real customer result. Every row carries the evidence grade behind it, and a control nobody could establish says so.
| Control | Status | Evidence | Note |
|---|---|---|---|
| Secrets are managed outside source code | Failed | E2 | PS.1 and PW.5. A provider key present in git history, still valid |
| Dependencies are free of known-critical vulnerabilities | Verified | E3 | PW.4. Resolved dependency graph checked against public advisories |
| Transport security (TLS) is enforced | Verified | E4 | PW.9. Redirect and protocol versions observed on the deployment |
| Deployment rollback path exists | Partial | E2 | PO.4. A pipeline and reversible migrations in source, no rehearsal attested |
| Verified backups and restore procedure | Uncovered | Not graded | PO.5. No attestation given, and nothing a scan reaches can settle it |
Mapped to published standards
Each control is tested against a named clause, so a result means something outside our own vocabulary. Mapping is not certification, and none of these bodies endorse StackAttest.
What this does not tell you
- It is not a penetration test. A deterministic check and a runtime probe are not an adversarial human engagement, and there are classes of weakness only a person hunting for them will find.
- It is not SOC 2 and does not replace it. SOC 2 attests to organisational controls over time; this validates technical controls in the software. They answer different questions for different buyers.
- It does not replace human due diligence. It gives a reviewer repeatable evidence to start from, which is a different thing from being the reviewer.
- Controls the run could not reach are reported as uncovered rather than passed. A result you did not earn is worse than no result.
- It is not a certification and there is no such thing to award. OWASP and NIST publish these documents openly. Neither one endorses, accredits, reviews or has any relationship with StackAttest, and a result produced here is a result against named clauses that you can check yourself, which is the only kind worth having.
- It does not assess conformance with the framework. Conformance is an organisational claim about how your team works, covering people, process and records. A run reads a repository and a deployment, so it can support part of that claim and can never make it.
- It does not touch the practices that leave no artefact. How security requirements are set, who is accountable for them, and how vulnerabilities are handled after release are all real parts of the framework and all outside what any scan can see. They are your description to write, not our result to report.
- Two of the practices here are evidenced by attestation. Backups and rollback rehearsal are things you state and we record as stated. That is honest evidence of a weaker kind, and treating it as equivalent to a probe result would misrepresent the two controls that matter most when something has already gone wrong.
Questions
What is a NIST SSDF assessment?
It is an assessment of how software is produced, against the practices in NIST's Secure Software Development Framework. That makes it different from a security test of a running application: the framework asks what your team does, not what your server returns. The two overlap where a practice leaves something behind in a repository or a deployment, which is the part a validation run can evidence.
Which SSDF practices does StackAttest provide evidence toward?
Seven, across eleven of the thirteen controls: PO.4, PO.5, PS.1, PW.1, PW.4, PW.5 and PW.9. The table above gives the evidence behind each and how strong it is. Two controls carry no SSDF mapping at all, and everything outside those seven practices is untouched rather than satisfied.
Does this make us SSDF compliant?
No. Conformance with the framework is an organisational matter covering people, process and records, and nothing that reads a repository can establish it. What a run gives you is checkable technical evidence toward some of the practices, which is a useful part of the answer when a buyer asks, and is not the whole answer.
How is SSDF different from OWASP ASVS?
SSDF describes how software is built and is aimed at the producer. ASVS describes properties a built application must be verified to have and is aimed at the application. They are complementary rather than competing, and a technical run has a more direct relationship with ASVS for exactly that reason: it tests a running system, which is what ASVS is about.
Does NIST endorse or certify StackAttest?
No. NIST publishes SSDF as open guidance and has no relationship with us. There is no NIST certification for a product or for a tool that assesses one, and any vendor implying there is has invented it.
Our customer sent us an SSDF questionnaire. What do we send back?
Two things, kept visibly separate. First, the evidence: what is in the source, what shipped, what the deployment enforces, with the grade recording how each was established. Second, a plain description of the organisational practices, in your words, standing on your say-so. Merging them into one confident summary is the thing that makes a careful reviewer distrust both halves.
We are four people with no compliance function. Where do we start?
With the half that leaves artefacts, because it is the half you can get for the cost of running something. Secrets, dependencies, transport and header configuration, injection-safe data access and authorisation behaviour are all evidenced by a run and stay current on rerun. Then write down the organisational half once, honestly, including the parts you have not done yet.
Related
Find out what is actually true of your application
Start with the layer you can run today. The report says which layers ran and what they could not reach, so the result is honest about its own limits.