Feature Requests

Summary Improve the "Variables" search functionality in the Pipeline execution/editor view to provide precise scoping (definitions vs. references) and direct navigation to search results. Problem: Currently, the search feature in the Pipeline Variables modal can be misleading and lacks actionable navigation: Scoping Confusion: Searching for a term returns a count of matches (e.g., "13 results found"), but these often include references (usage in YAML) rather than just definitions (the actual variables). This makes it difficult for users to distinguish between where a variable is created and where it is simply being used. Lack of Visibility: The UI indicates the number of results but does not highlight where the matches are within the variables list or the pipeline structure. No Navigation Path: While users can cycle through results (X of Y), there is no hyperlink or "jump-to" functionality to take the user to the specific stage, step, or YAML line where the term was found. Proposed Solution Search Categorization: Differentiate between "Variable Definitions" (found in the variables list) and "Variable References" (found in steps/expressions). Visual Highlighting: Auto-scroll to and highlight the matching variable within the side modal when cycling through results. Navigation Links: Provide a "View in Pipeline" or "Go to Step" link for each search result so users can immediately see the context of the variable usage. Contextual Metadata: Display the location of the match (e.g., Found in: Stage "Deploy" -> Step "Shell Script") directly in the search results list.

The SSCA artifact signing and verify steps export the image to a docker-archive tar and cosign reads it whole, so the step's memory grows with the image. A 4.7 GB image needs a 16Gi limit to sign. On Kubernetes build infra sequential steps share the pod and every container gets the largest limit, so every build pod becomes a 16Gi pod. Request: sign the image digest instead of the tarball for keyless (Fulcio) signing, as cosign sign image@digest does, so memory stays constant.

Restore Cache and Save Cache steps don't currently indicate whether a cache was actually restored or saved, the step reports success either way. The only related setting, failIfKeyNotFound, fails the whole stage on a miss, which isn't practical to use just for visibility. Harness Support confirmed hit/miss reporting exists for the newer "restore from Harness" cache step, but not for S3/GCS-backed cache steps on self-hosted infrastructure. We'd like the same reporting extended to those step types, including how much was actually restored. This would let us track time and cost savings from cache restores per pipeline, and identify which pipelines aren't using cache effectively so we can take action

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

Summary EKS clusters with OPA Gatekeeper enforce runAsGroup. Harness supports Pod Spec Overlay for CI stage Kubernetes infrastructure, but Container steps in Custom stages don’t expose Pod Spec Overlay or a runAsGroup field, causing admission failures unless users manually edit YAML per pipeline/step. Current Behavior Custom-stage Container step UI exposes Run as User / Run as Non Root / Privileged / Capabilities, but not runAsGroup or Pod Spec Overlay. Adding podSpecOverlay directly in YAML works, but must be repeated everywhere. Request Allow a default/inherited Pod Spec Overlay at Kubernetes infrastructure/connector/account/org/project level applied to all K8s step executions (CI + non-CI).

In Harness IaCM, there appears to be a hard-limit of 1 hour for the IaCM Approval timeout. This is reflected in the UI not permitting a timeout value greater than 1 hour. It would be helpful for the timeout limit to match the timeout for the standard Harness Approval step.

Make the "Ask AI" button moveable, dock-able, or placed elsewhere. When using certain screens (e.g. Workflow Playground) the "Ask AI" button is directly over the "Next" button and you need to micro-scroll the screen to see the "Next" button you want to click. Nothing broken, just annoying at times.

Hi Team, We would like to have logging support to check whether a notification was send successfully or not for pipeline events, if there are any failures we would like to have it logged

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.

Currently, in the k8s infra, if someone refers to a secret in the run step as an inline or environment variable, the value is already generated at runtime, instead of the step where it is needed. Due to this, if till the step, if the value has expired, the step starts failing. We need a support where, instead of generating the secret value at the time of stage init, generate the value in the step, where the secret expression is called dynamically.