In an SSDF gap assessment, PW work happens in code review but no PO process is written down - how do you score it?
answer
- Practised is not the same as defined
- Ask who owns it when the reviewer leaves
- One group describes what another group does
- Assertion is not evidence
- Partial, with the missing definition as the gap
basics
~20 sScore it partially met: the outcome happens but no defined, owned process produces it. Record the missing definition and missing evidence as the gap, because an undocumented habit is not repeatable and cannot be attested to.
solid answer
~50 sConsistent practice with nothing written down is a **partial**, not a pass. In SSDF the PW group is the engineering outcome and the PO group is the organisation's definition of it - PO.1 the security requirements, PO.2 the named roles, PO.4 the criteria a check must meet. If the only thing making code review catch security defects is that two senior engineers happen to care, then the practice has no owner, no stated criteria, no evidence retained, and it evaporates the day those engineers move or a forty-first service is spun up. So the gap record for each task reads: outcome currently achieved, no defined process, no retained evidence, owner unassigned. The remediation is not more code review - it is writing down the criteria and roles that already exist implicitly, once, centrally, and then sampling PR records as evidence. Scoring it green would also mean signing an attestation whose only backing is somebody's memory of how the team usually works.
go deeper
Know that SSDF cares whether a practice is defined and owned, not only whether it happens. 'We always review code' is not by itself an answer an assessor can use.
Explain what the organisational practices add on top of the engineering ones - stated requirements, named roles, defined check criteria - and what breaks when each is missing.
Show you would record a precise per-task state with evidence and owner, defend the partial score, and sequence the remediation so the write-once fix lands before forty per-service conversations.
Own the argument with compliance about checklist versus narrative, and the exposure created by signing an attestation whose only backing is institutional memory.
## The scenario Roughly forty internal services, all built from a shared Maven parent, all reviewed before merge. You walk the SSDF practices with the teams and the pattern is consistent: the PW group looks genuinely healthy - designs are discussed, dependencies are chosen carefully, code is reviewed by someone competent, tests exist. The PO group is empty. There is no written secure-development process, nobody is named as accountable for one, and there are no stated criteria for what a security check has to find or block. The question every assessor eventually faces: does an undocumented good practice count? ## The answer, and the reasoning behind it It counts as **partially met**, and the distinction matters more than it looks. SSDF's PO group exists precisely because outcomes that depend on individuals are not organisational properties. PO.1 asks the organisation to define security requirements for its development work. PO.2 asks for roles and responsibilities to be implemented - a named owner, not an implied one. PO.4 asks for defined criteria for software security checks, so that 'reviewed' means something specific rather than 'somebody looked'. Every one of those is missing here, and each absence is a concrete failure mode: - **No definition.** Two reviewers apply different bars, and neither is wrong, because no bar was written. - **No owner.** When review quality drifts, nobody's job it is to notice. - **No criteria.** A new service, a new team or a contractor starts with nothing to conform to and everyone assumes they absorbed it. - **No evidence.** You cannot show a customer or an assessor that the practice happened; you can only assert it. That last one is the sharpest. The asset at risk in this scenario is audit truth. An attestation or a customer questionnaire answer backed only by 'that is how we usually work' is a claim you cannot substantiate if it is ever challenged, and the person who signed it carries that. ## How to record it A gap assessment is per task, and each row wants four things: | Field | What it holds | | --- | --- | | Current state | Not met / partially met / met, in plain language | | Evidence | The artifact that demonstrates it, or 'none' | | Gap | Specifically what is missing - definition, owner, coverage, evidence | | Owner and date | Who will close it and by when | For this estate the PW rows read 'performed consistently, no defined criteria, evidence available by sampling merge records' and the PO rows read 'not met - no defined process, no assigned role'. Being that precise is what separates a gap assessment from a checklist. A checklist yields a tick or a cross and hides the fact that the same cross means 'we do this well but never wrote it down' in one row and 'nobody has ever thought about this' in another. Those two need completely different remediation and completely different urgency, and a narrative is the only form that carries the difference. This is also the standing argument you will have with a compliance function that wants SSDF rendered as a per-task-ID checklist with one evidence row each. The checklist form is genuinely useful - it is auditable, it makes coverage visible, and it maps cleanly onto a questionnaire. But it cannot express 'practised but undefined', 'defined but unevidenced' or 'scoped out deliberately for low-risk internal tools'. The workable answer is usually both: a per-task table for coverage, with a short narrative per practice group explaining what the states actually mean. ## Sequencing the fix The cheap insight in this scenario is that PO is a *write-once, apply-forty-times* fix while PW would be forty separate conversations. You already have the practice; what you lack is its description. So: 1. Write the secure-development criteria and the review expectations down, drawing them from what the good teams already do rather than from a template. Adoption is nearly free because nothing changes on the ground. 2. Name the owner and the review cadence. 3. Make the evidence a by-product - merge records, check results retained where somebody can sample them - instead of a separate reporting task, which is the thing teams quietly stop doing. 4. Then re-walk PW per service, because with criteria defined you can now find the services that were *not* doing what the good ones do. That set is almost never empty, and it was invisible while the standard lived in people's heads. ## What a weak answer looks like Two failure modes. One is scoring it green because the work demonstrably happens - generous, and it buries the real finding. The other is scoring it not met and telling forty teams to change how they work - which burns credibility on teams that were already doing the right thing, when the only genuine defect is that nobody wrote it down.
- What evidence would you accept that code review actually meets its SSDF outcome?Retained merge records showing who reviewed what against stated criteria, sampled across services and across time rather than cherry-picked. Sampling matters: a policy plus a handful of exemplary reviews proves little, whereas a random sample that holds up shows the practice is uniform. Absence of retained records is itself the finding.
- The compliance lead wants a per-task-ID checklist with one evidence row each. Is that wrong?Not wrong, just incomplete. A checklist makes coverage auditable but flattens 'practised but undefined', 'defined but unevidenced' and 'deliberately scoped out' into the same mark. Deliver the table for coverage and a short narrative per practice group for meaning; refusing the table entirely just loses you the argument.
- Would you fix PO or PW first across the forty services?PO, because it is written once and applies to all forty, and because the criteria it defines are what let you find the services quietly not doing what the good ones do. Fixing PW first means forty parallel conversations against a standard nobody has written down yet.
saying these in an interview costs you the question
- Scores an undocumented practice as fully met
- Marks it not met and orders teams to change what works
- Confuses a checklist tick with an evidence record
- Cannot say why the organisational group exists at all
- Attests to a practice with no retained artifact behind it