Modern software is mostly other people's code. A typical application pulls in hundreds of open-source packages, each pulling in more, and every one runs with the trust of the app that imports it.
Attackers noticed.
Instead of breaking into a company, they poison something it already installs and let the build do the rest. One compromised package can reach every project that depends on it.
It has played out again and again: malicious packages published to public registries, legitimate projects taken over and backdoored, dependency confusion that tricks a build into pulling a hostile version, typosquatted names waiting for a developer's slip.
The reason it works is trust inheritance. A package manager does not know a maintainer was compromised, and a build script does not know a name was typosquatted, so the malicious code is trusted the moment it lands.
Too much security still watches the perimeter and the running app. These attacks arrive earlier, inside the software, before anything is deployed.
Why "update everything" is no longer enough
The old rule, keep your packages patched and you are fine, no longer holds on its own. Updates now arrive from accounts that can be hijacked and releases that can be poisoned, so pulling the newest version without checking it can itself be the way in.
The answer is not to stop using open source, which is neither possible nor sensible. It is too narrow where you place blind trust, and to defend the chain at more than one gate rather than a single check.
Where the risk lives
Supply-chain risk sits at three connected points. There are the dependencies you pull, both the direct ones and the transitive ones they drag in behind them. This is where malicious packages, maintainer takeovers, and typosquatting live.
There is the build itself, where a clean dependency can still be tampered with through a poisoned pipeline or a swapped artifact. And there is the first-party code written on top, which has its own flaws that clean dependencies will never fix.
A defense that covers only one of the three leaves the other two open.
What this year's winners are building
Start at intake. ActiveState won in Open Source Security for maintaining vetted versions of popular open-source packages, so teams install from a controlled source instead of pulling straight from a public registry.
Then the artifact itself. ReversingLabs won in Software Supply Chain Security for scanning built packages and binaries for obfuscated code or unexpected network calls. Inspecting what actually ships catches tampering that source review can miss: a poisoned release, a swapped artifact, or a package that turned malicious after a maintainer takeover.
Because dependencies do not hold still, CleanStart Security won in the same category for showing teams which components carry known risk or have changed hands before the next build ships them.
Even with a clean dependency graph, the code a team writes on top still has to hold. AISLE won for an application security platform that finds flaws in first-party code and helps fix them before they ship.
HoundDog was recognized for a privacy scanner that catches sensitive data leaking through code before it reaches production, where a missed leak becomes customer-data exposure, a compliance problem, or both.
What to do now
- Pull from an internal, curated repository, not straight from the public registry. Proxy and mirror external packages through a controlled source where you can scan them and apply policy, instead of letting every build reach the open internet.
- Pin dependencies and verify them cryptographically. Use lockfiles that fix exact versions and check hashes or signatures, transitive dependencies included, so a build cannot quietly swap in a hostile version.
- Inspect for intent, not just known bugs. Vulnerability scanners find known CVEs; supply-chain attacks hide in behavior. Add analysis that flags obfuscated code, unexpected network calls, or attempts to read build secrets.
- Keep an SBOM, and treat it as a start. A bill of materials tells you what is in a release, which makes the next zero-day far cheaper to answer. But it only helps if you also verify that those components were not tampered with after they were published.
- Watch high-risk dependencies at runtime. If you cannot fully trust a package, monitor what it does once it is running. A date-parsing library has no reason to open a network connection or spawn a process, and behavior catches what static scans miss.
The supply chain changes the question. It is not just whether your code is secure. It is whether you can trust what it is made of, where those pieces came from, and what changed before release.
No single tool closes the chain, which is why the winners sit at different links of it. The honest goal is to narrow where you place trust, not to pretend you can stop inheriting it.
Trust a build that pulls code automatically, and you trust every maintainer upstream. The most dangerous code in your environment may be code you never wrote.
Part of The Stars Briefing, our editorial series on the trends behind the 2026 Cybersecurity Stars Awards, a program The Hacker News runs. This piece analyzes where the field is moving and uses the winners as examples. It is not a product review. The complete list of 2026 winners is live at awards.thehackernews.com/winners/2026.