Feature Requests

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.

Harness Wiz step plugin support with Wiz CLI v1.x

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.

Hello team! I've been trying to use Harness Caching in a SecurityTests stage, but I have since found out from this support ticket ( https://support.harness.io/hc/en-us/requests/109850 ) that it is not supported. The UI and schema show configuration fields for caching, so my assumption initially was that it was supported like it is in the CI stage. Could you please enable caching support for SecurityTests stages? Thank you!

When STO baseline regex set in account level is changed, project level baselines are not updated for existing targets. In reference to https://support.harness.io/hc/en-us/requests/109863 .

Currently, the Harness STO SonarQube step fails to retrieve the Quality Gate status when integrating with SonarCloud (the SaaS version of SonarQube). During the pipeline execution (both in Extraction and Ingestion modes), the step successfully fetches vulnerabilities and code smells but consistently fails at the final Quality Gate check with the following error: Root Cause: Through debugging and confirmation from Harness Support ( https://support.harness.io/hc/en-us/requests/110004 ), we identified that the STO runner makes the following API call to fetch the Quality Gate: GET /api/qualitygates/get_by_project?project=<project_key> While this works for self-hosted SonarQube instances, SonarCloud’s API strictly requires the organization query parameter alongside the project parameter. When testing manually via curl, the API call succeeds only when formatted like this: GET /api/qualitygates/get_by_project?organization=<org_key>&project=<project_key> Because the Harness runner omits the organization parameter, SonarCloud rejects the request with an HTTP 400 error, which the runner misinterprets as a permissions issue. Expected Behavior: The Harness STO SonarQube step should support passing an organization parameter (either by extracting it from the connector/settings or providing a dedicated input field in the step configuration) and append it to the /api/qualitygates/get_by_project API call when querying SonarCloud servers. Workarounds Attempted: Verified Sonar token has full Administer/Quality Gate permissions at both the Project and Organization levels. Tested both Extraction and Ingestion modes. Tested passing the organization parameter in the settings/tool blocks. Rolled back to older runner tags (e.g., 1.68.0). None of the above resolved the issue, as the parameter is hardcoded out of the specific API call.

Invicti is globally used by us. We would appreciate DAST Scanning support in Harness. https://www.invicti.com/