How to Apply STRIDE Threat Modeling and SonarQube Analysis for Secure Software Development

Secure software requires both design-time and code-time protection. STRIDE threat modeling helps identify risks early in system design, while SonarQube enforces secure coding practices through static analysis. Together, they provide a practical, end-to-end approach to building secure applications.

In this article, you'll learn how to apply STRIDE threat modeling and SonarQube static analysis to identify, prevent, and fix security vulnerabilities in modern applications.

Table of Contents

• Why Security Must Be Built In, Not Added Later

• Prerequisites

• Understanding STRIDE Threat Modeling

• Applying STRIDE Step-by-Step

• Introduction to SonarQube

• How SonarQube Enhances Security

• Bridging STRIDE and SonarQube

• Practical Example: Securing a Login API

• Best Practices for Secure Development

• Common Challenges and Limitations

• When NOT to Rely Solely on These Tools

• Future Enhancements

• Conclusion

Why Security Must Be Built In, Not Added Later

Modern applications handle sensitive data, user identities, and critical business logic. Yet many systems still treat security as a final step – something to “add” before deployment. This approach is risky and often leads to vulnerabilities slipping into production.

Security issues such as SQL injection, broken authentication, or data exposure are rarely caused by a single mistake. Instead, they emerge from a combination of poor design decisions and insecure implementation.

This is where a shift-left security approach becomes essential. Instead of waiting until testing or deployment, security is integrated early in the development lifecycle.

Two powerful techniques enable this:

• STRIDE threat modeling: identifies risks during system design

• SonarQube static analysis: detects vulnerabilities in code

When combined, they create a layered security strategy that addresses both architecture-level threats and code-level weaknesses.

In this tutorial, you’ll learn how to systematically identify security threats using the STRIDE framework and then validate your implementation using SonarQube.

We’ll walk through real examples, build a simple threat model, map risks to code-level vulnerabilities, and use automated analysis to detect and fix them. By the end, you’ll understand how to integrate threat modeling into your development workflow and use static analysis tools to continuously enforce secure coding practices.

Prerequisites

Before following along, you should have:

• Basic programming knowledge (preferably C# or JavaScript)

• Familiarity with web applications or REST APIs

• Understanding of authentication and authorization concepts

• Basic Git and CI/CD knowledge (helpful but not required)

Understanding STRIDE Threat Modeling

What is STRIDE?

STRIDE is a threat modeling framework developed by Microsoft to systematically identify security risks in software systems.

It categorizes threats into six types, helping developers think about potential attack vectors early in the design phase.

STRIDE Categories Explained

Applying STRIDE Step-by-Step

This section introduces the general step-by-step process for applying STRIDE threat modeling to any system. We'll use a simple running example: a login system where a user interacts with a web application, which communicates with an API and a database.

To keep the approach clear and reusable, we’ll first walk through the methodology at a high level. Later in the article, we’ll apply these same steps to a practical login API example so you can see how STRIDE works in a real-world scenario.

1. Define System Scope

For our login system example, we start by identifying:

• Actors (users, admins, services)

• Assets (data, APIs, credentials)

• Entry points (login forms, endpoints)

Example system: User → Web App → API → Database

2. Create a Data Flow Diagram (DFD)

For our login system example, a Data Flow Diagram (DFD) helps visualize how data moves through the system.

It has these basic components:

• External entities (users)

• Processes (application logic)

• Data stores (databases)

• Data flows (requests/responses)

A simple Data Flow Diagram (DFD) for our login system might look like this:

[User] → (Login Service) → [Auth Database]

In this diagram:

• [User] represents an external entity interacting with the system

• (Login Service) represents a process that handles authentication logic

• [Auth Database] represents a data store where user credentials are stored

Even though this is a simplified textual representation, it captures how data flows between components. In real-world scenarios, DFDs are often visual diagrams with arrows and labeled flows.

It’s also important to identify trust boundaries—points where data moves between different security zones (for example, from the user’s browser to your backend API). These boundaries are critical because they are common locations for attacks such as spoofing or tampering.

About Trust Boundaries:

A trust boundary represents a point where data moves between different levels of trust. For example, data coming from a user’s browser into your backend API crosses a trust boundary because external input cannot be trusted by default. Similarly, communication between your application server and database may also cross a boundary depending on access controls and network configuration.

To add trust boundaries in a DFD, you typically draw a line (or dashed box) around components that share the same trust level, and mark where data flows cross into another zone. Each of these crossings should be treated as a potential attack surface.

For instance, when a request moves from the user to the login service, you should consider threats like input tampering or spoofing at that boundary and apply appropriate validations and security controls.

3. Identify Threats Using STRIDE

Using the DFD we created in the previous step (User → Login Service → Auth Database), we can now apply STRIDE by mapping each threat category to specific components in the system. This helps us systematically analyze where different types of security risks may occur.

For example:

In this context, each component from the DFD is evaluated against STRIDE categories to identify relevant threats.

For instance, the Login API is exposed to spoofing attacks because it handles authentication, while the database is at risk of tampering if proper validation and access controls are not enforced.

Example threat: An attacker could bypass authentication by forging a JWT token (Spoofing).

4. Risk Assessment

Not all threats are equal, so you need a structured way to prioritize them based on likelihood and impact. Likelihood refers to how probable it is that a threat can be exploited, while impact measures the potential damage if the attack succeeds.

To assess likelihood, consider factors such as how exposed the component is (public API vs internal service), the complexity of exploiting the vulnerability, and whether known attack techniques already exist. For example, an unauthenticated public endpoint with no input validation would have a high likelihood of being exploited.

To assess impact, evaluate what happens if the attack succeeds. Ask questions like: Does it expose sensitive user data? Can it compromise the entire system? Does it affect availability or business operations? For instance, a breach that leaks user credentials would have a high impact, while a minor logging issue might be low impact.

Once likelihood and impact are determined (Low / Medium / High), you can use a simple risk matrix to prioritize threats and decide which ones to address first:

Simple matrix:

This structured approach ensures that you focus your efforts on the most critical risks rather than treating all threats equally.

5. Define Mitigations

Once you’ve identified and prioritized threats, the next step is to define mitigations, also known as security controls.

A control is a safeguard or mechanism used to reduce the likelihood or impact of a threat. This can include technical solutions (like encryption), process changes (like logging), or access restrictions (like authentication and authorization).

To map threats to controls, you analyze how each threat could occur and then apply a corresponding defense that either prevents the attack or minimizes its impact.

For example, if a threat involves spoofing (impersonating a user), the appropriate control would be strong authentication mechanisms such as multi-factor authentication or secure token validation.

Here’s how this mapping works in practice:

This process ensures that every identified threat is paired with a concrete action. Over time, these controls form a layered defense strategy that protects your system across multiple attack vectors.

Introduction to SonarQube

While STRIDE is primarily used during the design phase to identify potential threats before implementation, it's not limited to early-stage use. In practice, you can also apply STRIDE iteratively as the system evolves – during development, after major feature additions, or when reviewing existing architectures.

For example, steps like identifying threats, assessing risks, and defining mitigations (as shown earlier) often involve analyzing components that are already partially implemented. This makes STRIDE a flexible tool that bridges both design-time and review-time security.

In contrast, SonarQube operates at the code level, analyzing actual implementations to detect vulnerabilities.

Together, they complement each other by covering both what could go wrong (design perspective) and what is currently wrong (code perspective).

SonarQube performs static code analysis, meaning it inspects code without executing it.

The tool has some key capabilities:

• Detects bugs and vulnerabilities

• Identifies code smells

• Enforces coding standards

• Provides security hotspots

Setting Up SonarQube

You can quickly run SonarQube using Docker:

docker run -d --name sonarqube -p 9000:9000 sonarqube

Access it at http://localhost:9000.

How to Analyze a Project

SonarScanner is the command-line tool that acts as the bridge between your codebase and SonarQube. It reads your project configuration, scans your source files, and sends the analysis results to the SonarQube server for processing and visualization. In simple terms, it's the component that actually performs the scanning and reports findings to the dashboard.

To analyze a project, you first need to install SonarScanner, which is responsible for executing the static code analysis process:

npm install -g sonarqube-scanner

Create a config file:

// sonar-project.js
module.exports = {
  serverUrl: "http://localhost:9000",
  options: {
    "sonar.projectKey": "secure-app",
    "sonar.sources": "./src"
  }
};

This configuration file defines how your project connects to and communicates with SonarQube during analysis.

The module.exports syntax is a standard Node.js pattern that allows the SonarQube scanner to load these settings. The serverUrl specifies where your SonarQube instance is running. http://localhost:9000 is the default for a local setup, but you can change this to a remote server if needed.

Inside the options object, "sonar.projectKey" acts as a unique identifier for your project within SonarQube, enabling it to track analysis results and maintain history over time.

The "sonar.sources" property tells SonarQube which directory to scan for source code – in this case, the ./src folder.

When you run the scanner, it reads this configuration, connects to the specified server, identifies the project using the key, and analyzes all files in the defined source directory. The results are then sent to the SonarQube dashboard, where you can review code quality issues, vulnerabilities, and maintainability metrics.

Use this command to run the analysis:

sonar-scanner

What the SonarQube Dashboard Shows:

After the scan is completed, results are displayed in the SonarQube dashboard, which provides a detailed overview of your project’s code quality and security status.

A typical dashboard includes:

• Bugs (logic errors in code)

• Vulnerabilities (security issues like SQL injection)

• Code Smells (maintainability problems)

• Security Hotspots (areas requiring manual review)

• Coverage (test coverage percentage)

• Duplications (repeated code blocks)

Each issue is categorized by severity (Blocker, Critical, Major, Minor), allowing developers to prioritize fixes effectively. For example, a SQL injection vulnerability would appear as a Critical Vulnerability, while unused variables might be marked as a Minor Code Smell.

The dashboard allows you to drill down into each issue, view the exact file and line of code, and understand why it was flagged, making it easier to fix problems directly at the source.

When you run the scanner, it first loads the sonar-project.js configuration file to understand how the analysis should be performed (which you specified above). It then connects to the SonarQube server using the defined serverUrl and identifies your project through the sonar.projectKey, ensuring results are mapped correctly.

After establishing this context, the scanner analyzes all files within the specified ./src directory and finally sends the collected code quality and security insights to the SonarQube dashboard, where you can review and act on them.

How SonarQube Enhances Security

SonarQube identifies real vulnerabilities in your code. Let's look at a few examples to see it in action.

Example 1: SQL Injection

Here's our vulnerable code:

app.get("/user", (req, res) => {
  const query = "SELECT * FROM users WHERE id = " + req.query.id;
  db.query(query);
});

In the vulnerable version of the code, the application directly concatenates user input (req.query.id) into the SQL query string. This creates a serious security flaw known as SQL Injection because an attacker can manipulate the input to modify the structure of the query itself.

For example, instead of a simple numeric ID, a malicious user could inject SQL commands that allow them to access or modify unauthorized data in the database.

Issue: User input is directly concatenated.

Now, here's the secure version:

app.get("/user", (req, res) => {
  const query = "SELECT * FROM users WHERE id = ?";
  db.query(query, [req.query.id]);
});

In the secure version, the query uses a parameterized statement (SELECT * FROM users WHERE id = ?), where the user input is passed separately as a parameter ([req.query.id]) instead of being directly inserted into the query string. This ensures that the database treats the input strictly as data, not executable SQL code, effectively preventing injection attacks and making the application significantly more secure.

Example 2: Hardcoded Secrets

Here's a bad practice:

const password = "admin123";

In the bad practice example, the password is hardcoded directly into the source code as const password = "admin123";. This is insecure because anyone with access to the codebase can easily view sensitive credentials. If the code is ever pushed to version control or shared, the secret is exposed permanently.

Hardcoded secrets are a common security vulnerability and can lead to unauthorized access if an attacker obtains them.

Here's a quick fix:

const password = process.env.DB_PASSWORD;

In the fixed version, the password is retrieved from an environment variable using process.env.DB_PASSWORD. This approach keeps sensitive information outside the source code and allows it to be managed securely at the system or deployment level.

It improves security by separating configuration from code, reducing the risk of accidental exposure and making it easier to rotate credentials without changing the application logic.

Security Hotspots vs Vulnerabilities

In SonarQube, issues are categorized into two important security-related groups: vulnerabilities and security hotspots. Understanding the difference is critical for proper triage.

Vulnerabilities

Vulnerabilities are confirmed security issues that are clearly exploitable and must be fixed immediately. These are situations where SonarQube is confident that the code introduces a real security risk, such as SQL injection, insecure deserialization, or exposed secrets.

Vulnerabilities are typically treated as high-priority issues because they can directly lead to system compromise.

Security Hotspots

Security Hotspots, on the other hand, are areas of code that are security-sensitive but require human review to determine whether they are actually risky. SonarQube flags these when the code could be insecure depending on context, but it can't confidently classify them as vulnerabilities.

For example, password handling or authorization logic may be flagged as hotspots because they require developer validation to ensure they're implemented securely.

In short, vulnerabilities are confirmed problems that must be fixed, while hotspots are potential risks that must be reviewed and validated by developers before deciding whether action is needed.

Quality Gates

In SonarQube, a Quality Gate is a set of predefined conditions that determine whether a project is ready to move forward in the development pipeline. It acts as an automated checkpoint in CI/CD, ensuring that only code meeting specific quality and security standards is allowed to progress to production.

If the code fails any of the defined conditions, the build is marked as failed, and developers are required to fix the issues before proceeding. This helps enforce consistent quality and prevents vulnerable or poorly written code from being deployed.

Here are examples of common Quality Gate conditions:

• No critical vulnerabilities: The project must not contain any unresolved critical or blocker security issues, such as SQL injection or authentication bypass risks. Even a single critical vulnerability will fail the gate.

• Minimum code coverage: The project must meet a required percentage of test coverage (for example, 80%). This ensures that a sufficient portion of the codebase is tested and reduces the risk of untested bugs reaching production.

• Security rating thresholds: The project must maintain a minimum security rating (for example, A or B). If the rating drops due to new vulnerabilities or poor security practices, the Quality Gate will fail.

Together, these rules ensure that only code meeting defined security and quality standards is allowed to progress through the development lifecycle.

Bridging STRIDE and SonarQube

Here’s where things get interesting. Bridging STRIDE and SonarQube means using both together as part of a single security workflow rather than treating them as separate tools.

You'll use STRIDE during system design to anticipate what could go wrong by identifying potential threats in the architecture. You'll use SonarQube during implementation to detect what is actually wrong in the written code.

When combined, STRIDE helps you think about security before you write code, and SonarQube ensures those design assumptions are enforced and validated in the final implementation. This creates a continuous feedback loop between design decisions and code-level security checks.

Mapping Example

This mapping table shows how STRIDE threat categories can be translated into corresponding types of code-level issues that tools like SonarQube are designed to detect. In other words, it connects high-level security thinking (design-time threats) with low-level implementation problems (code-level vulnerabilities).

By aligning each STRIDE category with a typical coding weakness, you can better understand how architectural risks eventually manifest in real code and how they can be identified or prevented during development.

Combined Workflow

The combined workflow shows how STRIDE and SonarQube are used together in a continuous security process across the development lifecycle. Instead of treating threat modeling and code analysis as separate activities, this approach integrates them into a single iterative loop where design decisions directly influence implementation, and code-level findings feed back into design improvements.

This means that security is not a one-time activity, but an ongoing cycle of identifying risks, implementing safeguards, and validating them through automated analysis tools.

The process typically follows these steps:

1. Perform STRIDE threat modeling

2. Identify high-risk areas

3. Implement secure code

4. Run SonarQube scans

5. Fix detected vulnerabilities

This creates a feedback loop between design and implementation.

Practical Example: Securing a Login API

Let’s apply both approaches in a practical example so you can see how they work in practice.

Step 1: STRIDE Analysis

Instead of treating design and implementation as separate stages, STRIDE helps identify potential threats early in the system design, while tools like SonarQube validate whether those risks are properly addressed in the implemented code.

In this practical example of securing a login API, we'll begin with STRIDE analysis at the design level.

Here's our system:

User → Login API → Database

This creates a feedback loop between design and implementation by ensuring that security is considered both at the architectural level and during actual coding.

The system flow is defined as User → Login API → Database, which helps visualize how data moves through the application and where trust boundaries exist. This high-level view allows us to reason about possible threats such as spoofing at the login stage, tampering during request handling, or information disclosure from database responses before any code is even written.

Identified Threats:

Step 2: Vulnerable Implementation

Let's start with the vulnerable code:

app.post("/login", async (req, res) => {
  const { username, password } = req.body;

  const user = await db.findUser(username);

  if (user.password === password) {
    res.send("Login successful");
  }
});

In the vulnerable implementation, the login API directly compares the plain-text password provided by the user with the stored password in the database using a simple equality check (user.password === password).

This approach is insecure because it assumes passwords are stored in plain text, which exposes users to severe risks if the database is compromised. It also lacks proper authentication safeguards like hashing, error handling for missing users, and protection against unauthorized access patterns.

Step 3: Secure Implementation

Now let's see how to secure it:

const bcrypt = require("bcrypt");
const jwt = require("jsonwebtoken");

app.post("/login", async (req, res) => {
  const { username, password } = req.body;

  const user = await db.findUser(username);
  if (!user) return res.status(401).send("Invalid credentials");

  const isValid = await bcrypt.compare(password, user.password);
  if (!isValid) return res.status(401).send("Invalid credentials");

  const token = jwt.sign({ id: user.id }, process.env.JWT_SECRET, {
    expiresIn: "1h"
  });

  res.json({ token });
});

In the secure implementation, the code introduces industry-standard authentication practices. It uses bcrypt to safely compare the hashed password stored in the database with the user-provided password, ensuring that raw passwords are never exposed or stored. It also includes proper validation to handle cases where the user does not exist, preventing runtime errors.

After successful authentication, a JWT (JSON Web Token) is generated using jsonwebtoken, signed with a secret key stored in process.env.JWT_SECRET, and set to expire in one hour. This ensures secure, stateless session management and significantly improves the overall security of the login system.

Step 4: Run SonarQube

At this stage, we assume the login implementation has been completed and is now being analyzed using SonarQube. Since we're working with a concrete example, SonarQube would only report issues that actually exist in the codebase rather than hypothetical ones.

For the secure version of our login API, a SonarQube scan would typically focus on detecting issues such as insecure cryptographic usage, missing input validation in edge cases, or improper handling of authentication flows. But if we're following best practices (as in our secure implementation), the number of critical issues would be significantly reduced or potentially zero.

A typical scan result in the SonarQube dashboard would show:

• Vulnerabilities: 0 (if no insecure patterns are detected)

• Code Smells: Minor issues such as formatting or unused imports

• Security Hotspots: Review points around authentication logic

• Quality Gate Status: Passed or Failed depending on thresholds

For example, in a well-secured login implementation, SonarQube might highlight the JWT generation block as a Security Hotspot for manual review, but it would not necessarily flag it as a vulnerability if implemented correctly.

The results would be displayed in the SonarQube dashboard as a project summary, showing metrics like bug count, vulnerability count, security rating, and maintainability index. Developers can then drill down into each issue to view the exact file, line number, and suggested fix.

Best Practices for Secure Development

1. Integrate Security Early

This is a critical practice in secure development. Security should be introduced during the initial design phase rather than added later in the development lifecycle.

By combining STRIDE threat modeling with early design discussions, teams can identify potential risks before any code is written. This helps prevent architectural flaws that are expensive and difficult to fix after implementation.

2. Automate Security Checks

Security checks should be automated as part of the CI/CD pipeline to ensure continuous enforcement of secure coding practices. Tools like SonarQube can be integrated into build workflows so that every code change is automatically analyzed for vulnerabilities, code smells, and security issues. For example:

- name: SonarQube Scan
run: sonar-scanner

This ensures that insecure code is detected early and prevents it from being merged or deployed without review.

3. Keep Threat Models Updated

Don't treat threat models as a one-time activity created only during initial system design. Instead, you'll want to continuously update them as the system evolves.

Whenever new features are added, APIs are modified, or architectural changes occur, the existing STRIDE analysis should be revisited to identify new threats or changes in risk exposure.

For example, introducing a new third-party authentication provider or exposing a new endpoint would require re-evaluating spoofing, tampering, and information disclosure risks. This ensures that the threat model remains aligned with the current state of the system and continues to provide accurate security guidance throughout the development lifecycle.

4. Use Defense in Depth

Defense in depth is a security strategy that assumes no single control is sufficient to fully protect a system. Instead, multiple layers of security are applied so that if one layer fails, others still provide protection. In practice, this means combining different types of safeguards across the system rather than relying on a single mechanism.

For example, authentication ensures that only legitimate users can access the system, authorization restricts what those users are allowed to do once inside, encryption protects sensitive data both in transit and at rest, and monitoring continuously observes system activity to detect suspicious behavior or potential attacks.

When these layers are used together, an attacker would need to bypass multiple independent controls, significantly increasing the difficulty of a successful breach and improving overall system resilience.

5. Educate Developers

Security tools alone are not sufficient to build secure systems. Developers must understand secure coding principles, common vulnerabilities, and how threats manifest in real applications.

Regular training sessions, code reviews, and hands-on exercises using tools like STRIDE and SonarQube help build this awareness. Over time, this improves the team’s ability to write secure code by default rather than relying solely on automated tools.

Common Challenges and Limitations

STRIDE Challenges

STRIDE has certain limitations. First, you need developers who understand the framework and can apply it effectively. Beginners may struggle to accurately identify threats across complex systems.

It can also become time-consuming when used on large-scale architectures with multiple components and interactions. But your team may decide the time and effort are worth it.

SonarQube Limitations

SonarQube has some known limitations, including false positives, limited understanding of runtime behavior, and difficulty detecting complex business logic flaws that depend on application context. However, these challenges can be managed effectively with the right practices.

False positives can be reduced by tuning rules, customizing quality profiles, and regularly reviewing and marking issues as “false positive” or “won’t fix” based on team consensus.

Limited runtime awareness can be addressed by complementing SonarQube with dynamic testing tools and runtime monitoring systems.

For business logic flaws, manual code reviews and threat modeling (such as STRIDE) remain essential, as these require human understanding of application intent.

By combining these approaches, teams can significantly improve the accuracy and usefulness of SonarQube in real-world development workflows.

Organizational Barriers

In addition to technical challenges, organizations often face cultural and procedural barriers such as a lack of security awareness or security-first mindset among teams, along with resistance to adopting new security practices or changes in established development workflows.

When NOT to Rely Solely on These Tools

While STRIDE and SonarQube provide strong foundations for secure software development, they aren't complete security solutions on their own.

STRIDE is primarily a design-time approach and doesn't detect runtime vulnerabilities that emerge during actual system execution. Similarly, SonarQube focuses on static code analysis and may miss deeper business logic flaws or complex security issues that only appear under specific runtime conditions.

To build a more complete security strategy, these tools should be combined with additional practices such as penetration testing, security audits, and runtime monitoring.

Penetration testing helps simulate real-world attacks, security audits ensure compliance and structured review, and runtime monitoring detects suspicious behavior in live environments. Together, these practices create a more resilient and defense-in-depth security model.

Future Enhancements

AI-Assisted Threat Modeling:

AI-assisted threat modeling uses intelligent tools to automatically analyze system architecture and suggest potential security threats. This reduces manual effort and helps developers identify risks that might be overlooked during traditional analysis. Over time, it improves accuracy and speeds up the threat modeling process.

DevSecOps Integration:

DevSecOps integration embeds security practices directly into continuous integration and continuous delivery (CI/CD) pipelines. This ensures that every code change is automatically tested for vulnerabilities before deployment. It promotes a culture where security is treated as a shared responsibility across development, operations, and security teams.

Runtime Protection:

Runtime protection focuses on detecting and preventing attacks while the application is actively running in production. It complements static analysis by monitoring real-time behavior such as suspicious requests or abnormal system activity. This layered approach helps protect systems even after deployment.

Policy-as-Code:

Policy-as-code defines security rules and compliance requirements in a programmable format rather than manual documentation. These policies can be automatically enforced across environments, ensuring consistency and reducing human error. It enables scalable and repeatable security governance in modern software systems.

Conclusion

Secure software development requires more than just writing good code – it demands a proactive and structured approach to identifying and mitigating risks throughout the entire development lifecycle.

By combining STRIDE threat modeling with SonarQube, developers can address security from both the design and implementation perspectives, ensuring that potential threats are identified early and continuously monitored as the system evolves.

This integrated approach provides early visibility into design flaws, enables continuous detection of code-level vulnerabilities, and ultimately strengthens the overall security posture of the application. Instead of treating security as an afterthought, it becomes an embedded part of every development stage.

The best way to adopt this practice is to start small: model a simple system using STRIDE, analyze your code with SonarQube, and iteratively improve. Over time, this disciplined workflow significantly reduces vulnerabilities and leads to more secure, reliable software.