OWASP SAMM: Threat modeling

26 April, 2022

Threat modeling is the security practice that realizes the security by design principle. It draws the line between aspiring beginners and security experts.

In this blog series, we will present how Codific implements OWASP SAMM. In each blog we focus on a specific security practice and highlight the processes and tools we use to achieve a certain maturity level.

My journey in application security (AppSec) started almost 20 years ago at the DistriNet research lab of the University of Leuven. Back in the days secure software development was what you’d call a “buzzword” today. The release of Microsoft Security Development Lifecycle pushed AppSec to the main stage. One particular development in software security has changed my career. Threat modeling is a concept initially introduced by Frank Swiderski and Window Snyder. Adam Shostack has evangelized those ideas in his “Threat Modeling: designing for security” book. Meanwhile Kim Wuyts and her research colleagues from DistriNet (including myself) have worked on LINDDUN. LINDDUN is the threat modeling for privacy. GDPR made LINDDUN a superstar overnight as it is now considered a privacy by design methodology and is part of the NIST and ISO standards. Make sure to check out the podcast I did with Kim around privacy threat modeling and the blog post that was written about it!

Threat modeling experts.
One of the perks of being a researcher at a world-class security lab is that you get to meet and work with the best. From left to right: Kim, Adam and me.

Software Assurance Maturity Model (SAMM) is one of the most notable projects in the OWASP community. Security is a journey, not a destination. SAMM is your map and itinerary. Adam’s and Kim’s work largely define the Threat Assessment security practice in SAMM.

OWASP SAMM model overview.

Implementing SAMM Threat Assessment

In this blog I will discuss how we implement SAMM’s Threat Assessment security practice. Threat Assessment practice focuses on identifying and understanding of project-level risks based on the functionality of the software being developed and characteristics of the runtime environment. It consists of two streams:

  • Application Risk Profile is an activity to evaluate the application risk per application, estimating the potential business impact that it poses for the organization in case of an attack.
  • Threat Modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations.

At Codific we leverage a process that we have developed at DistriNet during my postdoc research. The approach we use combines STRIDE, LINDDUN and a lightweight version of FAIR. Over the years we have also developed our own tool to support the process. You can use any other existing threat modeling tool (e.g., ThreatModeler, IriusRisk, Threat Dragon, Pytm). The most essential part of the process is the actual threat modeling activity itself. In order to create a threat model you need to go through 4 essential steps:

  • What are we building?
  • What can go wrong?
  • What are we going to do about it?
  • Did we do a good enough job?

Data Flow Diagram (“What are we building”)

Data Flow Diagrams (DFD) are the ideal means to communicate the system that is being developed. As we all (should) already know “all models are wrong, but some are useful”. The DFDs we create are often updated with more details, however we try to keep them as high-level as possible. Here is a partial sample DFD from the previous generation of our Videolab Product.

Data Flow Diagram in Threat Modelling
Videolab: Data Flow Diagram

Threat elicitation (“What can go wrong?”)

Threat elicitation is the meat and the core of threat modeling. The more you threat model the better threats you will be able to come up with. We typically run an initial threat elicitation brainstorming session. We also regularly update the list of threats as new threats arise or whenever by chance we think of new threats.

Secure development tools
List of threats in our in-house tool

Security Countermeasures (“What are we going to do about it?”)

Once we have identified the list of threats we typically look into the necessary security countermeasures. Codific has a strong security culture. We have a whole set of security solutions readily available as a blueprint for every product we create. Hence most of the threats are often already partially solved by existing countermeasures. However leveraging “defense in depth” we look into further minimizing the likelihood and impact (i.e., the risk) of each threat.

Risk analysis (“Did we do a good enough job?”)

For each threat we look into how well is it tackled by using a simple classification scheme for likelihood and impact (Negligible, Limited, Significant, Maximum). We also assign a risk management label. This labels indicates whether we will mitigate the risk, accept it or transfer it to another party. Depending on the risk we might also prescribe a future countermeasure that should be implemented within a specified timeframe.

How to use Secure Development tools
Unawareness threat details

GDPR questionnaire

Our in-house tool also comes with a privacy-specific questionnaire that lists among others the following aspects of the data processed:

  • what data is being processed and how does the lifecycle of data work
  • where is the data stored (always in the EU)
  • what are the storage duration of the data
  • are the data collected adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed?
  • etc.

Manage your SAMM using the SAMMY tool

SAMMY is a SAMM management tool developed by Codific. We use SAMMY to manage our SAMM posture and plan the improvements in term of application security.


In this blog we have presented how Codific implements the Threat Assessment practice. Security experts all agree that this practice is absolutely essential for systematically tackling security and privacy by design. We leverage our in-house LINDDUN tool to document both streams. We also leverage SAMMY – our own SAMM management tool – to track each security practice in a systematic way.

What are the things we build with SAMM and SAMMY?

Codific is a team of security software engineers that leverage privacy by design principles to build secure cloud solutions. We build applications in different verticals such as HR-tech, Ed-Tech and Med-Tech. Secure collaboration and secure sharing are at the core of our solutions.

Videolab is used by top universities, academies and hospitals to put the care in healthcare. Communication skills, empathy and other soft skills are trained by sharing patient interviews recordings for feedback.

SARA is used by top HR-Consultants to deliver team assessments, psychometric tests, 360 degree feedback, cultural analysis and other analytical HR tools.

SAMMY Is a Software Assurance Maturity Model management tool. It helps your organization assess and improve its security posture. That way other companies can help us build a simple and safe digital future. And we off course use it ourselves in all our application, including SAMMY.

We believe in collaboration and open innovation, we would love to hear about your projects an see how we can contribute in developing secure software and privacy by design architecture. Contact us.

Recommended reading:

April 2022


Aram is the founder and the CEO of Codific. With over 15 years of experience, he has a proven track record in building complex software systems by explicitly focusing on software security. Aram has a PhD in cybersecurity from DistriNet KU Leuven. His contributions to the refinement and streamlining of the LINDDUN privacy engineering methodology have been incorporated into ISO and NIST standards. Aram is also a core contributor to OWASP SAMM project and the architecture and security mentor for all our teams.

If you have questions, reach out to me here