Feature Requests

In STO, the "Issue Type" created by Harness from our SCA sarifs is labeled as "SAST" instead of "SCA". We do not manually set this field; it seems Harness is doing so automatically. Can we improve the automation detection rules set or add an option to manually select this field?

We would like that feature that allows the security scanner team to individually assess(approve/not approve) bulk exemptions that are raised by developers.

We received confirmation from the Harness team that currently there is no native support for executing STO scans directly on ARM infrastructure without relying on ingestion mode. As of now, the workaround involves running the scan in a separate run step, generating the scan file, and then using the STO step in ingestion mode to feed the results. https://developer.harness.io/docs/security-testing-orchestration/whats-supported/infrastructure/ We would like to request an enhancement to support direct STO scan execution on ARM infrastructure, eliminating the need for this multi-step workaround. This would streamline the process and improve integration efficiency for ARM-based environments.

There is a hard limit applied for number of occurrences where after an issue/vulnerability occurred for 1000 times in scan results, harness STO is not scrutinizing the other number of occurrences. Expected Solution: The STO should have an ability to report all the occurrences of the vulnerability/issue in scan results.

Hi Team, We are trying to execute the Harness inbuilt Checkmarx SCA scan step. We are referencing the 'checkmarx-job-runner' base image to add on few elements (like SCA resolver, package managers such as nuget, python etc) and use the built image to run the SCA scans using Resolver. Could you please create a new 'checkmarx-job-runner' base image that has python version 3.11 instead of 3.9 since the SCA Resolver executionEnvironment (cx-pip-python311-cli:fb1e8be) and a few dependencies in 'requirements.txt' or 'pyproject.toml' files are not compatible with 3.9 version and it fails the package resolution for python dependencies. Hence, this fails the build too. This is also required since the virtual env in the scan step is already created and pointing to 3.9 version because of the base image.

If two steps detect the same issue, the issue will be listed twice in the vulnerabilities page. This comes when we try to click on them and get the details. No matter which one we click, both of them are “selected” and the same issues detail pane comes up. When we click on an issue, only that one should be selected and the details for that specific issue should be displayed Internal JIRA: STO-9662

User Story: As a Security Engineer, I want to create and enforce policies based on the age of a vulnerability, so that I can automatically fail builds that violate our internal Service Level Agreements (SLAs) for remediation. Problem Statement / Business Justification: During a recent customer Proof of Value, their security team lead explained a critical part of their current governance process: they allow a specific "grace period" for developers to fix vulnerabilities based on severity (e.g., 5-10 days for a 'Critical'). After that period expires, any build containing that vulnerability is automatically failed. Currently, while Harness STO can identify the age of an active issue, this data is not exposed to the Open Policy Agent (OPA) engine. This prevents customers from automating this common and critical security SLA enforcement directly within Harness, forcing them to rely on manual tracking or external tooling. Adding this capability would significantly increase the value of our governance features and align the platform with mature enterprise security practices. Proposed Solution / Acceptance Criteria: The "age" of a vulnerability (i.e., the duration since it was first detected for a given target) needs to be made available as an attribute within the OPA input document during pipeline execution. AC 1: The STO data model available to OPA must include a field representing the vulnerability's age (e.g., age_in_days or a first_seen_timestamp). AC 2: A user can successfully write, save, and apply a REGO policy that references this new age attribute. AC 3: The pipeline correctly fails or passes based on the time-based policy. For example, a policy like deny if vulnerability.severity == 'Critical' && vulnerability.age_in_days > 10 must be enforceable.

As a security engineer, I seek to run SCA (software component analysis) scans as late in the CICD process as possible (shift right). However I do not want to block releases at this point. What I DO want is for vulnerabilities discovered at this late stage to auto request an exemption, and for the exemption to be automatically granted, and for the duration of the exemption to be configurable to my organizations SLO for remediating security findings. The vulnerability severity needs to be configurable, but for our needs it's High and Critical. Additionally, notification to myself, repo owners, security staff via email would be amazing.

In an STO pipeline with multiple stages, if any stage fails, the vulnerabilities tab does not display the scan results when the pipeline is re-run—even though the results were available in the original run. Please update this behavior so that the results are also shown on the rerun.

As a user of Harness Security Testing Orchestration (STO), I would like the ability to change or edit the severity of findings identified during security scans. Since the severity is not matching as per our considerations and the actual risk in our environment. Add an option to edit the severity of a finding directly from the findings dashboard. Implement role-based permissions to control who can change the severity of findings.