Supply Chain Attack Defense

Compromised dependencies caused major breaches. Defend against them.

Dependency scanning

Software supply chain attacks compromise the build pipeline rather than the deployed application directly. The attacker injects malicious code into a dependency, a base image, or a build tool; downstream consumers of that artifact pull the compromise into their own environments. Defending against supply chain attacks requires treating every dependency as a potential attack vector and applying multiple layers of verification.

What dependency scanning provides:

• Daily scans of dependencies for new CVEs.: Every dependency in every project is scanned daily against vulnerability databases (NVD, GitHub Advisory Database, Snyk, Sonatype). New CVEs surface within hours of publication. The team learns about vulnerable dependencies quickly.
• Auto-PRs for security updates.: Tools like Dependabot and Renovate open PRs that update vulnerable dependencies. The PR includes the CVE details, the affected version range, the safe target version. The engineering team reviews and merges; the human cost is minimized.
• Transitive dependency coverage.: Vulnerabilities in transitive dependencies are surfaced. A direct dependency that pulls in a vulnerable transitive dependency is flagged. The scanning sees the full dependency graph, not just direct dependencies.
• Coverage across language ecosystems.: npm, PyPI, Maven, RubyGems, Go modules, Cargo, Composer, NuGet. Each ecosystem has its own vulnerability data; the scanner integrates with each. Polyglot codebases are covered consistently.
• Container image scanning.: The scanning extends to container base images. Vulnerable system libraries and runtime components in base images are surfaced. The image is treated as another supply chain layer.

Dependency scanning is the first layer. It catches the vulnerabilities that are publicly known; it does not catch the malicious code that has not yet been disclosed.

Provenance

Provenance is the cryptographic verification that the artifact you are about to deploy is the artifact your build system produced. The signature is generated at build time; the verification happens at deploy time. The chain of trust runs from source code to running production workload.

• Sign artifacts.: Every produced artifact (container image, binary, package) is signed by the build system. The signature includes the artifact's hash, the build identity, the timestamp. Tools like Sigstore (cosign) make signing operationally simple.
• Verify at deploy.: The deployment pipeline verifies the signature before deploying. Unsigned artifacts are rejected. Artifacts signed by unauthorized identities are rejected. The verification catches tampering between build and deploy.
• SLSA framework.: The SLSA (Supply chain Levels for Software Artifacts) framework defines progressive levels of provenance maturity. Level 1 captures basic provenance; Level 4 requires hermetic builds and two-party review. The framework gives the team a roadmap.
• Build-time SBOM.: The Software Bill of Materials is generated at build time and signed alongside the artifact. The SBOM lists every component included; the verification confirms what is actually deployed. SBOMs are now common compliance requirements.
• Verify upstream provenance.: When pulling dependencies, prefer dependencies that themselves provide provenance. The chain extends upstream: your build verifies its inputs; their builds verified their inputs. The chain reduces the attack surface.

Provenance is the layer that catches tampering. Without provenance, an attacker who compromises a registry or a CDN can substitute malicious artifacts unnoticed.

Trusted sources

The most effective defense against supply chain attacks is reducing the attack surface in the first place. Trusted sources, pinned versions, and verified hashes mean the attacker has fewer places to inject code and fewer ways to substitute artifacts.

• Pin to specific versions.: Production dependencies are pinned to exact versions. No version ranges, no caret operators, no "any 1.x". The pin is exact. Build reproducibility depends on it; supply chain security amplifies the value.
• Verify hashes.: The pinned versions are also hash-verified. The lock file (package-lock.json, requirements.txt with hashes, Gopkg.lock, Cargo.lock) records the expected hash. The package manager refuses to install if the downloaded artifact does not match.
• No 'latest' in production.: Production never pulls 'latest' tags or unpinned dependencies. The 'latest' tag is mutable; an attacker who compromises the registry can repoint it to malicious code. Pinning eliminates this attack path.
• Use private registries with mirroring.: Internal builds pull dependencies from a private registry that mirrors public sources. The mirror is the team's source of truth; it can be audited; it can be locked down. Direct internet pulls from build systems are restricted.
• Vet new dependencies.: Before adopting a new dependency, the team checks: who maintains it, how recent are commits, are the maintainers responsive to security issues, what is the dependency's own dependency footprint. The vetting filters out high-risk dependencies.

Supply chain attack defense is a layered discipline. Nova AI Ops integrates with dependency scanners, signing tools, and SBOM generators to surface supply chain risk and produce the audit trail that proves the controls are working.