Trust in Your Software Must be Complete

In this episode of ReversingGlass, Matt makes the essential point that trust in your software supply chain is all or nothing. He explains that trusting anything less than 100% of the components in your software package will set your organization up for major risk. This is why trust in software supply chains needs to be complete, so that the risk of a software supply chain attack to your organization can be minimized. 

Learn More
-ReversingGlass: Trust and Software Supply Chain Security
-Blog: Do you trust your software? Why verification matters
-Report: Tools gap leaves orgs exposed to supply chain attacks

Episode Transcript

MATT ROSE: Hi, everyone. Welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs. Today's episode is Trust Must Be Complete. Previous episode was talking about trust and do you trust your software supply chain, do you trust your applications. But in order to trust something, it has to be complete.

It has to encompass everything. As an example let's do a little silly example here about trust. This is my house. Not my house, but representation of my house here. So if I want to trust that my house is secure, my possessions, let's say you have fancy paintings or art or exotic animals or baseball cards or whatever, you want to trust that it is secure. And you trust that the security on your front door is effective.

You trust that this window has all sorts of sensors and lasers, sharks with lasers, if you will. All the upper windows are trust. But hey, you don't really know about this window. This window, I don't really trust that one. It's been buggy. It doesn't really work. So can you say you trust the security system on your house if you only trust the door and the windows over this side, but this window, you're not really trusting it?

Think about that as you go down the path of trusting your software supply chain, trusting the security of your applications or your software or your emails or the files that you do business with. To expand on that thought, let's create my happy birthday present here, the package, the piece of software, and as it's all separated out, we have different components of this package.

We have the open source, we have the first party code, we have dependencies, and then binary repositories. All these things are combined together during your CI/CD process. A lot of times people talk about software supply chain security in the terms of just the open source and it's a big deal.

Most applications are composed of a ton of open source and the numbers associated with that, depending on what industry analyst you look at or read or, a fan of, 40 - 80% of any modern piece of software application is open source. Okay let's say we're on the high end. We have 20%. Even if we choose 80% coverage or 80% and you roll out a software composition analysis, you look at the open source code, you look at the vulnerabilities in those, there's still 20% of risk.

How can you trust the security of your package, the compiled piece of software application if there's still a 20% potential for risk? It's just like the house. I trust the security of my house, the doors, some windows, but one window is a problem. That's 20%. That's all it takes. That is the open window or the unlocked door into risk.

How did that get in there? You could do the best job possible with all sorts of application security testing from, the code to the running state, even to the tooling. That's a three. Your first party code, the code you're writing, you're making sure that's secure. You have a very robust program around SAST or scanning the core source code.

You have a runtime testing program with DAST to look for vulnerabilities at runtime. You're locking down your development CI/CD pipelines with the IDEs, the code repos, the build systems, the CI orchestration layer. But there's still potential for a gap. And for trust to be complete with your software supply chain security, you have to look at the whole package.

There has to be a final exam to ensure you didn't miss something, because that is the biggest thing that happens is you miss something. You spent time, energy, you had the smartest minds, but let's face it. Software is complicated. Applications in this modern CI/CD DevOps ecosystem are complicated. And to make sure that you're doing everything correctly is, I think, a little bit of a, I don't know, a dream?

So testing this final package to make sure all that work you did is vitally important. Don't leave a window open when you're locking everything else. Because you know what? Nefarious dudes, as I like to say, have unlimited time and unlimited resources to find that open window. They're going to try them all, and if you don't lock them all down, you cannot trust your software.

Trust is complete. Make sure you look at the complete picture. I'm Matt Rose. This is ReversingGlass. Have a great day, everybody.