The Software You Ship Is Assembled, Not Written

Yoav Landman, JFrog's co-founder and CTO, put the shift plainly on LinkedIn: "The bottleneck is no longer writing secure code." In an AI-driven world, the harder problem is governing what enters, runs, and lives inside your organization.

He is describing a change most security programs have not caught up to. For a decade, the industry poured its energy into the code developers wrote, with linters, SAST, secure-coding training, and pull-request gates.

Then AI made writing code nearly free, and the center of gravity moved. The software you ship today is mostly assembled from parts you never wrote and never reviewed.

The numbers are not subtle. Open source now appears in 98% of codebases, and 64% of the components in those codebases are transitive according to Black Duck's 2026 OSSRA report.

Transitive means indirect. That is your dependencies' dependencies' dependencies, several layers removed from anything you chose. The average codebase now carries 1,180 open source components, and roughly two-thirds of them arrived as a side effect of something else you pulled in.

That is the real attack surface. And it is the one your first-party security controls were never designed to cover.

Assembly Is Where the Attackers Went

If you want to know where risk concentrates, watch where the attackers spend their time. In 2025 they industrialized the supply chain. Sonatype counted more than 454,600 new malicious packages, a roughly 75% year-over-year jump, with more than 99% of it landing on npm.

This is no longer spam and stunts. It is sustained, automated campaigns aimed at the tooling that builds software.

The 2026 incidents make the pattern concrete. The self-propagating Shai-Hulud worm stole developer and cloud credentials, then used them to publish poisoned versions of still more packages. It hit over 100 npm and PyPI packages.

The Hades campaign that started June 1 harvested cloud credentials through Python startup hooks that execute the moment the interpreter loads. TrapDoor spread a credential stealer across npm, PyPI, and Crates.io in 34-plus packages and 384-plus versions.

Feross Aboukhadijeh, Socket's founder and CEO, named the uncomfortable part: "These are not typosquats. These are the real packages." The compromise came through hijacked maintainer accounts, not lookalike names. The package you correctly pinned and audited turned hostile after the fact.

Jeffrey W. Brown, Microsoft's Chief Security Advisor for Financial Services, framed the strategic version of this for CISOs: "SBOMs are maps now, and adversaries have the same GPS." An inventory tells you what you have. It does not tell you what is actually reachable, or what to fix first.

Everyone has the same map. The advantage goes to whoever can act on it faster.

npm v12 Is a Door, Not a Mechanism

The ecosystem is responding. The biggest change in years arrives with npm v12 in July 2026: install scripts from dependencies no longer run automatically. The preinstall, install, and postinstall hooks that attackers love become opt-in through an allowlist you commit alongside your code.

npm also stops resolving Git dependencies and remote-URL tarballs by default. It is a genuinely good change, and it closes one of the most abused code-execution paths in the ecosystem.

It also does not solve the problem this post is about. The account tracking these threats, OpenSourceMalware, said it cleanly: the allowlist "is only as strong as the review behind it." A package you approve today keeps its approval tomorrow, with no re-evaluation if the maintainer account behind it is compromised next month.

That is exactly the seam Feross pointed at. npm v12 blocks malicious code at install time, but it cannot tell you whether the vulnerable code already three layers deep in your tree is reachable, and it cannot fix it for you.

That is the gap. And "govern your dependencies" is an empty instruction until you close it.

The Backlog Math Stopped Working

Here is what the gap looks like on a Tuesday. A scanner flags a critical CVE in a package four levels deep in your tree. A ticket gets created and assigned to a backlog that already holds thousands of others.

Weeks later a developer picks it up, spends two hours tracing which direct dependency to bump, attempts the upgrade, watches the test suite fail, and reverts. The ticket goes back to the pile, and four months later someone tries again.

That is not negligence, it is arithmetic. When the industry mean time to remediation runs 252 days and most of a security team's time goes to deciding what is real rather than fixing it, the queue only grows.

Attackers now weaponize disclosures in hours. A remediation cadence measured in months against an exploitation window measured in hours is a losing position, and no amount of hiring closes a gap that structural.

The way out is not more scanning. It is compressing the two steps that actually consume the time: deciding what matters, and shipping the fix. Automate both and that months-long cycle collapses toward days. That is where the tooling has to earn its keep.

What Owning Your Dependencies Actually Requires

Governing assembled software comes down to two questions that software composition analysis (SCA) never fully answered on its own. You have to answer them at scale, on every repository, every day. Which of the thousands of dependency vulnerabilities in my tree actually touch my code? And for the ones that do, how do I ship the fix without breaking production?

First, triage by reachability. Your application imports a library. That does not mean it calls the vulnerable function inside it. Most of the time it does not. Reachability analysis follows how your code actually reaches into your transitive chains, separating the SCA vulnerabilities that can fire from the ones that will never execute.

This is the difference between a queue of thousands and a queue of dozens. For dependencies specifically, it is harder than SAST triage, because you are tracing paths through libraries you did not write into sub-dependencies you did not choose. Done well, it removes the majority of the noise before a human ever looks at it. Pixee's exploitability analysis drives up to a 95% reduction in false positives on that basis.

Second, remediate at the manifest, including transitively. A reachable CVE three layers deep does not get fixed by editing your code. It gets fixed by resolving the dependency graph. You trace back to the direct dependency you control, find the version whose own tree no longer includes the vulnerable package, and confirm the whole chain stays consistent.

Version bumping is not the same as vulnerability fixing. A blind major-version bump can resolve a CVE and introduce a breaking API change in the same commit, which is why developers stop trusting automated dependency PRs after a few broken builds. What closes the loop is a fix that resolves the transitive chain from the root, predicts the breaking change, adjusts your calling code to match the new API, and arrives as a pull request that reads like your team wrote it.

Transitive resolution is the part most automation skips, because bumping a direct dependency to clear a vulnerability buried in its sub-tree means reasoning about the whole graph at once. Pixee generates those fixes, and developers merge 76% of them across more than 100,000 pull requests.

Notice that neither question is answered by another scanner or another SBOM. Detection is a solved, crowded market. Snyk and Mend maintain excellent vulnerability databases, Endor Labs and Socket do real work on reachability and malicious-package detection, and Dependabot and Renovate automate the version bump.

What none of them close is the loop from a reachable transitive CVE to a merged, convention-matching fix. That is the piece that turns an inventory into an outcome.

Triage and Fix, on the Scanners You Already Run

The point of owning your dependencies is not to add a sixth tool to a stack that already averages more than five. Pixee sits on top of the scanners you run. It ingests their findings, triages them by exploitability so consolidation means fewer alerts to chase rather than fewer detections, and then remediates the ones that survive triage with fixes developers actually accept. Your Snyk subscription gets more valuable when a reachable finding becomes a merged PR instead of a ticket that ages out over months.

That shift, from a backlog you groom to a queue you clear, is what software supply chain security has to mean now. Not another inventory, but triage and SCA remediation on the dependencies you assembled.

Triage decides what is real. Remediation ships the fix. Both have to be automated, because the math of manual dependency management stopped working the day AI made assembly the default.

The software you ship is assembled, not written. Your security program should be built the same way, around the parts you did not author but are still on the hook for.

See It On Your Code

The only honest way to evaluate this is against your own dependency tree, your own backlog, your own conventions.

See how Pixee triages and remediates dependency vulnerabilities at scale →

Related reading:

• Pixee: SCA Remediation at Scale: Dependencies Are the Real Challenge

• Pixee: Software Supply Chain Security — The Complete Guide

• Pixee: Scanner-Agnostic Remediation