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.
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.
Securing artifacts requires looking beyond basic vulnerability scanning. Here are the most pressing risks lurking inside artifacts today:
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.
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.
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.
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.
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.
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:
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.
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 provides a structured framework for improving software supply chain security, focused on artifact provenance.
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.
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:
These risks are not theoretical. They were at the core of both the Codecov and Aqua Security incidents and many more that have occurred.
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.
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.
Many enterprises are now adopting a multi-layered approach to secure their artifacts. Here are key practices every team should implement:
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 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.
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.
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.
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.
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
Harness delivers a modern, integrated solution for artifact security through its Supply Chain Security (SCS) and Security Testing Orchestration (STO) modules.
Harness SCS enables organizations to:
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 adds powerful security testing capabilities for artifacts:
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.
Stop struggling with tools—master modern CI/CD and turn deployment headaches into smooth, automated workflows.