Native Grace Periods For NVD-Updated Findings In Harness STO
I
Innocent Deer
Harness STO should provide a native solution for handling vulnerabilities that become blocking because of frequently updated NVD or scanner intelligence data.
Today, a deployment can be blocked even when no code has changed because NVD data changes after the artifact was built. Examples include a newly published CVE, an updated CVE record, a CVSS score increase, or scanner data refresh that changes the finding’s severity or policy status.
Harness should distinguish these NVD-updated findings from older unresolved vulnerabilities and allow DevSecOps teams to configure a grace period for them directly in the Harness UI.
The UI should support configuration such as:
Grace period duration, for example 24, 48, or 72 hours
Which severities qualify for grace period handling
Whether grace period applies to newly published CVEs, updated CVEs, CVSS escalations, or first-detected findings
What happens during the grace period, for example warn only, notify, create obligation, or route to exemption workflow
What happens after the grace period expires, for example hard gate future deployments
During the grace period, Harness should surface the finding clearly in STO and pipeline results, but not hard-gate the current deployment if the policy is configured that way. After the grace period expires, the same finding should become blocking unless fixed or exempted.
The STO UI should clearly show:
Why the finding is currently allowed
The NVD published or updated timestamp
The grace period expiry timestamp
The remaining time before enforcement
The expected developer action
This would reduce unexpected deployment failures caused by NVD data refreshes while still preserving security accountability and giving teams a defined timeline to remediate or request exemptions.
Log In
I
Innocent Deer
This grace period capability should also support exemption SLAs. Because remediation timelines vary by customer and severity, Harness should allow customers to configure grace periods per severity and treat qualifying new vulnerabilities as covered by a system-applied temporary exemption until the configured SLA expires. For example, a customer may configure Critical findings with a 7-day grace period and High findings with a 30-day grace period.
Could we prioritize the exemption grace period capability before the NVD/scanner intelligence grace period?
This would immediately help development teams by reducing the need to raise repeated exemptions during the development phase. When combined with 'Show Grace-Period Findings As Disabled In Current Scan' feature, it would also provide better visibility inside pipeline builds for vulnerabilities covered by temporary exemptions, especially those approaching expiry.