Verify and validate the security design

A design review approves an architecture, the build follows it exactly, every test in the plan passes, and the service still fails in its first month of operation because the requirement everyone tested against described the wrong problem. Nothing in that story is a testing failure. It is the gap between two questions that sound alike and are not. If you already sit in design reviews and read test reports, that gap is what this page closes: which activity produces the evidence a given claim needs, and what that evidence still leaves uncovered.

NIST defines verification^[1] as confirmation, through the provision of objective evidence, that specified requirements have been fulfilled, and validation^[2] as confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled. Verification compares architecture or implementation evidence against the requirements, constraints, and design criteria that were written down. Validation compares the resulting system, in its operational context, against what stakeholders actually need. Because the two measure against different yardsticks, both are performed and neither substitutes for the other.

The two failure modes this creates

A design can verify cleanly against an incomplete requirement set and still fail validation, because it solves a problem nobody has. The reverse also happens: a system that clearly serves the operational need can still fail verification on a specified constraint such as a mandated cryptographic algorithm or a required separation of duties. Evidence that every written requirement was implemented is a verification result and says nothing on its own about fitness for use, while evidence that the system serves its intended purpose in context is validation, whatever the activity is called locally.

Three ways the evidence is obtained

Every activity on this page produces its evidence in one of three ways, and NIST SP 800-115^[3] names them. Examination checks, inspects, reviews, observes, or analyzes an object such as a design document, a configuration, or source code in order to obtain evidence. Interviewing holds discussions with the people responsible in order to clarify a point or locate evidence. Testing exercises an object under specified conditions and compares actual behavior against expected behavior. NIST SP 800-53A uses the shorter verb forms examine, interview, and test for these same three methods, and both forms appear on this page wherever one reads better than the other. Those three methods are named for every technique described below, in the comparison table, and in the decision tree, so the question to ask of any proposed activity is which of the three it is and what it can therefore prove.

Where this page sits in the domain

The other objective in this domain selects the architecture approach, the framework, the reference content, and the threat-modeling framework, and it runs the threat model, meaning the analysis that models the attack and defense sides of a system in order to find where it can be attacked. This objective begins once a candidate design and its threat model exist, and it consumes threat-model output as an input rather than producing it. Gap analysis, compensating controls, third-party review, and code review methodology are covered on this page.

The figure below places the two questions against the artifacts each one measures.

Takeaway: verification asks whether the system was built to its specification, validation asks whether that specification was the right one, and each activity below is an examination, an interview, or a test.

This section covers the test family that answers the verification question directly: functional acceptance testing, regression testing, and the negative cases that separate a working feature from an enforced control.

Functional acceptance testing demonstrates that required functions and security behavior satisfy the acceptance criteria agreed with the people who will accept the system, in the context it is intended for. The word agreed is load-bearing. Criteria written after the build, or inherited from a different system, produce a pass that nobody can act on. Developer unit tests are supporting evidence and nothing more: they show that individual components behave as their authors expected, not that the complete set of acceptance criteria has been satisfied.

Positive results are only half a security test

A security functional test has to demonstrate two things: that authorized operations succeed, and that disallowed operations are prevented. Testing only the permitted path shows that a feature is available and leaves every authorization failure path unexercised, which is precisely where a broken control hides. A test suite that proves an administrator can read the audit log, without ever proving that an ordinary user cannot, has verified availability of a feature and nothing about the control. Write the denial cases into the acceptance criteria so they are agreed rather than optional.

Regression testing after a change

Regression testing reruns relevant prior tests after a modification, to find unintended effects in functions and controls that nobody deliberately changed. The failure mode it exists to catch is indirect: a change to a shared library, a configuration default, a schema, or an authorization helper can invalidate a security property in code the change never touched. Retesting only the new functionality is the common shortcut, and it systematically misses exactly the class of defect regression testing was invented for.

Selecting the regression set is itself a design decision. The set should cover the security properties that the changed component participates in, not simply the tests that run fastest. When the change also alters trust relationships, data flows, the deployment environment, or a mitigation, the threat model^[4] needs revalidation as well, which the section on threat-model results below expands.

What the pass actually licences

An acceptance pass licences a readiness decision against the criteria that were agreed, in the context that was tested. It says nothing about requirements nobody wrote down, environments nobody exercised, or paths the suite never reached. Those boundaries are not a weakness of testing; they are the reason examination and interview evidence sit alongside it.

Takeaway: acceptance testing decides readiness against criteria agreed in advance, security functional tests cover both the permitted and the prohibited path, and regression testing after a change looks at what the change did not intend to touch.

How much testing is enough is a design decision with a defensible answer, and the answer is not the same for every component. Test scope, depth, detail, and rigor should provide the confidence required for the most significant adverse effect that can occur if the component fails, together with any assurance requirement that applies to it.

Applying one shallow test set uniformly gets this wrong twice at once. It spends effort on components whose failure is an inconvenience, and it under-tests the components whose failure is severe. The corrective is to grade the design first, by consequence, and then choose techniques per grade rather than choosing a house-standard technique and applying it everywhere.

The pattern is explicit elsewhere in NIST guidance

The same scaling appears in contingency-plan testing, where NIST SP 800-34 Revision 1^[5] ties the depth and rigor of the test to the availability impact level of the system: a tabletop suffices at low impact, a functional exercise including recovery from backup media is expected at moderate impact, and a full-scale functional exercise with failover to the alternate location is expected at high impact. Read that as an illustration of the principle rather than as a rule about design verification, because the underlying logic transfers: the exercise gets more expensive and more disruptive precisely where the consequence of being wrong is highest.

What raises the required depth

Several factors raise the depth a component needs, and they are cumulative rather than alternatives. The severity of the worst credible adverse effect is the primary driver. An explicit assurance requirement, whether from a regulator, a customer contract, or an internal high-assurance policy, sets a floor independently of the architect's own risk view. Position matters too: a component that many other components depend on for a security property is graded by what its failure would do to those dependents, not by its own function alone. NIST SP 800-160 Volume 1^[6] frames this as the trustworthiness context of a system, where the evidence required is set by what has to be believed about the system, not by what is convenient to produce.

Stating the decision

Record the grading, because it is the part an assessor can challenge and the part that explains the test plan. For each component or interface, state the worst credible effect of its failure, the assurance requirement that applies, the depth chosen, and the techniques that deliver that depth. A plan written this way survives the question of why one service got a penetration test and another got a design walkthrough.

Takeaway: grade components by the worst credible consequence of their failure and by any applicable assurance requirement, then buy depth where the consequence is severe rather than spreading one shallow test set evenly.

Acceptance and regression tests exercise the cases somebody thought of. Two techniques exist because attackers do not restrict themselves to that set: fuzz testing explores inputs nobody enumerated, and penetration testing explores paths nobody intended. This section covers what each one can establish and, more importantly, what a clean result from either does not establish.

Fuzz testing

Fuzz testing^[7], also called fuzzing, supplies invalid, unexpected, or randomly generated data to an application, either from the environment or from another process, and watches how the target responds. The tools that do this are called fuzzers, and the failures they surface are crashes, hangs, memory faults, and other anomalous behavior that reveals defective input handling, including buffer overflows. Its value is that it explores the space of inputs developers did not enumerate, complementing specification-based tests rather than reaching a space they cannot reach by construction. Its limit follows from the same property: finding no crash is not a proof of correctness, because the technique samples an input space rather than covering it.

Penetration testing

Penetration testing^[3] attempts to exploit vulnerabilities within a defined scope in order to show how controls fail together and what access or impact an attacker can actually achieve. That is a different claim from a vulnerability scan, and NIST SP 800-115 draws the line precisely: a scanner checks only for the possible existence of a vulnerability, while the attack phase of a penetration test exploits it to confirm that the vulnerability is real. A scan enumerates candidates; a penetration test validates exploitability for the candidates it pursues.

SP 800-115 structures the work in four phases. Planning agrees rules of engagement, scope, and written management authorization, and performs no testing. Discovery gathers information and scans for candidates. Attack exploits what Discovery found, and loops back to Discovery whenever a new foothold exposes targets that were not previously visible. Reporting runs concurrently with the other phases and ends in findings, risk ratings, and recommended mitigations. The figure below shows those phases with the loop that makes the process iterative rather than linear.

The asymmetry both techniques share

A successful exploit is strong evidence for the specific path demonstrated. Failure to exploit within a time-boxed engagement is not evidence that no other path exists. The tester had a scope, a schedule, a toolset, and a level of access, and the result is bounded by all four. Report the finding as what it is, which is an existence proof when it succeeds and an absence of evidence when it does not.

Takeaway: fuzzing explores unanticipated inputs and penetration testing demonstrates a concrete exploitable path, and neither a quiet fuzzing run nor an unsuccessful penetration test establishes that the design is sound.

The threat model arrives from the other objective in this domain as a set of scenarios, affected assets, attack vectors, preconditions, and expected consequences. Its job here is to decide what is worth testing, so that reviewers test whether a proposed control interrupts a modeled path instead of testing controls one at a time in isolation.

NIST SP 800-154^[4] defines an attack vector as a segment of the entire pathway that an attack uses to access a vulnerability, and characterizes each vector by three things: the source of the malicious content, the potentially vulnerable processor of that content, and the nature of the content itself. Those three parts are not bookkeeping. Each one is a place the segment can be detected or stopped, so a vector described only as an attacker profile or a motive gives a reviewer nothing to test against. The figure below shows the three parts and where the interruption opportunities sit.

Likelihood and impact stay separate

Likelihood addresses the possibility that a threat event will occur and result in adverse effect. Impact addresses the magnitude of harm to operations, assets, individuals, or objectives if it does. Keeping them as separate estimates matters because they call for different treatment: a rare catastrophic scenario usually needs containment, recovery, and an explicit acceptance decision, while a frequent minor one usually needs prevention or automation. A single composite score can rank the two identically and hide that difference, which is why NIST SP 800-30 Revision 1^[8] carries them as distinct inputs to a risk determination rather than merging them earlier.

Likelihood is a property of the architecture, not the adversary

The same threat source does not create the same risk in every design. Predisposing conditions^[9], meaning conditions within an organization or system that affect the likelihood that a threat event results in adverse impact, sit alongside exposure, susceptibility, and the controls already in place. Verification should therefore test the assumptions behind a likelihood estimate. If the estimate rests on a claim that a service is not reachable from the internet, that reachability claim is the testable item, and treating likelihood as an adversary attribute quietly removes it from the test plan.

Selecting the tests

Work from the modeled path. For each credible scenario, identify the abuse cases that follow from its vector and preconditions, meaning the ways the system would be used deliberately against its purpose, then choose assurance activities that establish whether the proposed controls break that path. This trace is what lets a reviewer answer the only question that matters at a design gate, which is whether the design defeats the scenario, rather than whether each control works when exercised on its own.

When the model itself expires

A threat model is valid only for its documented system boundary, assumptions, technology, and threat context. New trust relationships, new data flows, a different deployment environment, changed adversary behavior, or added mitigations can each invalidate a prior conclusion. Changes to any of those call for reassessing the affected conclusions, and reusing an approved model unchanged across later releases can leave a design verified against a system that no longer exists.

Takeaway: characterize every vector by source, processor, and content, keep likelihood and impact apart, test the assumptions that produced the likelihood, and reassess the model when its documented boundary or context changes.

A gap is a comparison, so this section covers what has to be compared with what before a finding can be called a gap. A list of scanner findings, sorted by severity, is not that comparison: it describes what a tool noticed, and it cannot say which required capability is absent, because nothing in it refers to a required capability.

A design gap is established by comparing the required target capability with the existing or proposed implementation and the evidence for it, element by element. The comparison is between corresponding states, which means each target element is matched to whatever plays its role today, or to the explicit finding that nothing does. That produces a decision per element rather than a severity count.

The four dispositions

This guide uses four practical dispositions, and stating them is what turns the analysis into a plan:

Disposition	What it means	What it produces
Carry forward	The existing element already satisfies the target requirement	Evidence that it does, and the assurance activity that produced it
Add	The target requires a capability that nothing currently provides	A new requirement traced to the target element
Remove	An existing element serves no target requirement	A retirement decision and the check that nothing depends on it
Replace	An existing element addresses the requirement but cannot meet it as specified	A treatment decision, which the next section covers

A finding with no disposition is unfinished work. A disposition with no corresponding element in the other state can still identify a gap.

Why the target trace is the whole point

Without the trace back to a target requirement, three failures follow and none of them is visible in the output. The analysis cannot show coverage, because there is no denominator. It cannot justify removal, because nothing establishes that an element is unneeded. And it cannot be reviewed, because a reader has no way to tell a missing capability from a tool's blind spot. Counting scanner findings and calling the total a gap is the exact failure this discipline exists to prevent.

What feeds the comparison

The target state comes from the requirements identified in the governance, risk, and compliance domain and from the architecture selected in the other objective of this domain. The existing state comes from the design documentation plus evidence about what is actually deployed, which is a place where examination and interview evidence usually disagree with each other and the disagreement is itself a finding. Where a target element depends on an assumption about the environment, record the assumption with the element, because the section on threat-model results above makes those assumptions testable items.

Takeaway: compare each target element against what exists today, end every comparison in carry forward, add, remove, or replace, and treat any finding without a target-state trace as something other than a gap.

Once a gap is established, something has to change, and the design review question becomes whether the proposed change actually treats the risk. A control listed next to an affected asset is an intention. A treatment is a claim about a modeled scenario, and it can be checked.

A safeguard has to change the scenario

A proposed safeguard is relevant when it does at least one of four things to the modeled scenario: reduces the probability that exploitation succeeds, limits the harm when it does, improves detection and response, or removes a precondition the attack requires. Those four are the options this analysis works with, and each one is a testable claim about a specific step of the path described in the threat model. Associating a control family with the affected asset demonstrates none of them, which is why a mapping table is a starting point rather than an answer. The figure below shows the modeled chain with the four places a safeguard can act on it.

When the preferred control cannot be implemented

A compensating security control^[10] is a management, operational, or technical control employed in place of a recommended control, which provides equivalent or comparable protection. It is selected during tailoring, when a baseline control cannot be implemented as written. Three conditions carry the argument, and all three are evidence, not assertion: the substitute addresses the same requirement and the same threat, it does so within the environment as it actually is rather than an idealized one, and the exposure that remains after substitution is stated and approved.

Cost or convenience establishes none of that. Neither does membership of the same control family, which is the most common wrong answer available: a cheaper control from the same family may address an entirely different step of the scenario. State what the original control was protecting against, and show the substitute doing the same job.

Layering only helps with different failure modes

Defense in depth^[11] applies multiple security safeguards to protect the integrity of the information and the system. The assurance comes from the safeguards acting at different points in the scenario, or failing in different ways, so that one failure does not carry the others with it. Duplicating one mechanism across several locations does not achieve that when every copy shares a dependency: the same expired certificate authority, the same identity provider, the same misconfigured rule set, or the same defect takes them all down together. Before claiming independent layers, name the failure mode each layer covers and confirm the list contains more than one.

Comparing alternatives across the trade space

Where several designs could close the gap, the comparison covers how each satisfies the security requirements together with cost, performance, interoperability, usability, lifecycle, and operational constraints. Selecting the technically strongest control while ignoring those constraints produces a design that verifies against the security requirement and fails validation in operation, because operators route around a control they cannot work with. Record the comparison, since the reason a weaker-looking control was chosen is exactly what a later reviewer will ask about.

Takeaway: a treatment earns its place by changing the modeled scenario, a compensating control has to match the original intent within the real environment, layers need different failure modes, and alternatives are compared across the whole trade space rather than on security strength alone.

A control passed its test, so the risk is closed. That sentence is the defect this section exists to remove. Verifying that a mitigation operates as intended establishes that the mitigation works, and it establishes nothing about how much risk is left once it does.

Residual risk^[12] is the portion of risk remaining after security measures have been applied. It remains after any treatment that reduces an exposure rather than removing it, because a treatment that reduces probability leaves the reduced probability, a treatment that limits harm leaves the limited harm, and a treatment that improves detection leaves the window before detection. The question at a design gate is not whether residual risk exists but whether the right person has seen it and decided.

What has to be recorded

Four items make the residual position reviewable, and a mitigation test result supplies none of them on its own. The post-treatment likelihood states how probable successful exploitation now is with the control in place. The post-treatment impact states the harm that would still follow. The assumptions state what has to remain true for those two numbers to hold, which is usually where the fragility lives. The uncertainty states how confident the estimate is, since a wide band on a severe impact is itself a reason to seek more evidence.

Who decides

The disposition belongs to the authorized decision maker, meaning the person with the authority to accept the exposure on behalf of the organization, not the architect who designed the treatment and not the assessor who tested it. Two outcomes are available: accept the residual exposure as it stands, or require further treatment. Recording which one was chosen, by whom, and on what date is what makes the decision an accountable act rather than an assumption.

Automatically closing a risk when its planned control passes a test removes that decision from the person accountable for it, and does so silently. The risk register then shows a clean state that nobody actually approved, which is worse than an open item, because an open item is at least visible.

Takeaway: a successful mitigation does not by itself show that risk has been eliminated, so record post-treatment likelihood, impact, assumptions, and uncertainty, and route the accept-or-treat-further decision to the authorized decision maker instead of deriving it from a passing test.

A design is finished, the tests pass, and the remaining doubt is not about the code. It is about whether the response plan works when three teams have to coordinate at 3am, whether the design contains an assumption the team stopped noticing years ago, and whether the exception paths do what the requirements say. Those doubts are answered by people rather than by tools, and each method below answers a different one. They fall into two groups, which is the split the comparison table and the decision tree use: tabletop exercises and simulation take the response plan and the people executing it as their subject, while manual functional review and peer review take the design artifact as theirs. Pick by the doubt you have.

Tabletop exercises

A tabletop exercise^[5] presents a simulated scenario to participants, who discuss their responsibilities, the coordination between them, the decisions they would make, and the actions they expect to follow. Nothing is deployed and no production system is touched, which is what makes it cheap enough to run often and safe enough to run on a live service. It is well suited to exposing unclear authorities, missing decision rights, and procedural gaps. Its boundary is equally clear: a discussion in which everyone agrees on the failover procedure is not evidence that the failover works, and a successful tabletop says nothing about whether the technology can execute under load.

Modeling and simulation

Modeling and simulation^[13] represents selected system or operational behavior in a controlled environment, so scenarios and assumptions can be explored without production consequences. It suits questions of scale, timing, and interaction that a discussion cannot settle and a live cutover would be too risky to answer. The assurance it produces is bounded by the fidelity of the model, the quality of the inputs, and every difference between the simulated setup and the operational one, so a simulation result is quoted together with the model it came from.

Manual review of functions

A reviewer can trace use cases, state transitions, trust decisions, and exception paths against the requirements and the threat scenarios, before the implementation exists or without executing it. This is examination evidence, and it is the strongest method available for architecture logic and for behavior that is missing altogether, which no test can detect because there is nothing to invoke. The matching limit is strict: document review cannot show that a runtime control actually enforces, so using it as the sole evidence for an operating control applies a method built for a different question.

Peer review

Peer review puts qualified peers in front of the design so they can identify omitted viewpoints, inconsistent requirements, unsafe assumptions, and trade-offs the original team normalized into invisibility. Its effectiveness depends on the reviewers' competence, the scope they were given, and their access to the rationale and the evidence behind the design. Attendance by another architect is not the mechanism, and a review whose participants saw only the final diagram cannot challenge the reasoning that produced it.

Takeaway: choose the human method by the doubt it removes, tabletop for authorities and coordination, simulation for behavior at scale, manual functional review for logic and omissions, and peer review for assumptions, and pair any of them with a test when the claim is about runtime enforcement.

Two assessments can examine the same system, apply the same procedures, and carry very different weight. This section covers the three properties that decide which one a reviewer should believe: who performed it, how many kinds of evidence it rests on, and what scope its conclusion actually covers.

Independence

An assessor who took no part in the design or implementation decisions is less exposed to self-review bias and to incentives that conflict with reporting a problem. That is the entire mechanism behind independent verification and validation^[14], where the work is performed by an organization technically, managerially, and financially independent of the development organization. Independence raises confidence in the objectivity of a finding, and it supplies nothing else. It does not supply technical competence in the technology under review, an adequate scope, or access to the evidence the assessment needs. An external label on its own is therefore not assurance, and choosing an assessor because third-party status is assumed to guarantee quality replaces one unexamined assumption with another.

Corroboration across the three methods

Section one introduced the three assessment methods, and NIST SP 800-53A^[15] is where they become an assessment procedure: examine artifacts, interview the people responsible, and test the mechanisms or processes. Combining them is not thoroughness for its own sake. Each method sees a different thing, and only the combination distinguishes a design that is documented, a practice that is understood, and a control that is operating. Inferring all three from a single source is the failure this corroboration exists to prevent, and it is how a well-written design document becomes evidence for a control nobody has ever run. The figure below shows the three methods and what their combination establishes.

Evaluated assurance has an explicit boundary

A Common Criteria^[16] evaluation is the formal version of this same idea, with the boundary written into the result. It provides assurance for the defined Target of Evaluation, meaning the specific product or system and its associated guidance that were submitted, against the security claims and properties specified in its Security Target^[17], the document expressing the security requirements and functions for that one Target of Evaluation, or in a claimed Protection Profile^[18], the equivalent implementation-independent statement of security needs for a whole class of product, as examined by the applicable evaluation methods and activities. Everything outside that statement is unevaluated, including functions that were out of scope, configurations other than the evaluated one, and operating conditions the evaluation did not consider.

The assurance requirements for the evaluation are expressed separately as an Evaluation Assurance Level^[19], a well-formed package of security assurance requirements representing a point on a predefined assurance scale. A higher level means more was examined, more rigorously; it does not mean the product is more secure than one evaluated at a lower level against a different Security Target.

Takeaway: independence buys objectivity and nothing else, corroborating examination, interview, and test is what separates a documented design from an operating control, and an evaluated result is bounded by its Target of Evaluation and its Security Target.

Software is where a design either becomes an enforced control or quietly does not, so this objective names code review as its own methodology with four approaches. A team asked to review an application will reach for whichever one it owns a tool for. The architect's job is the prior decision: which approach answers the question being asked, and what each one is structurally unable to see.

Secure code review^[20] is the umbrella activity. It audits application source to verify that the appropriate security and logical controls are present, that they operate as intended, and that they have been invoked in the right places. Its objective is to discover security defects and, where possible, identify solutions. Note the third clause: presence and correct operation are not enough, because a control that exists and works but is not invoked on one of the paths that needs it protects nothing on that path. Verifying invocation at every required point is what separates a code review from a control inventory.

The four approaches

Manual review is the only approach that reasons about intent. A human reviewer can follow authorization logic, workflow abuse, trust assumptions, misuse of security functions, and requirements that were never implemented, because understanding what the code is supposed to achieve is a prerequisite for noticing that it does not. It is resource intensive, which is why it is aimed rather than applied evenly.

Static analysis^[21] examines source or compiled code without executing it, inspecting code structure and data or control flows for weakness patterns. It covers a large codebase consistently and runs before anything is deployable, and its output requires triage: pattern matching without runtime context produces false positives and findings whose validity depends on how the code is actually reached.

Dynamic analysis supplies inputs to a running system and observes the behavior and the responses. It sees what static analysis cannot, meaning runtime and configuration-dependent flaws, and it sees only the paths, states, and interfaces the test actually reached. A clean dynamic result covers the executed paths and makes no claim about the rest, which is the same asymmetry the section on penetration testing described.

Software composition analysis^[22], usually abbreviated to SCA, inventories the libraries and other dependencies the software includes so that known vulnerabilities, versions, provenance, and other supply-chain concerns can be assessed. It answers a question about what was brought in, not about what was written, so it cannot tell you whether your own authorization code enforces your own requirement. The figure below sets the four approaches beside what each one sees and what each one cannot.

Third-party components are judged by their use

The NIST Secure Software Development Framework^[23], published as SP 800-218 and usually called the SSDF, directs organizations to review third-party components in the context of their expected use, and to repeat the evaluation when that use changes substantially. The reason is that risk is positional. A parsing library that is acceptable in an offline developer tool carries a different risk when the same version handles untrusted input on a trust boundary, meaning the place where two parts of a system under different security policies meet, and no inventory-level score captures that difference.

The threat model chooses where to spend

Mapped assets, trust boundaries, abuse cases, and attack paths identify where manual review, static analysis, dynamic analysis, fuzzing, and penetration testing each return the most value. Tool coverage metrics point the other way, toward whatever is easy to scan, and a review programme steered by coverage percentages will look thorough while leaving the critical interfaces to whichever tool happened to reach them.

Takeaway: manual review reasons about intent, static analysis sees structure without execution, dynamic analysis sees executed behavior only, SCA sees imported components only, and the threat model rather than tool coverage decides where each is worth running.

The methods above generate findings. This section covers what has to happen to a finding before the review can be called complete, because a report is an input to the process rather than its output.

The SSDF describes developer verification as a cycle rather than a scan. Discovered issues are recorded, their validity and priority are determined, remediation is routed into the development workflow, and the fix is verified. Each of those four steps produces something a later reviewer can inspect, and skipping any one of them leaves a gap that the remaining steps cannot fill.

Triage is a decision, not a filter

Determining validity separates real weaknesses from tool artifacts, and determining priority orders the real ones against the threat model and the criticality grading from earlier in this page. Both are decisions with owners and reasons. A finding dismissed as a false positive carries the reason it is not exploitable in this design, because that reason is the thing a reviewer checks, and because the same pattern will be reported again on the next run.

Remediation goes through the normal workflow

Routing fixes into the ordinary development workflow, rather than a side channel, is what makes them visible to code review, to the test suite, and to the release process. A patch applied outside that path skips the controls that would have caught a regression introduced by the fix itself.

Verification closes the loop

The fix is verified, and the verification is regression-aware: it establishes both that the reported weakness is gone and that the change did not break a security property elsewhere, which is the regression case from earlier in this page applied to a security fix. Without that step there is a remediation claim and no evidence.

What does not count as evidence

A raw scanner or analyzer report submitted as final assurance evidence does not complete the four-step developer verification cycle. It records issues without determining validity, orders nothing, routes nothing, and verifies nothing. Counting alerts is a measure of tool activity, and the number goes up when a scan is configured more aggressively, which is the opposite of the direction assurance is supposed to move.

Takeaway: a review is complete when findings have been recorded, triaged for validity and priority, remediated through the normal development workflow, and verified with regression evidence, and an untriaged report is none of those things.

Items on this objective are rarely about whether you can define a technique. They present a situation in which several defensible activities exist and ask which one produces the evidence the situation actually needs. Three reading habits resolve most of them.

Habit one: name the question before the technique

Decide first whether the stem is asking about verification or about validation. Wording such as met the documented requirements, conforms to the specification, or every requirement was implemented points at verification. Wording such as fit for intended use, meets the operational need, or works in the environment it will run in points at validation. An option that produces excellent verification evidence is wrong for a validation stem no matter how rigorous it sounds, which is the trap behind an answer offering a complete requirements trace when the stem asked whether the system solves the right problem.

Habit two: match the evidence type to the claim

Once the question is fixed, check what kind of evidence the correct answer must produce. A claim about a runtime control needs a test, so document review and peer review are wrong regardless of how thorough they are. A claim about missing behavior or about design logic needs examination, because there is nothing to execute. A claim about roles, authorities, or coordination needs discussion with the people who hold them. The stem usually names the claim; the options usually differ by the method.

Habit three: distrust options that overclaim

Several recurring distractors are wrong for the same underlying reason, which is that they read a bounded result as an unbounded one:

The option says	Why it is wrong
A time-boxed penetration test found nothing, so no exploitable path exists	Failure to exploit within a scope and a schedule is an absence of evidence, not evidence of absence
The design document shows the control, so the control operates	Examination evidence cannot establish runtime enforcement
The tabletop went well, so failover works	Discussion establishes authorities and coordination, not technical capacity under load
The certified product is evaluated, so the deployment is assured	Assurance is bounded by the Target of Evaluation and the Security Target
Software composition analysis reported no vulnerable dependencies, so the application is secure	It says nothing about first-party logic
The planned control passed, so the risk is closed	Residual risk requires a disposition by the authorized decision maker
A cheaper control from the same family was substituted	A compensating control must satisfy the original intent for the same threat
The scanner report was delivered	Findings require triage, remediation, and verification

A worked reading

A stem describes a release that adds a new integration to an approved design, notes that the new feature was tested and passed, and asks what the architect should require before approval. The new feature passing is verification evidence for the new feature only. Two things are missing: regression evidence that the change did not invalidate a previously satisfied security property, and a reassessment of the threat model, because a new integration introduces a new trust relationship and a new data flow, which are exactly the conditions that expire a model. An option offering more testing of the new feature is answering a question the stem already answered.

Takeaway: identify verification or validation first, then the evidence type the claim requires, and eliminate any option that stretches a bounded result into a general guarantee.