Feature Requests

The cleanup policy currently allows specifying the number of versions to retain through the Cleanup Rule, while the Retention Rule allows defining tag patterns but does not provide an option to specify the number of versions to retain. The requested enhancement is to support independent retention counts for production and non-production versions. For example: Cleanup Rule: Retain the latest 5 non-production versions (versions not matching . prod. ) Retention Rule: Retain the latest 5 production versions (versions matching . prod. ) This would ensure that the registry independently retains the latest 5 production and 5 non-production versions.

Overview The Dependency Firewall dashboard "double-counts" blocked violations for the same package version within a single execution. This is particularly prevalent when using virtual registries (e.g., npm_local_account_level) configured with an upstream proxy (e.g., npm-upstream-proxy). The dashboard logs separate events for the fetch attempt at the proxy level and the subsequent CLI dependency graph evaluation. The Problem The duplication is triggered by the multi-phase evaluation flow in the Harness CLI: The Registry Context: The package is requested through a virtual registry (npm_local_account_level) that proxies to an upstream source. Native Fetch Pass: When npm install requests the tarball directly from the upstream proxy, the firewall returns a 403 Forbidden. This is logged as a violation. CLI Fallback Pass: If a lockfile is missing, the CLI resolves the full tree and bulk-submits the package (e.g., registry-url@7.2.0) for evaluation again. This is logged as a second violation. Because the dashboard does not deduplicate by registry or execution ID, one actual policy hit appears as two separate security events. Customer Impact Metric Inflation: Customers see inflated violation counts, making it difficult to assess the true volume of blocked packages. Registry Ambiguity: Without deduplication, it isn't always clear that multiple dashboard entries refer to the same package being pulled through the same virtual registry endpoint. Operational Noise: Security teams spend unnecessary time triaging "duplicate" hits that stem from the same single user action. Proposed Solution Update the Dependency Firewall reporting logic to deduplicate entries. The dashboard should group violations by: Package Name & Version Target Registry (to ensure legitimate violations across different registries are still caught) Execution/Pipeline ID If a package is blocked multiple times while being pulled from the same registry during the same pipeline run, it should render as a single dashboard entry.

Our requirement is to have a Yarn equivalent of the existing npm command: hc artifact npm install Specifically, we are looking for support for: hc artifact yarn install The objective is to standardize dependency installation in our Harness pipelines and ensure that Yarn dependencies are resolved through the Harness Artifact Registry and Dependency Firewall during the install process.

Context: Currently, Harness Lifecycle Rules perform a "soft deletion" of artifacts, moving them to a Deleted tab within the Artifact Registry rather than removing them permanently. Problem: The Deleted tab lacks a UI option to perform permanent deletions in bulk. For users managing large registries with numerous soft-deleted artifacts, cleaning them up requires significant manual effort, as each must be handled individually. Proposed Solution: Introduce a Bulk Permanent Delete option under the Deleted tab. This would allow users to select multiple soft-deleted artifacts and remove them permanently from the registry in a single action. Benefit: This enhancement would significantly simplify artifact lifecycle management, reduce manual maintenance toil, and streamline registry cleanup for large-scale environments.

Hello Harness Support, We are trying to configure an Jfrog Artifactory connector using OIDC authentication in Harness. We are receiving the following message: This feature is behind the feature flag CDS_ARTIFACTORY_OIDC_AUTHENTICATION. Contact Harness Support to enable the feature. Could you please enable the following feature flag for our Harness account? Feature Flag: CDS_ARTIFACTORY_OIDC_AUTHENTICATION Harness Account ID: YzRhNTgyNzEtNjIyZi00ND This is required for us to configure OIDC authentication with our JFrog Artifactory connector. Please let us know if you need any additional information. Thanks, Naveen

I am actually trying to trigger my Playwright Automation Test Cases from Harness where I don't see any image with Node JS + Playwright Tool + Python pre baked in the available images. I have to set them install for every run which would be cumbersome. If I can have a readily available image i can use it to save time . Can you please create one with asked tech stack ?

Module: Artifact Registry — Upstream Proxy Registry type affected: npm Problem: The current upstream proxy only supports Basic authentication or anonymous access. npm's registry API ( https://registry.npmjs.org/ ) requires Authorization: Bearer <token> for authenticated requests. Basic auth returns 401. Impact: Private scoped packages (e.g., @payloadcms/*) cannot be resolved through a Harness npm upstream proxy. Root cause: npm permanently revoked classic tokens in December 2025; only granular access tokens sent as Bearer tokens are supported. Requested feature: Either: A native Bearer token authentication type for upstream proxies, with the token stored in Harness Secret Manager, or A custom static Authorization header per upstream proxy, sourced from Harness Secret Manager.

When we scan container images for vulnerabilities earlier in the pipeline (before the image is pushed to Harness Artifact Registry), that scan data is lost on push. HAR's built-in scanner has to rescan from scratch to populate the "Vulnerabilities" tab on the artifact version, duplicating work we've already done and losing the original scan context (timing, tool, findings). Request: an API or pipeline step that lets us post externally generated scan results directly into the Vulnerabilities section of a specific artifact version in HAR, rather than requiring HAR's own scanner to be the only source of that data. • We already run security scans as part of our pipeline (before the container reaches the registry) and want that data to persist, not be discarded • We also periodically rescan stored containers for newly disclosed CVEs, so ideally this would support posting updated/incremental results to an existing artifact version over time, not just a one-time import at push • Reduces redundant scanning cost/time and gives us one consistent vulnerability view per artifact regardless of which scanner produced the data

Today, when a lifecycle policy removes an artifact version from a registry, the only option is deletion. We'd like the ability to optionally configure a registry with a "cold storage" destination, a customer-managed cloud storage target (e.g., S3 Glacier or equivalent), so that instead of deleting the artifact when a lifecycle policy triggers, Harness moves it there. Goal is to preserve older artifact versions (for various reasons) without keeping them in the primary registry (which is priced/optimized for active use) Key points: • Cold storage is opt-in per registry; default behavior (delete) is unchanged if not configured • Admins would provide the cloud storage account/bucket and credentials to upload to, but the "connection" would be managed within Harness settings. • Multiple registries could optionally share the same cold storage destination for consolidation.

Dependency Firewall exemptions require an expiration date to be set at creation time. To help prevent unexpected build failures, the user who created the exemption should receive an email notification as the expiration date approaches. This gives them sufficient time to proactively address any outstanding issues, renew the exemption if appropriate, or implement a permanent solution before the exemption expires.