DevSecOps Threat Modelling Implementation on Simple Web Application

Arjan Ridwan

Arjan Ridwan

Dec 17, 2025

DevSecOps Threat Modelling Implementation on Simple Web Application

Executive Summary

When designing software or applications, an assessment needs to be carried out to find out what threats may arise. One way is to do threat modeling. Threat modeling is a proactive process of looking for threats in a software or application. When creating software or application models, we usually use two types of models: the model of what will be built, and the model of any threats that may arise.[1]

Requirements

The security goal of this exercise:

  • Determine the appropriate threat modeling approach and method to do threat modeling before the implementation of DevSecOps.
  • Can identify threats early and carry out mitigation to reduce the consequences of these threats.

Below are the requirements needed to implement threat modeling using STRIDE:

  • Information relating to applications, services, and topologies used
  • Approach method
  • Framework
  • Threat modeling tool
  • Data flow diagram

Threat Modeling Approach & Framework

Threat modeling approach and framework

Research

In carrying out threat modeling, three approaches can be used according to OWASP as follows:

  • Application-centric approach: visualizing the application.
  • Asset-centric approach: identified by the list of assets.
  • Attacker-centric approach: using attacker perspective.

After researching several of these approaches, I chose an application-centric approach by considering the data that can be taken as a reference for threat modeling.

Next, determine the framework that can be used with an application-centric approach. I researched several frameworks available for threat modeling. The following are some of the currently available frameworks for threat modeling:

  1. LINDDUN
  2. Attack Trees
  3. TRIKE
  4. STRIDE
  5. VAST Modeling
  6. PASTA
  7. Persona non-Grata
  8. Quantitative TMM
  9. hTMM
  10. CVSS
  11. OCTAVE
  12. Security Cards

Next, I mapped the framework based on the approach, and the following results were obtained:

  • Asset-centric: STRIDE, LINDDUN, Security Cards, Quantitative TMM, VAST Modeling, OCTAVE, PASTA.
  • Attacker-centric: PASTA, Persona non-Grata, hTMM, TRIKE, Attack Trees.
  • Application-centric: STRIDE, CVSS, Attack Trees, Security Cards, VAST Modelling, OCTAVE.

The following are the results of comparative research from several of the frameworks above.

MethodsProsCons
STRIDE
  • Most mature
  • Easy to use
  • Provides a structured approach to identifying and categorizing threats
  • Can use tools
  • Comprehensive coverage (​Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege)
  • Time consuming
  • Pretty complex
PASTA
  • Realistic threat scenarios
  • Provides a structured approach to identifying and categorizing threats
  • Adaptable to various development methodologies
  • Provides a structured methodology with seven stages (​Define, Scope, Identify, Assess, Respond, Monitor, Report)
  • Lack of tooling support
  • Complex
  • Potential to overwhelm
  • Resource intensive
LINDDUN
  • Easy to use
  • Scalable and can be adapted to different project sizes and complexities
  • Integration with Privacy Concerns
  • Limited scope
  • Less comprehensive
  • Needs expertise
  • Lack of tooling support
CVSS
  • Standardized scoring
  • Integration with Vulnerability Management
  • Community support and resources
  • Widely Adopted
  • Focus on technical factors
  • Complex
  • Limited coverage of threats
  • Subjectivity in scoring
Attack Trees
  • Visual representation
  • Flexible
  • Scenario exploration
  • Complex
  • Resource intensive
  • Difficulty in quantification
  • Maintenance overhead
Persona non-​Grata
  • Focus on threat actors
  • Realistic scenarios
  • Alignment with risk management
  • Contextual understanding
  • Complex
  • Resource intensive
  • Limited scope
Security Cards
  • Rapid prototyping
  • Flexible customization
  • Easy to understand
  • Limited details
  • Lack of standardization
  • Limited scalability
  • Dependency of facilitation
hTMM
  • Human-​centric approach
  • Realistic threat scenarios
  • Mitigation of social engineering attacks
  • Complex
  • Resource intensive
  • Limited coverage of technical threats
  • Dependency on user involvement
Quantitative TMM
  • Cost-​benefit analysis
  • Optimize for risk management
  • Communication with Stakeholders
  • Numerical risk assessment
  • Complex
  • Assumption dependency
  • Modelling limitations
  • Resistance to adoption
TRIKE
  • Structured approach
  • Integration with existing practices
  • Community support
  • Complex
  • Resource intensive
  • Dependency on knowledge bases
  • Limited coverage of emerging threats
VAST Modeling
  • Easy to understand
  • Simplicity
  • Alignment with development processes
  • Lack of details
  • Limited coverage
  • Resource intensive
OCTAVE
  • Comprehensive approach
  • Tailored to organizational context
  • Integrated with Risk Management
  • Holistic perspective
  • Complex
  • Resource intensive
  • Documentation overhead
  • Limited scalability

In determining the approach and method, the following are the criteria I determined for making the selection:

  • Easy to use
  • Using data/information that is easier to obtain
  • Can use tools
  • One of the mature frameworks

Based on the criteria above and the results of comparative research on several approaches and frameworks, the application-centric approach using the STRIDE framework was selected which meets all the specified criteria. Below is a threat modeling framework using STRIDE.

Determine approach and framework

Design & Prototype

This is the design for doing threat modeling.

  1. Conducted research into several threat modeling approaches and processes.
  2. Determining the threat modeling approach and method based on research results to determine which is suitable.
  3. Determining the scope for threat modeling in the internal environment.
  4. Information collection for the selected scope environment.
  5. Creation of Data Flow Diagrams.
  6. List identified threats using STRIDE methodology and Microsoft Threat Modeling Tools.

Testing & Implementation

Scoping

The following are the testing conditions and implementation of this exercise with the scope of a simple Web Application environment for the DevSecOps threat modeling exercise.

Information Collection

Below is an example of simple web application architecture topology.

  1. Architecture topology.

    Architecture topology
  2. List of Applications/Service

    • User browser (Chrome, Mozilla, Edge, etc.)
    • HTTPS
    • Web applications
    • API
    • Web service
    • Database server

Data Flow Diagrams

The first step is to create a Data Flow Diagram (DFD). DFDs play a fundamental role in threat modeling by providing a clear visual representation of how data moves through a system. Their primary function is to help analysts and security teams identify potential threats and security vulnerabilities within an application's architecture.

Data flow diagrams

Threat Model Summary

Total Threats: 31

Threats List

After creating the DFD, we identify potential threats to each element using a structured approach with the STRIDE method.

In the table created, we can enter information such as Threat, Category, Description, and Priority.

  • Threat: Contains the types of attacks that can be used by attackers according to the elements used.
  • Category: Attack categories based on STRIDE elements (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
  • Description: Detailed explanation regarding attack activity.
  • Priority: Priority in carrying out repairs is based on the severity level of the risk value of each type of attack. Determining the risk value can be calculated using the CVSS (Common Vulnerable Scoring System) calculator independently, referring to companies that have already carried out calculations, or from CVEs that have been publicly released.
  1. API (Web App - Web Service)

    API Web App to Web Service
    NoThreatCategoryDescriptionPriority
    1Web Application Process Memory TamperedTamperingWeb applications can tamper with web services if given memory access.Critical
    2Replay AttacksTamperingPackets without sequence numbers can be intercepted and retried in other ways.Medium
    3Collision AttacksTamperingAttackers can overlap data by sending a series of packets.Medium
    4Weak Authentication SchemeInformation DisclosureVulnerable to common weaknesses in authenticationHigh
    5Elevation Using ImpersonationElevation of PrivilegeWeb services can seek additional privileges by imitating the context of a web applicationHigh
  2. API (Web Service - Web App)

    API Web Service to Web App
    NoThreatCategoryDescriptionPriority
    1Web Service Process Memory TamperedTamperingWeb service can tamper with web applications if given memory access.Critical
    2Cross-​Site Scripting (​XSS)TamperingIf the input is not properly sanitized, web applications can be subject to XSS attacks.High
    3Elevation Using ImpersonationElevation of PrivilegeWeb services can seek additional privileges by imitating the context of a web applicationHigh
  3. Database Request

    Database request
    NoThreatCategoryDescriptionPriority
    1Spoofing of Destination Data Store DatabaseSpoofingAn attacker can spoof the database which can cause data to be written to the target.High
    2Potential SQL Injection Vulnerability for DatabaseTamperingSQL injection is a type of cyber-​attack that targets web applications by exploiting vulnerabilities in their SQL database interactionsHigh
    3Potential Excessive Resource Consumption for Web Service or DatabaseDenial of ServiceAttacks that use resource consumption are possible when the web or database controls resources by taking explicit steps.Medium
    4Weak Credential StorageInformation DisclosureCredentials on the server can be exposed, and credentials on the client can be stolen.High
    5Risks from LoggingTamperingLog files can be used to attack the log readersMedium
    6Lower Trusted Subject Updates LogsRepudiationToo many people writing logs can be a problem in repudiation.Medium
    7Data Logs from an Unknown SourceRepudiationLogs from unknown external users must be identifiedMedium
    8Insufficient AuditingRepudiationLog data that is not captured properly will complicate the audit process.Medium
    9Potential Weak Protections for Audit DataRepudiationAttacks on audit mechanisms such as log deletion may occur.High
  4. Database Response

    Database response
    NoThreatCategoryDescriptionPriority
    1Spoofing of Source Data Store DatabaseSpoofingAn attacker can spoof the database which can cause data to be written to the target.High
    2Weak Access Control for a ResourceInformation DisclosureConfidential information may be read by attackers if database protection is not performed properly.High
    3Risks from LoggingTamperingLog files can be used to attack the log readersMedium
  5. HTTPS (Browser - Web App)

    HTTPS browser to web app
    NoThreatCategoryDescriptionPriority
    1Cross-​Site ScriptingTamperingIf the input is not properly sanitized, web applications can be subject to XSS attacks.High
    2Elevation Using ImpersonationElevation of PrivilegeWeb applications can seek additional privileges by imitating the context of the user'​s browserHigh
    3Potential Data Repudiation by Web ApplicationRepudiationWeb applications do not accept data from outside sources that are not trusted but this can happen without being noticedMedium
    4Potential Process Crash or Stop for Web ApplicationDenial of ServiceWeb applications can experience several obstacles.Medium
    5Data Flow HTTPS Is Potentially InterruptedDenial of ServiceExternal agents can disrupt data flow.High
    6Web Application May be Subject to Elevation of Privilege Using Remote Code ExecutionElevation of PrivilegeUser browsers can be exploited using remote code execution exploits from web applicationsCritical
    7Elevation by Changing the Execution Flow in Web ApplicationElevation of PrivilegeData to a web application can be passed by an attacker to change the program flow.High
    8Cross-​Site Request ForgeryElevation of PrivilegeCSRF is a type of cyber-​attack where an attacker tricks a user into performing actions on a web application without their consent or knowledgeMedium
  6. HTTPS (Web App - Browser)

    HTTPS web app to browser
    NoThreatCategoryDescriptionPriority
    1Spoofing of the User Browser External Destination EntitySpoofingAn attacker can spoof a user'​s browser to send data to the attacker.Medium
    2External Entity User Browser Potentially Denies Receiving DataRepudiationUser browsers do not accept data from outside sources that are not trusted but this can happen without being noticedLow
    3Data Flow HTTPS Is Potentially InterruptedDenial of ServiceExternal agents can disrupt data flow.High

Conclusion & Lesson Learned

From the implementation of threat modeling for simple web applications, 31 threats were identified. All these threats still need to be validated later, to see which threats have been mitigated, and which ones have not.

The following are the advantages that I can take from doing threat modeling.

  1. Early detection of security flaws
  2. Improved understanding of the system
  3. Enhanced risk management
  4. Compliance and standards adherence
  5. Informed decision-making
  6. Enhanced communication and collaboration
  7. Improved security posture
  8. Increased confidence in doing business
  9. Continual improvement
  10. Reduced incident response costs

In summary, threat modeling is a strategic process that not only helps in identifying and mitigating security risks early but also improves overall system understanding, promotes better communication, ensures compliance, and enhances the security posture of an organization.

References

  1. [1]
    Adam Shostack - Threat Modeling: Designing for Security-Wiley (2014).
  2. [2]
    OWASP DevSecOps Guideline - v-0.2 | OWASP Foundation. Accessed: Apr. 08, 2024. Available: https://owasp.org/www-project-devsecops-guideline/latest/00b-Threat-modeling
  3. [3]
    L. Obiora Nweke and S. D. Wolthusen, A Review of Asset-Centric Threat Modelling Approaches, 2020. Available: https://ijacsa.thesai.org
  4. [4]
    M. J. Coles, Izar Tarandach & Threat Modeling: A Practical Guide for Development Teams.

© 2026 Tjakrabirawa Teknologi Indonesia. All Rights Reserved.