Software supply-chain risk is no longer limited to vulnerable libraries sitting inside a finished application. The more dangerous pattern is showing up earlier: attackers are targeting the developer workstation, the package manager, the CI/CD runner, and the cloud runtime that turns code into production software.

Unit 42’s latest analysis frames this shift clearly: modern applications are assembled through a chain of open-source packages, scripts, extensions, build tools, containers, and cloud identities. That means the “factory” building the software is now part of the attack surface. Read the original Unit 42 research here.

What changed

Traditional application security programs tend to focus on the final artifact: scan the repository, produce an SBOM, patch known CVEs, and ship. That still matters, but it misses the moment when supply-chain malware actually executes.

Package lifecycle scripts, IDE extensions, CI/CD plugins, helper tools, and container base layers can all run with enough privilege to steal secrets, alter builds, or create persistence before the application ever reaches production. A clean source-code scan does not prove the build path was clean.

The ChainDrop-style pattern is especially important for defenders because it combines three behaviors that are difficult to catch with compliance-only controls:

  • Execution during routine developer activity: malware can run when a developer installs a dependency or when a pipeline resolves packages.
  • Credential and token theft: temporary CI/CD tokens, cloud credentials, GitHub or npm tokens, and local developer secrets become propagation fuel.
  • Self-propagation through trusted accounts: stolen publisher and repository access can be used to republish packages or seed new malicious repositories.

Why this matters for SMBs and government contractors

Large enterprises are not the only target. Small software teams, managed service providers, and government contractors often rely heavily on open-source packages, GitHub Actions, hosted build systems, container registries, and SaaS developer tooling. Those environments may have production-level access but lighter monitoring than traditional servers.

That creates a practical risk: an attacker who compromises a developer endpoint or build runner may not need to exploit the production application directly. They can steal deployment credentials, alter dependencies, backdoor a release, or use trusted build infrastructure as a launchpad into customer environments.

The defensive lesson: map where code executes

An SBOM is useful, but it is not enough by itself. Defenders need visibility into every place third-party code can execute across the software delivery lifecycle:

  • Developer endpoints: package managers, shell scripts, local environment files, IDE extensions, SSH keys, cloud CLIs, and browser-stored developer sessions.
  • CI/CD pipelines: build runners, workflow actions, plugins, secrets stores, OIDC trust relationships, artifact signing, and outbound network access.
  • Cloud runtime: container base images, operating system packages, service identities, registry provenance, and runtime drift from approved images.

For many teams, the highest-value starting point is not buying another scanner. It is answering a simple question: “If a dependency install script or CI/CD plugin tried to steal credentials today, where would we see it?”

Practical controls worth prioritizing

  • Disable install scripts by default where possible. For npm-heavy environments, evaluate --ignore-scripts and only permit lifecycle scripts for reviewed packages that truly require them.
  • Pin dependencies and actions. Pin GitHub Actions and critical packages to specific versions or commit SHAs instead of floating tags.
  • Use package cooldown policies. Do not auto-ingest newly published packages or versions into sensitive builds without a waiting period and review.
  • Move away from long-lived secrets. Prefer short-lived OIDC-based authentication for CI/CD, scoped tokens, and rapid token revocation workflows.
  • Restrict CI/CD egress. Build runners should not have unrestricted internet access. Alert on unusual outbound connections during builds.
  • Use ephemeral runners. Treat build systems as hostile-by-default and rebuild them from known-good images rather than leaving persistent runners alive indefinitely.
  • Sign artifacts and verify provenance. Signed commits, signed build artifacts, and verifiable provenance make unauthorized build-path changes harder to hide.
  • Monitor developer tools. IDE extension changes, package-manager configuration changes, unexpected tasks, and new credential access from developer machines should be treated as security telemetry.

Bulwark Black assessment

The core mistake is treating the SDLC as a trusted internal process instead of a production attack surface. Developer machines, build pipelines, registries, and cloud deployment identities are now control-plane assets. They deserve the same segmentation, logging, identity governance, and incident-response planning as public-facing infrastructure.

For small teams, the right approach is incremental: start by inventorying build tools and secrets, reduce long-lived tokens, lock down CI/CD egress, and enforce dependency pinning for sensitive projects. Those steps will not eliminate supply-chain risk, but they materially reduce the blast radius when the next malicious package or compromised maintainer account appears.