Make software verification a layered test plan, not a single scanner

Bottom line: no single scanner observes every useful class of software defect. Verification should combine techniques that examine design, source, built behavior, historical failures, included components, and relevant application interfaces, with the results tied to a specific release.

Source fact: what NIST recommends

NIST IR 8397 describes eleven broadly applicable software verification techniques. The publication includes threat modeling, automated testing, static code scanning, tools for possible hardcoded secrets, built-in checks and protections, black-box tests, code-based structural tests, historical tests, fuzzing, web application scanning where applicable, and attention to included code such as libraries, packages, and services.

NIST explicitly states that the listed techniques do not address the totality of software verification. They are presented as minimum recommendations, not as proof that software is free of defects.

What the source does not establish

The document does not prescribe one product, coverage threshold, severity gate, or test frequency. Running all eleven technique categories mechanically does not establish useful depth, correct configuration, complete scope, or responsible findings handling. A clean report may reflect a narrow test or a tool limitation.

Applicability depends on language, architecture, threat model, exposed interfaces, safety and business impact, third-party components, release cadence, and whether the organization controls source or receives only a binary or hosted service.

Applicability questions

• Which security properties and abuse cases must be verified for this release?
• Which techniques can observe design, code, dependency, build, and runtime failure modes?
• What code, generated artifacts, infrastructure definitions, and external services are in scope?
• What blocks release, who may accept residual risk, and how long can an exception remain?
• Can each result be reproduced against the same revision and test environment?

DSE recommendation: design complementary coverage

The following steps are DSE recommendations based on the cited source.

1. Start with the threat model and intended use. Define the properties, boundaries, misuse cases, and dependencies that verification must address.
2. Select multiple techniques because they answer different questions. Record why each applies, its scope, configuration, known blind spots, and expected evidence.
3. Pin every result to source revision, dependency state, build artifact, tool and rules version, test data, environment, and timestamp.
4. Triage findings through an owned process. Confirm material issues, record remediation or bounded acceptance, retest fixes, and prevent silent suppression.
5. Turn escaped defects into regression tests when practical. Review recurring findings for a design, training, dependency, or pipeline cause.
6. For acquired software, request verification evidence at a useful level without treating a vendor assertion or one scan report as a warranty.

Verification and evidence

Choose a recent release and produce the approved verification plan, threat model, tool configurations, raw and normalized results, findings decisions, retest evidence, dependency record, and release approval. Confirm that another qualified reviewer can connect every artifact to the deployed version.

Official references

• NIST IR 8397 — Guidelines on Minimum Standards for Developer Verification of Software — National Institute of Standards and Technology; finalized October 6, 2021
• NIST SP 800-218 — Secure Software Development Framework — National Institute of Standards and Technology