One of the trickiest problems for organizations trying to secure their software supply chain is making risk decisions without really understanding where the biggest threats lie in their software, whether open source or commercial. Even with a full slate of application security testing (AST), it can be difficult to get a sweeping view of how all of the different deployed components and packages play into an overall threat posture without first modernizing your approach with software supply chain security (SSCS) tools.
Chris Romeo, co-founder and CEO of the threat modeling company Devici and co-author of the Threat Modeling Manifesto, lays out below how you can supercharge your software risk management by adding the deeper visibility that comes with binary analysis-based SSCS with threat modeling — a systematic and collaborative approach to mapping out how things can go wrong in software, systems, and architectures.
Key to going beyond traditional AST is complex binary analysis, which the Enduring Security Framework (ESF) working group has urged organizations to adopt to take on modern supply chain threats. Here are five ways organizations can marry threat modeling with binary analysis to get ahead of risk.
[ Join Romeo in this Webinar: Supercharge Your Threat Modeling with Software Supply Chain Security ]
1. Fully understand the software components in use
Romeo said organizations should first apply threat modeling to gain a fuller understanding of the components in use in the supply chain — and not just what those components are pulled to do, but also their full capabilities — so they can begin to develop a better picture of the complete attack surface that those components introduce into the supply chain.
“A lot of times, as a developer, you grab a library to solve a single problem, but you don't realize what else is in that library that you could be exposing.”
—Chris Romeo
A developer can use a well-architected library for a single function and not open up the organization to any other reachability challenges, but because not all components are created equal, it takes care and consideration to minimize the reachable attack surface of all the components that make up a supply chain.
2. Use data-flow diagrams to communicate the state of the system
The second step of using threat modeling in the supply chain is to use data-flow diagrams to get a look at what the overall solution is doing, Romeo said. “Include your open-source libraries within your threat models and within your data-flow diagrams,” he said.
“I like data-flow diagrams because they're simple and they're visual. If you throw a data-flow diagram up on your screen right now, I can spend about 30 seconds and I can pretty much trace through and consume it and go, ‘Okay, I understand now what you're telling me about the system.’"
—Chris Romeo
The data-flow diagram can serve as the system baseline for a threat modeling exercise, showing everyone how the system is working — which is the first step toward figuring out how it could be abused by attackers or otherwise cause exposures, Romeo said.
One other key thing is to ensure that you're properly extending into open-source components within your threat model.
"What people will often do is draw a process and in that circle there's a bunch of open source that's operating, but they never go to that next level of detail to expose that. They just say, ‘Well, that's in the API endpoint.’ But what about all the things you use to build the API endpoint that you're relying upon? Have you gone to that next level?”
—Chris Romeo
3. Threat model for the big picture — and for individual user stories
As organizations begin to threat model application architectures, there is value in modeling different levels of abstraction, Romeo said.
“There are times where I need the 30,000-foot, out-the-plane-window view to quickly understand the impact of a given new software supply chain vulnerability across an environment. I need to see the big picture, but the big picture doesn't get me everything I need. There is a need to compose a threat model of the entire system, but there's also a need to threat model every user story or every feature in the software supply chain.”
—Chris Romeo
Approaching threat modeling in this multidimensional way will uncover a better-fidelity view of the risks facing the supply chain, he said.
4. Threat model the individual components
A follow-on tip is that the most important open-source components could also use some threat modeling attention, Romeo said.
“Just because you're not on the open-source team that's building the component doesn’t mean you can’t still threat model the component yourself. Often, people will take in a given open-source component and just assume that it's secure because it's been vetted."
—Chris Romeo
If there is no threat model for the top components that you're relying upon across your application or products, "you should be threat modeling those things yourself, at least at a high level,” he said. Organizations should prioritize that work based on their component inventory, focusing on the most used and most security-relevant components first, he said.
“This is completely hypothetical, but maybe the top library I’m using just controls colors in an application, whether it is light blue or dark blue. And then the 10th most-used component is an authentication component. That library is not very relevant from a security perspective, but that authentication library better bump up the list.”
5. Educate developers and stakeholders on how to leverage threat models
The final tip to adding threat modeling to software supply chain security is to educate everyone. Security teams should help train not just developers but also other product stakeholders on how threat modeling exercises work, how to read data-flow diagrams, and how to take that information and make better decisions.
“Threat modeling is a team sport, and it’s important to have a diversity of knowledge and experience and roles at the table. Education is big, and companies need a proper approach to educating not only your developers and engineers, but also your product managers, your architects, your QA and test.”
—Chris Romeo
A better road map for managing software risk
Romeo stressed that doing threat modeling with SSCS regularly and at different levels of abstraction can give the business and developers a better road map for figuring out how to control component usage and mitigate the biggest risks first.
Learn more and join the Q&A in the upcoming webinar with Chris Romeo and ReversingLabs' Josh Knox.
