Feature Requests

We need the output file for the twistcli scanner. Currently, the Prisma Cloud step copies that file to an internal location and then performs it’s own logic for Harness STO. I would like a simple way to gain access to the file without breaking the Harness STO as we still want to see the scan results as part of Harness STO. I can create my own template to replicate what Harness already does and gain access to the file, but I think a simple flag on the current Prisma Cloud step that produces an output file would be a great feature for teams that need access to the raw scanner data.

Ref request/ticket: #124169 The current Wiz normalizer treats all failedPolicyMatches returned by Wiz as EXTERNAL_POLICY_FAILURE, without distinguishing between AUDIT and BLOCK enforcement methods. As a result, an AUDIT policy match can currently contribute to the EXTERNAL_POLICY_FAILURE count and trigger the OPA policy for failure. We want to segregation for this to avoid pipeline failures.

Improve the visibility, consistency, and synchronization of finding/vulnerability states and related triage information between Harness and Checkmarx CxOne. The goal is to ensure that developers and AppSec teams see a consistent and meaningful representation of a finding regardless of whether they are working in Harness or Checkmarx. REQUIRED IMPROVEMENTS STATE AND STATUS SYNCHRONIZATION The ongoing effort to implement synchronization between Harness and Checkmarx should cover all state-changing actions related to Checkmarx findings/vulnerabilities. Synchronization should include, where supported by the respective APIs: Finding state/status changes Comments and predicates/reasons Exemption requests Exemption approval or rejection Exemption expiration dates Other relevant triage metadata Synchronization should work in the required direction depending on the workflow: Checkmarx -> Harness Harness -> Checkmarx Changes performed in either platform should not result in conflicting or misleading finding states. STATUS MAPPING BETWEEN HARNESS AND CHECKMARX Harness-specific statuses and exemption reasons must be mapped to meaningful Checkmarx states or predicates. Examples of Harness exemption reasons include: False Positive Acceptable Risk Acceptable Use Fix Unavailable Compensating Controls Other The integration should define an explicit mapping between these values and the appropriate Checkmarx state/predicate. A generic Harness status such as "Remediated" must not be displayed when the underlying Checkmarx finding has not actually been remediated. EXEMPTION EXPIRATION Harness allows an exemption request to specify an expiration period through the "For how long?" option. If Checkmarx supports an equivalent expiration date or validity period through its APIs, this information should also be synchronized. Expiration should remain consistent between both systems so that a temporary exemption in Harness cannot become an indefinite state in Checkmarx, or vice versa. FINDING INFORMATION VISIBILITY In general, all useful information provided by Checkmarx for a particular finding/vulnerability should also be available in Harness, provided that the information is exposed through the Checkmarx APIs. This should especially include information that helps developers and AppSec teams: Understand the vulnerability Validate whether the finding is applicable Triage the finding Determine remediation options Understand previous triage decisions Review comments and reasoning Understand the current Checkmarx state Identify exemptions and their expiration Navigate back to the corresponding Checkmarx finding when deeper investigation is required Harness should provide enough Checkmarx context that users do not need to switch to Checkmarx for basic triage and remediation information. RBAC AND APPROVAL WORKFLOW The RBAC model for security findings in Harness needs to be clarified and potentially adjusted. Currently, even as an AppSec member, the available action appears to be limited to "Request Exemption". The expected workflow should distinguish between developer and AppSec responsibilities. Developers should be able to: Review findings Add relevant comments or justification Request an exemption or state change Propose an appropriate reason, such as False Positive or Acceptable Risk or Not Exploitable AppSec should be able to: Review developer requests Approve or reject exemption/state-change requests Perform security triage Update relevant finding states where appropriate Add or update security comments/predicates Manage or override exemptions according to the defined governance model A developer-requested risk acceptance, false-positive classification, or equivalent security decision should not become authoritative without the required AppSec approval. CONFIRMED / TO_VERIFY WORKFLOW Currently, AppSec members also appear unable to explicitly triage a finding and mark it as "Confirmed", which is possible in Checkmarx. This needs to be clarified. There are two possible approaches: Option 1 - Expose an explicit Confirmed action in Harness AppSec can review a TO_VERIFY finding and explicitly confirm that the vulnerability is valid. Option 2 - Treat the absence of an exemption as implicit confirmation If the Harness workflow intentionally does not require a separate Confirmed state, this behavior should be clearly defined and documented. The preferred solution should ensure that the Harness representation remains semantically consistent with the underlying Checkmarx finding lifecycle. EXPECTED OUTCOME Harness should provide a consistent security finding lifecycle in which: Checkmarx remains synchronized with relevant actions performed in Harness. Harness accurately represents the current Checkmarx state. Status labels cannot incorrectly imply that a vulnerability has been remediated. Triage comments, reasons, exemptions, and expiration dates remain synchronized. Developers can request security decisions. AppSec can review, approve, reject, and perform security triage. Sufficient Checkmarx finding information is available directly within Harness for effective triage and remediation.

We are requesting native support for Snyk Reachability Analysis metadata (or generic custom SARIF properties/tags) in the Harness STO UI. Currently, when ingesting Snyk results using the native type: Snyk step, Harness STO's normalization engine strips out custom SARIF properties and tags. As a result, our developers lose all visibility into the reachability status of their vulnerabilities in the STO dashboard. Please add the ability to display Snyk Reachability states (e.g., "REACHABLE", "NO PATH FOUND") natively in the STO UI. This feature is critical for our teams to filter out non-exploitable vulnerabilities and reduce security triage noise.

Hi Team, Could you please enable the OIDC based authentication for JFrog Artifactory connectors for our tenant. Many Thanks in advance! Best Regards, Sri

by default we are getting results of Sonarqube and prisma scan under "vulnerabilities" tab for a CI build.. I know we could control with filter which report we want to see and as of now there is no way we can disable the sonarqube SAST scan report.. looking for some flag setting in either sonarqube and/or prisma where users will have control to disable the reports.

Please enable STO_ENABLE_BULK_EXEMPTION for our account. Thank you!

When running Wiz scans in Harness STO, external policy failures are surfaced in the Vulnerabilities tab as an External Policy Issue Type. However, the individual violations and issues that are tied to the failed external policy are not visible in the issue list view, even though this detail is present in the raw data of the reported issue. What I can currently see: External Policy failure issues listed in the Vulnerabilities tab Raw data for each issue which contains the violated policy details What I would like to see: The specific external policy that caused the issue to be displayed within the STO Vulnerabilities issue list view The individual violations/issues tied to the failed external policy to be visible and accessible from the issue list, rather than only being available in the raw data

We have multiple CVE's that are impossible to patch (either because they're disputed or won't be patched), but we have to exempt them each time they pop up. Being able to exempt at the CVE ID level would help allow us to minimize the friction developers get.

Teams that run a vulnerability-remediation SLA off STO need a single per-issue dataset to compute remediations completed inside vs. outside SLA. When the SLA is driven by a combination of CVSS, EPSS, and Reachability, the report needs all of these in one place, per issue: Issue (CVE / title) CVSS score EPSS score (and percentile) Reachability Found date (first detected) Remediated date (when the issue was resolved) Today the Issues list (Active Issues / All Issues) exposes only Severity, Issue Type, Title, Targets Impacted, Occurrences, Last Detected, Tickets, and Status. It does not surface EPSS, CVSS, Reachability, or an explicit found/remediated date pair. The All Occurrences dashboard already carries most of this (EPSS Score and Percentile, Reachability, CVSS, First Seen) and exports to CSV, but it is a separate surface from the Issues list, it is Enterprise and limited-availability, and it has no explicit "remediated date" column (only Status = Remediated plus Last Seen as a proxy). In practice its EPSS data can also come through sparsely populated, which pushes users to stitch EPSS in externally. ## What we need Expose EPSS (score and percentile), CVSS, and Reachability as columns in the Issues list (Active Issues / All Issues), not only on the dashboard. Add an explicit remediated-date field alongside found date, so in-SLA vs. out-of-SLA remediation can be computed directly from the Issues surface. Make the combined dataset exportable as a first-class report from the Issues list. Clarify and, where applicable, populate Reachability for Snyk-based scanning setups (see below), since Reachability is one of the SLA inputs. ## Why it matters Without a consolidated dataset on the Issues surface, teams cannot compute in-SLA vs. out-of-SLA remediation from STO natively. They fall back to exporting from a separate dashboard and joining EPSS and Reachability in externally, which defeats the point of reporting from STO and blocks adoption of STO as the system of record for remediation SLAs. ## Related Reachability data source: for Snyk-only scanning setups it is currently unclear whether Snyk's native reachability output is ingested into STO's reachability field, or whether reachability is derived only from Harness scanners. This gates the Reachability portion of the ask and is being clarified separately. A near-term follow-on is using EPSS and Reachability as OPA pass/fail criteria (for example: a Critical CVE deemed not reachable with EPSS <= 0.1 should not fail a build, while a High CVE deemed reachable with EPSS 0.5 should). ## Use case A security team onboarding STO wants to run its internal vulnerability-remediation SLA report directly from STO. SLA priority is determined by CVSS, EPSS, and Snyk reachability. They need one exportable dataset per issue (CVE, CVSS, EPSS, Reachability, found date, remediated date) to show which remediations landed inside vs. outside SLA.