By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

You can do everything right and still be impacted by a software supply chain attack.

 worm, and its variants, are recent examples of this. Compromised packages ran 

 scripts, that executed malicious code to exfiltrate keys and credentials before any scan in the consuming team’s pipeline ran. The worm then used those stolen credentials to inject malicious code into other packages in that maintainer account.

Organizations running code review, SAST, and SCA that were impacted by these attacks likely did everything right. The tools did the job they were designed to do. It’s just that the attack mechanism targeted a gap in the supply chain security ecosystem.

Teams now need to think about having a different control at each stage of the supply chain, so a package that gets past one control meets the next. Each tool covers part of the chain. Defense in depth comes from connecting them. Detection tools find risk and can help prioritize remediation, enforcement points act on detection findings, and the stack holds when a finding from one tool reaches a control that can stop the package before it’s used.

This blog series examines the software supply chain security ecosystem, identifies the primary tooling categories and where they run in the development lifecycle, and situates the role artifact management plays in relation to each category.

The development process sees code written, committed, built, published, distributed, selected, and run. Every exchange point in that process presents a gap and is a potential attack target.

Using AI agents to generate code introduces a potentially unreliable author to the development phase. This risk extends to ‘vibe coding’ or ‘citizen developers’ who may lack training or context around coding best practices and package selection when prompting agents. Any decisions made by AI agents or citizen developers cross your environment’s trust boundary the same way decisions made by your developers do.

Slopsquatting is like typosquatting but designed for AI agents. AI can hallucinate package names. Attackers can track naming trends in these hallucinations and proactively create malicious packages using those package names.

Attackers that compromise maintainer accounts target the 

 of open source software. If a maintainer contributes to multiple projects, a single attack can infect them all. These attacks often use social engineering to get maintainer account credentials. Typically, attackers have two paths for getting malicious code into the development environment. One, they use a stolen token to bypass the build stage and upload a malicious version directly to the public registry. Two, with access to the source repository, they can alter the contents of the build itself and publish it through the maintainer’s trusted build pipeline. In this situation, malicious packages can carry valid provenance and signatures, making them appear trustworthy.

Shai-Hulud-style attacks exploit default configurations in the security ecosystem. Package managers, such as npm, run install scripts unless explicitly told not to, and those scripts gain access to long-lived publish tokens that sit on machines.

Detection finds risk. Enforcement stops it.

There are two complementary aspects of software supply chain defense. One is detection and visibility. The other aspect is enforcement and the ability to act on detection findings.

Detection can happen in multiple locations, and those findings need to feed enforcement mechanisms that sit at a point where they can stop malicious packages before they enter developer environments. Endpoint protection tools sit on a single machine’s path and are quick to roll out, and they cover installs that never touch a shared registry. They also depend on being installed, updated, and configured the same way on every machine, which gets harder as a company grows. A platform such as an artifact manager sits where most paths converge, so one policy covers every laptop, runner, and agent that routes through it. Most organizations need both: the platform as the default path, and endpoint controls for whatever goes around it.

The ecosystem has two functional concepts that underpin the whole software development lifecycle and six stages that follow, roughly, the order of software development, from writing code to running it. Modern development is continuous and iterative; multiple build processes can run at different stages at the same time. Each stage ends at a handoff, and each handoff is a place where a threat can slip through. Many tools run in more than one stage, so where a given tool fires depends on how your organization configures and triggers its build pipelines. The general shape holds, though, and it shows where each category does its job and where its reach ends.

The teams responsible for each stage select and configure tools for that stage, and some types of tools might have roles in multiple stages. The breakdown below describes the threats and tools common in each stage and discusses how artifact management adds to and interacts with the tools already there.

Functional concept 1: identity and organization security

: Many of the largest and most recent supply chain compromises started with stolen credentials. Phished maintainer accounts, leaked CI tokens, and long-lived publish keys left on a build runner allow attackers to act as someone you trust. The self-replicating worm campaigns of 2025 and 2026 spread because each account compromise stole the tokens it needed to publish the next one.

: Identity tooling makes the people and systems that produce your software hard to impersonate. Elements of identity management include single sign-on, phishing-resistant multi-factor authentication, scoped permissions, and short-lived tokens that reduce the window attackers have to use them. Identity management applies to both human and non-human identities. A CI job that authenticates with a short-lived OIDC token leaves nothing long-lived behind. A malicious install script can only use a short-lived token while that job runs.

: Identity providers (e.g., Okta, Microsoft Entra ID), the identity and token/secret controls built into GitHub and GitLab, secrets managers, hardware security keys, and trusted publishing on public registries like npm and PyPI.

: Identity controls stop impersonation. They don’t stop a legitimately signed-in user, or a hijacked session, from pulling or publishing a bad package. Similarly, secret detection tools typically identify leaked credentials, but don’t indicate whether those credentials are still valid or need rotation.

: Your identity provider decides who someone is; the artifact manager decides what that identity can pull and publish. An artifact manager sits downstream and consumes identity from your identity provider (IdP), adding its own controls: role-based access, fine-grained publish and consume permissions, and OIDC authentication for CI so pipelines don’t need long-lived credentials.

Functional concept 2: detection and analysis

: Risk hides in first-party code and in third-party dependencies. Those risks include known and unknown vulnerabilities, malicious packages, leaked secrets, unsafe code patterns, and licenses you can’t or don’t want to ship. Your first-party code, whether written by developers or AI agents, is usually the smaller share of what ships. The rest is third-party dependencies.

: Detection tools find risk and report it. The same scanner can run in the IDE, on a pull request, in CI, and against a registry, and its output at every one of those points is a finding. That visibility is how teams learn what’s wrong, and most of the security tooling teams already own sits here.

: Software composition analysis (SCA), static application security testing (SAST), secret scanning, malware and behavioral package analysis, reachability analysis, and license detection. Example vendors include Snyk, Semgrep, Socket, Endor Labs, and GitHub (CodeQL and Dependabot).

: Detection only stops something when you connect findings to a mechanism that can act on them. Scans are point-in-time assessments and a software bill of materials (SBOM) is an inventory until actioned. A package that was clean when it arrived can pick up a critical advisory next week, so dependencies you pulled a year ago need re-checking as much as the ones arriving today.

: Artifact management adds a place to act on detection findings for every package that routes through it: matching stored packages against vulnerability and malware intelligence, re-checking them as new advisories land, applying policy when there’s a match, and blocking or quarantining packages that fail policy checks. Your SCA tool keeps doing what it does best, assessing reachability, fix paths, and remediation pull requests, and the registry provides a place to proactively enforce those findings.

: Bad code gets written or slips past review, or someone tampers with the repository directly. The author might be a developer or an AI assistant so the authoring environment matters at this stage, too: IDE extensions, AI code generators and editors, and MCP servers can all run with a developer’s privileges, and a poisoned extension or hidden instruction file can misdirect an AI author.

: Tools at this stage govern first-party code before and as it’s committed. Branch protection, basic source control management (SCM) best practices, and required reviews keep changes from landing unchecked. SAST reads source code for patterns that lead to vulnerabilities, like injection flaws or hard-coded credentials. Secret scanning catches keys and tokens before they reach a shared repository. Commit signing shows that a change came from the source that claims it.

: SAST (e.g., Semgrep, Snyk Code, GitHub CodeQL, Checkmarx, Veracode), secret scanning (GitHub secret scanning, TruffleHog), commit signing (Git’s native signing, Sigstore’s gitsign), and source control platforms with built-in policy (GitHub, GitLab, Bitbucket, Azure DevOps).

: These tools scan the repository you own. Third-party packages arrive in 

 or a virtual environment, not in your source tree, so SAST and code review never see them. In other words, 

a dependency’s pre- or post-install script never shows up in a pull request diff

: SAST and code review cover the code you write, while artifact management covers the code you pull in. These two code paths meet during the build process. Some artifact managers integrate with IDEs so developers can see package data while they work, but source code security stays with the tools above.

: Whoever controls the build controls the output, and an attacker can feed a build malicious inputs, like a poisoned dependency or a tampered build setting, or compromise the build platform itself. The 

 attack in June 2026 turned a project’s own process against it. The attack used a compromised maintainer account to push commits into Red Hat repositories without review. Those commits added a GitHub Actions workflow that ran inside the project’s own trusted publishing pipeline. The pipeline built and published malicious versions of packages in the 

 npm namespace, and because the legitimate pipeline produced them, they came with valid provenance attestations.

: Build integrity tooling aims for builds that are hermetic (no unexpected outside inputs), reproducible (the same source produces the same artifact), and provable. The output is provenance: a record of which build platform produced the artifact, from which source, with which parameters, that someone downstream can check later.

: Hosted build platforms with provenance support (GitHub Actions, GitLab CI), container build tooling (Docker BuildKit), hardened build pipelines (Chainguard), and open frameworks such as SLSA, in-toto, and the slsa-github-generator.

 went into the build was safe. The Miasma packages were built and published by the project’s real pipeline, so their provenance was accurate. The problem was the code the attackers had already slipped in before the build ran.

: The build runs in CI/CD, not in the registry. Artifact management touches this stage at both ends. Going in, it’s the source of a build’s dependencies, so a governed registry controls the build’s dependency inputs. Going out, it ties each push to a specific pipeline identity through OIDC and stores the provenance the build produces alongside the artifact.

Stage 3: artifact signing and attestation

: This stage is where a build leaves the build process and enters distribution. The primary threat is that what consumers receive isn’t what the legitimate build produced, or wasn’t produced by the legitimate build at all. Stolen publish tokens are a common threat route: the attacker skips the build entirely and publishes a malicious version straight to the registry under the maintainer’s name. That’s how Shai-Hulud spread.

: Signing binds an artifact, and its provenance, to the identity that published it, so consumers can detect any change after signing. Trusted publishing replaces long-lived publish tokens with short-lived OIDC identity tied to a specific pipeline, which closes off the stolen-token route.

: Sigstore (Cosign for artifacts, with Fulcio and the Rekor transparency log), Notation, GPG signing, GitHub artifact attestations, and trusted publishing on npm and PyPI.

: A signature proves who published an artifact and that it hasn’t changed since. It doesn’t prove that the contents are safe. That’s what happened with Miasma – attackers worked through the project’s actual pipeline, so the malicious packages carried valid signatures and passed verification. A signature is only useful if something checks it before using the artifact, and that check happens downstream on the consuming side.

: Signing tools and trusted publishing create the proof in the build, and a registry is one of the places that can check that proof before anything uses the artifact. A registry can keep signatures and attestations with the artifacts they describe, add its own signature on distribution, and refuse artifacts that arrive unsigned or with provenance that doesn’t match an approved pipeline, when policy specifies.

Stage 4: registries and artifact management

: The public registries or CDNs serving your artifacts get compromised, or serve something other than what was published.

: Every registry stores and distributes artifacts. Artifact managers do more, enabling private registries to function as a control point: they verify signatures, keep artifacts immutable, cache upstream sources so builds don’t depend on the public registry staying up, and apply access and security policy to what goes in and out.

: Universal artifact managers (Cloudsmith, JFrog Artifactory, Sonatype Nexus), cloud provider registries (AWS CodeArtifact and ECR, Azure Artifacts, Google Artifact Registry), developer platform registries (GitHub Packages, GitLab Package Registry), and vendor-curated registries for hardened images (Chainguard, Docker Hardened Images).

: A registry protects what’s in its custody. It doesn’t govern how artifacts were written or built upstream, and it only covers the paths that route through it. A developer laptop pointed at a public registry and with no other endpoint protections in place receives none of the safeguards an artifact manager may provide.

: This is artifact management’s primary function: one place to store, govern, and distribute the formats a team uses – language packages, containers, and AI models – with immutable versions, access controls, and caching close to your builds. Public registries and vendor-curated registries for hardened images stay in the picture as upstream sources; an artifact manager proxies and governs them.

Stage 5: package selection and policy gating

: A developer, build, or AI agent pulling the wrong package: a misspelled package name (typosquatting), an internal package name hijacked on a public registry (dependency confusion), a name an AI assistant hallucinated that an attacker registered (slopsquatting), or a brand-new malicious version of a package you already trust. Install scripts increase the pressure to select a safe dependency because they run the attacker’s code before your code imports anything.

: Tools at this stage decide what’s allowed into your environment before it’s installed. A 

 evaluates each package request against policy and takes action on the ones that fail, blocking or quarantining them. 

 hold brand-new versions until the community has time to spot a compromise, which doesn’t depend on an advisory existing. Curated catalogs and hardened images narrow the set of approved components from the start. Package managers help too: pnpm 10 no longer runs dependency install scripts by default.

: Dependency firewalls, deployed on endpoints (Socket Firewall’s CLI), as proxies (Socket Firewall Enterprise, Sonatype Repository Firewall, Veracode Package Firewall, StepSecurity Secure Registry), or inside an artifact manager (Cloudsmith, JFrog Curation); dependency confusion protection; allowlists and curation; and hardened images and curated libraries (Chainguard, Docker Hardened Images, Minimus, RapidFort).

Cloudsmith Blog

Software Supply Chain Defense in Depth: A Stage-by-Stage Guide