Feature Requests

Description: STO supports Linux arm64 across infrastructure types, but GitHub Advanced Security, Aqua Security and Mend are listed as exceptions in Supported Infra - https://developer.harness.io/security-testing-orchestration/use-sto/sto-scanner-configuration/shared/supported-infrastructures?utm_source=kapa On a Linux arm64 stage, the GHAS step in orchestration mode fails with exec /bin/ start.sh : exec format error, because the github-advanced-security-job-runner image is not built for arm64. In ingestion mode, the STO plugin starts and runs on the same arm64 stage. Request: Publish an arm64-compatible (multi-arch) GHAS job-runner image so the GHAS step works in orchestration mode on Linux arm64 build infrastructure. Impact: Teams are moving build workloads to arm64 for performance, sustainability and cost reasons. They often use a single stage template covering source scan, build, package and artifact scan on one architecture. Without arm64 support for GHAS, they must split scanning into a separate AMD64 stage, which means maintaining multiple stage templates and is hard to enforce across teams. The ingestion-mode workaround doesn’t help, because the CodeQL SARIF would still need to be generated on a separate AMD64 stage.

Currently, harness have the vulnerability's first discovered date available at the STO dashboard level, but this information is not available at the pipeline level. Having this information at the pipeline level is important to establish when a vulnerability was first introduced or detected, distinguish existing vulnerabilities from newly introduced ones, and enforce security gates to prevent new vulnerabilities from progressing through the deployment pipeline.

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.

Background As part of the rollout of PR gating and stage gating, exemptions are being used to provide developers with a defined period to remediate security findings when immediate fixes are not feasible. Effective communication and visibility of exemption status are critical to ensuring timely remediation and preventing unexpected deployment failures once exemptions expire. Current Gap Currently, there is no automated notification mechanism to inform stakeholders when: A new exemption is approved. An exemption is approaching its expiry date. An exemption has expired. An exemption request is approved or rejected.

At Present we are able to Approve security exemptions one by one. But there is an option for Bulk exemption creation similarly if there is Api option for Bulk approvals that would be great.

Request: Enable Harness OPA Policy Sets to select the Git branch used for policy evaluation and enforcement, instead of always using the repository's default (main) branch. Why: Allow teams to test and validate policy changes from a feature branch in an active environment before merging to main. Expected Behavior: When a policy set is configured to use a different branch (for example, feature/new-policy), Harness should load, evaluate, and enforce the OPA policies from that branch. Switching branches should immediately change the source of truth for policy enforcement, allowing easy testing and promotion of policy changes without impacting the default branch.

When a new exemption is requested for an SCA or SAST finding whose previous exemption has expired, we would like Harness to display the history of the previously approved exemption. Currently, reviewers need to manually investigate whether the finding had an earlier approved exemption and when it expired. Expected Behavior: When reviewing a new exemption request, Harness should indicate whether an exemption was previously approved and expired, along with its expiration date and previous justification, if available. This will help reviewers make informed decisions and avoid manual investigation.

When a new exemption is requested for an SCA or SAST finding whose previous exemption has expired, we would like Harness to display the history of the previously approved exemption. Currently, reviewers need to manually investigate whether the finding had an earlier approved exemption and when it expired. Expected Behavior: When reviewing a new exemption request, Harness should indicate whether an exemption was previously approved and expired, along with its expiration date and previous justification, if available. This will help reviewers make informed decisions and avoid manual investigation.

We are able to run Checkmarx scan in the pipeline using Harness built-in Checkmarx step. The security findings are ingested properly, but the Checkmarx SBOM is not automatically ingested. I've tried to solve this in the follow ways: I looked for a checkbox in the Checkmarx step to include SBOM, but it does not seem to have one. I think other scanners may have this, but not the Checkmarx step. This would be ideal solution, can Harness add it? I tried to configure Checkmarx CLI arguments so that it would write the SBOM on disk and in a subsequent step I could ingest it. But this does not work because Harness Checkmarx step assumes report-format is JSON, not SBOM and in a specific location. Checkmarx CLI does not seem to allow multiple output formats. I considered whether or not we can make a subsequent request to Checkmarx API to download SBOM, but Harness Checkmarx step does not make scan ID available in output. I'm not yet able to find a way to do this without dropping the Harness Checkmarx step directly and instead writing custom code.” We leverage checkmarks as our primary security testing tool. This tool has the ability to generate an S-bomb, and we would like to do so using the tool that we have. We will then inject the S-bomb in a later SCS step, but it seems that Harness does not allow generating the S-bomb in the built-in checkmark step We would also like Harness to output the scan ID in the checkmark step so that we can potentially download the SBOM from the checkmarks tool for later ingestion in an SCS step

We are required to rescan previously completed builds every ~4-hours to detect newly disclosed vulnerabilities and severity re-ratings. These rescans will be initiated on the backend (not by re-running the original pipeline execution). Today, Harness STO does not support updating the STO dashboard view for a specific historical build after a rescan. As a result, a vulnerability that is newly detected (or an existing vulnerability whose severity increases) is not reflected for the original pipeline execution/build in the STO dashboard. Requested Enhancement Provide a first-class “rescan” capability for historical builds such that: Rescan results can be associated to an existing build identified by pipeline execution ID and/or build number. STO preserves the original scan results (immutable snapshot) including the original scan date/time. When a backend rescan occurs, STO creates a new dated rescan entry/view for that same build and highlights what changed (e.g., new vulnerabilities, severity changes, updated counts). The STO dashboard for that build can show: --- Original scan (timestamped) --- Latest rescan (timestamped) --- Delta/change view between scans Why this matters This enables continuous vulnerability management for already-built artifacts and ensures the STO dashboard reflects the current security posture of prior builds as vulnerability intelligence evolves.