Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
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
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.
Chris RomeoA 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.
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.
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.
Chris RomeoI 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.’
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.
Chris RomeoWhat 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?
As organizations begin to threat model application architectures, there is value in modeling different levels of abstraction, Romeo said.
Chris RomeoThere 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.
Approaching threat modeling in this multidimensional way will uncover a better-fidelity view of the risks facing the supply chain, he said.
A follow-on tip is that the most important open-source components could also use some threat modeling attention, Romeo said.
Chris RomeoJust 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.
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.
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.
Chris RomeoThreat 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.
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.
While prompt injection and data disclosure remain concerns, excessive agency climbed the list — not surprising with recent security incidents.
The post-mortems of two compromises by rogue AI agents show that security teams need to focus on guardrails, not the AI model.
Research into an Active Directory takeover with a single AI prompt highlights why organizations need to focus on agentic SOCs.