Feature Requests

Similar to STO, we are requesting for the Supply Chain Security module to allow for license exemption by component. Requesting the person who created the exemption be different then the person who approves the exemption. Additionally requesting the ability to exempt by project, org, or account level depending on if the role access is for a project, org, or account level access.

We do not use SBOM Orchestration and instead use SBOM ingestion mode. Due to this, the parent license shows up as "No Relationship" vs being categorized as indirect or direct relationship. Requesting to enable SBOM Ingestion Mode to see Parent License relationship of direct or indirect.

Request to enhance the Harness supply chain supply module by integrating LicenseConditions attributes into the Harness UI, enabling visibility and filtering. Requested Enhancement: Add the following LicenseConditions attributes as columns in the Harness UI: name description message additionalGuidance Filtering Capability: Enable users to filter supply chain items based on these LicenseConditions attributes Rationale: Improves transparency and compliance tracking by making license conditions easily accessible. Allows users to quickly identify and act on supply chain items with specific license requirements or guidance. Streamlines workflow by enabling targeted filtering and sorting. Example UI Change: Add new columns for each attribute in relevant supply chain tables. Provide filter options for each attribute (e.g., search by name, filter by guidance). Impact: Enhances user experience and compliance management. Reduces manual effort in tracking license conditions. Example JSON { "spdxId": "MIT", "name": "MIT License", "legalStatus": "Approved", "policyColorDesignation": "GREEN", "policyColorMessage": "Does not trigger copyleft obligations. Generally ok to proceed as long as minor obligations (attribution, etc.) are complied with.", >>>> "licenseConditions": [ { "name": "must_attribute", "description": "Need to Attribute", "message": "\"Need to Attribute\" means distribution requires attribution through copyright notice, as specified by the license", "additionalGuidance": null },

Description: Please add support for including workspace tags in the Policy On Save payload for IaCM workspaces. Problem When policies are evaluated on IaCM workspace save events, the payload does not currently include the tags defined on the workspace itself. Because of that, policies cannot validate or protect workspace tags during save operations. Why this matters Tags are often used to drive governance, automation, ownership, environment controls, and feature behavior. Without tag data in the policy input payload, it is not possible to create robust policies that: • require certain tags • block changes to protected tags • validate allowed tag values • enforce governance based on workspace metadata Requested enhancement Include the workspace’s tags in the On Save policy evaluation payload for IaCM workspaces. Expected outcome Policy authors should be able to reference workspace tags directly in policy inputs during save events and create policies that enforce tag presence, tag immutability, and tag-based controls. Impact Today, this creates a governance gap for IaCM workspaces because policies cannot evaluate one of the core metadata fields commonly used for controls and automation.

As part of improving the overall management and organization of the module registry, there is a need to address scenarios where modules may become obsolete, unused, or not aligned with established naming or governance standards. To support this, enhanced lifecycle management capabilities would be beneficial, including the ability to deactivate modules . This would allow modules to be marked as inactive prior to deletion and automatically scheduled for removal after a defined period (for example, 30 days). Such functionality would enable teams to manage and clean up unused or redundant modules in a controlled and structured manner, rather than relying on immediate deletion, thereby improving governance, visibility, and overall maintainability of the registry.

In harness STO, user is not able to raise the multiple exemptions at once if there is more than one vulnerability in a pipeline.

Add dark mode option to Gitness UI

When Test Intelligence is enabled, some tests are skipped, and the generated report includes only the tests that were executed. This leads to a significant drop in coverage when integrated with SonarQube. Since Harness already has visibility into the skipped tests, we are looking for a way to have these tests also accounted for in the coverage report. This would allow us to leverage Test Intelligence while still maintaining accurate coverage metrics for SonarQube and pipeline gating.

There is support for most properties, but can we include tags as well? Currently, only these workspace expressions are supported : https://developer.harness.io/docs/infra-as-code-management/workspaces/workspace-expressions/ It will be of great use if something like <+workspace.tags.SOME_TAG> is available.

There are cases where we need to perform both actions, LOCK and UNLOCK for any IACM workspace, can we convert that to a button, would be easy interface to interact with.