Feature Requests

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.

Harness STO should show grace-period or soon-to-be-enforced findings in the current scan results in a disabled or non-blocking state. These findings should be visible to developers, but clearly marked as not requiring immediate action in the current build. The UI should explain that the finding is currently allowed because it is within a configured grace period, but will block future deployments after the grace period expires. The current scan section should display: Finding details Grace period expiry date/time Reason it is currently non-blocking (Expiring Exemption/ NVD update grace period/No Fix/ Transitive/zero day/Reachability/ Exploitability) This gives developers clear visibility without creating confusion or unnecessary urgency during the current build.

Harness STO should provide context-aware vulnerability gating across all CVE-based scanners, not just basic severity-based OPA policies on critical and high. Current severity-only policies cannot distinguish whether a finding is reachable, exploitable, transitive, newly updated by NVD, or has no available fix. Harness STO should normalize and expose richer vulnerability context to both OPA policies and the STO UI, including: Reachability status: reachable, unreachable, unknown Exploitability and zero-day indicators Direct vs transitive dependency status Fix availability and fixed versions NVD published and updated timestamps Ability to configure OPA policy rules that account for this context, such as excluding unreachable or non-exploitable findings, treating transitive dependency findings differently, and applying grace periods for newly published or recently updated NVD findings. The STO UI should clearly distinguish zero-day, unreachable, transitive, no-fix, and NVD-updated CVEs so developers can quickly understand why a vulnerability exists, how urgent it is, and what action is expected. This would reduce unnecessary deployment blocks, save developer effort, and make vulnerability gates more meaningful and actionable.

Harness exemption approvers look at the "5mins ago" text under the "Requested By" column from Exemptions screen to define an SLA between the Approvers and Engineering teams. Exemptions have to be reviewed and actioned upon within the agreed SLA. When an Approver rejects the ticket and instructs the developer to follow certain steps and raise another exemption Developers may take 12hrs or 24hrs or even an hour to make the recommended changes and re-raise the exemption We have observed that the same issue now shows that this exemption was raised "12hrs ago" or "24hrs ago" or even "an hour ago" Even though the developer worked on our suggestions and took 24hrs to re-raise the exemption, the Harness exemptions page must show "5mins ago" instead "2hrs ago"

We want to remove the specific value "For All Time" field for the "how long?" field. Ideally, being able to customize the values in the drop down would be the goal. Specifically, we want to remove For All Time, because the developers want to submit exemptions with the max time, but there are no reasons why we would allow a "for All Time" value. It doesn't appear that OPA allows us to control value or control the submission routine. This causes problems for us because it adds unnecessary delays when people submit a request for "For All Time"

Requirements: Critical severity: Auto-select and limit to maximum 7 days High severity: Auto-select and limit to maximum 30 days Disposition options: Allow users to categorize issues as either "False Positive" or "Risk Accepted" False Positive: Enable "All time" duration Risk Accepted: Limit to maximum 180 days and automatically re-open the issue after expiration The system should prevent users from selecting non-compliant durations based on severity and disposition rules. Previous request we had : https://support.harness.io/hc/en-us/requests/94519

I need asset id tag that is already added for a project to be displayed in the STO reports that we are exporting/downloading

This is in relation to a previous ticket I have had open working with the Harness Reps. Specifically ticket #110470. Based off my discussion with Harness, Grace policies are only able to be created through a very manual process that is only possible by manually selecting findings/flaws after a scan has been completed. After that is completed, then you have to modify the existing OPA policy associated with that project. My suggestion here for a request is to update that process. Following Veracode specifically, as I have discussed with Abhishek Sahu, Veracode allows you to create a policy that can be associated to all projects and findings based on the discovered date. If a flaw is found on X day, then 30 days after the discovered date is when the pipeline will fail if left unfixed. Instead of it being a manual process, it should be added as a feature that will automatically be captured by Harness and its findings database. TL:DR Grace periods that are automatically catalogued instead of manually.

Current behavior: Exemptions in STO expire only on the date explicitly set at grant time (or never, if granted permanently). When the underlying vulnerability is actually remediated, the exemption remains in an "active" state until its configured expiration date. It continues to show up as an active exemption in reporting, dashboards, and audit exports. Impact: Stale exemptions accumulate over time and pollute our risk reporting. It becomes difficult to answer "what risk are we currently accepting?" without manual reconciliation between active exemptions and current scan findings. Audit and compliance reviews require manual correlation to prove each active exemption still corresponds to a real, present finding. Requested behavior: We would like STO to detect when an exempted issue no longer appears in scan results and then transition the exemption to a distinct terminal state (e.g., "Remediated / Inactive") so that it's clearly differentiated from "Expired" or "Rejected."

In harness STO, user is not able to raise the multiple exemptions at once if there is more than one vulnerability in a pipeline.