Feature Requests

When testing a policy against a pipeline execution, there is no filter for the name of the pipeline. The filters are "Entity Type", "Organization", "Project" and "Action". Can you add an input box to filter the pages of pipelines that come back in the existing results? This would make it much easier to find the correct pipeline rather than scrolling through pages of pipeline executions, especially if the pipeline was not recently executed.

We are looking for a centralized mechanism within Harness where policy exceptions can be recorded, reviewed/approved with validity periods, and then automatically considered during OPA policy evaluation so that approved exceptions do not result in policy enforcement failures. With this managing and tracking OPA policy exception within the Harness UI would really help to provide better control.

We’re building a fleet solution for Spinnaker. When a user hits the global load balancer at spinnaker.prod.aws .[domain].net/<user_seal_id>, an NGINX service consults a router service to determine the user’s dedicated Spinnaker instance and then routes the request to that instance. Routing works today, but the browser URL updates to the underlying fleet instance. Instead, we want users to always see the global URL while transparently serving content from their assigned instance. The goal is per-user instance routing (decided by the router service) with the instance address fully hidden behind the global endpoint, including for a session across Deck/Gate.

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.

I am trying to setup this logic where if this secret exists on the acount level, use that secret, if it does not, use the value "No API KEY". 'IDP_SERVICE_API_KEY: <+<+expression.isResolved(<+secrets.getValue("account.nfr-testing-idp-api-key")>)>?<+secrets.getValue("account.nfr-testing-idp-api-key")>:"No API Key">' However, when I try to use this method, I get this error: 'io.harness.exception.ngexception.CIStageExecutionException: Unable to get secret information : [nfr-testing-idp-api-key] with scope: [ACCOUNT]' Is there a way in Harness where if I try to access a secret key and it does not exist, could it then default to a text to avoid this error. Thank you. Link to pipeline - https://app.harness.io/ng/account/AbxyMx_xQDyZL99AYBGckQ/all/orgs/Testing_Team/projects/TFSTestingPlatform/pipelines/Microservice_CD_Component_Testing/deployments/Y9U7oDw6SpqGAUCNwhjMgA/pipeline?connectorRef=account.Shared_Services&repoName=pipeline_testing_template&storeType=REMOTE

We want access to larger macOS runner tiers (large/extra large) for their iOS build pipeline. Currently limited to MacOS (small), our app build takes 25-30+ minutes on the Archive step alone due to Swift Package Manager dependency resolution and full xcodebuild archive compilation. A higher CPU/RAM tier would significantly reduce build times.

We currently make full use of the Jira Integration and Jira Templates. We also make sure of the Security Events and Threat Activities views and have saved filters there. It would be of extreme value and use to be able to create a full automation that would pick up anything that populates under those events or activities and automatically generates a Jira Story.

As of today, each account has a Feature Flag limit at the account level. My customer has several different orgs and projects within their account and they would like to see a flag limit be able to be imposed at the project level or at least organization level. The use case here is for governance to ensure one project/org doesn't use up all of the accounts flags and take them away from others. This is to ensure each project doesn't hit their limit and to encourage flag hygiene.

Summary: The UI currently limits the TTL input for ephemeral environments to a maximum of 24 hours (hh:mm:ss), even though the backend supports TTL values greater than 24 hours. This prevents users from configuring longer-lived environments directly from the UI. Expected Enhancement: Update the TTL picker to support durations greater than 24 hours (e.g., days + hours) and correctly display the updated expiration time. Customer Impact: Customers requiring environments to run longer than 24 hours (e.g., 36 or 48 hours) must manually extend the TTL before expiry, resulting in a poor user experience and operational risk.

Secrets referenced through JEXL expressions, for example <+secrets.getValue(" account.my _secret")> inside step settings, plugin configs, or shell scripts, are resolved at runtime but are not recorded as references. As a result, the Referenced By tab and the Secrets API show zero usage even when the secret is actively used by live pipelines. Request: detect and track expression-based secret usage, surface it in the Referenced By tab, and expose it via the Secrets API so admins can perform reliable impact analysis before rotation, restriction, or decommissioning. Example: account-level secret harness_svc_account_token is used via secrets.getValue() in plugin step settings across two active pipelines on the default branch (main), yet shows no references in the UI or API.