Feature Requests

When designing the STO dashboard, the following enhancements should be considered for its auto-explore functionality: Issue Criticality Details: Currently, the explore feature displays only the issue ID and a list of associated pipelines. However, it lacks hyperlinks for the pipelines, making navigation less intuitive. Target Type Details: The dashboard currently displays the target type as "container" but does not provide additional details about the container, limiting the available context.

We found information on the official Veracode website indicating that the --baseline-file flag can be used. This flag specifies the location of a JSON file containing results from a previous scan, with the default filename being result.json. To create a baseline file, the --results-file flag must also be included. However, when we attempted to use the --baseline-file or baseline-file result.json flag, it was marked as invalid. Could you please consider adding support for the Baseline File flag in the Veracode Scan?

STO has it's own way of calculating vulnerabilities than that of the scan tool. We'd like the ability to use the specific calculation of the scan tool instead of what STO returns. For example, we have a medium severity vulnerability reported by Prisma Scan that Harness is reporting as high/critical. Although Harness does provide the raw scan results from the scanner, we'd like the ability to set the default results to be from Prisma instead of taking the calculation from STO in the Harness UI.

Coming from a customer request, they would like the ability to perform similar policy-based STO enforcement on their NexusIQ scans. They would also like a template-step experience for it as well. https://developer.harness.io/docs/security-testing-orchestration/sto-techref-category/sonarqube-sonar-scanner-reference/#view-sonarqube-code-coverage-results https://help.sonatype.com/en/policy-violation-rest-api.html

In harness STO platform, we need a centralized view of exemptions raised across all the projects. Also, whenever there is an exemption raised, there should be an notification shown/sent.

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

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

We have done STO Sonar integration for our dotnet services and it has been working fine. We are trying to do the same for our windows services, but I'm getting the below error in the Initialize step, 'Back-off pulling image " gcr.io/gcr-prod/harness/sto-plugin:latest "' As suggested in the ticket ( https://support.harness.io/hc/en-us/requests/63663 ), I'm applying Ingestion method for the Sonar and Veracode STO evaluations. https://app.harness.io/ng/account/H6rHO8vtQYKelD_wgjnMpA/all/orgs/AODevSecOps/projects/SandBox/pipelines/POCWindows2/executions/QiCniWtjS5WGL9vP_xAvJA/pipeline?storeType=INLINE Later, we came to know that STO ingestion with Windows OS is only supported when you run the build on Harness cloud. But we are running on our own k8s cluster. Hence I'm submitting this feature request to get the STO support for windows. Regards, Janish

Currently, Jira creation from the pipeline is proxied through the delegate, while Jira creation from STO initiates directly from the server. In cases where this involves a protected Jira instance (e.g., passing through a firewall to an on-prem Jira), the STO call won’t be allowed unless firewall settings are adjusted.

Similar to how CI can pull JUnit.xml from both the Test-specific steps as well as any arbitrary Run step in CI stages, it would be awesome for Run steps to have an option to pass the location of a SARIF or STO-formatted JSON, as well as the Target/Variant information, to effectively remove the requirement for a downstream Custom Ingest step and save on overall build time and maintenance.