As organizations seek better ways to establish secure-by-design software, threat modeling can play a huge role in anticipating, avoiding, and planning for potential risks in software across all phases of the software development lifecycle (SDLC) — design, development, testing, and post-deployment.
Threat modeling can already be extremely beneficial on an application-by-application basis, but with a programmatic and continuous approach to threat modeling, the practice can be more broadly invaluable to maturing an organization's software supply chain security program.
Here's what your security teams need to understand about threat modeling, which is essential to mapping out and understanding software supply chain risk.
[ See Webinar with Chris Romeo and Matt Rose: Threat Modeling & Software Supply Chain Security: Why It Matters More Than Ever ]
Modeling good security starts with mapping out the threat landscape
At its heart, threat modeling is a systematic and collaborative approach to mapping out the things that could go wrong in a system or project from the perspective of security and privacy, explains the Threat Modeling Manifesto, a vendor-neutral blueprint similar to the Agile Manifesto.
"It also allows you to pinpoint design and implementation issues that require mitigation, whether it is early in or throughout the lifetime of the system."
—Threat Modeling Manifesto
Developed by 15 security luminaries in 2020, the manifesto distills threat modeling to four key questions that should be asked about any system or software:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
Ultimately, the goal is to produce documentable analysis that can inform decisions that a DevOps team would make to build that software more securely — be it by avoiding toxic authentication scenarios, bolstering the security posture of implemented configurations, hardening the system to denial-of-service attacks, or something else.
Chris Romeo, a co-founder of Devici Security, a co-author of the Threat Modeling Manifesto, and a former chief security advocate at Cisco who helped establish and scale threat modeling processes across the company, called threat modeling an essential tool.
"Whether we're talking about the building of software-based products, hardware-based products, or more broadly implementing in the software supply chain, threat modeling is a core capability process and, really, a tool that we can use to really understand the security and privacy challenges that exist inside of what we're building."
—Chris Romeo
When threat modeling met supply chain security
Threat modeling has an obvious role in the development processes on an app-by-app level. But it can also be used to strengthen the security posture of an organization's entire supply chain ecosystem — as it is deployed and running, Romeo said.
Threat modeling exercises can be invaluable in identifying security issues, which then can scope out the vetting needed across all software components in the tooling and pipelines used to build and release software, he said.
"When I think about threat modeling in a software supply chain perspective, it fits into the secure development lifecycle, the process we're using to build software. But I would even stretch it further and say people should be threat modeling the software supply chain itself. What I mean by that is they should be threat modeling their build pipelines."
–Chris Romeo
Finding a way to infuse threat modeling across the open-source ecosystem that fuels so many of the components used in enterprise software supply chains would be a great place to start, he said.
"One of the biggest differences threat modeling could make for our industry in a software supply chain context is ... in building open-source project packages."
—Chris Romeo
It would be valuable for teams to practice threat modeling when developing or designing changes for open-source projects, Romeo said, as well as to use threat modeling to assess "the entirety of what they've built in previous years."
This is exactly the kind of industrywide work that the Linux Foundation's OpenSSF Alpha-Omega team is working on today. Part of that group's mission is picking some of the most critical open-source software projects — those most heavily leaned upon by the enterprise software supply chain — and sponsoring high-value security work, including threat modeling.
Over the past year, Alpha-Omega has doled out $1.5 million to critical projects. Top of the list was a $460,000 grant to help prepare a threat model of the Rust Foundation's ecosystem and drive relevant improvements based on that analysis.
Romeo said companies don't have enough security people to threat model everything. However, he added, "if we could get to the point where threat modeling and secure by design/secure by default is practiced in the open-source community — so that all packages were being threat modeled before ever being downloaded them — that would have a big impact."
"If we could get them to threat model things, understand this discipline, and start to apply it, I think we would see a big improvement on half of the supply chain piece."
—Chris Romeo
Threat modeling should also play a larger role in how application security teams manage third-party risk. A recent Software Supply Chain Threat Modeling Checklist from IANS Research offers a valuable resource in understanding what organizations should be analyzing during their threat modeling exercises of third-party components — including defining trust boundaries using threat modeling frameworks such as STRIDE, building data flow diagrams, and identifying controls. Another big part is asking those third parties — be they commercial or open source — about whether they've done threat modeling themselves.
"Request a copy of the threat model — at least at a high level — to understand what risks the component introduces and to gain a better understanding of the third party’s security practices."
—IANS Research
Threat modeling and software bills of materials
One of the big ways that threat modeling can be leveraged to bolster software supply chain security is by harmonizing modeling efforts with investments being made in leveraging software bills of materials (SBOMs). For example, using SBOMs provided by third parties could jump-start a threat modeling process to vet a component for a particular use cases in an organization's supply chain, said Matt Rose, field CISO for ReversingLabs.
"Using the SBOM as the starting point is, I think, going to speed up the threat modeling process and make it much more complete and comprehensive. Because if that SBOM is exactly representative of what the application is, then you're not going to miss things, and then you can actually bring in the experts for the specific areas of concern or risk. It gives you a foundational list of things, [so] then you could actually play that 'who, what, where, why' game."
—Matt Rose
Romeo is leery of SBOMs because they are usually imperfectly used. In most organizations, SBOM information may be collected and forgotten, he said. However, the SBOM model of standardizing on a format such as CycloneDX or SPDX could change the equation for SBOMs, opening the door for threat modeling across the open-source world and the software supply chain ecosystem.
Threat modeling and supply chain security maturity: A reality check
One key problem for implementing thread modeling for better supply chain security is that there's currently no standard way of listing the findings from a threat modeling exercise, which speaks to the general immaturity of threat modeling, Romeo said.
While Romeo has been skeptical of SBOMs, he said standardization of results reporting could help ease the pain of making threat modeling useful for bolstering software supply chain risk management.
"[Imagine] a threat model BOM. If someone gave me some money and said, 'Solve this problem today,' that might be my first step, to try to bolt and attach on all of the momentum we have going on in the world of building SBOMs."
—Chris Romeo
