Site icon SheHacksPurple

Software Supply Chain: Bigger (and Scarier) Than We Realize

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:

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:

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?

Exit mobile version