What are you defending against? From upstream dependencies to code repositories, threat modeling ensures you're prepared to mitigate risks, reduce vulnerabilities, and avoid costly compromises.
December 17, 2024
Securing your SDLC starts with understanding what you're defending against. Threat modeling is the process of identifying and preparing for vulnerabilities based on your tools, dependencies, and potential attackers. Techniques like STRIDE and PASTA help you ask the right questions at every stage of the SDLC, so you can prioritize risks and build proactive protections. From upstream dependencies to code repositories, threat modeling ensures you're prepared to mitigate risks, reduce vulnerabilities, and avoid costly compromises.
The answer to “how do I secure my software development life cycle (SDLC)?” depends on what you’re defending against. Supply chains are complex, and the threats you face will change based on your dependencies, your tools, your outputs, your data, and who wants to get at any of those. The process of identifying, understanding, and preparing for vulnerabilities in your SDLC is called threat modeling.
Threat modeling is a foundational part of securing your software supply chain. You have to know what you’re defending against in order to properly protect yourself. Further, threat modeling helps you understand the likelihood of risks, allowing you to prioritize your resources in support of the threats you’re most likely to face. Securing the SDLC is an ongoing and continuous process, so you need to start with the most important pieces.
Many threat modeling techniques have been developed to help guide you through the process. STRIDE and PASTA are two popular and well-tested techniques. Ultimately, those techniques help you ask the right questions:
For each stage of the SDLC, you need to answer each of those questions. Some of the answers will be straightforward and consistent across applications. Most applications’ threat models will include threats from upstream dependencies, developer workstations, code repositories, build infrastructure, and so on. AI models will have other considerations like the training data. The type of application matters, too. A mobile banking app will be a more lucrative target to attackers than a console game because of the increased access to financial information. If your company is a defense contractor, you don’t just have to worry about opportunistic attackers who will try to gain access to whatever systems are easy to crack, you may also be the subject of persistent and determined attacks from well-resourced nation state actors.
Once you know what threats you reasonably face, you can identify approaches to mitigate those risks. For example, you might create an internal mirror for the dependencies that you use to avoid the impact of compromised package repositories. You might protect against accidental (or intentional!) introduction of vulnerabilities by requiring additional reviewers before code changes are committed.
Reacting to vulnerabilities is stressful and expensive. When a critical vulnerability is announced, you have to find all of the places where you use the vulnerable software, remediate the vulnerable code, and check for compromises. If a compromise occurred, you have to deal with that, which may include paying fines, giving customers refunds or restitution, and addressing reputational harm.
Proactive security starts with knowing the landscape. When you understand the threats your environment faces, you can prioritize the most impactful protections. Threat modeling your SDLC gives you the knowledge you need to reduce the impact of vulnerabilities — or to avoid a vulnerability entirely.
No older posts
No newer posts