Supply Chain Security Enters Its Automated, AI-Assisted Threat Phase

Software supply-chain attacks are shifting from opportunistic compromises toward automated campaigns aimed at the systems that select, build and deploy code. Sonatype’s 2025-2026 State of the Software Supply Chain report described a continued expansion of malicious open-source components and attacks exploiting maintainer accounts, dependency confusion and package-name imitation. The CVE database also recorded continued growth in vulnerabilities affecting build systems, package managers and development infrastructure, though CVE counts capture only disclosed flaws and not malicious packages that operate as designed. The August 2026 discovery of Rust crates that impersonated legitimate packages and stole developer credentials illustrates the change, according to The Register. Separately, Snyk’s State of Open Source Security research found that AI-assisted development can introduce packages without adequate verification. Researchers have called one variation “slopsquatting”: An AI coding agent recommends a nonexistent dependency, and an attacker registers that name before a developer installs it. August threat-intelligence reports also described phishing kits priced around $10,000 that could hijack authenticated sessions and enroll rogue passkeys, allowing access to persist after a password reset. The concentration of access is what makes these incidents consequential. CISA’s 2025-2026 supply-chain advisories said compromises of build services, publishing credentials or widely used dependencies can propagate to many downstream organizations. CISA’s August warning about a remote-code-execution vulnerability in Ray, a framework used for distributed and AI workloads, reinforced the exposure created when development infrastructure is reachable or insufficiently isolated. A Microsoft Security Response Center advisory assigning a critical Entra ID flaw a maximum severity score similarly showed that cloud identity belongs inside the software-production threat model. Executives should ask a narrower question than whether their companies own security tools: Can the company prove which source revision, dependencies, workflow and identities produced each deployed artifact? Google’s SLSA documentation treats that evidence as provenance, while Sigstore’s model binds signatures and attestations to verifiable identities. An SBOM alone doesn’t provide that proof. CISA describes SBOMs as transparency instruments, not guarantees that components are safe. The governing objective should be enforceable provenance: protected source, isolated builds, authenticated artifacts and deployment policies that reject outputs failing those tests. Sonatype’s findings suggest that registry hygiene—particularly in npm and crates.io—remains a weak point, making verification at build and deployment time more important than repository inventories alone.

Organizations implementing supply-chain controls should begin by distinguishing evidence generation from evidence enforcement. Google’s SLSA framework defines progressively stronger guarantees around build provenance and build-platform integrity. Its adoption materials indicate that provenance generation has spread through major cloud and open-source platforms, but that implementation remains uneven outside organizations with centralized build engineering. Many teams can produce basic attestations; fewer can demonstrate isolated, ephemeral builds in which developers can’t alter provenance or retrieve signing secrets. That distinction makes “SLSA compliant” an imprecise procurement claim. Google’s SLSA documentation organizes requirements by track and level, and an organization should identify the specific level, builder and workload being assessed. A vendor that emits provenance for one release workflow shouldn’t imply that every package, container and internal binary receives the same protections. Sigstore has reduced the operational barrier to artifact signing. According to the Sigstore project’s usage reporting, Cosign and related services have gained traction in Kubernetes, container and GitHub-centered workflows. GitHub artifact attestations and npm provenance have extended similar concepts into common developer workflows. Yet Sigstore’s documentation emphasizes that a valid signature proves an artifact was signed by an identity; it doesn’t establish that the identity was authorized, that the source was reviewed or that the build was safe. Production verification is therefore the dividing line. A company may sign every image while allowing its clusters to run unsigned images. CISA’s supply-chain guidance recommends policies that validate both artifact integrity and the authority of the producer. Teams should initially observe violations, establish exception procedures and then move high-risk environments to blocking admission. Coverage should be measured as the share of deployed artifacts successfully verified, not the number of repositories with a signing workflow. Dependency scanning also requires more than one analytical lens. GitHub’s native dependency review and Dependabot are designed to identify known vulnerable versions during pull requests. Snyk’s State of Open Source Security report describes reachability and remediation analysis intended to determine whether vulnerable code can be invoked. Behavioral tools such as Socket examine signals including install scripts, obfuscation, unexpected network access and abrupt maintainer changes. Sonatype’s 2025-2026 report found that malicious components may not contain a conventional vulnerability, which means a CVE-only scanner can miss packages whose intended behavior is credential theft. Registry controls deserve particular attention. Sonatype identifies public repositories as a persistent route into development environments, while The Register’s report on malicious Rust crates showed that a language ecosystem with strong memory-safety properties can still distribute hostile code. Lockfiles prevent unreviewed version drift, but they don’t make a deliberately selected package trustworthy. That limitation is more important when an AI agent proposes dependencies, according to Snyk’s research into AI-assisted development. Five measures should be prioritized. **First, make inputs immutable.** Pin dependencies, base images and CI actions to cryptographic digests, and require reviewed automation to update them. CISA recommends reducing mutable references in sensitive build workflows. **Second, generate evidence for every release.** Produce an SBOM and SLSA provenance from the final artifact, then retain both beside its immutable digest. Google’s SLSA documentation says provenance should identify the source, builder, invocation and output. **Third, remove persistent signing credentials.** Sigstore recommends workload identity and short-lived certificates so that CI systems don’t store reusable private keys. **Fourth, enforce verification.** Admission systems should confirm the digest, signer identity, trusted workflow and required attestations before deployment, consistent with Sigstore and CISA guidance. **Fifth, separate build and release authority.** CISA recommends protected branches, ephemeral runners, restricted network access and controls preventing a compromised build job from publishing without an independent authorization step. These controls won’t prevent every malicious dependency. They can, however, limit what a compromised package can reach and make unauthorized outputs materially harder to promote.

SLSA implementation starts with precise terminology. Google’s current SLSA Build track formally defines Levels 1 through 3. Level 4 belonged to an earlier version of the framework and shouldn’t be presented as a current certification level, according to the SLSA documentation. Organizations may retain Level 4-like requirements—such as hermeticity and reproducibility—as internal controls, but they should state those requirements explicitly. At Build Level 1, provenance records how an artifact was produced. Google’s SLSA provenance specification calls for an in-toto statement whose subject contains the output digest and whose predicate records information such as the source, builder and invocation. This evidence supports incident response, but it is only as trustworthy as the party generating it. At Level 2, Google requires provenance to be generated by a hosted build platform rather than solely on a developer workstation. The objective is to place artifact production and evidence generation under an authenticated service identity. At Level 3, the build platform must provide stronger resistance to tampering, including isolation between builds and controls preventing build users from forging provenance. SLSA’s threat model focuses on whether an attacker who controls one build can affect another, steal durable credentials or produce evidence for an artifact that wasn’t actually built. A practical GitHub Actions design should begin with minimal permissions. GitHub’s security documentation recommends read-only repository access unless a job needs additional capabilities. A release job using Sigstore keyless signing generally needs permission to request an OpenID Connect token, while registry write access should be limited to the publishing stage. CISA’s CI/CD guidance recommends splitting untrusted testing from privileged release jobs because pull-request code can attempt to read tokens, alter outputs or contact external systems. The build should reference a protected commit and pin third-party actions by full commit digest rather than a mutable tag. It should also resolve the base image by digest. Sonatype’s supply-chain research identifies mutable dependencies and compromised publishing paths as recurring sources of downstream risk. For containers, BuildKit can emit provenance and SBOM attestations while producing the image, but teams should confirm that the provenance mode captures the required metadata and doesn’t expose sensitive build arguments. Multi-architecture releases need additional care. The OCI image specification represents a multi-platform release through an index that points to platform-specific manifests. The release process should sign the index digest and retain per-platform SBOMs because native libraries can differ between Linux distributions and CPU architectures. Sigstore’s Cosign documentation recommends verification against immutable digests rather than tags, which registries can move after signing. In Sigstore’s keyless flow, Cosign creates an ephemeral signing key, Fulcio issues a short-lived certificate after validating the workload’s OIDC identity, and Rekor records signing metadata in a transparency log, according to Sigstore’s architecture documentation. This design removes the need to store a long-lived signing key in CI. It doesn’t remove the need to secure the identity provider or workflow configuration. Verification should constrain both the certificate issuer and the precise workload identity. For GitHub Actions, policy should ordinarily require the GitHub token issuer and the exact repository, workflow file and protected branch authorized to release. Sigstore warns that broad regular expressions can authorize similarly named repositories, forked workflows or pull-request contexts. A certificate that proves “GitHub issued this identity” is insufficient unless policy establishes that the identified workflow was permitted to publish the artifact. The SBOM should be generated from the immutable release image, not only from the checked-out source tree. CISA’s SBOM guidance notes that source manifests can omit operating-system packages, copied binaries and dependencies introduced during container assembly. Tools such as Syft can produce SPDX or CycloneDX documents from an image digest. SPDX’s specification emphasizes licensing, package relationships and document exchange, while the CycloneDX specification includes constructs useful for vulnerability operations, services and dependency analysis. The SBOM should then be attached as an attestation whose subject is the image digest. The same principle applies to SLSA provenance: The subject digest must equal the artifact evaluated by deployment policy. Google’s SLSA documentation warns that provenance referring only to a tag or an intermediate build output doesn’t reliably bind evidence to the deployed object. Admission policy closes the chain. Kyverno, OPA-based controllers and other Kubernetes admission systems can require signed images and attestations before a workload is accepted. Kyverno’s verification documentation supports digest mutation and signature checks, while Sigstore documents integrations for verifying keyless identities. A sound rule should require an immutable digest, a trusted issuer, an exact workflow identity and designated attestations. It should fail closed in production after an audit period, with exceptions that expire and identify an accountable owner. Provenance also needs semantic validation. An artifact may have a valid signature while its provenance points to an unexpected repository or an unprotected branch. Policy should compare the source URI, commit digest, builder identity and workflow parameters with an approved release definition. In-toto’s specification supports layouts that authorize identities for source review, build, test and release steps and connect each step’s materials to its products. Build isolation is equally important. CISA’s advisories recommend ephemeral runners, restricted egress and separation of secrets from untrusted build steps. The August 2026 CISA warning concerning Ray remote-code execution illustrates why internal development services shouldn’t be assumed safe merely because they aren’t intended for public use. Microsoft Security Response Center’s advisory on the maximum-severity Entra ID flaw likewise underscores the need to treat federated identity and token validation as dependencies of the release system. For monorepositories, provenance should identify both the repository commit and the component’s build path. Component-specific SBOMs reduce ambiguity when only part of a repository is released. For air-gapped environments, Sigstore documents private Fulcio and Rekor deployments as well as key-based Cosign workflows using KMS or HSM-backed trust roots. Offline environments can import signed bundles, but operators must define how transparency data, certificate roots and revocations are updated. The target state is a connected chain: protected source, immutable inputs, an isolated builder, provenance and an SBOM bound to the output digest, an authorized signature, registry publication and deployment-time verification. Google’s SLSA framework, Sigstore’s architecture and CISA’s supply-chain guidance converge on the same principle: Generating evidence is useful; refusing artifacts that lack valid evidence is the security control.