Cybersecurity / Advanced: architecture, recovery, and governance / Lesson 17

Security verification and the software supply chain

Trace security requirements to proportionate tests, reviewed dependencies, and release evidence. Distinguish artifact identity and provenance from a claim that software has no vulnerabilities.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Use versioned ASVS references and SSDF practices with explicit scope.
Evaluate dependency and provenance evidence without overstating assurance.

Select and version the verification requirement

OWASP ASVS supplies application security requirements that can inform design and verification; the stable 5.0.0 release was published in May 2025. Pin the version and selected identifiers because requirements can move between releases. NIST SSDF Version 1.1 describes secure-development practices across preparation, software protection, secure production, and vulnerability response. These resources are complementary rather than a single automatic compliance score. Choose requirements from the service’s data, trust boundaries, and harm scenarios, then state who owns each decision and what evidence is proportionate. A tutorial’s local labels must not be presented as real standard requirement numbers.

Make the evidence chain reviewable

The record below links a fictional organization-scope requirement to planned verification. The identifiers are explicitly local, and evidenceState remains planned so a written test reference is not mistaken for a passing result. A real record should identify the source version, applicability reasoning, implementation, test method, observed result, environment, and known limitations. Include expected refusal and error handling as well as ordinary success. Traceability helps a reviewer ask whether the chosen evidence actually supports the requirement; it does not turn a spreadsheet, dashboard, or JSON file into a security control by itself.

json A local requirements-to-verification link

{
  "localRequirement": "LOCAL-ORG-SCOPE-01",
  "behavior": "record reads retain the authenticated organization scope",
  "standardSelection": "versioned-ASVS-selection-recorded-separately",
  "owner": "portal-maintainer",
  "verification": ["same-scope-unit-case", "different-scope-unit-case"],
  "evidenceState": "planned"
}

Expected meaning: two planned cases address one local behavior, but no pass, ASVS identifier, or certification is asserted. The actual standard selection and evidence must be reviewed separately.

Know what entered the build and why it is trusted

A dependency inventory or software bill of materials describes components and versions within its declared coverage; it does not prove that every component is safe or that runtime use is correctly configured. Review direct and transitive dependencies, update ownership, support status, advisories, and acceptable sources. Artifact digests identify expected bytes only when the reference is protected. Provenance can describe source, builder, inputs, and production steps, but its authenticity and policy acceptance also need verification. A valid signature from an unexpected identity is not automatically approval. Keep the build environment and release privileges within the threat model.

Test a narrow local evidence policy

This pure Python example finds requirements with no accepted evidence state. It uses invented metadata rather than scanning a repository, installing packages, or evaluating a real artifact. The expected missing record is the dependency-origin review. Changing its text to passed would satisfy this small bookkeeping function without proving any verification occurred, which illustrates the limit of metadata gates. A real release decision needs authenticated evidence, appropriate reviewers, matching artifact identity, and a defined response to gaps. Automated checks should make missing evidence visible while preserving the distinction between a recorded claim and demonstrated behavior.

python An offline metadata completeness policy

required = {"LOCAL-ORG-SCOPE-01", "LOCAL-DEPENDENCY-ORIGIN-02"}
evidence = {
    "LOCAL-ORG-SCOPE-01": {"state": "passed", "artifact": "synthetic-build-a"},
    "LOCAL-DEPENDENCY-ORIGIN-02": {"state": "planned", "artifact": "synthetic-build-a"},
}
missing = sorted(r for r in required if evidence.get(r, {}).get("state") != "passed")
assert missing == ["LOCAL-DEPENDENCY-ORIGIN-02"]

The assertion reports the planned dependency review. It does not authenticate evidence, verify signatures, analyze packages, or authorize a release. All component and artifact labels are synthetic.

Keep assurance claims bounded through change

Unit tests cover declared cases, dependency tools cover their databases and supported analysis, and manual review depends on scope and expertise. Passing one method does not establish absence of all vulnerabilities. Record exclusions, false positives, untested paths, and the evidence version used for a decision. Reassess relevant requirements when a dependency, build identity, permission, or interface changes. Define remediation ownership and time-bound exceptions rather than hiding failures behind a green dashboard. The practical objective is a defensible connection between service requirements, artifact identity, safe verification, remaining risk, and an accountable release decision, without scanning or exploiting any live environment.

Common errors and fixes

A green dependency report is called complete security assurance

Why it happens: Tool coverage and vulnerability knowledge are treated as exhaustive.
How to fix it: State scope and combine appropriate evidence for the requirement.
Prevent it next time: Review exclusions and residual risk in release decisions.

A signature is accepted without checking expected identity

Why it happens: Cryptographic validity is confused with policy authorization.
How to fix it: Verify trust, identity, artifact binding, and approved production context.
Prevent it next time: Record the accepted provenance policy before ingestion.

An unversioned ASVS identifier changes meaning

Why it happens: A moving reference was used as a fixed requirement.
How to fix it: Pin the release and review mappings when upgrading it.
Prevent it next time: Keep requirement version with the test and release evidence.

Check your understanding

1. A package inventory lists every declared direct dependency. What remains unproven?

Show worked solution

It may omit transitive, build-time, generated, or runtime components, and inclusion does not establish safety, support, configuration, or trusted origin. State the inventory’s coverage, verify required provenance and advisories, and connect those checks to the actual released artifact.

2. Both scope unit cases pass. Can the release state that all ASVS requirements are verified?