what is software supply chain security​ | Harness Glossary

If you ask most security engineers what supply chain security means in practice, the answer usually involves Software Composition Analysis (SCA) and maybe Software Bill of Materials (SBOM). That's a reasonable place to start. It's not a reasonable place to stop.

Software supply chain security is the discipline of protecting every stage of the software delivery process - from how code is committed and built, to how artifacts are stored and promoted, to what actually runs in production. A compromise at any node in that chain can propagate downstream with the same trust and signing credentials as a legitimate release. That's what makes supply chain attacks so damaging, and so difficult to detect after the fact.

The threat model has matured considerably. Attackers are no longer just hunting for vulnerable versions of log4j in your dependency tree. They're targeting CI runners, poisoning build scripts, pushing malicious commits through compromised developer accounts, and replacing artifacts in registries. SolarWinds, XZ Utils, and the 3CX attack all followed variations of this pattern - trusted build infrastructure turned into a delivery mechanism for malicious code.

This guide covers the full scope of what modern software supply chain security requires: the attack surface, the technical controls, the frameworks (SLSA, NIST SSDF, OWASP CI/CD Top 10), and how to operationalize them without grinding delivery to a halt. If you're running SCA and generating SBOMs today, this is the map for what comes next.

Why SCA and SBOM Are Not Enough

SCA and SBOMs are genuinely valuable. SCA tells you which dependencies carry known CVEs. An SBOM gives you a machine-readable inventory you can query when the next zero-day drops. If you're doing both consistently, you're ahead of a lot of organizations.

But here's the problem: SCA and SBOMs only address one node in the chain — dependency ingestion. The moment code leaves your editor and enters your build system, you have a much larger attack surface to worry about.

Consider what SCA and SBOMs don't cover:

• Build pipeline integrity. Nothing in your SBOM tells you whether your CI runner was compromised, whether a build script was modified between runs, or whether your build environment is pulling from a pinned, verified base image. The XZ Utils backdoor wasn't a vulnerable dependency; it was malicious code introduced during the build process itself, by a contributor who had spent two years earning maintainer trust.

• Artifact provenance. Can you prove, cryptographically, that the container image in your production registry was built by your pipeline from your source code — and nothing else? Without SLSA attestations, the answer is probably no. An SBOM tells you what's in an artifact. Provenance tells you how it got there.

• CI/CD posture. Your pipeline tooling is infrastructure with its own attack surface. Overprivileged service accounts, unrotated secrets, unauthenticated webhook endpoints, and third-party Actions with excessive permissions are all common findings that SCA will never surface.

• Policy enforcement. Knowing you have a vulnerable library or an unsigned artifact is only useful if something actually stops it from being promoted to production. SCA generates findings. Policy-as-code enforces decisions. Those are different capabilities.

The teams that get breached via the supply chain aren't usually the ones ignoring SCA. They're the ones who stopped there and assumed the rest of the chain was someone else's problem. Modern software supply chain security means treating every stage - source, build, artifact, delivery, runtime - as part of the same threat model.

What Makes Up the Software Supply Chain?

Software supply chain security starts with knowing what you're defending. The chain includes every step and system that contributes to how software is built and delivered:

• Source Code Management (SCM). Where code lives, gets reviewed, and gets merged. Compromised developer accounts, insufficient branch protections, and weak MFA are common entry points that rarely show up in a dependency scan.
• Dependencies and open source libraries. The packages your code pulls in at build time. This is where SCA and SBOMs apply, and where most teams have at least some coverage.
• Build and CI systems. The infrastructure that compiles, tests, and packages your code. Build runners are high-value targets: a compromised runner can inject malicious code into an otherwise clean artifact without touching your source repository.
• Artifact registries. Where built images and packages are stored before deployment. Unauthorized access, missing signing, and insufficient promotion controls can turn a registry into a distribution mechanism for tampered artifacts.
• CD pipelines and deployment tooling. The systems that move artifacts into production. Overprivileged service accounts and weak approval gates here can give an attacker a direct path to your live environment.
• Runtime and infrastructure. The clusters, cloud services, and compute that actually run your software. Drift from your expected SBOM baseline at runtime is a signal worth monitoring.

Every stage is an entry point. Effective software supply chain security means having controls, visibility, and policy enforcement across all of them - not just the dependency layer.

Why Software Supply Chain Security Matters Now

The threat landscape is one reason teams are formalizing software supply chain security programs. Regulatory and customer pressure is the other.

• Regulatory requirements are catching up. Executive Order 14028 directed federal agencies to require SBOMs from software vendors. CISA's Secure by Design guidance and NIST SSDF set expectations for provenance, vulnerability disclosure, and secure build practices. If you sell to the federal government or work in regulated industries, these aren't optional.
• Customers are starting to ask. Enterprise procurement teams increasingly include security questionnaires that go beyond "do you have a SOC 2?" They want to know about your SBOM practices, how you handle zero-days in upstream dependencies, and whether your build pipeline produces signed artifacts. Supply chain security posture is becoming a sales conversation.
• The blast radius of a supply chain breach is disproportionate. A vulnerability in your own code affects your users. A compromised build pipeline can affect every customer who installs your software, potentially before you even know something went wrong. The SolarWinds breach reached 18,000 organizations through a single tampered update. That asymmetry is what makes this threat category different.

Getting software supply chain security right isn't just a defensive play. Done well, it produces artifacts from the evidence - SBOMs, attestations, signed releases - that build trust with customers and auditors, and that make incident response dramatically faster when something does go wrong.

Common Software Supply Chain Attack Vectors

Understanding where attacks enter the chain is the foundation of any software supply chain security program. Modern incidents rarely start in production. They start earlier, in the systems your team trusts most.

• Dependency confusion and malicious packages. Attackers publish packages to public registries with names that shadow internal or popular packages, betting that your build system resolves the wrong one. Typosquatting variants of widely-used libraries follow the same logic. The payload gets pulled in at build time, signed and packaged alongside legitimate code.
• Compromised maintainer accounts and malicious contributions. The XZ Utils backdoor is the clearest recent example: a contributor spent roughly two years building maintainer trust before introducing a carefully obfuscated backdoor. Compromised accounts on GitHub or npm can push malicious commits or releases to projects your team depends on, often without triggering automated alerts.
• CI/CD pipeline tampering. Build runners that pull from external sources, execute unreviewed scripts, or run with excessive permissions are a persistent target. An attacker with access to a CI environment doesn't need to touch your source code; they can modify the build process itself and produce a compromised artifact that passes every downstream check.
• Artifact registry poisoning. Replacing or modifying images and packages after they've been built but before they're deployed. This is exactly the gap that artifact signing and SLSA attestations are designed to close. If you can't cryptographically verify that what's in your registry matches what your pipeline produced, you're trusting storage integrity alone.
• Exposed secrets and misconfigured access. Leaked CI tokens, overprivileged service accounts, and unauthenticated webhook endpoints are consistently among the most common findings in pipeline security assessments. They don't require a sophisticated attacker, just someone paying attention to what's exposed.

No single control closes all of these doors. That's why software supply chain security is a program, not a tool.

Key Components of Software Supply Chain Security

Software supply chain security isn't a single control. It's a set of capabilities that need to work together across every stage of delivery. Here's what a mature program covers:

1. Source Code Security

Your SCM is the starting point of the chain and one of the most commonly overlooked attack surfaces. The basics matter: enforce MFA, apply least-privilege access, require code reviews before merge, and use branch protection rules to prevent direct pushes to main. Beyond access controls, monitor for anomalous activity, such as unusual commit patterns, new contributors with immediate merge access, or unexpected changes to CI configuration files.

Secret management belongs here too. Credentials, API keys, and tokens committed to source are a persistent source of exposure. Use a dedicated secrets manager and rotate aggressively.

2. Dependency and SBOM Management

SCA scanning catches known CVEs in your open source dependencies. SBOMs give you a persistent, machine-readable inventory of every component in a release so you can respond quickly when a new vulnerability is disclosed. Both are table stakes at this point.

The operational gap most teams hit isn't generating SBOMs; it's doing something useful with them. SBOM quality matters: incomplete or inaccurate inventories create false confidence. And SBOMs need to be centralized and queryable, not just produced as build artifacts and forgotten. Harness SCS generates SBOMs per build, centralizes them so security teams can identify exposure across every active release when a zero-day drops, and allows you create and enforce policy based on SBOM contents.

3. Build and Pipeline Security

Build infrastructure is high-value and frequently under-secured. Runners should be ephemeral, isolated, and built from verified base images. Build scripts should be reviewed with the same scrutiny as application code. Secrets injected at build time should be scoped and short-lived.

SLSA provenance is the other piece here. Generating a signed attestation for each build - capturing what source commit was used, which pipeline ran, and what inputs were present - lets you verify later that an artifact is exactly what your pipeline produced. Harness SCS generates SBOMs and SLSA attestations as part of the build process, without requiring separate tooling.

4. Artifact Governance

Artifacts need to be treated as first-class security objects, not just build outputs. That means signing images before they're pushed to registries, validating attestations before artifacts are promoted between environments, and enforcing policy on which images are allowed to move toward production.

Promotion gates are where policy-as-code becomes practical. Rather than relying on manual approval for every deployment, you define which attestation and SBOM quality criteria an artifact must meet to advance — and enforce that automatically. Harness SCS controls artifact promotion by validating SLSA attestations and SBOM completeness at each stage.

5. Delivery Pipeline Security

CI/CD tooling is infrastructure, and it needs to be treated that way. Service accounts should follow least privilege, webhook endpoints should be authenticated, and third-party integrations - GitHub Actions, orbs, plugins - should be pinned to verified versions. Overprivileged pipeline credentials are one of the most common findings in supply chain security assessments and one of the easiest to fix.

Policy enforcement in the delivery layer is also where governance becomes real. Harness CD includes pipeline governance capabilities that let you define who can deploy what, to which environments, and under which conditions - enforced consistently rather than dependent on individual discipline.

6. Runtime Monitoring

Runtime is where everything upstream either held or didn't. Monitor for drift from your expected SBOM baseline - if a component appears in production that wasn't in your build inventory, that's a signal. Feed anomalous behavior, unexpected API calls, and configuration drift back into your supply chain security program so findings inform upstream controls, not just incident response.

Industry Frameworks for Software Supply Chain Security

Frameworks don't secure your pipeline. But they give your program a shared vocabulary, a maturity target, and, increasingly, a compliance baseline that customers and auditors will ask about. These are the ones that matter for software supply chain security specifically.

SLSA (Supply Chain Levels for Software Artifacts)

SLSA is the most directly actionable framework for build and artifact security. It defines three levels of maturity, each adding stronger guarantees about how software was built and whether the resulting artifact can be trusted.

Level 1 requires that your build process is scripted and produces provenance. Level 2 requires that provenance is generated by the build platform itself, not the build script, and that the source is version controlled. Level 3 adds requirements for hardened build environments and verified provenance. Most production pipelines are realistically targeting L2 as a near-term goal; L3 requires more infrastructure investment but is increasingly expected in high-assurance contexts.

The practical value of SLSA isn't the level number - it's the provenance artifact. A signed SLSA attestation lets you answer, cryptographically, whether an artifact in your registry was built from the source commit you think it was, by the pipeline you expect, with no undocumented inputs. That's exactly what's missing when teams rely on SBOMs alone.

NIST SSDF (Secure Software Development Framework)

SSDF (SP 800-218) organizes secure development practices into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. It's less prescriptive than SLSA and more broadly scoped, covering everything from developer training to vulnerability disclosure processes.

For security engineers, SSDF is most useful as an audit framework and a gap analysis tool. It's also the basis for several federal procurement requirements following EO 14028, so if you're selling to government customers, alignment with SSDF isn't optional.

OWASP Top 10 CI/CD Security Risks

Where SLSA and SSDF describe what good looks like, the OWASP CI/CD Top 10 describes what bad looks like, and it maps directly to real attack patterns. The list covers insufficient flow control mechanisms, inadequate identity and access management, dependency chain abuse, poisoned pipeline execution, and insufficient credential hygiene, among others.

This is the most practical checklist for hardening an existing pipeline. If you're doing a pipeline security assessment, running through the OWASP CI/CD Top 10 will surface actionable findings faster than any other starting point.

CISA Enduring Security Framework (ESF) and Secure by Design

CISA's ESF guidance on software supply chain security and its Secure by Design principles push responsibility upstream, toward vendors and platform teams, not just end users. The core ask is that security be built into the delivery process rather than bolted on after the fact. For security engineers, this translates to owning pipeline controls proactively rather than waiting for a compliance requirement to force the conversation.

Challenges in Implementing Supply Chain Security

Knowing what good looks like and getting there are different problems. These are the obstacles that consistently slow programs down in practice.

• Visibility across a fragmented toolchain. Most pipelines weren't designed with security in mind. They were assembled over time from whatever CI, SCM, registry, and deployment tools the team preferred. Getting a coherent view of your supply chain posture across all of them, without a dedicated layer that aggregates and correlates signals, is genuinely hard. Point tools give you point findings. They don't tell you whether an artifact that passed SCA in CI is the same artifact that's running in production.
• Keeping pace with release velocity. Security checks that add meaningful latency get disabled or bypassed. If SBOM generation, attestation signing, and policy evaluation aren't fast and integrated, they become the bottleneck that teams route around. Software supply chain security only works if it's embedded in the pipeline, not bolted on outside it.
• Ownership gaps between security and platform teams. Pipeline security sits at the intersection of AppSec, platform engineering, and DevOps. In most organizations, nobody owns it cleanly. Security teams don't always have the access or context to harden CI infrastructure. Platform teams don't always have the security background to know what "hardened" means. That gap is where misconfigurations persist longest.

Translating framework requirements into pipeline controls. SLSA levels and SSDF practices describe outcomes, not implementations. Turning "generate signed provenance" or "protect the build environment" into actual pipeline configuration requires both security knowledge and platform engineering skill. Most teams have one or the other.

How Harness Approaches Software Supply Chain Security 

Most software supply chain security programs start as a collection of point tools - a scanner here, an SBOM generator there, manual approval gates somewhere in between. The coverage looks reasonable on paper. The gaps show up when you try to answer a simple question: can you prove, right now, that every artifact running in production was built from reviewed source code, by a verified pipeline, with no undocumented inputs?

For most teams, the honest answer is no. Not because they haven't invested in security tooling, but because the tooling is fragmented. Findings don't connect across stages. Policy exists in documentation rather than enforcement. And when a zero-day drops, reconstructing exposure across every active release takes days instead of minutes.

Harness SCS is built around that operational reality. Rather than adding another point tool, it sits across your CI, CD, and artifact management layer to provide continuous, correlated visibility and enforceable policy across the full chain.

What that looks like in practice:

SBOM generation and management. Harness generates SBOMs automatically as part of each build and centralizes them so security teams can query across every active release. When a new CVE is disclosed, you can identify every artifact containing the affected component immediatel, not after a manual audit.

SLSA provenance and attestation. Harness generates signed SLSA attestations for each build, capturing the source commit, pipeline, and inputs used. Those attestations travel with the artifact and can be verified at any promotion gate, giving you cryptographic proof of build integrity rather than assumed trust.

Artifact promotion governance. Harness enforces policy at each promotion stage. Artifacts that don't meet defined SBOM quality thresholds or lack valid attestations don't advance toward production. Policy-as-code replaces manual gates that get bypassed under pressure.

CI/CD posture scanning. Harness continuously scans your pipeline configuration, including service accounts, secrets handling, third-party integrations, webhook endpoints, against frameworks including the OWASP CI/CD Top 10. Findings are surfaced in context, not as a separate audit artifact.

Integrated security testing. For teams also running SAST, SCA, container scanning, and DAST, Harness AST brings those capabilities natively into your pipelines. SCS and AST share the same platform, so findings across dependency, artifact, and pipeline layers are correlated rather than siloed.

Because Harness sits across CI, CD, and artifact management rather than alongside them, you get a continuous chain of custody from commit to production, and the evidence to prove it to auditors, customers, and your own incident response team when it matters.

Practical Steps to Strengthen Your Software Supply Chain Security Posture

The right starting point depends on where you are. But the sequencing matters. There's no point generating SLSA attestations if you don't have branch protections in place, and there's no point enforcing artifact promotion policy if your SBOMs are incomplete. Work through the chain in order.

1. Map what you're actually defending. Before adding controls, get visibility. Document every SCM, CI system, artifact registry, and deployment target in use, including the unofficial ones. Identify which teams own which pipeline segments and where handoffs happen. Most organizations discover tooling they didn't know existed. You can't secure what you haven't inventoried.
2. Harden your SCM first. Source is the start of the chain. Enforce MFA across every account with repository access, apply branch protection rules on main and release branches, require code review before merge, and audit service account permissions. Rotate any long-lived tokens. These controls are high-impact, low-cost, and frequently skipped.
3. Get SCA and SBOMs working properly, not just running. If you're already running SCA, audit the quality of your output before moving on. Are SBOMs complete and accurate, or are they missing transitive dependencies? Are findings actually being triaged and remediated, or accumulating in a backlog nobody owns? Fix the operational gaps in what you have before expanding coverage.
4. Add SLSA provenance to your build process. Once your source and dependency layers are solid, move to build integrity. Start at SLSA Level 1 - scripted builds with provenance output. Then work toward L2, where the build platform itself generates and signs the provenance rather than the build script. This is the step that takes you from "we think this artifact is clean" to "we can prove it."
5. Enforce policy at artifact promotion gates Define what an artifact must demonstrate to advance between environments - minimum SBOM completeness, valid attestation, no critical unresolved CVEs - and enforce it automatically. This is where policy-as-code replaces manual approval processes that get bypassed under release pressure. Start with a single promotion gate (staging to production) and expand from there.
6. Assess your CI/CD posture Run a pipeline security assessment against the OWASP CI/CD Top 10. Look specifically at service account permissions, secrets handling, third-party Action and plugin versions, and webhook authentication. Most teams find high-severity misconfigurations here that no amount of SCA scanning would ever surface.
7. Add runtime monitoring as a feedback loop Runtime is where you validate that everything upstream held. Monitor for SBOM drift - components present in production that weren't in your build inventory - and feed anomalies back into your supply chain security program. Runtime findings should inform upstream controls, not just trigger incident response after the fact.

Where to Go Next With Supply Chain Security (SCS)

Securing the software supply chain is no longer optional. By understanding each component of your pipeline, adopting industry frameworks like SLSA and OWASP risk lists, and using AI-native tools such as Harness SCS, you can catch supply chain issues early while maintaining release velocity. 

Software supply chain security (SCS) spans source code, dependencies, CI/CD pipelines, and runtime environments; addressing each area with scanning, policy enforcement, and continuous monitoring lets teams ship faster without sacrificing trust.

Frequently Asked Questions (FAQs): Software Supply Chain Security

What's the difference between software supply chain security and application security?

Application security focuses on vulnerabilities in the code your team writes - the logic bugs, injection flaws, and misconfigurations that SAST and DAST are designed to catch. Software supply chain security focuses on the integrity of everything that surrounds that code - the dependencies it pulls in, the build system that compiles it, the pipeline that delivers it, and the artifacts that end up in production. In practice, the two overlap, and SCA lives in both worlds, but a strong AppSec program doesn't automatically give you supply chain security, and vice versa. You need controls at both layers.

I'm already running SCA and generating SBOMs. What's actually missing?

SCA and SBOMs cover your dependency layer. They tell you what dependencies are in your software and whether any of it has known CVEs. What they don't cover is everything that happens to your software after the source code is written - whether your build environment is clean and isolated, whether the artifact in your registry is actually what your pipeline produced, whether your CI service accounts are overprivileged, and whether policy is being enforced at promotion gates or just documented somewhere. Those gaps are where modern supply chain attacks land. SCA is the right starting point. It's not a complete program.

What is SLSA and why does it matter?

SLSA (Supply Chain Levels for Software Artifacts) is a framework that defines maturity levels for build integrity and provenance. The core deliverable is a signed attestation - a cryptographically verifiable record of what source commit was built, by which pipeline, with which inputs. That attestation travels with the artifact and can be verified at any promotion gate. Without it, you're trusting that the artifact in your registry matches what your pipeline produced. With it, you can prove it. Most teams should be targeting SLSA Level 2 as a near-term goal, where the build platform itself generates and signs provenance rather than the build script.

What's the difference between an SBOM and SLSA provenance?

They answer different questions. An SBOM tells you what's in an artifact - every component, dependency, and library included in a release. SLSA provenance tells you how that artifact was built - the source commit, the pipeline, the build environment, and the inputs used. You need both. An SBOM without provenance tells you what's in the package but not whether the build process was clean. Provenance without an SBOM tells you the build was verifiable but not what it contains. 

How do we get started if our pipeline is already complex and fragmented?

Start with inventory, not tooling. Map every SCM, CI system, artifact registry, and deployment target your teams are actually using, including the unofficial ones. Most organizations discover tooling during this exercise they didn't know existed. From there, prioritize your highest-risk pipeline segments: the ones that produce customer-facing releases, handle the most sensitive credentials, or have the weakest access controls. Harden those first. Trying to fix everything simultaneously is how programs stall. Sequencing matters more than speed.

Will adding supply chain security controls slow down our pipelines?

They can, if they're bolted on outside your existing workflow. SBOM generation, attestation signing, and policy evaluation that run as separate, sequential steps add latency that teams will eventually route around. The goal is integration - these controls running in parallel with your existing build and test stages, not after them. Tools that sit natively inside your CI/CD layer, rather than alongside it, are what make the difference between security that holds and security that gets disabled under release pressure.

How often should we audit our supply chain security posture?

Continuous scanning during every build and deployment is the baseline - that's what catches new CVEs against your SBOM and validates attestations at each promotion gate. Deeper assessments of your pipeline posture (running through the OWASP CI/CD Top 10, auditing service account permissions, reviewing third-party integrations) should happen at least quarterly, or after any significant change to your pipeline infrastructure. Treat pipeline configuration with the same change management discipline you'd apply to production infrastructure.