Harness.io has been positioning itself as the commercial one-stop CI/CD platform for several years, and with the acquisition of Drone and the shipment of their Software Supply Chain Assurance (SSCA) module, they now have a plausible end-to-end story from code commit to signed production deployment. The question for a security team evaluating Harness is not whether the individual features exist — they do — but whether the platform's defaults lead you to a secure state, what configuration you have to do yourself, and where the gaps are.
This post is a hands-on review of Harness supply chain security as it stood in the mid-2024 releases, specifically the Harness CI, CD, and SSCA modules at SaaS release 1.58 and self-managed enterprise 0.24. It is based on configuration, pipeline design, and policy enforcement, not on marketing claims. The goal is to help you understand what you actually get out of the box and what you have to build to close the gaps.
The SSCA module and what it actually does
Harness SSCA is the module that generates and validates Software Bill of Materials documents, signs artifacts with cosign, and enforces policy on both. Out of the box, adding an SSCA step to a CI pipeline generates a CycloneDX 1.5 SBOM from the build context, signs the resulting artifact with a Harness-managed or customer-provided key, and stores the signed attestation in the Harness artifact repository.
The SBOM generation uses syft under the hood, which is fine and industry-standard, but the accuracy depends on running the SSCA step at the right point in the pipeline. If you run it on the source checkout, you get a dependency SBOM that reflects declared dependencies. If you run it on the built container image, you get a more accurate SBOM that reflects what actually shipped. If you run it on both and compare, you get the Harness "SBOM Drift" detection which flags differences between declared and actual dependencies. This last mode is the one to use in production, because it catches the specific supply chain attack pattern where a malicious build step adds dependencies that are not in the declared manifest.
The SSCA policy enforcement is done through OPA policies evaluated at pipeline gate steps. Harness provides a set of starter policies — deny critical CVEs, deny GPL-3.0 licenses in commercial products, require cosign signatures — and you can write your own in Rego. The policies are evaluated against the generated SBOM and attestation, and a failed policy blocks the pipeline. This works well once it is configured, but the starter policies are not enabled by default, so a fresh Harness installation has no SBOM policy enforcement until you configure it.
CI pipeline governance and step-level controls
Harness CI inherits much of its architecture from Drone, including the container-per-step execution model. Each step in a pipeline runs in its own container, and the step image is the security boundary. The Harness governance layer adds organization-wide policies on which step images can be used, which integrations can be referenced, and which delegate pools can run the pipeline.
The governance policies are defined in the Policy Management module and are evaluated at pipeline parse time. A typical production configuration includes a deny rule for unpinned step images (image: .*:latest), a deny rule for step images from untrusted registries, and an allow-list for the specific plugin types that have been reviewed. Getting these policies right requires an initial investment to enumerate the images and plugins your teams use, but once configured, they prevent the most common supply chain regressions.
A specific feature worth noting is the Harness Delegate architecture. Delegates are self-hosted runners that execute pipeline steps, and they replace the direct runner model from Drone. The delegate pool is where your pipelines actually execute, and the delegates have access to whatever secrets and cloud credentials you have configured for them. Delegate isolation between teams is a configuration decision — you can have one shared delegate pool, or dedicated pools per team — and the security story depends on which you choose.
STO and the vulnerability-gate story
Harness Security Testing Orchestration (STO) is the module that integrates vulnerability scanning into pipelines. It wraps existing scanners — Snyk, Aqua Trivy, Anchore, Semgrep, and others — into a common step interface and aggregates the results into a unified findings database. The practical value is that you get one place to manage vulnerability findings across multiple scanners, with common policy enforcement and common suppression workflow.
The gate story is where STO earns its cost. A pipeline step in STO mode runs the configured scanners, compares the findings against the policy, and either blocks the pipeline on critical findings or allows it through with an attached report. The policy language supports CVSS thresholds, exploitability flags from CISA KEV, and suppression rules with expiration dates. The expiration is important: an STO suppression that does not expire is a permanent exception, and those accumulate faster than most teams track.
The STO integration with the SSCA module is where the supply chain story gets interesting. A pipeline can generate an SBOM, scan it for vulnerabilities, attach the scan results as a signed attestation to the artifact, and have downstream CD pipelines enforce policy on the attestation at deploy time. This is the full SLSA-3-equivalent flow, and Harness supports it end-to-end. The catch is that configuring the full flow takes deliberate pipeline design — you have to choose to generate the SBOM, choose to attach the attestation, and choose to enforce at deploy time. The defaults do none of this.
CD and deployment-time policy enforcement
Harness CD enforces policies at deployment time through the Policy Management module, the same engine that governs CI. The deployment-time policies can check the deployed artifact's signed provenance, validate that it passed the STO gates in CI, and block the deployment if the policy fails.
A typical production CD policy for a high-sensitivity environment might look like:
package harness.deploy
deny[msg] {
not input.artifact.signed
msg := "Artifact is not signed"
}
deny[msg] {
not input.artifact.sbom
msg := "Artifact has no SBOM attestation"
}
deny[msg] {
input.artifact.sto_findings.critical > 0
msg := sprintf("Artifact has %d critical findings", [input.artifact.sto_findings.critical])
}
deny[msg] {
not input.artifact.ci_pipeline_id
msg := "Artifact does not reference a validated CI pipeline"
}
The policy is evaluated against a JSON representation of the artifact metadata that Harness assembles from the CI pipeline, the SSCA attestations, and the STO scan results. A deployment that fails the policy is blocked, and the block is auditable.
This is the feature that distinguishes Harness from a bolt-together CI system plus a separate supply chain tool. The integration between CI, SSCA, STO, and CD is native, and the policy language is consistent across the stages. For an organization that is already invested in Harness, turning on the full policy flow is an investment in configuration rather than in new platform components.
The gaps
Three gaps are worth flagging for any Harness deployment. First, the default signing key configuration stores keys in the Harness-managed Key Management Service. For regulated environments, you want to use a customer-managed KMS (AWS KMS, GCP Cloud KMS, or HashiCorp Vault Transit), and that is a deliberate configuration choice, not the default. Second, the SSCA SBOM Drift detection requires explicit configuration to enable, and it is the single most valuable signal SSCA produces. Third, the STO suppression workflow defaults to no expiration, which turns suppressions into permanent exceptions unless you change the default.
None of these gaps are dealbreakers. They are configuration decisions that a security team should make deliberately rather than inheriting from the default installation.
How Safeguard Helps
Safeguard integrates with Harness SSCA and STO by ingesting the signed SBOM attestations and vulnerability findings as they are produced, cross-validating them against independent scanner outputs, and alerting when a policy gate is bypassed or a suppression is extended past its expiration. The platform also monitors Harness delegate configurations for secret-scope issues, tracks the signing key provider for each artifact against your KMS policy, and provides an auditable external record of supply chain posture that is independent of the Harness platform itself. That independence matters for regulated workloads where the audit evidence should not be held by the same system that produced it.