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.