I know it didn’t always feel like it, but with the benefit of hindsight, Application Security used to be a straightforward game. You wrote your code, you ran your scans, you fixed your warnings, and you went home.
But lately there has been a shift. Teams aren’t spending their time fixing the code they wrote anymore. Instead, they’re chasing issues in a 3rd-degree dependency, managed by a developer who hasn’t logged in since 2019.
This is exactly why Software Supply Chain Failures climbed to #3 on the OWASP Top 10 for 2025. It’s not just a ranking, it’s a recognition that we are losing our grip on the assembly line.
The Truth Behind the Numbers
Maybe some of you are skeptical. Maybe you want to point out that this jump was driven by a community survey rather than hard breach data. Maybe, you say, it’s just “Log4j PTSD” or vendor hype.
Maybe. But in my view, that’s missing the forest for the trees.
Breach Data is a rearview mirror. It tells you where you’ve already crashed. The community survey is the headlights. It captures the “Shadow Risk” practitioners are seeing every day. The reality that while we’re pretty good at securing our own logic, we’ve built a massive tower of trust on a foundation of unverified open-source code.
So, why should a leader care if the data hasn’t caught up yet? Because by the time supply chain failures show up in your incident reports, the damage is already systemic. You aren’t just patching a bug, you’re questioning the integrity of your entire production environment.
Velocity vs. Veracity
You might ask: “Can’t we just scan all the code before it goes into the product?” You can, but not if you want to ship on time.
Modern development is increasingly about assembly. 90% of your app is code you didn’t write. If your strategy is to run a deep security scan on every single update of every single library, your release cycle is going to crawl. Scanning for vulnerabilities, trying to find a needle in a haystack of code we didn’t write, is a losing game of catch-up. It’s a “velocity tax” that most businesses can’t afford to pay.
Good work bumming us all out, Malcolm! Where does this actually leave us?
If we can’t scan our way out of this, we have to change the way we trust. This is where most organisations I see get it wrong: They are so focused on checking the package for bugs, they forget to verify the sender and the delivery driver.
Think of it this way: You don’t need to frisk every person who walks into your office if they are wearing an ID badge that proves they belong there. In the software world, those badges are things like Digital Provenance and Security Scorecards.
Treating our vendors and open-source contributors like “part of the internal team” isn’t about reading every line they write; it’s about requiring the same identity and process standards we use at home. We move toward a Curated Trust model where we set automated policies:
- We require our developers to use MFA; why do we accept code from a registry where the maintainer doesn’t meet a minimum Security Scorecard (like OpenSSF) for basic hygiene?
- We require peer reviews for our own PRs; why do we pull in dependencies that don’t provide Digital Provenance (like npm provenance or SLSA) to prove how they were built?
It’s the shift from reactive “frisking” to proactive “identity verification.” We aren’t giving up external packages; we’re just being deliberate about which ones get a badge.
Moving Beyond Security Theater
If your current supply chain strategy is just generating mountains of SBOMs (Software Bill of Materials) that no one reads, then deep-down, you already know you are kidding yourself. That’s compliance, not security.
To actually move the needle, we need to focus on Provenance over Patches. We need to stop asking “Is this library old?” and start asking “Can I prove where this code came from and that it hasn’t been tampered with since?”
This means:
- Hardening the Path: In most shops, a single hijacked developer credential can bypass every security gate you have. If your build pipeline isn’t a “locked vault”, you don’t have a supply chain strategy.
- Accepting Interdependence: We have to treat our vendors and open-source contributors the same way as our internal team. If they aren’t secure, we aren’t secure.
The Difficult Questions
The jump to #3 in the OWASP Top 10:2025 should be a wake-up call for how we manage the “Identity” of our software.
The question we should be asking our team tomorrow isn’t “Are we secure?” It’s: “If an attacker poisoned our build pipeline tonight, how long would it take us to notice? Can we actually prove that the code in production is the code we intended to ship?“
If the answer is a long, uncomfortable silence, you’re not secure. You’re just lucky. Time to stop obsessing over the package, and start vetting the source.
