Most security teams don’t need convincing that the software supply chain security problem is real. What’s changed is the way it shows up.

A few years ago, the nightmare scenario was a rare, high-skill attack aimed at a handful of high-value targets. In 2026, the risk is far more ordinary. A routine dependency update. A trusted package that isn’t trusted anymore. A small change that slips into a build because the process assumes updates are always safe, and always urgent.

That shift in threat behaviour is exactly what came through in a recent Security Strategist podcast conversation with Root. The discussion wasn’t about exotic exploits or theoretical risk. It was about how modern attacks exploit normal workflows, and how dependency decisions made at speed can quietly reshape an organisation’s exposure.

em360tech image

This is why dependency management is moving from “engineering hygiene” to frontline defence. And it’s why dependency pinning security deserves to be treated as a strategic control, not a niche practice reserved for the most cautious teams.

Why Dependency Updates Are Now a Supply Chain Risk

Modern software supply chain attacks don’t always rely on finding a zero-day in your code. They often aim for something simpler: get malicious code into the packages you already consume, then let normal workflows distribute it.

Package registries are a high-leverage target because they sit upstream of everything. If an attacker compromises a maintainer account or publishing workflow, they can inject malicious packages or taint legitimate ones. After that, the spread is powered by your own pipelines.

Industry reporting in 2025 and 2026 has been blunt about the scale of the problem. Sonatype reported identifying more than 454,600 new malicious packages in 2025 in its 2026 State of the Software Supply Chain report. That number matters because it reframes what “rare” looks like.

At the same time, organisations are feeling the impact directly. Black Duck reported that 65% of organisations surveyed had been hit by a software supply chain attack in the past year. When the majority of teams can say “this happened to us”, the conversation has to move beyond awareness and into controls that change outcomes.

So yes, keeping dependencies up to date still matters. But “update everything automatically” is no longer an unqualified good. The same mechanism that brings you security fixes can also become the mechanism that delivers the compromise.

What Dependency Pinning Actually Means in Practice

Dependency pinning is simple in concept: you lock your software to known versions of third-party components, and you only change those versions intentionally.

In practice, it means your builds don’t float. They don’t quietly pull “latest minor version” because it happens to be available that day. They don’t drift because a transitive dependency changed upstream and your tooling decided it was fine.

Pinning typically shows up through:

  • Pinned dependencies: explicitly selecting versions for direct dependencies.
  • Lockfiles: recording the exact dependency tree (including indirect dependencies) so builds are repeatable.
  • Controlled upgrade workflows: changes happen through a defined process, not as a side effect of running a pipeline.

This isn’t about freezing everything. It’s about reproducible builds and predictable change. If a security incident happens, you want to know exactly what you shipped, exactly what changed, and exactly what needs to be rolled back. Pinning makes that possible.

Why Pinning Improves Security Outcomes, Not Just Stability

A lot of teams first adopt pinning for stability. They’re tired of mysterious breakages caused by dependency drift. Security benefits tend to follow, and in 2026 they’re too significant to treat as a bonus.

Pinning improves security outcomes in a few concrete ways.

Infographic titled “How Dependency Pinning Changes Security Outcomes” comparing unpinned and pinned dependencies. The left column, “Unpinned Dependencies,” lists: surprise updates, rapid malware spread, inconsistent builds, and reactive response. The right column, “Pinned Dependencies,” lists: intentional updates, reduced blast radius, repeatable builds, and faster incident response. Bottom text reads: “Pinning doesn’t stop change. It makes change intentional.” Root logo appears bottom left and EM360 logo bottom right.

It reduces surprise inputs. When versions don’t move without intent, you lower the chance of pulling in compromised code during a routine run. That’s a direct reduction in attack surface.

It slows malware propagation. Registry-native campaigns often rely on speed. They want tainted packages to flow downstream while teams are still trusting the update channel. Pinning makes you harder to rush. You can still upgrade, but you’re not forced into an automatic race.

It strengthens your incident response. When you know your dependency set is controlled, your triage gets faster. You’re not trying to answer “Did we pull that version?” while your systems continue rebuilding against whatever the registry serves next.

It improves audit and transparency work. SBOMs (software bills of materials) are only as useful as the consistency of your builds. If the same source can produce different dependency trees across environments or days, your SBOM becomes less reliable. Pinning helps keep SBOMs accurate and defensible.

This is the heart of dependency pinning security: you’re not just managing packages. You’re managing change.

The Trade-Offs Teams Run Into When They Start Pinning

Pinning isn’t a magic switch. If you adopt it without a plan, you’ll discover the sharp edges quickly.

The first trade-off is CVE pressure. Pinning can slow your access to upstream fixes, especially if you previously relied on broad automatic upgrades to “wash through” patches. Teams can end up staring at a CVE backlog and feeling like they traded one problem for another.

The second trade-off is ownership. Dependency work often falls between security and engineering, which means it belongs to everyone and therefore to no one. If there’s no clear owner for dependency policy and updates, pinning becomes a brittle rule that gets bypassed under pressure.

The third trade-off is operational burden. You need a workable routine for evaluating updates, testing compatibility, and dealing with exceptions. Without that, pinning can feel like a slowdown tax on engineering.

The point isn’t to pretend these issues don’t exist. It’s to make sure your pinning approach is paired with a remediation strategy that keeps pace with risk.

How Security Leaders Can Use Pinning Without Stalling Remediation

The best way to think about pinning is as part of security governance, not a tooling choice. You’re defining what “safe change” means for your organisation, then building a repeatable process around it.

Here’s a practical playbook that fits most enterprise environments.

Start with policy that engineering can actually follow. Define what must be pinned (direct and transitive dependencies where possible), what’s allowed to float (if anything), and what counts as a “high-risk” update. Keep it short. If it’s too complex, it won’t survive real delivery pressure.

Create a normal update cadence. Weekly or fortnightly dependency updates work better than heroic, sporadic clean-ups. It keeps change small, testable, and easier to roll back. It also reduces the temptation to accept risky large jumps just to catch up.

Are you enjoying the content so far?

Set rules for urgent security exceptions. Some vulnerabilities will require fast action. Define what qualifies, who approves, and what evidence is required. The goal is speed with accountability, not speed with chaos.

Separate dependency maintenance from feature work where you can. One reason remediation becomes painful is because it competes with roadmap delivery. If you can allocate capacity or establish a clear operating model for dependency upkeep, you stop treating it like an interruption and start treating it like hygiene.

Measure outcomes that matter to both sides. Security wants risk reduced. Engineering wants less disruption. Track things like time-to-update for critical fixes, number of emergency exceptions, and the percentage of dependency changes that break builds. If pinning is working, emergency work should trend down and predictability should trend up.

Infographic titled “Making Dependency Pinning Work” presenting a four-step guide. Step 1: “Set clear rules” with bullets: define what must be pinned, agree on upgrade thresholds, document security exceptions. Step 2: “Create a steady update rhythm” with bullets: small, regular dependency updates, planned review windows, fewer emergency upgrades. Step 3: “Separate ownership” with bullets: clear responsibility for dependency health, security sets policy, engineering focuses on delivery. Step 4: “Plan for urgent fixes” with bullets: fast-track critical vulnerabilities, risk-based approvals, temporary exceptions with review. Root logo appears bottom left and EM360 logo bottom right.

Done well, pinning doesn’t stall remediation. It makes remediation more intentional and less panic-driven.

Why Dependency Pinning Fits the Direction Security Is Headed

The industry is moving toward tighter control of software inputs, and it’s not subtle.

GitHub has outlined security changes for npm publishing that include stronger authentication expectations and shorter-lived publishing tokens, aiming to reduce the blast radius of compromised credentials. Platforms are responding because attackers are exploiting the assumptions baked into modern dependency delivery.

Frameworks are also converging on the same idea: repeatability builds trust. SLSA, for example, explicitly points to pinned dependencies as part of creating builds that run on the same set of inputs. You don’t need to chase every framework to benefit from the direction they’re pushing. The underlying logic is consistent. If you can’t control what goes into your software, you can’t control what comes out.

In other words, pinning isn’t a fad. It’s a step toward software provenance, auditability, and supply chain resilience that most organisations will end up needing anyway.

Final Thoughts: Security Improves When Change Is Intentional

Dependency pinning isn’t about fear of updates. It’s about refusing to treat your build pipeline like a trust fall.

In 2026, the riskiest change is often the one that looks routine. A dependency update that arrives quietly, gets accepted automatically, and spreads widely before anyone thinks to ask whether it should’ve been trusted at all.

Teams that treat dependency control as a real discipline, with clear policy, steady cadence, and defined exceptions, won’t just reduce open source risk. They’ll build a security posture that holds up under pressure because it’s designed for the reality we’re in now.

Conversations like this one, including the recent Security Strategist discussion with Root, point to a broader shift underway. Security leaders are starting to rethink how much implicit trust they give to upstream code, and what it really means to stay ahead of supply chain risk.

For teams navigating that shift, EM360Tech continues to bring together practitioners, analysts, and vendors like Root to examine what’s changing, what’s working, and what needs to evolve next.