Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
An AppSec lead sees fewer findings before a release, but cannot tell whether remediation improved or a scanner stopped reporting. A scanner coverage review gives the release discussion a defensible denominator: which assets needed assessment, which runs completed and where evidence is still missing.
Consider a fictional retailer with a checkout API, a receipt worker and a cloud account used for reporting. A pipeline change stops scanning the receipt image, while the checkout scan continues normally. This is an illustrative operational scenario, not a customer incident or a measured SecurityVault result. The proposed workflow below is a review method, not a universal scanning schedule.
Scanner coverage starts with expected work
A findings list contains observations that arrived. It does not, by itself, identify every asset that should have produced an observation. Start with an authorised inventory of repositories, build artefacts and environments, then specify the assessment expected for each relevant subject.
For the retailer, the checkout repository needs its configured source checks, the receipt image needs an assessment tied to its digest, and the reporting account needs its enabled cloud collectors. Do not combine these into a single claim that the business was scanned. They cover different objects and different classes of weakness.
The OWASP Vulnerability Management Guide describes preparation, identification, reporting and remediation as parts of a repeatable lifecycle. The practical recommendation here is to make preparation explicit: agree what belongs in the population before interpreting the resulting queue. Record exclusions with an owner and rationale instead of quietly omitting difficult assets.
Separate completion from the number of findings
Use distinct states for expected work: completed with results, completed with no reported findings, failed, incomplete, and not yet observed. These are suggested review labels rather than names of SecurityVault interface fields. A job that starts and exits before producing its required output is not equivalent to a successful empty result.
For each run, retain an identifier, assessed subject, start and completion times, tool identity, configuration reference and outcome. Where available, preserve the tool’s evidence of coverage and relevant limitations. A successful process exit is useful, but the reviewer also needs to establish that the expected report was produced and associated with the right subject.
In the receipt example, the last successful report belongs to the previous image digest. The current digest has no matching completed run. The appropriate conclusion is missing assessment evidence for that artefact, even if the previous report contained no findings. Do not silently reuse an older result to make the release display appear complete.
Scanner coverage needs an explicit reconciliation
Compare the expected population with the completed runs using stable identities. Repository names, mutable image tags and service display names can change or refer to more than one object. Retain the commit or digest and the environment context needed to understand the scope of the assessment.
An initial review can use a small table maintained in an approved system. Give each row the subject reference, expected assessment, observed run, evidence date, outcome and next owner. The important operation is finding unmatched expectations, not producing a larger spreadsheet of findings. Validate ambiguous matches before treating them as coverage.
The retailer now has three useful conclusions: checkout has current source-check evidence; the receipt artefact has a missing run; the reporting collector completed within its agreed scope. Those conclusions should remain separate. A complete cloud collection does not compensate for an unscanned application image, and source analysis does not establish cloud-account configuration.
Freshness depends on the subject and the decision
Choose freshness rules for the decision being made, with the relevant security and service owners. A new build identity can require new evidence even if the previous scan finished recently. Changes to enabled rules, target scope or advisory information may also change what an earlier report can support.
Avoid declaring one interval suitable for every workload. A frequently released service and an infrequently changed appliance have different operational constraints. Record the organisation’s chosen trigger, the evidence needed when it fires and what happens if collection cannot complete. A timestamp alone cannot establish that the report answers the present question.
For the retailer, a receipt-image change triggers a new assessment for that digest. A missing result creates an explicit release-review item with an accountable owner. This complements verification of remediation: proving that a particular fix is live and establishing that expected assessments ran are related but different responsibilities.
Investigate the gap before changing access
Trace a missing run through the expected workflow: scheduling, execution, report creation, transfer and association with the asset. Use existing authorised logs and job records. Capture the first point where expected evidence is absent, and distinguish an execution failure from a result that exists but was not ingested.
Suppose the pipeline change removed the receipt scan job entirely. Rotating a connector credential would not restore that job and would introduce another change to investigate. Conversely, a completed report rejected during ingestion needs a different repair. Keep credentials and raw sensitive payloads out of the coverage record; link to access-controlled diagnostic evidence.
After correcting the cause through the normal review process, rerun the assessment for the intended subject and verify the result reaches the right record. Preserve the earlier gap and its resolution. Do not backdate a new report or imply that restored collection proves there was no exposure during the missing interval.
Report uncertainty alongside remediation progress
Present coverage gaps next to the remediation queue so a lower finding count cannot automatically become a claim of lower risk. Useful measures include expected subjects, completed assessments and unresolved gaps, with the time window and population definition attached. Avoid comparing periods with different populations without explaining the change.
NIST SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology (April 2022) includes verification within enterprise patch management. That supports preserving evidence of the outcome rather than relying only on work being scheduled. It does not prescribe the exact coverage table or release policy proposed here; those remain organisational design choices.
Exercise the process with a synthetic packet before depending on it: one current report, one failed job and one report for an old digest. Ask a reviewer to identify the missing assessment and next action without being told the intended answer. Record confusing identities and inaccessible evidence links, then improve the handoff. This tabletop check is not an exploit test or proof of complete detection.
Key takeaways
- Define the expected asset and assessment population before counting results.
- Keep successful empty results separate from failed or missing runs.
- Match evidence to the subject and decision it actually supports.
- Restore collection with an accountable owner and preserve the gap history.
How SecurityVault approaches this
SecurityVault’s integration overview describes bringing source and asset context into investigations and exposing connector health through dashboards and alerts. That is relevant when an AppSec team needs to investigate why expected evidence stopped arriving. Connector health is one part of the review; it does not by itself establish that every expected asset received every required assessment.
Its vulnerability management workflow connects findings with affected software, ownership and verification context. For the retailer, the intended business outcome is a release conversation in which the receipt artefact, its missing assessment and the responsible team can be discussed together, rather than interpreting a smaller queue as assurance.
Evaluate that workflow against your own expected population and supported integrations. Include an intentionally missing run and an older artefact reference so the evaluation exposes uncertainty as well as successful results. Bring one service and its scan-evidence handoff to a SecurityVault demo and discuss how your team will account for missing assessments before the next release.