Reconcile scan records before approving a release

TL;DR: An assessment is useful only for the input and scope it actually examined. Bind each required result to the intended release and retain unsupported scope as an open decision.

Where you are. You have the component inventory; now determine whether the supplied reports support releasing the next worker image.

Treat each report as a scoped assertion

For this exercise the intended release is revision R2, artifact D2 and production plan P2. A release manifest names the required methods and their inputs before jobs run. That prevents a convenient existing report from redefining the gate after the fact.

The records are fictional. No live scanner is needed. Your job is to decide which claims survive these mismatches, which require new evidence, and whether a scoped exception has authority to permit release.

Compare the supplied records

The worker release is built from revision R2 into digest D2. The source-analysis report covers R1. The dependency report covers D2 but omits an optional document plugin. The infrastructure report evaluates module defaults, while production supplies different network variables. Every job is marked successful.

Create a release evidence manifest. For each assessment, record input identity, method, supported scope, rule version, result and time. Job completion is one field; the security conclusion is another. A completed analysis of the wrong revision cannot satisfy the required source assessment for R2.

Decide what remains valid

The dependency report can still describe the components it examined in D2. Preserve that evidence while marking the plugin gap. Do not discard an entire useful report because it is incomplete, and do not extend its conclusion to unsupported components.

The source result needs a justified applicability analysis or a fresh assessment of R2. The infrastructure result needs the actual resolved production plan. If a relevant value remains unknown after planning, keep it unresolved rather than assuming the default will apply.

Review a finding before proposing a repair

The dependency report identifies the parser package through a transitive dependency. Trace the path in the resolved build inputs. A direct manifest change may leave the vulnerable transitive version unchanged. Confirm the affected version and conditions before deciding that the proposed update addresses the finding.

Source findings need the same discipline. A dataflow report should identify input, sensitive operation and the relevant validation. A manual review may establish that an alert is inapplicable to this revision, but a blanket suppression would hide later code paths with different controls.

Set the release decision

Hold the required gate while evidence is missing, or use a named and bounded exception process. State exactly which assessment is absent and which risk remains. The gate should fail visibly if a report cannot be retrieved; an empty response must not look like an empty finding list.

After the corrected inputs are assessed, test legitimate document conversion alongside the denied unsafe case. A patch that stops every conversion is not a useful repair. Carry the evidence manifest forward, because the next lesson reviews who is allowed to produce and approve these records.

Evaluate evidence completeness before severity

A gate has at least three decisions: did the assessment finish, did it examine the required object and scope, and were its findings dispositioned under policy? Store those decisions separately. A parsing error in a report must not become an empty finding array. Likewise, “not applicable” needs a reason and approver; it is not another spelling of “not scanned.”

required = {
    "source": ("R2", {"api", "worker"}),
    "components": ("D2", {"base", "parser", "plugin"}),
    "secrets": ("R2", {"source", "history-policy"}),
    "infrastructure": ("P2", {"network", "identity"}),
}
reports = {
    "source": {"input": "R1", "scope": {"api", "worker"}, "status": "complete", "reviewed": True},
    "components": {"input": "D2", "scope": {"base", "parser"}, "status": "complete", "reviewed": True},
    "secrets": {"input": "R2", "scope": set(), "status": "error", "reviewed": False},
    "infrastructure": {"input": "P1", "scope": {"network", "identity"}, "status": "complete", "reviewed": True},
}

def gaps(records):
    missing = {}
    for method, (identity, scope) in required.items():
        row = records.get(method)
        reasons = []
        if row is None:
            reasons.append("missing report")
        else:
            if row["status"] != "complete": reasons.append("assessment incomplete")
            if row["input"] != identity: reasons.append("wrong input")
            if not scope <= row["scope"]: reasons.append("scope gap")
            if row["reviewed"] is not True: reasons.append("findings not reviewed")
        if reasons: missing[method] = reasons
    return missing

assert set(gaps(reports)) == set(required)
repaired = {name: {"input": identity, "scope": scope, "status": "complete", "reviewed": True}
            for name, (identity, scope) in required.items()}
assert gaps(repaired) == {}
del repaired["secrets"]
assert gaps(repaired) == {"secrets": ["missing report"]}
print(len(gaps(reports)), len(gaps(repaired)))  # => 4 1

This code validates a manifest projection, not a scanner's truthfulness. In a release system, authenticate the producer, constrain rule versions and bind the report to its immutable input. A contributor must not be able to satisfy the gate by editing the reviewed boolean. The release authority obtains approval from the trusted review workflow and checks its subject.

Work through a dependency disposition

The worker's resolved graph is application → converter → parser. An optional plugin can also load a separate parser version at runtime. Updating the application's direct dependency does not establish that either resolved path changed. Compare the lockfile, build output and runtime loading behavior; record unsupported dynamic installation as a scope gap.

A component inventory or SBOM says which components are reported to be present. It does not, by itself, establish reachability, vulnerable configuration or exploitability. Conversely, a static call graph that finds no path may miss reflection, plugins or native bindings. Preserve the assumptions behind a “not affected” disposition and expire it when the source, configuration or analysis changes.

For a source finding, ask the reviewer to identify the external input, transformation, authorization boundary and sensitive operation. The repair test should demonstrate the legitimate path and the prohibited path under the same contract. Do not publish an exploit payload to make that reasoning concrete; use harmless typed records and policy assertions.

Scope exceptions and rescans precisely

A report may remain valid for unchanged components while another part needs reassessment. Record that partial applicability rather than discarding useful work or pretending it covers everything. A rescan should preserve the input identity and method version so the reviewer can explain why results changed.

An exception names the exact finding or missing assessment, service, release, compensating control, owner and expiry. It cannot turn a provider outage into a clean result. Make the release decision reference the exception without rewriting the underlying evidence. When a required control remains unavailable, the default hold should be visible to both security and delivery teams.

Maintain a small independent regression set for the gate itself: missing report, wrong subject, incomplete scope, parser error, untrusted producer and expired exception. These tests exercise decisions the pipeline depends on. They are more useful than asserting that the dashboard renders the word passed.

Do this before moving on

Run the manifest checker, then fix one report at a time. Record why the release remains held after the first three repairs. Add a required assessment that has no supplied record and verify that the gate detects it.

Write a dependency disposition for the converter-to-parser path and the separately loaded plugin. Include version evidence, analysis limits, an owner and a condition that invalidates the disposition. Do not mark a plugin unaffected merely because it was absent from the scanner's inventory.

Review your result. The manifest retains all four original gaps and the valid partial component evidence. The fixed release names its actual revision, digest and plan. The disposition separates presence, reachable use and business exposure, and preserves unknown dynamic scope.

Go deeper

• Code scanning explains the observation made by each testing method.
• SCA traces advisory matches through the built dependency graph.
• Release evidence gap tests how the gate changes under an urgent release request.

Key takeaways

• Keep valid partial evidence without overstating its scope.
• Bind assessments to source, artifact or deployment inputs as appropriate.
• Unknown required checks need resolution or an explicit exception.