What do teams get wrong about securing dependencies and build workflows?

A common mistake is assuming code review and dependency management alone provide enough protection. Those controls help, but they miss threats that execute during compilation, hide inside transitive packages, or appear after publication. Teams also underestimate how quickly attackers adapt to pipeline automation, so static checkpoints without continuous monitoring leave material gaps.

Where dependency security usually breaks down

Teams often treat dependencies as a procurement or review problem, but build security is really about what executes, what is trusted, and when that trust is validated. A package can be clean at review time and still introduce risk through a malicious install script, a compromised transitive dependency, or a later-published update that changes behaviour after the initial approval.

The same mistake shows up in build workflows. Controls focused only on source review miss the moment code is fetched, generated, compiled, or signed. If the pipeline assumes that every package manager, build step, and artifact source is trustworthy by default, the organisation inherits the weakest trust decision in the chain.

Build and dependency security therefore needs to cover provenance, integrity, and execution context together. The question is not only whether the code looked safe in the repository, but whether the artefact that reached production was the same thing that was reviewed, built, and intended.

Why transitive risk and pipeline time matter

Transitive dependencies are where most teams underestimate exposure. The direct package may be well known, but its nested dependencies, installer hooks, and post-install scripts can expand the attack surface far beyond what a code review of the top-level manifest reveals. That is why provenance and artifact integrity matter as much as package selection.

Pipeline timing also matters. Attackers do not need to win at the point of code commit if they can influence the build environment, substitute a dependency during resolution, or wait until publication to introduce a poisoned release. In other words, the trust boundary is not fixed at the repository, it shifts across the full delivery chain.

Continuous verification is stronger than one-time approval here. The dependency graph changes, packages are republished, build agents drift, and automation can spread a single mistake to every release branch in minutes. A secure workflow has to assume that anything outside a validated artifact boundary can change after it was first inspected.

What resilient teams verify in build workflows

Good teams separate approval from trust. They verify that the build consumed a known source, that the resulting artifact is attributable to that source, and that any dependency or plugin used during the build was explicitly accepted rather than inherited by default. This is where provenance controls, lockfiles, signing, and reproducible build checks become practical safeguards instead of abstract ideals.

They also watch for execution during build as a distinct risk. Installer scripts, code generators, CI runners, and package manager hooks can all run with privileges that are broader than the application itself ever needs. A dependency policy that ignores build-time execution leaves a gap even if the final artifact is signed.

SLSA is a useful anchor for this problem because it forces teams to think about provenance, build integrity, and tamper resistance rather than package choice alone. For teams formalising development practice, OWASP SAMM helps connect build security to repeatable engineering process instead of ad hoc review gates.

Risk and Threat Considerations

Dependency and build-chain weaknesses are attractive because they scale. One compromised package, poisoned update, or abused build step can affect many downstream consumers at once, which makes this a concentration-risk problem as much as a technical one.

Failure mechanism: An attacker abuses a trusted dependency, build script, or CI runner to introduce malicious code before the artifact is signed or deployed, or after review but before publication.

Impact: The resulting compromise can bypass code review, spread through transitive dependencies, and persist until teams detect that the released artifact no longer matches the reviewed source.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while SLSA, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Build provenance and artifact integrity are central to dependency and build workflow security.
Recommendation — Adopt provenance controls that let you verify how each release artifact was built and from which source.
OWASP SAMM	Software Assurance Maturity Model	The question is about hardening the software delivery process around dependencies and builds.
Recommendation — Use SAMM to embed dependency review, build integrity, and release verification into engineering practice.
MITRE ATT&CK	T1195 — Supply Chain Compromise	The answer concerns compromise paths that abuse dependencies and build workflows.
Recommendation — Map build-chain abuse to supply-chain techniques and hunt for tampering across acquisition and release steps.
NIST SP 800-53 Rev 5	CM-3 — Configuration Change Control	Dependency and build changes need controlled review and approval to avoid unsafe drift.
	SI-7 — Software, Firmware, and Information Integrity	Artifact integrity and tamper detection are core to trustworthy builds and dependency handling.
Recommendation — Require formal approval for dependency and build configuration changes before they enter release pipelines. Verify artifact integrity and reject builds that cannot prove software has not been altered.

Practitioner Guidance

What to verify: Treat dependency approval, build execution, and artifact release as separate trust decisions. If the workflow cannot prove which source produced which artifact, the control is incomplete even if the code passed review.

Common mistake: Teams often overestimate the value of a dependency allowlist while leaving package installation hooks, build scripts, and CI credentials broadly trusted. That leaves the most dangerous execution points unbounded.

What good looks like: The pipeline should produce an artifact that is traceable to a known source, built in a controlled environment, with dependency changes and build-step execution visible enough to investigate quickly when behaviour changes.

Practitioner takeaway: Secure build workflows by bounding what can execute, not just what can be reviewed, because provenance without execution control still leaves a workable attack path.