The scan whose result stopped reaching anything.
RA-5 (vulnerability monitoring and scanning) is the NIST 800-53 control that requires a system to be scanned for known vulnerabilities on an organization-defined cadence, including when a newly reported vulnerability is identified as potentially affecting it, using tools that can pick up newly identified vulnerabilities, with results analyzed and legitimate vulnerabilities remediated within the organization's own defined, risk-based response times. It does not prescribe any particular enforcement mechanism like a CI gate. It is a different obligation from patching a vulnerability you already know about, which is closer to NIS 2's cyber-hygiene point: RA-5 is about whether the monitoring and analysis mechanism itself still works, whether the scan runs, what it covers, and whether a result still reaches whatever is supposed to act on it. For CI-based scanning, part of that mechanism is configured in the workflow, in code.
The shapes the same control failure takes.
Vulnerability scanning weakens when a change narrows what gets scanned, how often, or whether a result still reaches something that acts on it. The recurring shapes:
An established gate is removed without a replacement
A scan step that used to fail the build on a finding gets a continue-on-error or allow-failure flag, and nothing else (a ticket, a tracked exception) picks up what it used to catch.
Scan scope narrows
A directory, image, or manifest is added to the scanner's ignore list to clear a stubborn finding, with nothing tracking that the exclusion should be temporary.
Scan cadence stretches
A scan that ran on every pull request, or re-ran when a newly reported vulnerability was identified as potentially affecting the system, moves to a rare or manual schedule, so a newly disclosed vulnerability can sit unseen for days.
The scanner's own data goes stale
The vulnerability database or feed a scanner depends on stops updating (a pinned scanner image, a disabled sync), so the tool keeps running but can no longer catch anything published after that point.
A finding is suppressed without a tracked fix
An ignore or suppress annotation is added for a specific advisory to unblock a merge, with no ticket, owner, or expiry attached to it.
A container scan whose enforcement quietly disappears.
The scan step is set up to fail the build on a High or Critical finding (exit-code: "1"), and it does: a release is blocked by a High-severity finding in a base image layer. The real fix means rebuilding on a newer tag the team has not tested yet, so someone adds continue-on-error to the same step to get the release out today, with no ticket or replacement triage opened for the finding it was catching. The scan keeps running on every build afterward and keeps reporting findings; they just stop reaching anything that acts on them.
- name: Scan image for vulnerabilities uses: aquasecurity/trivy-action@0.24.0+ continue-on-error: true with: severity: HIGH,CRITICAL exit-code: "1"The step was already configured to fail the build on a High or Critical finding (exit-code: "1"); continue-on-error is what removes that, and no ticket or replacement triage is opened for the finding it was catching. RA-5 expects scan results to be analyzed and legitimate vulnerabilities remediated within the organization's own defined, risk-based response times, not just produced. Fix the underlying finding or open a tracked, time-boxed exception, rather than quietly disconnecting the scan from anything that acts on it.
Scanning is checked by whether a result still reaches something that acts on it.
An assessment under NIST 800-53 looks at whether vulnerability scanning actually runs at the expected cadence, with tooling that can pick up newly identified vulnerabilities, and whether results get analyzed and legitimate vulnerabilities remediated within the organization's own defined, risk-based response times, not just whether a scan step exists in the pipeline. A scan whose enforcement was quietly removed with nothing else picking up its findings, whose scope narrowed, or whose cadence stretched onto a slower schedule is the concrete gap behind that, and it is visible in the diff to the workflow or its configuration.
A review, not your scanner.
heygrc flags changes that touch RA-5 and cites the control so the fix happens in the pull request. It does not run your vulnerability scans or triage your findings. It catches the moment a change disconnects a scan from whatever is supposed to act on its results, at the diff.