A rant

It can be argued that a secure supply chain is the basis upon which all security is built. This may be seen by some as hyperbolic, but it’s an easy thing to prove. Think about your application/service/product for just a moment. You might be working at BigCorp or LittleStartup.io, but if you’ve got a product, you have the same problems. Where does this product come from? Is it a masterpiece of engineering prowess you or your army of developers has written? Or rather, is it actually a set of glue and string that binds a loosely related set of components.

I’d argue that just about any major product or service these days is the latter. You use open source components, these might be pulled in from a package manager or if you’re at a bigger organisation via more exotic means such as Nix, but the outcome is the same. You didn’t write the MVC framework, you didn’t create the database driver, you probably didn’t create the language you’re using either. These are parts of your risk model, whether you like it or not. You’re adopting the hygiene practices of a random developer that works hard on their open source project as much as you’re adopting the practices of multi-billion-trillion dollar companies that produce libraries for consumption.

What are you doing about it? I am willing to bet a reasonable amount of money it’s a lot of nothing.

Sure, you’ve probably got S*yk or DependaBot, and maybe you’re addressing the vulnerabilities that come through on those channels…maybe. There is a possibility that you’ve got an artefact repository, it’s doing a vague job of blocking vulnerable packages. That’s okay, though, it’s not your fault. A lot of the blame for these failures can be placed directly upon the shoulders of vendors. We’ve allowed vendors to define the space with solutions. We’ve allowed ourselves to be told that Static Analysis is the only answer for supply chain woes. We’ve drunk the kool-aid that SBOM/ABOM is the only way to model your supply chain. We’re eating chips with SLSA (Supply Chain Levels for Software Artifacts) right; that’s if you’re lucky enough to have heard of it. Does any of this reflect the reality of the problem space?

AKA the vendor gap

The answer of course is no, none of this addresses the problem space. Before anyone says it, I am not asking for magic bullets. I am asking for an honest evaluation of the status quo. What do we need to do with our supply chain?

The problem space

I got lost in a rant, let’s look at what supply chain security is made up of. When modelling these things in my day job (supply chain security team) I like to break it down into the following steps:

  1. Do the filthy static analysis/sca: actually do it, though, like look at what vulnerabilities you have. Fix them, get rid of packages you don’t need. Talk to your developers.
  2. Model the Supply Chain: understand what is in there, where you’re getting it from, who you are getting it from and what you’re doing it with. SBOM isn’t going to cut it here. You need one, but you probably should do more.
  3. Evaluate the risks you face and make a policy: what problems do this current model create for me, vulnerability? Exploitation? Compliance? Legal? Ethical? Triage, plan and respond in the next steps. What is your risk profile? Understand this before you do anything.
  4. Stem the bleeding: start with an artefact repository, get your stuff in there, get your clients pulling from it, get your build agents pulling from it, get your freaking production systems pulling from it
  5. Validate the policy: Now you have control, it’s time to actually set some policies in place. Let’s start seeing exactly how many builds you’re going to break, production releases you’re going to stall, developers laptops you’re going to quarantine. Work with your developers to solve those problems before you move forward.
  6. Block, break, enforce: Hopefully you’ve learnt enough about your systems in the last step because it’s time to start breaking stuff. Block packages that are vulnerable, come from repositories with 2 commits in the past 10 years…. etc….
  7. Now you can think about SLSA: Let’s not boil the ocean.

Of course, there is more to it. This is a tounge-in-cheek evaluation. But seriously, how many of these things are actually vendor things? Two of them. An artifact repository: which by the way good luck finding one that will meet all of your organisational needs and risk profile (we are building one at Canva because we couldn’t find one that met our needs) and that damn static analysis/SCA again. That doesn’t mean automation/tooling isn’t necessary, for example: if you don’t codify modelling your supply chain, good luck keeping up.

The hook

The real output of this? Don’t think that procuring something or listening to a vendor is going to help you. Follow the steps above, I am entirely willing to give you more advice and a serious version of those at any point.

Another output, there are some shit hot product ideas waiting for creation. For all vendors listening, if you could give me a product that would model the entirety of my software supply chain and put it in a graph, tell me how those things relate, give me all the information about where they come from and who uses them…. SHUT UP AND TAKE MY MONEY.