--- title: "Software supply chain security: a defense-in-depth guide" description: "A stage-by-stage look at software supply chain defense, using the Shai-Hulud and Miasma attacks to show where tools stop and how artifact management helps close gaps." canonical_url: "https://cloudsmith.com/blog/software-supply-chain-defense-in-depth-a-stage-by-stage-guide" last_updated: "2026-11-05T13:00:00.000Z" --- # Software supply chain security: a defense-in-depth guide You can do everything right and still be impacted by a software supply chain attack. The self-replicating [Shai-Hulud](https://cloudsmith.com/blog/evolution-of-shai-hulud-worms) worm, and its variants, are recent examples of this. Compromised packages ran `postinstall` scripts, and later iterations used `preinstall` 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. ## **Every handoff is an attack surface** 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 _production_ 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 software supply chain security stack** 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. ```json { "_key": "1f44c9c50fbc", "_type": "image", "alt": "Overview of the key inputs into the software development lifecycle.", "asset": { "_createdAt": "2026-11-04T19:23:32Z", "_id": "image-9313acc050cf93a947c7b8dd1b94f4e3ff58b315-3840x2160-png", "_rev": "sMpkL00so0fjEqhHQHnIHa", "_type": "sanity.imageAsset", "_updatedAt": "2026-11-04T19:23:32Z", "assetId": "9313acc050cf93a947c7b8dd1b94f4e3ff58b315", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "MBSY{stm~U%Ls*-pjZt6ozR+_2V?K5ogRR", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.7777777777777777, "height": 2160, "width": 3840 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAPoAAAD6AG1e1JrAAAByElEQVQokX2T62obMRBG8/6vVgrtj1JoLq5T27u2V3dpdV2dsptLk0A6IDQjmMMnfaMbPkSrndlXvC44ldEiYmTC6YI3lTwv9IVP4+Zt0TdgI7iAUxavHFYYrHzKnXKkkOhLf27oT00v+StwKzpt6cypYK0lWEnymugkwSqmSXIaBEp7am303unLqnaF9jfANWmN3iphruwuhdtTZNIz8zwTgkMax68/hq+3ivvBYUJijonoZ4oPtBBYUoRl4YZWWYKhWYkUjm+7xJe7zOM1I0zgLDSnSfNw0vzcS3ajYRSG81UhTxf8YSAeD1RxoZfETa+FZgRVjlip2Z8T92PhrDKTdhwvkuNFcbwqHke5wdc1jBPiMOL3R+LjnnId6DmuV1428pIjOWVMKAib0b5gQ0LZwKQDD4Pjx17ze3Sbcm0cXhqyUFQpaE6zint2+elBa1vQPnNWEWUzKTdqa/hY2A2G73cXfo+WEMtmTKuVXip93VvdjHk3Nrl2zrpwmFalbXN9dTOnghSC4XRASknOdTt/dfedyx+AF9sYVSPkFfYy6AUjHXqSGOmJodDaywD+Z7Dr0rHzgg7LBv8HrDidcSZvPyaG+inwL9DgVXZZ8crWAAAAAElFTkSuQmCC", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#163d82", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#133570", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#6b97e5", "foreground": "#fff", "population": 1.53, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#b1bfd2", "foreground": "#000", "population": 0.89, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#91cefc", "foreground": "#000", "population": 0.01, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#c4a693", "foreground": "#000", "population": 0.43, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#6b97e5", "foreground": "#fff", "population": 1.53, "title": "#fff" } }, "thumbHash": "/fcBDID4iJt2iGdvh4r1iDqfqA==" }, "mimeType": "image/png", "originalFilename": "4 ECOSYSTEM + Cloudsmith.png", "path": "images/rafvlnhi/production/9313acc050cf93a947c7b8dd1b94f4e3ff58b315-3840x2160.png", "sha1hash": "9313acc050cf93a947c7b8dd1b94f4e3ff58b315", "size": 222435, "uploadId": "379f3d3274373b4807a560898d1b2983f5c72379", "url": "https://cdn.sanity.io/images/rafvlnhi/production/9313acc050cf93a947c7b8dd1b94f4e3ff58b315-3840x2160.png" }, "caption": "Overview of the key inputs into the software development lifecycle.", "link": { "_type": "link", "href": null, "openInNewTab": false }, "markDefs": null } ``` 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** _Threats_: 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. _What the tools do_: 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. _Tool categories_: 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. _Where its reach ends_: 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. _Artifact management’s role: **contributor**_: 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** _Threats_: 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. _What the tools do_: 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. _Tool categories_: 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). _Where its reach ends_: 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’s role: **contributor**_: 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. ```json { "_key": "18c139bf3731", "_type": "image", "alt": "Stage 1 of the software supply chain security stack", "asset": { "_createdAt": "2026-11-04T19:27:30Z", "_id": "image-6d0010838e25ab811c601ba73c1c62b478faf6c1-1920x1080-png", "_rev": "9eqmGbUy4mxL63NADXG339", "_type": "sanity.imageAsset", "_updatedAt": "2026-11-04T19:27:30Z", "assetId": "6d0010838e25ab811c601ba73c1c62b478faf6c1", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "M9SPeFNh^$_1E5-pV@NdX8ae~AIUIqNKRi", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.7777777777777777, "height": 1080, "width": 1920 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAPoAAAD6AG1e1JrAAABl0lEQVQokY2S225TMRBF8/9/BeKBDyBUBVVV00su5+oc3z3jhY4TlYcAxdKWLMteM569N/MSGY3D2EjMilYopRK94F1pWvc5Kap8uDbd5DgOZ6ZzIGZBtJJCYZk9ZrTMo+U8ObyNiHxM3PSz5zRZ1k4bUJTgI9MwMfYDY3fRYhaklPeHtVb0qnVf6xVog7CEgo1CKpVclG6O3O8M28eJ7ePI98eJ3cHiQkFVKSKEmLE+NvmYyEVYmZuQYZXPNGDIlede+Poj8Wkb+Lz1fLmLfNslxiURYmqQfl546yZeTyPH0bQzUf0NDFdgkspgKw9H5e4lN93vhZdBMC7hQ2RxgdNo2B16nvZdA59d+ANQajNldXt2Qm8y3bx2VliC4mLBhoILGWM9o7EMZp2/I6Tc5vkXYGVYhLch8tIFjnPm7C9FOrNChSyXWZamNVIXV26+XKRiY+V1VB4OmZ/7zFMn9ItinDDZQkj67upNbG6AWnGpcjSV50HY9cLrpExOideC12b+A9guX6A+aZvbKhuVkBWpa/7+HexfawpYOC/SYS4AAAAASUVORK5CYII=", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#0d3b8b", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#0b3379", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#5e94f0", "foreground": "#fff", "population": 0.89, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#b1bed5", "foreground": "#000", "population": 0.09, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#74acfc", "foreground": "#000", "population": 0, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#868e94", "foreground": "#fff", "population": 0.07, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#5e94f0", "foreground": "#fff", "population": 0.89, "title": "#fff" } }, "thumbHash": "/fcBDIDkW4Bmh2dfZYryiU6s+A==" }, "mimeType": "image/png", "originalFilename": "STAGE 1.png", "path": "images/rafvlnhi/production/6d0010838e25ab811c601ba73c1c62b478faf6c1-1920x1080.png", "sha1hash": "6d0010838e25ab811c601ba73c1c62b478faf6c1", "size": 76829, "uploadId": "ca94f18af67c06f91e2c3b2031598eb0435f3703", "url": "https://cdn.sanity.io/images/rafvlnhi/production/6d0010838e25ab811c601ba73c1c62b478faf6c1-1920x1080.png" }, "caption": "Stage 1 of the software supply chain security stack", "link": { "_type": "link", "href": null, "openInNewTab": false }, "markDefs": null } ``` **Stage 1: source and code integrity** _Threats_: 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. _What the tools do_: 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. _Tool categories_: 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). _Where its reach ends_: These tools scan the repository you own. Third-party packages arrive in `node_modules` 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_. _Artifact management’s role: **adjacent**_: 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. ```json { "_key": "25d402d5c6a8", "_type": "image", "alt": "Stages 2-5 of the software supply chain security stack occur during the build process. Note: The location and function of Stages 4 and 5 changes when using Cloudsmith.", "asset": { "_createdAt": "2026-11-04T19:28:22Z", "_id": "image-0c84805c82c37f4a32c28c97dc4ee6b427048748-1920x1080-png", "_rev": "9eqmGbUy4mxL63NADXG7gZ", "_type": "sanity.imageAsset", "_updatedAt": "2026-11-04T19:28:22Z", "assetId": "0c84805c82c37f4a32c28c97dc4ee6b427048748", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "M9R:KTyE.7?uxu~qjDIWIpbI^*xUE2E3WA", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.7777777777777777, "height": 1080, "width": 1920 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAPoAAAD6AG1e1JrAAAB40lEQVQokWWS7U7cMBBFef83q1RRflBKYbdQ2N12N7E9Hn8mcfZUCagtYOnqjKXR6Hp8LyRUjE9IKNSh0dpMa415njmfWbWcBVObyUMj1UYalvpMGaCM/3ThwkAvhYW5TJQyknOl1JFxnGnTzNzOtHZmGBoaB5xWJAyENJHKTKpn8qsuQpnRPLMw10YMAyqF4OuqqAM5jq+a8L5iTcbZgrUFLwPqx1UxNi7+t1uGmagZbxW1ihjBG0+wSnCBpIUgCTF+7XG9IL1fe5b7YubNQM2N3THytLecOseps3SLekvfO8RnYoxEFVLwK+NSLwx+XdXfgXWEzjc+3yc+fVfunoXt3rM9KD8OwsMv5WAKEgshZWJ+YUgZjWllKtNbhzZMXP+MfNkq3548d7vA/T5x+6xs9oGDyXSS1lQ4zRiJdC5wskovER/fPVlSWwdcbiOXG+Vq67naCpd3lusHYdclep/XgVYTVjzGWnpjsSL4mD/u8OlUuXnK3DwGbh86bjY7vt7v2DweOZqwxmuNjSaCN6g9oOZA9CdSih9/OcQJ65ZoJFzvMMcj/e8j3hhiyGiYcG7AuYxawfcnpDsSnSW9d1jHMyW3lwxKJenCgreZ6CslTcTQEFtxtuJdRZY8moxf+lPjD0MHTAaW5YrRAAAAAElFTkSuQmCC", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#104788", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#0d3d76", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#4c94ea", "foreground": "#fff", "population": 0.1, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#d4c4b4", "foreground": "#000", "population": 0.01, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#8dcdfb", "foreground": "#000", "population": 0.04, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#a0927c", "foreground": "#fff", "population": 0.03, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#4c94ea", "foreground": "#fff", "population": 0.1, "title": "#fff" } }, "thumbHash": "/PcBBIDorIV9VZiPRGXAuy6p+g==" }, "mimeType": "image/png", "originalFilename": "STAGES 2-5.png", "path": "images/rafvlnhi/production/0c84805c82c37f4a32c28c97dc4ee6b427048748-1920x1080.png", "sha1hash": "0c84805c82c37f4a32c28c97dc4ee6b427048748", "size": 130816, "uploadId": "a3529333a8c65c725a760429f3e655887b22eff8", "url": "https://cdn.sanity.io/images/rafvlnhi/production/0c84805c82c37f4a32c28c97dc4ee6b427048748-1920x1080.png" }, "caption": "Stages 2-5 of the software supply chain security stack occur during the build process. Note: The location and function of Stages 4 and 5 changes when using Cloudsmith.", "link": { "_type": "link", "href": null, "openInNewTab": false }, "markDefs": null } ``` **Stage 2: build integrity and provenance** _Threats_: 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 [Miasma](https://cloudsmith.com/blog/miasma-worms-path-of-destruction) 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 `@redhat-cloud-services` npm namespace, and because the legitimate pipeline produced them, they came with valid provenance attestations. _What the tools do_: 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. _Tool categories_: 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. _Where its reach ends_: Provenance proves _how_ something was built, not that _what_ 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. _Artifact management’s role: **contributor**_: 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** _Threats_: 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. _What the tools do_: 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. _Tool categories_: Sigstore (Cosign for artifacts, with Fulcio and the Rekor transparency log), Notation, GPG signing, GitHub artifact attestations, and trusted publishing on npm and PyPI. _Where its reach ends_: 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. _Artifact management’s role: **contributor**_: 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** _Threats_: The public registries or CDNs serving your artifacts get compromised, or serve something other than what was published. _What the tools do_: 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. _Tool categories_: 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). _Where its reach ends_: 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. _Artifact management’s role: **core**_: 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** _Threats_: 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. _What the tools do_: Tools at this stage decide what’s allowed into your environment before it’s installed. A [dependency firewall](https://cloudsmith.com/blog/a-dependency-firewall-gives-your-scanner-better-inputs) evaluates each package request against policy and takes action on the ones that fail, blocking or quarantining them. [Cooldown policies](https://cloudsmith.com/product/package-cooldown-policies) 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. _Tool categories_: 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). _Where its reach ends_: A gate only protects the paths that go through it. Endpoint tools cover the machines where they’re installed and kept up to date. Proxies cover the ecosystems they support. Any path that reaches the public registry directly bypasses the artifact registry gate. Policy can have an operational cost: if it’s too strict, developers route around it and if it’s too loose, it doesn’t reduce risk. _Artifact management’s role: **core**_: An artifact manager is positioned to gate every supported package on the entry path packages already take, with policy set once for the whole organization instead of on each machine. It’s also where policy can act after the fact, quarantining a package already in use when new intelligence flags it. Detection tools feed this stage. A behavioral analysis tool’s findings and the registry’s enforcement cover different parts of the same decision. Endpoint firewalls remain relevant because they can cover installs that go around the registry. ```json { "_key": "9a16326eb43a", "_type": "image", "alt": "Stage 6 of the software supply chain security stack", "asset": { "_createdAt": "2026-11-04T19:34:35Z", "_id": "image-1291cc9ce6bc72bce097925e85146df42edf8e2f-1920x1080-png", "_rev": "9eqmGbUy4mxL63NADXH2ed", "_type": "sanity.imageAsset", "_updatedAt": "2026-11-04T19:34:35Z", "assetId": "1291cc9ce6bc72bce097925e85146df42edf8e2f", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "MCSr_zL2%g+zFL%NWBWBWBWB.lm,D*Orrr", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.7777777777777777, "height": 1080, "width": 1920 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAPoAAAD6AG1e1JrAAABW0lEQVQokZXT626jMBBA4bz/G6600jYN5k7AYALYM3NWkLTpSq1WsXT+IPTJePDJTytXP+PDyhoVM15c9ui+TtU1ULQj/biwPUA1Q0RJIp+JCCqKqe4vPFJMBFN5gmU7kjeeYVrZkiFqbDExhoV+mu+NM5MPrH5CxoCFG8w3bJ7RcUBv4RM9+TniQ2Re5QCTKPOyUV1HXNMf5fWVJm8Il4I1K5GiwaoWrSrE/UG7Aosb++edlggffYBhWSk7z6XqjrKyo84qpjfH8uaI7wXqKtQ55PwLrS9YXP8HDgf2Xt7BxtWEc856dqRLgeUvg/65w6qjPkDHdnZItoP162BWX49c1dEUDXNWkvadFTVWtmhZINlvtM1/PsN9ysuWjsm2w3TUDRO+H9n6ER0mzN9T79G+QcOASbpP+R9Q7Pi9djQmYYvPUkxYSpDkS/uzCDv2uBHfgj9fCvu+L+svsnpWOUEm2SIAAAAASUVORK5CYII=", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#6a3f2e", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#5c3627", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#d6b5b2", "foreground": "#000", "population": 0.22, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#d6b5b2", "foreground": "#000", "population": 0.22, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#f6c4ac", "foreground": "#000", "population": 0.04, "title": "#000" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#ad8a82", "foreground": "#fff", "population": 0.08, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#c48c76", "foreground": "#000", "population": 0.01, "title": "#fff" } }, "thumbHash": "/QcCDIK4doR3d3dfhIdwhwV2OA==" }, "mimeType": "image/png", "originalFilename": "STAGE 6.png", "path": "images/rafvlnhi/production/1291cc9ce6bc72bce097925e85146df42edf8e2f-1920x1080.png", "sha1hash": "1291cc9ce6bc72bce097925e85146df42edf8e2f", "size": 53393, "uploadId": "69b14c66ebafdd3176b0a863406c5d4412e442cf", "url": "https://cdn.sanity.io/images/rafvlnhi/production/1291cc9ce6bc72bce097925e85146df42edf8e2f-1920x1080.png" }, "caption": "Stage 6 of the software supply chain security stack", "link": { "_type": "link", "href": null, "openInNewTab": false }, "markDefs": null } ``` **Stage 6: runtime and admission control** _Threats_: Malicious packages become dangerous when they run at install time on developer machines and CI runners, as well as in production. Malicious code in install scripts harvests credentials during installation. _What the tools do_: Admission controllers can refuse to deploy artifacts without valid signatures or provenance. Runtime monitoring watches deployed workloads for behavior they shouldn’t show, such as unexpected network requests or cryptojacking. On build infrastructure, CI-runner monitoring watches build jobs for unexpected network traffic and processes. _Tool categories_: Kubernetes admission control (Kyverno, OPA Gatekeeper, Sigstore policy-controller), cloud and runtime security platforms (Wiz Defend, Sysdig/Falco, Prisma Cloud, Aqua), and CI-runner monitoring (StepSecurity Harden-Runner). _Where its reach ends_: These tools act last, after selection, build, and distribution already happen. Production runtime tools don’t see a developer laptop or a CI runner, which is where install-time attacks land. Admission control can only check signatures and provenance that were produced earlier in the chain. _Artifact management’s role: **adjacent**_: Runtime and admission controls live in the deployment environment. Artifact management feeds them, supplying the signed, attested artifacts that admission controllers verify, and the record of what was pulled, by whom, and when. ## **How Shai-Hulud moved through each stage** Shai-Hulud is a useful example of the whole stack because it touched almost every stage and still got past teams with controls in place. **Stage 1** never saw the attack coming in. The malicious code didn’t pass through any repository, so code review and SAST had nothing to scan. It showed up here on the way out: the worm used stolen GitHub tokens to push malicious workflow files into its victims’ repositories, where branch protection and required reviews on workflow changes could have slowed it down. **Stage 2** never came into play. There was no build to compromise because the attackers went around the build pipeline. **Stage 3** is where the attack got in. Attackers used stolen npm tokens to publish new patch versions directly to the public registry, which accepted them because they arrived with valid credentials. The malicious versions carried no provenance. Trusted publishing, with token-based publishing turned off, could have rejected those uploads. The worm also spread through this stage, using each victim’s tokens to republish the other packages they maintained. **Stage 4** served the malicious versions like any other release until they were reported and removed. Teams pulling directly from the public registry were subject to that removal timeline. Teams pulling through a governed registry could block or quarantine a flagged version for every consumer at once. **Stage 5** is where the attack hit most teams, often without intentionally choosing the infected package. A version range like `^1.2.3` pulls in the newest patch automatically, so the next install or lockfile update brought the malicious version with it. Teams that pinned an earlier version stayed on the one they already vetted. A cooldown on new versions, or a dependency firewall checking packages against current malware intelligence, could have stopped the attack before install. Most of the attack’s damage happened at **Stage 6**, but not necessarily in production. Install scripts ran the payload the moment the package installed, on developer laptops and CI runners holding npm tokens, GitHub tokens, and cloud keys. The payload collected those secrets and sent them out to GitHub repositories the worm created with the victim’s own tokens. Production runtime tools never saw it. Install scripts turned off by default, short-lived build credentials, and limits on what CI runners can send out could help reduce the available data an attack can exfiltrate. Across the stack, none of the tools failed. Trusted publishing could have blocked the stolen-token uploads. Analysis tools [flagged the malicious packages within a day](https://www.reversinglabs.com/blog/faq-shai-hulud-explained). Lockfiles, cooldowns on new versions, and a dependency firewall could have kept most installs from picking them up, and install scripts turned off by default could have limited what the payload took from anything that got through. There are two aspects to the gap between those controls: the zero-hour window before a threat advisory existed, and the time after, when findings existed but hadn’t reached anything that could stop the next install. A cooldown on newly published packages covers the first part, and enforcing known advisories covers the second part. Stage 5 is where artifact management does both. It takes the intelligence that detection tools produce and enforces it on every laptop, runner, and agent that installs through it, including quarantining versions already pulled. The other controls still matter because a registry can’t stop a stolen token from publishing, or a worm from pushing workflow files into your repositories. ## **Artifact management sits where producers meet consumers** Artifact management is the process of storing, organizing, versioning, securing, governing, and distributing software artifacts across the entire development and deployment lifecycle. Routing external package sources through an artifact manager creates a single entry path into your environment and a control point for governing those packages before they land. Most organizations consume and produce software, and the two processes meet at the build, where third-party dependencies and first-party code combine to produce the artifacts you ship. Artifact managers sit on both sides of that point, governing the code that enters a build, and acting as the governed channel for the artifacts you publish. The artifact manager is also where the output of the rest of the stack can come together. Identity from your IdP decides who can pull and publish. Findings from detection tools become policy decisions on each package. Storing build signatures and provenance with the artifact allows registry policy or deployment checks to verify them. Hardened images and curated components arrive as governed upstream sources. All these tools have an important job to do, and the artifact manager governs and records their output. Artifact management works best at securing external packages and protecting your development environment when every source routes through it. Resolving packages through the artifact manager, instead of directly from public registries, applies the same checks whether the install happens on a workstation, a CI runner, or by an AI agent. Keeping that path easy to use – OIDC for pipelines, access controls set once, and a clear exception process when policy blocks something a team needs – is what keeps developers from routing around it. ## **Building a defense-in-depth stack** The supply chain security ecosystem requires a defense-in-depth approach that includes SAST, SCA, hardened images, dependency firewalls, an artifact registry, and more. Building an effective security posture also requires understanding how these tools work and what their limits are. Point these tools at the gates and entry points they’re designed to protect. Each tool in the stack covers a specific stretch of the development process: SAST and review on the code you write, SCA and behavioral analysis on the dependencies you use, hardened images and dependency firewalls on what you pull, signing and provenance on what you build, runtime and admission controls on what you run. Artifact management connects these tools at the point where external packages enter and your own artifacts leave, so findings from the rest of the stack turn into decisions on every package that routes through it. Learn more about Cloudsmith’s [software supply chain security](https://cloudsmith.com/product/software-supply-chain-security) features and capabilities.