August 6, 2025

Why Securing Artifacts Is Critical for Software Supply Chain Security

Table of Contents

Securing source code and CI/CD workflows is no longer enough artifacts like container images, binaries, and scripts have become a critical blind spot in the software supply chain. Attackers increasingly target these assets post-build, exploiting misconfigurations, embedded secrets, and unverified dependencies. To protect against evolving threats, teams must adopt a layered artifact security strategy rooted in frameworks like SLSA and OSS-RISK, and automate signing, scanning, provenance tracking, and promotion policies with tools like Harness SCS and STO.

Software is released faster than ever today. While many organizations are focused on securing source code, scanning dependencies, and tightening CI/CD workflows, there is one critical piece of the software supply chain that remains dangerously overlooked: software artifacts.

Artifacts, the build outputs of your code, are the actual assets that get deployed to production. These are your container images, binaries, packages, and scripts. They are what run in your environments, not the source code itself. Yet, for many organizations, artifacts remain an open attack surface. It is no longer enough to secure your code and CI pipelines. If you are not securing your artifacts, your software supply chain is still at risk.

If you want to dive deeper into this topic, you can watch the recording of our recent webinar, Architecting Secure Delivery Pipelines: Automating Security and Ensuring Software Supply Chain Integrity at Scale. It covers actionable strategies to secure every stage of your pipeline, from source code to artifacts to deployment.

Real-World Lessons From High-Profile Attacks

Software supply chain attacks have evolved. Attackers are not just targeting source code repositories. They are now focusing on artifacts, where security gaps are far more common.

Consider the 2021 Codecov Bash Uploader incident. Attackers gained unauthorized access to Codecov’s artifact storage. They replaced a widely used Bash script with a malicious version that silently exfiltrated secrets and credentials from thousands of organizations for over two months. This breach did not happen because of a coding mistake or a missing dependency patch. It happened because an artifact, the Bash Uploader script, was tampered with after it was built. Most users never thought to verify the script’s integrity before using it in their CI pipelines.

This incident is not isolated. Research by Aqua Security in 2022 uncovered over 2,100 misconfigured artifact registries, exposing more than 250 million artifacts to the public. Many of these artifacts contained hardcoded secrets, API keys, and proprietary code. These were not theoretical risks. They were actively exposed assets from well-known enterprises. These incidents highlight a hard truth. Focusing solely on source code security leaves a massive gap in your SDLC. Without securing artifacts, organizations are one malicious upload or accidental misconfiguration away from a breach.

Key Risks Hidden in Artifacts

Securing artifacts requires looking beyond basic vulnerability scanning. Here are the most pressing risks lurking inside artifacts today:

Tampering After Build

Artifacts can be modified after the build process finishes. If you are not verifying the artifact before deployment, you are trusting that it has not been altered. This is how the Codecov attack succeeded.

Known Vulnerabilities Inside Artifacts

Even if your code is secure, artifacts can contain outdated libraries or packages with known CVEs. Vulnerable versions of dependencies can remain hidden inside artifacts for months if not properly scanned.

Unapproved or Hidden Dependencies

Artifacts often include bundled third-party software or transitive dependencies that may not be visible in source code reviews. Without Software Bill of Materials (SBOM) tracking, these dependencies go unnoticed.

Unmaintained or Outdated Components

Older or abandoned libraries are common inside long-lived artifacts. These components may no longer receive patches or updates, quietly increasing your security risk over time.

Embedded Secrets and Credentials

Secrets can accidentally get baked into artifacts. Hardcoded API keys, credentials, and tokens can remain inside artifacts stored in registries if not properly scanned and filtered.

Why Artifact Security Cannot Be Ignored

Attackers know that artifacts are often the weakest link in the software supply chain. They exploit assumptions that artifacts are safe once built.

In reality, artifacts change hands frequently across teams and environments:

  • From build systems to registries

  • From registries to deployment platforms

  • Across different teams and business units

At any point in that chain, an artifact can be tampered with, replaced, or exposed if proper security controls are not in place. Enterprises cannot afford to treat artifact security as optional. It needs to be a core part of any modern software delivery strategy.

Aligning Artifact Security with Industry Standards

Artifact security is not just about tooling. It requires alignment with established security frameworks that define best practices for mitigating risks in the software supply chain.

SLSA: Supply-chain Levels for Software Artifacts

SLSA provides a structured framework for improving software supply chain security, focused on artifact provenance.

  • Level 1: Generate provenance. Basic tracking of artifact origin is better than none.

  • Level 2: Tie provenance to specific systems and identities, ensuring traceability.

  • Level 3: Require two-person code reviews and fully isolated, reproducible builds to prevent tampering.

However, generating provenance is not enough. SLSA explicitly emphasizes that provenance must be inspected and verified before promoting artifacts. Harness Supply Chain Security (SCS) fully supports SLSA Level 3. SCS automatically signs and verifies artifacts before deployment, tracks provenance, and enforces policy-based artifact promotion. Artifact signing within Harness Artifact Registry currently requires connecting via a Docker connector for the signing step, while SBOM generation and SLSA provenance tracking integrate natively with it. This gives organizations seamless traceability and enforcement throughout the artifact lifecycle.

OSS Risks: Open Source Software Risks in Artifacts

Artifacts today almost always contain open source components. The Open Source Security Foundation (OpenSSF) categorizes common open source risks under OSS-RISK categories. Here are the OSS risks most relevant to artifact security and registries:

  • OSS-RISK-1: Known vulnerabilities
    Artifacts or registries may contain dependencies with known CVEs.

  • OSS-RISK-2: Compromise of legitimate package
    Artifacts can contain malicious versions of normally trusted components.

  • OSS-RISK-3: Name confusion attacks
    Registries can host malicious packages designed to mimic trusted ones by using confusing or similar names.

  • OSS-RISK-4 and OSS-RISK-5: Unmaintained or outdated software
    Artifacts may contain old or abandoned dependencies that are no longer patched.

  • OSS-RISK-6: Untracked dependencies
    Artifacts can bundle hidden dependencies that may introduce unknown risk.

  • OSS-RISK-9: Unapproved changes
    Artifacts may be tampered with or modified without approval.

These risks are not theoretical. They were at the core of both the Codecov and Aqua Security incidents and many more that have occurred.

CICD-SEC Risks: CI/CD Pipeline Security Gaps

The Cloud Security Alliance (CSA) also defines critical security risks in CI/CD systems, called CICD-SEC Risks. These apply across the software delivery lifecycle, including in artifact workflows.

  • CICD-SEC-9: Improper Artifact Integrity Validation
    Directly related to artifact signing and verification. This was a root cause in the Codecov attack.

  • CICD-SEC-2: Inadequate Identity and Access Management
    Registry misconfigurations often fall under this, as seen in the Aqua Security registry case.

  • CICD-SEC-5 and CICD-SEC-7: These relate to insufficient pipeline-based access controls and insecure system configurations, also highlighted by the Aqua findings on publicly accessible registries.

  • CICD-SEC-3: Dependency Chain Abuse
    This overlaps with artifacts that include malicious or vulnerable dependencies.

  • CICD-SEC-10: Insufficient Logging and Visibility
    This risk cuts across both examples, as neither Codecov’s users nor Aqua’s findings involved effective monitoring to detect the problems quickly.

These frameworks all point to a common truth: artifacts cannot be treated as "trusted by default." They must be verified, inspected, and controlled at every stage of the SDLC.

Best Practices for Securing Artifacts

Many enterprises are now adopting a multi-layered approach to secure their artifacts. Here are key practices every team should implement:

Artifact Signing and Verification

Every artifact should be signed at build time using cryptographic signatures. Before an artifact is promoted or deployed, its signature must be verified to confirm its integrity and authenticity.

Provenance Tracking

Provenance provides the full history of how an artifact was built—what source code it came from, which systems built it, and who approved it. Provenance helps prevent tampering and enforces accountability.

SBOM Generation

An SBOM, or Software Bill of Materials, lists every dependency inside an artifact. Generating SBOMs automatically during the build process ensures full visibility into what your software contains, enabling better vulnerability management and compliance tracking.

Artifact Scanning

Artifacts should be scanned for known vulnerabilities before promotion. This process goes beyond source code scans to inspect the compiled software as it will run in production.

Secrets Detection

Artifacts should also be scanned for embedded secrets such as API keys or credentials. These scans need to happen before storing artifacts in registries or releasing them to production.

Promotion Policies

Teams should enforce policies that allow only signed, verified, and vulnerability-free artifacts to progress through environments. Promotion gates are essential for stopping untrusted artifacts from reaching production

Where Harness Fits In

Harness delivers a modern, integrated solution for artifact security through its Supply Chain Security (SCS) and Security Testing Orchestration (STO) modules.

Harness SCS

Harness SCS enables organizations to:

  • Sign artifacts automatically during the build process

  • Verify artifact signatures before deployment

  • Track provenance and meet SLSA Level 3 standards

  • Generate SBOMs for full dependency visibility

  • Enforce policies that block tampered or unverified artifacts

SCS makes it possible to automate artifact integrity checks across container and non-container artifacts. It also integrates with the Harness Artifact Registry for end-to-end trust management.

Harness STO

Harness STO adds powerful security testing capabilities for artifacts:

  • Scans container images for known vulnerabilities using trusted security scanners such as Trivy, Wiz, and others

  • Integrates with artifact registries such as Docker Hub, Google Container Registry, and Azure Container Registry

  • Provides unified reporting across artifact and source code scans

  • Teams can also integrate external secret-scanning tools such as TruffleHog or Gitleaks within their pipeline alongside STO to scan the artifacts themselves

Harness combines artifact integrity, vulnerability scanning, and policy enforcement into a cohesive, automated security pipeline.

The world of software delivery has changed. Attackers no longer need to compromise your code directly; they can achieve their goals by targeting your artifacts. If you are not securing your artifacts, you are leaving your software supply chain exposed to tampering, hidden vulnerabilities, and credential leaks. Artifact security is no longer optional. It is a fundamental part of delivering trusted software.

The solution is not just scanning for vulnerabilities or tightening CI/CD controls. It requires a strategic, layered approach that is rooted in industry frameworks like SLSA, OSS Risks, and CICD-SEC and supported by automation that integrates artifact signing, provenance tracking, scanning, and policy enforcement. The strongest software delivery teams treat artifact security as a first-class concern, integrating signing, scanning, provenance, and policy enforcement into their daily workflows. With tools like Harness SCS and STO, these practices can be automated and scaled, helping teams to deliver not just faster software, but trusted software.

If you would like to learn more about how to secure every step of your software delivery process, you can watch the full recording of our webinar, Architecting Secure Delivery Pipelines: Automating Security and Ensuring Software Supply Chain Integrity at Scale. It offers in-depth guidance and practical examples to help you implement a more secure pipeline today.

Next-generation CI/CD For Dummies

Stop struggling with tools—master modern CI/CD and turn deployment headaches into smooth, automated workflows.

You might also like
No items found.
Book a 30 minute product demo.
No items found.
No items found.
Artifact Registry