Written by When we talk about the software supply chain security, most people think only of dependencies (open-source libraries and frameworks). But the supply chain is so much more than just that. It’s everything we use to build, test, and release our software: our IDE (and all those wonderful extensions), our CI/CD pipelines (including every script, config, and build step), our source repositories, our frameworks, and even our package registries. And every single part of it needs to be hardened, monitored, access-controlled, and all the other things we need to do to keep it safe. Right now, I see many of us only concerned with the 3rd party dependencies, forgetting the rest of this extremely powerful and far-reaching chain.
I do wonder… if I built a course on securing the entire software supply chain, from IDE to release pipeline, would anyone sign up? Because I think maybe we’re going to need it. 😉
The Threats to Dependencies Are Changing
Not long ago, dependency management was fairly simple: a library was either outdated or vulnerable, and tools told you so. That was helpful. But it was also full of false positives. I used to look at reports and think, “Sure, there’s a CVE in here, but if it’s never called in my code, do I need to do anything about it?” Many a developer and I have had this conversation, and it’s hard to press for big changes when we’re not even sure if it’s actually dangerous or not…
Some good news: modern SCA tools are getting smarter. Some can now tell whether a vulnerable function is reachable (your code calls the function that has the vulnerability in it), or even exploitable (not only can an attacker reach it through your app, but there is a proven way that it can be exploited). I haven’t tested any of the products claiming exploitability yet, but if it works… That would be huge! Then we could finally prioritize what matters instead of adding to the constantly expanding backlog that no one wants to talk about.
The New Threats
Unfortunately…While tools were improving, the attackers have been hard at work as well. :-/ New attacks include:
- Malicious actors joining open-source projects to sneak bad code into legit libraries.
- Look-alike packages published under almost the same name as trusted ones.
- AI tools generating imaginary dependencies and then attackers registering those names… With malicious code inside.
- Even the maintainers themselves are being compromised, leading to malicious “official” updates.
It’s a total mess! Especially since the current industry toolset can only spot known vulnerabilities (ones already reported). Everything else has the potential to slip through the cracks.
So… What Do We Do About It?
Here are some ideas for you. At the end I’m going to ask for your ideas. Email them to me!
1. Harden your entire supply chain.
Create a lightweight but consistent process for hardening your dev environment (from IDE to CI/CD). And try to create a change-management process that’s not too painful. Then teach your devs why it matters, so they’re less tempted to bypass it. Because they can do anything they want, let’s not kid ourselves. Make it matter to them, so they do the right thing.
2. Get an SCA tool that can prove reachability or exploitability.
Ask peers which ones work well (I don’t recommend specific products publicly, generally), and refuse to settle for ones that just shout every CVE they find as though that is helpful. Devs don’t have time for hundreds of false positives, they have work to do. Then fix the ones that introduce real business risk.
3, Push for industry-level change.
We need an official framework for managing open-source dependencies. Something that maintainers, companies, and governments can all work with and within. Imagine if we had:
- A shared set of release/security standards, that we all followed
- Government support for secure maintenance, that was enforced with legislation
- Private industry funding open-source security (financial donations or dev time), because they are using it and it has value. We pay for things that have value, and this applies to software!
What do you think? If you have ideas, email me. I’d love to gather your thoughts and maybe turn them into a follow-up blog post or add to this one. We need to figure this out together… Before the bad guys do. 💜
Maybe this is just a dream right now… but maybe it’s one worth dreaming together?
I think we’ll have, at least, to use a virus scan on local clones of all repositories, including IDEs, browsers or any other marketplaces, to search using binary heuristics. We can’t control the 3rd party OSS libs SDLC. Some attacks were using DLLs that were being executed in developers machines under the EDR radar. We can only inspect their product.
I can’t see an easy solution for this. This is really scary.