Feature Requests

AWS ECS and Serverless Lambda deployment types can store the definitions/manifests in S3. This is not possible for the AWS Lambda deployment type (limited to Git + Harness file store). We generate these definitions/manifests from Terraform on apply, so cannot store in Git. We would like to load AWS-Lambda-Function-Definition.yaml and AWS-Lambda-Function-Alias-Definition.yaml from S3 as we do for ECS.

We have requirement for additional tags in Sarif file for various use cases, we would like to filter the results of the vulnerabilities displayed on STO to developers based on those additional tags present in Sarif file. Request to kindly provide us the capability to add filter based on Sarif additional tags. Couple of examples where our teams are adding additional tags in Sarif file.: - Display only P1 Critical CISA KEV (Knowln exploited vulnerabilities) Display only actionable vulnerabilities to developers Display app/framework/base image vulnerabilities.

Currently, notification email addresses are set at the template level, so any update to the fixed/manual email list applies to all pipelines using that template. This causes all users linked to the template to receive notifications, even when the alerts are irrelevant to their pipeline or environment. We request the ability to configure notifications at the pipeline level with conditional rules. This would allow notifications to be sent only to the users responsible for the specific pipeline or environment. For example: Prod deployments → Notify Users A and B only. PreProd deployments → Notify Users X and Y only. This enhancement would reduce irrelevant alerts, ensure the right people are informed, and improve operational efficiency.

Current CI stage status in Dashboards Build & Repo visualization We currently can’t filter by Stage Type or Status. Unified Pipeline visualization CI stage type is available, but we can’t filter for the RUNNING status. Request Could we add support for: Filtering by Stage Type and Status in Build & Repo visualization. Filtering by RUNNING status in Unified Pipeline visualization.

Add a place to include usage examples with the modules in the registry. Similar to how these Google provided github modules provide examples: https://github.com/terraform-google-modules/terraform-google-network

Currently the "From email" exists on the SMTP setting which is generally at the account level Ref: https://developer.harness.io/docs/platform/notifications/add-smtp-configuration/#step-2-details . There are requests from internal customers to have this from email customizable. For instance, any setting at the Org/project level or the email/notification step level. It would help to have this feature and would be beneficial for the teams that operate at the Org/project level

Description: Currently, the Harness GCS artifact trigger only fires when a new file/object is added to the bucket. If an existing file is updated (new version uploaded with the same name), the trigger does not detect the change. Enhancement request: Enable the GCS artifact trigger to also listen for object updates/modifications in addition to new object creations. This would allow pipelines to run when a file is updated in place, without requiring a new filename. Impact: Current limitation prevents pipelines from running when teams overwrite or update existing files in the GCS bucket. Use case example: Customers with workflows that regenerate or patch files in place (e.g., Terraform outputs updating multiple JSON files) must rename or duplicate files to trigger pipelines, which is inefficient and error-prone.

Currently, workflow execution in IDP only supports the default branch, which limits flexibility when teams want to maintain and test different versions of workflows across multiple branches (e.g., dev, staging, release). Adding support to execute workflows from non-default branches would enable branch-based development and testing, allow safer validation before merging to default, and better align with GitOps practices where branches represent different environments or versions.

This is related to the STO Exemption request. The user provided the requested information, such as the duration and reason, and submitted the Exemption request. Currently, you can view the exemption description details in the pipeline UI by clicking on the vulnerability that was exempted and then clicking on the eye icon at the top to see the description. We are looking to display the exemption description directly in the Exemption UI.

We are using webhooks to receive notifications about pipeline events. However, there is a problem with webhooks: they can arrive out of order, or can be lost completely because of a network issue. Therefore, we need a durable audit log of all pipeline events (stored in order) that is accessible via API. Stored events should be "rich", i.e. contain all the metadata relevant to the event, such as pipeline/project tags, services and infrastructures involved (for deployment stages), as well as acting user where relevant (e.g. for approval stages).