TL;DR: CVE remediation is not complete when a patch lands in source control; Finite State argues it ends only when the fix is verified in the shipped artifact and the evidence is retained, which is harder for firmware and fielded devices than for software you control directly. That makes artifact-level validation and product-specific prioritisation the decisive controls, not scan closure alone.
Editorial analysis by NHI Mgmt Group, based on content published by Finite State: “CVE Remediation for Devices You've Already Shipped”.
Key questions
Q: What breaks when a CVE is patched in source but not in the shipped artifact?
A: The remediation claim breaks, because the vulnerable code can still be present in the release image even when source control shows a fix.
A: Treat CVSS as a baseline, then re-rank findings using exploit intelligence, asset criticality, and internet exposure.
Q: What should security teams do first when a vulnerable service cannot be safely patched yet?
A: Start with a runtime mitigation that blocks the observed exploit path, not a broad rule that assumes every instance of the CVE behaves the same.
Practitioner guidance
- Verify the shipped artifact, not just the source tree Compare the vulnerable build and the fixed build at the binary level, then confirm the corrected code is present in the release image customers actually run.
- Separate patching from remediation decisions Classify each finding as patch, reconfiguration, compensating control, component replacement, or written risk acceptance so the closure path is explicit.
- Prioritise by reachability and exploitation evidence Use reachability checks, active exploitation status, and product exposure to rank findings ahead of raw severity scores.
Bottom line: CVE closure depends on proof that the fix reached the shipped artifact, not just the source repository.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →