devopsy.kinsta.cloud

Tag: threat modeling

The Risk Profile of AI-Driven Development
In the cloud-native ecosystem, velocity is everything. We built Kubernetes, microservices, and CI/CD pipelines to ship faster and more reliably.

Now, AI coding assistants and autonomous agents are pushing that accelerator to the floor. What started as simple code completion has evolved into tools that draft requirements, generate Helm charts, scaffold microservices, and optimize CI/CD pipelines.

For those who care deeply about security hygiene, and especially dependency management, this acceleration requires a hard look at how we manage risk. When an AI agent can scaffold a microservice in seconds, it also makes dozens of architectural and dependency decisions in the blink of an eye.

Let’s discuss how the risk profile of development is shifting in the AI era, and how we must adapt.

The Pain Points: Dangerous Autonomy

Rapid Decision Velocity and Massive Volume

In traditional workflows, selecting a third-party library or container base image was often deliberate, sometimes even subject to architectural review. Today, dependency selection happens at the moment of coding.

When a developer asks an LLM to “scaffold a Python service for image processing,” the model chooses the libraries, the frameworks, and often the base image. This shift has two massive implications:
- Faster selection: Decisions are made instantly, often bypassing routine checks such as “is this maintained?” or “is this license compliant?”
- Increased volume: AI amplifies output. We are seeing more repositories, more sidecars, and more manifests.
A New Attack Surface

The core issue is that Large Language Models (LLMs) are trained on historical data. Even if that data was recently updated, their default recommendations reflect the state of the world then, not now.

This introduces specific risks to the software supply chain:
- Outdated and insecure patterns: AI may suggest deprecated projects or versions with known vulnerabilities simply because they were popular during the model’s training window.
- Hallucinations and typosquatting: There have been cases where models hallucinate package names that look plausible. Attackers can anticipate these “hallucinated” dependencies and register them (typosquatting), waiting for an AI to suggest them to an unsuspecting developer.
- Phantom dependencies: Transitive dependencies can spiral out of control. A single AI-suggested library can drag in a tree of unvetted packages, or a vulnerable base image can propagate across an entire cluster before a human reviewer catches it.
The Review Bottleneck

Perhaps the biggest operational risk is the Review Bottleneck. Traditional security gates, manual pull request reviews, periodic audits, and post-deployment scans do not scale linearly.

If your AI-assisted team doubles its output of YAML manifests and code, your security team cannot simply double its working hours to review them. This creates a dangerous paradox: autonomous development boosts productivity, but existing control mechanisms become the bottleneck that slows production — or worse, teams bypass them to keep moving.

The Solution: Autonomous Security for Autonomous Development

We cannot solve this by asking developers to slow down. Instead, we must treat AI-generated code with the same scrutiny as human-authored code, but apply governance at machine speed.

Shift Controls to the “Prompt” Level

Governance must move closer to the point of creation. We need policy-based dependency selection that enforces standards on versions, trusted registries, and licenses before the code even hits the repository. This means embedding checks into the IDE and CI/CD pipelines that can block high-risk components preemptively.

Threat Modeling as Engineering

We need a structured way to assess these new risks. OpenSSF’s Gemara model, a burgeoning standard for Governance, Risk, and Compliance (GRC) engineering, offers a blueprint here. It suggests breaking down systems into Capabilities (what the tech can do) and Threats (how it can be misused).

For example, if we use an AI agent to manage container lifecycles, we must map out its capabilities (e.g., “Image Retrieval by Tag”) and the specific threats (e.g., “Container Image Tampering”). By formalizing these threats in machine-readable formats, we can automate the validation process.

SBOMs and AIBOMs as Infrastructure

In this high-velocity environment, a software bill of materials (SBOM) is no longer just a compliance artifact. It is operational infrastructure. We need real-time visibility into every layer of our containers.

Furthermore, we must extend this transparency to the AI tools themselves via an AI bill of materials (AIBOM). We need to know which models are being used, what datasets they were trained on, and what their runtime dependencies are. This transparency is essential for building auditable trust in regulated sectors.

AI at Scale Demands Security at Scale

Cloud-native systems were built for automation — self-healing clusters, declarative infrastructure, and horizontal scaling. Security must adopt the same mindset.

The future of dependency management isn’t just about scanning for CVEs. It’s about intelligent automation fused with enforceable policies. As autonomous development becomes the standard, autonomous security must become the prerequisite. Only then can we accelerate innovation while building resilient, trustworthy, and secure systems.
March 13, 2026
Secure By Design, Secure by Default

“Shift left” has become a favorite mantra of engineering, IT and software teams. The idea is simple: Move critical practices earlier in the development process so that problems can be caught sooner and fixed more cheaply. It started with testing, then design, then DevOps, and now it’s security’s turn. Secure by design, secure by default. Just shift it left.

But there’s a problem. If you shift everything left, what’s on the right?

The term “shift left” sounds appealing, but it’s based on the notion that software development is a neat, linear process with design on the left and production on the right. That model might make sense on a Gantt chart, but real-world software is complex and messy. And complex and messy have important implications for how to think about security.

Code (and attack surfaces) don’t flow from left to right. They unfold across overlapping zones of activity that run in parallel. Some people are designing, some are coding, some are deploying, and others are investigating anomalies in production – all at the same time.

Security Needs to be Embedded

Security isn’t something you can “move left”. It’s something that needs to be embedded in all zones.

DevOps security is an extension of and should still conform to the organization’s overall enterprise security, compliance and governance policies. This ensures that the code that is developed and deployed meets the organization’s security requirements.

Optimize within a zone, sure. It’s important to do as much as possible early: threat modelling, secure coding and static analysis. That’s good hygiene. But those only address the development zone. The real world doesn’t stop there. Security in the production zone is just as critical: monitoring, detection, alerting, incident response and continuous improvement. These aren’t things you can shift anywhere. They’re tied to live, active systems. They happen where the threats are.

The irony is that shifting security left too far can give teams a false sense of safety. Boxes are ticked. Static scan looks good, threat modelling is done, so we must be secure. But attackers don’t care how early your checklist ran. They’re looking at the state of the system now.

The real issue is that we keep using linear metaphors for systems that aren’t linear. Software delivery is a dynamic, concurrent set of activities. Tasks feel linear because humans experience time that way, but the system as a whole behaves more like a living network. A dancing landscape that’s constantly adapting, feeding back, and evolving.

Security has to live across that system, moving as the landscape moves, not at one end of it.

You can absolutely optimize within a zone and make developers more security-aware and catch more vulnerabilities early, but that’s local optimization. It doesn’t make the system secure. A secure system is one where all zones are considered and continuously connected. Insights from incidents feed into design. Monitoring informs coding decisions. Security isn’t a phase; it’s a characteristic.

The challenge, then, is not to blindly start trying to shift security left, but to embed it everywhere in zone-appropriate ways. It may have made sense in organisations where security was treated as a final gate, though that, hopefully, is a practice far behind us these days, but thinking linearly doesn’t capture the reality of complex modern delivery. Real security is not about how early you start, but how continuously you adapt. Anything less risks being security theatre — reassuring on paper, but irrelevant to the real-world threats your systems face.

October 14, 2025
Elevating DevOps Security: Why Integrating Threat Modeling Transforms Pentesting
Penetration testing (pentesting) has long been a cornerstone of security practices, particularly for meeting compliance requirements. However, a recent conversation with a client revealed a crucial gap in this approach. Critical vulnerabilities — particularly in their APIs and third-party software — remained unaddressed despite passing their pentest. While the pentest checked the compliance box, it did not account for the real world, evolving threats their system faced.

Although compliance-driven tests serve their purpose, they often leave organizations exposed to risks such as API abuse, supply chain vulnerabilities and insider threats. Many organizations treat pentesting as a routine task, missing out on a broader strategy to defend against the ever-changing threats.

Where Traditional Pentests Fall Short in a DevOps Environment

The compliance-driven pen tests tend to follow static checklists. This approach often overlooks the dynamic nature of modern infrastructures, especially in environments with rapid deployments, cloud services and third-party integrations. These tests may not adapt quickly enough to the new risks that emerge as the systems evolve.

For example, vulnerabilities in open-source components or dependencies in the software supply chain often go undetected in traditional pentests. This can create a false sense of security — your system may pass compliance, but still be vulnerable to real-world attacks.

Threat Modeling: A Shift Toward Risk-Based Testing

Integrating threat modeling into your security strategy offers a more tailored, risk-focused approach. Instead of asking ‘What is vulnerable’, threat modeling shifts the focus to ‘What could go wrong’ and ‘How could an attacker exploit this system’. This proactive method aligns with the fast-paced, iterative nature of DevOps, helping in identifying risks earlier in the development cycle.

In a recent case, we worked with a cloud-based company that had passed several pentests but was concerned about their API security. Through threat modeling, we uncovered a critical vulnerability in their session handling that previous tests had missed. The company mitigated a serious security risk by addressing this issue early before it could be exploited.

Optimizing Resources with Targeted Testing

One of the key benefits of integrating threat modeling with pentesting is the ability to focus resources where they matter the most. For DevOps teams managing fast-moving pipelines, threat modeling ensures that pentesting efforts are concentrated on high-risk areas rather than spread thin across the entire system.

For instance, consider a cloud infrastructure security test that used a threat modeling framework to target identity management. The test revealed vulnerabilities related to privilege escalation that a broad, compliance-focused pentest might have missed. This targeted approach allowed the team to resolve the issues quickly, reducing risk without overextending resources.

How to Integrate Threat Modeling Into Your DevOps Workflow

To make pentesting more effective and align security with your DevOps processes, consider integrating threat modeling into your workflow. Here are four actionable steps to get started:
1. Adopt a Threat Modeling Framework
  Use frameworks like STRIDE or PASTA to structure your threat modeling efforts. These frameworks help prioritize the attack vectors specific to your environment, allowing you to focus on the highest risks.
2. Automate the Threat Modeling Process
  In fast-paced DevOps environments, automation is essential. Automating threat modeling ensures that the models evolve as your system changes, continuously identifying the potential risks and updating security practices. This prevents critical vulnerabilities from being overlooked as development progresses.
3. Embed Threat Modeling in CI/CD Pipelines
  To align security with DevOps, threat modeling should be embedded into your CI/CD pipeline. This allows teams to catch vulnerabilities early before they reach production. Integrating threat modeling into build and deployment processes ensures that the security is proactive, not reactive.
4. Foster Cross-Team Collaboration
  Threat modeling should involve more than just security professionals. Developers, architects and operations teams must collaborate to ensure the threat model reflects the system’s architecture and business needs. This cross-functional approach creates a holistic view of potential risks and strengthens your defenses.
Case Study: Threat Modeling for Cloud Security

A healthcare provider applied the STRIDE methodology to their cloud infrastructure, focusing specifically on identity management and session handling. By using this threat modeling framework, they identified vulnerabilities related to privilege escalation that the previous pentests had missed. This allowed the team to prioritize their pentesting efforts on the critical areas, ensuring that these vulnerabilities were resolved before the attackers could exploit them.

Why Threat-Driven Testing is Essential for DevOps

The future of pentesting in DevOps lies in shifting from compliance-focused to threat-driven approaches. By aligning testing with real-world risks, organizations can move beyond a static checklist and address the actual threats they face. This approach offers a more holistic and adaptable security strategy.

The DevOps teams can combine threat modeling with red team exercises and adversary simulations to test their defenses against sophisticated attack scenarios. These simulations emulate real-world adversaries, allowing the organizations to see how they would fare against insider threats or advanced persistent threats (APTs). This level of testing, driven by identified risks, ensures that your security posture can evolve as your system evolves.

Conclusion: Moving Beyond Compliance for Stronger Security

Relying solely on compliance-driven pentesting is no longer enough to safeguard modern, fast-moving DevOps environments. To stay ahead of the evolving threats, organizations need to integrate threat modeling into their security strategies. This approach goes beyond checking boxes — it enables teams to identify the most critical risks and address them proactively.

By adopting structured threat modeling frameworks, automating the process and embedding it into CI/CD pipelines, the DevOps teams can ensure that security is an ongoing, integral part of their workflow. Collaboration across teams further ensures that the security model aligns with both the system architecture and operational goals.

As attackers continuously evolve their tactics, your testing strategies must evolve too. Do not stop at compliance — embrace threat-driven pentesting and build a security posture that is ready for the real-world threats your organization faces.
October 2, 2024
Implementing Threat Modeling in a DevOps Workflow
Security remains paramount in the contemporary digital landscape, especially within the DevOps workflow. DevOps practices aim to streamline the software development lifecycle (SDLC) by fostering collaboration between development and operations teams, ensuring a secure SDLC. However, the rapid pace of DevOps can sometimes overlook critical security concerns. Integrating threat modeling into the DevOps workflow is essential to identify and mitigate potential security threats. This comprehensive guide explores how threat modeling can be effectively implemented within a DevOps framework to enhance security.

Understanding Threat Modeling

Threat modeling is a structured approach to identifying, evaluating and mitigating security threats to a system. It involves anticipating potential attacks, understanding their impact and devising strategies to defend against them. This proactive approach to security ensures that vulnerabilities are identified early in the development process, reducing the risk of security breaches post-deployment.

Key Elements of Threat Modeling
- Assets Identification: Determining what needs to be protected, including data, systems and services
- Threat Identification: Recognizing potential threats that could exploit vulnerabilities
- Vulnerability Identification: Identifying weaknesses in the system that could be exploited
- Mitigation Strategies: Developing countermeasures to address identified threats and vulnerabilities.
Integrating Threat Modeling into the DevOps Workflow

Integrating threat modeling into a DevOps workflow involves embedding security practices throughout the development and operations lifecycle. This approach ensures continuous security assessment and improvement, aligning with the DevOps principles of continuous integration and continuous deployment (CI/CD).

1. Shift-Left Security: Integrating Early in the SDLC

One of the fundamental principles of DevOps is the concept of ‘shift-left’ security, which means incorporating security practices early in the SDLC. By integrating threat modeling at the initial stages, potential security threats can be identified before they become deeply embedded in the codebase. This early integration supports a secure SDLC, ensuring that security measures are considered from the beginning and throughout the development process.

Benefits of Shift-Left Security
- Early Detection of Vulnerabilities: Identifying security issues early reduces the cost and effort required to fix them later
- Improved Code Quality: Encouraging developers to write secure code from the beginning
- Reduced Time-to-Market: Minimizing the risk of delays caused by security issues discovered late in the development process.
2. Continuous Threat Modeling

Continuous threat modeling aligns with the DevOps principle of continuous integration and deployment. This practice involves regularly updating threat models to reflect changes in the application, infrastructure and threat landscape. Automated tools can assist in maintaining up-to-date threat models, ensuring that security assessments are conducted consistently.

Key Aspects of Continuous Threat Modeling
- Automated Security Scans: Integrating security scanning tools into the CI/CD pipeline to detect vulnerabilities continuously
- Regular Updates: Revisiting and updating threat models as the application evolves
- Monitoring and Feedback: Utilizing feedback loops to improve threat models based on new information and detected threats.
3. Collaboration Between Development, Operations and Security Teams

Effective threat modeling in a DevOps environment requires close collaboration between development, operations and security teams. This cross-functional collaboration ensures that security is considered at every stage of the development lifecycle.

Strategies for Enhancing Collaboration
- Security Champions: Appointing security champions within development and operations teams to advocate for security best practices
- Regular Security Training: Providing ongoing security training to developers and operations personnel to raise awareness and build skills
- Shared Responsibility: Promoting a culture of shared responsibility for security across all teams.
4. Integrating Threat Modeling Tools

Numerous tools are available to facilitate threat modeling within a DevOps workflow. These tools can automate various aspects of threat modeling, making it easier to identify and mitigate potential security threats.

Popular Threat Modeling Tools
- OWASP Threat Dragon: An open-source tool for creating threat models and visualizing potential threats
- Microsoft Threat Modeling Tool: Provides a systematic approach to threat modeling with pre-defined templates
- IriusRisk: A platform that integrates with CI/CD pipelines to automate threat modeling and risk assessment
5. Case Studies and Statistics

Integrating threat modeling into a DevOps workflow is essential for identifying and mitigating potential security threats before they become significant issues. Real-world case studies and statistical evidence can illuminate the tangible benefits of this approach. This section delves into notable case studies, such as the Capital One and Equifax data breaches, to underscore the critical importance of threat modeling and continuous monitoring in DevOps practices.

Capital One Data Breach

In 2019, Capital One experienced one of the most significant data breaches in recent history, exposing the personal information of over 100 million customers. The breach was caused by a misconfigured web application firewall (WAF), which allowed an attacker to access Capital One’s Amazon Web Services (AWS) cloud environment. This incident highlights several critical points about the importance of continuous threat modeling and monitoring in a DevOps workflow.

Capital One’s breach underscores the necessity of rigorous configuration management and monitoring. A misconfiguration, such as the one that occurred in this case, can have devastating consequences if not detected and corrected promptly. Continuous threat modeling could have identified this misconfiguration early, allowing Capital One to address the issue before it was exploited. Furthermore, regular security assessments and automated monitoring tools could have alerted the security team to the vulnerability in time to prevent the breach.

The Capital One breach also illustrates the importance of a comprehensive approach to security that includes not only technical measures but also organizational practices. By fostering a culture of security awareness and implementing robust security practices throughout the DevOps lifecycle, organizations can reduce the risk of similar incidents. Continuous threat modeling ensures that security is an ongoing consideration, rather than a one-time task, and helps to create an environment where potential threats are identified and addressed proactively.

Equifax Data Breach

The 2017 Equifax data breach exposed the personal information of approximately 147 million people, making it one of the largest and most damaging breaches in history. The root cause of the breach was an unpatched vulnerability in Apache Struts, a widely used web application framework. This incident highlights the critical need for integrating automated security scanning tools into the CI/CD pipeline, a key aspect of threat modeling in DevOps.

The Equifax breach could have been prevented if the vulnerability had been identified and patched in a timely manner. Automated security scanning tools, integrated into the CI/CD pipeline, can continuously monitor for known vulnerabilities and alert developers to the need for patches. By integrating such tools, organizations can ensure that their applications are always up to date with the latest security fixes, reducing the risk of exploitation by attackers.

Moreover, the Equifax breach emphasizes the importance of a proactive security posture. In a DevOps environment, where rapid development and deployment are the norms, it is crucial to have automated systems in place that can keep up with the pace of change. Continuous threat modeling and automated security scanning provide a means to do this, enabling organizations to identify and mitigate vulnerabilities as they arise, rather than after they have been exploited.

Statistics Supporting Threat Modeling in DevOps

Statistical evidence further reinforces the value of integrating threat modeling into DevOps practices. According to Gartner, “By 2022, 90% of software development projects will claim to be following DevSecOps practices, up from 40% in 2019.” This significant increase reflects a growing recognition of the importance of integrating security into the DevOps workflow. Organizations that adopt DevSecOps practices, including continuous threat modeling, are better positioned to identify and address security threats early, reducing the risk of breaches and other security incidents.

The State of DevOps Report 2021 by Puppet provides additional insights. The report indicates that organizations integrating security into their DevOps practices are 2.4 times more likely to detect security incidents before they cause significant damage. This finding underscores the effectiveness of proactive security measures, such as continuous threat modeling, in identifying and mitigating threats before they can have a detrimental impact.

A survey by the SANS Institute revealed that 64% of respondents experienced improved security posture after implementing DevSecOps practices. This improvement is likely due to the continuous nature of threat modeling and security assessments in a DevOps environment, which helps organizations stay ahead of emerging threats. By continuously updating threat models and integrating automated security tools, organizations can maintain a robust security posture that adapts to new challenges and vulnerabilities.

Benefits of Integrating Threat Modeling into DevOps

The case studies and statistics discussed highlight several key benefits of integrating threat modeling into a DevOps workflow:
- Early Detection of Vulnerabilities: Continuous threat modeling and automated security scanning tools enable organizations to identify vulnerabilities early in the development process, reducing the risk of exploitation.
- Proactive Security Posture: By continuously assessing and updating threat models, organizations can maintain a proactive security posture that adapts to new threats and vulnerabilities.
- Improved Security Awareness: Integrating threat modeling into DevOps fosters a culture of security awareness, encouraging all team members to prioritize security in their work.
- Reduced Risk of Breaches: Continuous threat modeling helps organizations identify and address security threats before they become significant issues, reducing the risk of data breaches and other security incidents.
Statistics
- According to a report by Gartner, “By 2022, 90% of software development projects will claim to be following DevSecOps practices, up from 40% in 2019.”
- The State of DevOps Report 2021 by Puppet indicates that organizations that integrate security into their DevOps practices are 2.4 times more likely to detect security incidents before they cause significant damage.
- A SANS Institute survey revealed that 64% of respondents experienced improved security posture after implementing DevSecOps practices.
6. Best Practices for Implementing Threat Modeling in DevOps

Implementing threat modeling within a DevOps workflow is essential to ensuring that security is embedded into the SDLC from the outset. By following best practices, organizations can maximize the effectiveness of their threat modeling efforts, leading to more secure and resilient applications. The following sections expand on the best practices for implementing threat modeling in a DevOps environment.

Early and Continuous Integration

Integrate Threat Modeling Early

The concept of ‘shift-left’ security emphasizes the importance of integrating security measures at the earliest stages of the SDLC. By incorporating threat modeling during the initial phases of development, potential security issues can be identified before they become deeply ingrained in the codebase. Early integration of threat modeling ensures that security considerations are a fundamental part of the design and architecture process.

Continuous Updating of Threat Models

Threat models should not be static documents that are created once and forgotten. Instead, they need to be living artifacts that are continuously updated to reflect changes in the application, infrastructure and the evolving threat landscape. Continuous updating ensures that the threat models remain relevant and effective in identifying and mitigating potential security threats.

Utilize Automated Tools

Automated tools play a crucial role in facilitating continuous threat modeling and security assessments. Tools such as OWASP Threat Dragon, Microsoft Threat Modeling Tool and IriusRisk can automate various aspects of threat modeling, making it easier to integrate these practices into the CI/CD pipeline. Automation helps ensure that threat modeling is performed consistently and efficiently, reducing the burden on development and security teams.

Collaborative Approach

Foster Cross-Functional Collaboration

Effective threat modeling requires close collaboration between development, operations and security teams. This cross-functional approach ensures that security is considered from multiple perspectives and throughout the entire development lifecycle. Collaboration can be fostered through regular meetings, joint workshops and shared documentation.

Appoint Security Champions

Appointing security champions within development and operations teams can help promote a security-first mindset. These individuals act as advocates for security best practices, ensuring that security considerations are prioritized and integrated into everyday workflows. Security champions also serve as points of contact for security-related questions and issues, bridging the gap between different teams.

Provide Regular Security Training

Ongoing security training is essential to keeping all team members informed about the latest threats, vulnerabilities and best practices. Training should cover fundamental security principles, specific threats related to the technologies being used and hands-on exercises in threat modeling and mitigation. Regular trainings help build a culture of security awareness and ensure all team members have the knowledge and skills needed to contribute to threat modeling efforts.

Leverage Automated Tools

Automate Threat Identification and Mitigation

Threat modeling tools can automate the identification and mitigation of potential security threats, making the process more efficient and consistent. Tools such as OWASP Threat Dragon, Microsoft Threat Modeling Tool, and IriusRisk offer features such as visualizing threat models, suggesting mitigations and integrating with CI/CD pipelines. Automation reduces the manual effort required for threat modeling and helps ensure that security assessments are performed regularly.

Integrate Security Scanning Tools into the CI/CD Pipeline

Integrating security scanning tools into the CI/CD pipeline allows for continuous vulnerability detection. Tools such as Snyk, Veracode and Checkmarx can automatically scan code, dependencies and configurations for vulnerabilities as part of the build and deployment process. Continuous scanning helps identify security issues early, providing developers with immediate feedback and allowing them to address vulnerabilities before they reach production.

Regular Reviews and Updates

Regularly Review and Update Threat Models

Regular reviews and updates of threat models are essential to ensuring their continued effectiveness. As applications evolve and new features are added, threat models must be revisited to account for these changes. Regular reviews should be scheduled at key milestones in the SDLC, such as before major releases or after significant architectural changes.

Implement Monitoring and Feedback Loops

Monitoring and feedback loops are critical to continuously improving threat models. By collecting data on security incidents, vulnerabilities and threat model effectiveness, organizations can gain insights into areas for improvement. Feedback loops should involve regular debriefs and post-mortem analyses to understand what worked well and what could be improved. This iterative approach helps refine threat models and ensures that they remain relevant and effective.

Metrics and Reporting

Track Key Security Metrics

Tracking key security metrics is essential for measuring the effectiveness of threat modeling efforts. Metrics such as the number of vulnerabilities identified and remediated, time to resolve security issues and the impact of security incidents can provide valuable insights into the security posture of the organization. These metrics should be tracked over time to identify trends and measure progress.

Use Metrics to Identify Areas for Improvement

Metrics can be used to identify areas for improvement in threat modeling and overall security practices. For example, if certain types of vulnerabilities are consistently identified, it may indicate a need for additional training or changes to development practices. Metrics can also help prioritize security efforts, ensuring that resources are focused on the most critical areas.

Demonstrate Value to Stakeholders

Reporting on key security metrics helps demonstrate the value of threat modeling to stakeholders. By showing the tangible benefits of threat modeling, such as reduced vulnerabilities and faster resolution times, organizations can build support for continued investment in security practices. Regular reporting also helps keep stakeholders informed about the security posture of the organization and any emerging threats.

What’s Next?

Implementing threat modeling in a DevOps workflow is crucial for proactively identifying and mitigating potential security threats. By following best practices — such as early and continuous integration, fostering cross-functional collaboration, leveraging automated tools, regularly reviewing and updating threat models and tracking key security metrics — organizations can enhance their security posture and build more resilient applications. As the digital landscape continues to evolve, the importance of proactive security measures like threat modeling cannot be overstated. By embedding security into every stage of the SDLC, organizations can ensure that their applications remain secure and resilient against emerging threats.
July 18, 2024
Where to Start With Secure Design – Tips for Developers

Designing secure software is an increasingly hot topic, and for good reason. In recent weeks, we’ve seen a global effort from governments and cybersecurity agencies to encourage security by design through new guidance and changes to procurement rules. During the G7 in May, the QUAD nations (Australia, India, Japan and the United States) released a set of Joint Principles for Secure Software. In the U.S., there are even plans for legislation to make software makers liable for the security of their products. The need for software to be made secure at the design phase has been spotlighted further by recent cybersecurity incidents such as the hack by ransomware group CLOP that exploited flaws in MOVEit software.

But secure design is not a part of every developer’s skill set, and it’s not on the syllabus of every coding course. If you’re brilliant at writing code and keen to know more about how you make that code secure, where do you start?

Here are five tips from former DevSecOps and threat modeling engineer Fraser Scott, now IriusRisk’s VP of product:

1. Get to Know the Threats

To be able to design secure software effectively, you need to understand the threats. A great starting point is the OWASP Top 10. OWASP aims to identify the most critical security risks to web applications. Top of that list is broken access control, and insecure design itself sits at number four. Understanding the biggest risks is the first step towards mitigating them in software development.

2. Try Threat Modeling

The foundation of secure design is threat modeling, which is the process of identifying and mitigating plausible security threats. In its simplest form, this is about looking at your software design and asking Adam Shostack’s four questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

The OWASP Top 10 gives you a sense of what the risks might be, and threat modeling is the process of identifying them in your design. See if any of those top ten risks might impact your design, consider what could go wrong and work out what you can do to mitigate it. Before you start writing any code, consider whether you’ve done a good enough job to make the software secure. The sooner you find design issues, the cheaper and easier they are to fix.

3. Connect With a Community

There are plenty of communities of people out there grappling with the same challenges that you are. Experts in security and threat modeling and developers are coming together to discuss and try to solve some of the key challenges in secure design. One such community is Threat Modeling Connect, where people use the forum to share ideas and discuss issues. Experts also host webinars and write blogs. The community also held its first-ever conference in October. There is also a community dedicated to threat modeling on Reddit, and the OWASP Slack has a #threat-modeling channel.

4. Experiment With Automation

Companies who are developing software on a large scale use tools to automate the threat modeling process. IriusRisk makes a community edition of its automation tool available for free, for life, to people who want to give threat modeling a try. As someone who is starting out in secure design, using a tool like this, which generates many of the relevant threats and countermeasures for you, is a great way to experiment with your first threat models. And we’re not the only ones; you can also use the OWASP Threat Dragon and Microsoft’s Threat Modeling for free.

5. Build a Library of Secure Code

One shortcut to secure design is using existing secure design patterns and road-tested components. As you develop software, keep a library of secure code that has been threat-modeled and scanned using application security testing tools that you can return to in the future. The Threat Model Cookbook on Git Hub has some sample threat models you can use as a starting point.

November 17, 2023
Threat Modeling as a DevSecOps Practice

Software engineers are always under pressure to build more software, faster. At the same time, there is increasing regulatory and market pressure for secure software that meets users’ and regulators’ requirements for data privacy. This dynamic often puts software engineers at odds with application security or product security teams.

In fact, 81% of developer teams at large enterprises have launched applications that feature insecure code, according to one researcher, with half doing this on a regular basis. The firm argued that developers and security architects need a better relationship, and I couldn’t agree more.

These technical teams are working towards the same goal, so it’s in everyone’s interests—particularly senior leadership—to create a more cohesive working environment by breaking down barriers between teams. If the security of a system is designed and enforced by an external security team—disconnected from the rest of the engineering team—then this only reinforces security as a separate silo. But companies can ease tensions by embedding the responsibility for security in the engineering teams themselves: This is the thinking behind DevSecOps. Thinking about security starts when engineers think about solving the problem: At design time.

While the shift left movement was born two decades ago with the goal of ensuring product testing happened early in the development stage, I believe we need to start left to make real change. In adopting this culture, security and privacy will be less of a bolt-on afterthought and a built-in fixture within the development process, ensuring that engineers and security teams alike are aligned and have visibility of each other’s objectives.

By reimagining the build, test, fix, build, test, fix cycle through building an architecturally secure design in real-time, technical teams can detect software vulnerabilities sooner rather than later, which means more efficient product deployment. This is where the process of threat modeling as a business tool can be of great benefit.

Historically, threat modeling was a static, slow and manual process conducted on whiteboards, as part of a workshop led by a third-party security expert who lacked institutional knowledge of the inner workings of the company. However, this has evolved dramatically into an easily implemented, automated security practice that can be baked into the development and security cycle from the outset, empowering organizations to start left.

Through automated threat modeling, the security workload burden is relieved for both security architects and engineers. Companies are, in turn, better positioned to keep pace with the cadence of ongoing software rollouts, as an automated platform suggests security improvements as an application evolves. The launch phase bottleneck that’s typically created during the testing stage is therefore removed, as security requirements are identified prior to development—which means that risk is managed before a line of code is even written. Based on this, it should quickly become apparent what a time- and cost-saving exercise threat modeling is.

No developer or security specialist wants a flawed product to hit the market, so it makes good business sense to adopt a new approach that will lead to better outcomes. Enterprises that introduce threat modeling as part of their development and cybersecurity processes will be on course to embed a true DevSecOps system within the company, transforming the relationship between these two departments.

In my experience, culture and growth are the key factors for enterprises that decide to adjust their cybersecurity diet to include automated threat modeling. Convincing the app dev teams to invest time into the process is, by far, the most significant cultural hurdle to overcome, because they need to witness the benefits—and up until this point they’re disconnected from the AppSec process.

Once equipped with the tools and knowledge, delivering secure design will be second nature to developers and a new collaborative culture will be created. In essence, the more teams are given oversight of and accountability for software design flaws, the easier it is to recognize how vital these preliminary checks are.

Likewise, there comes a stage of business growth when the ‘security first’ and ‘start left’ mindsets are essential to keep enterprise project management on track—and this ties into the culture. As the rate of scale within a company begins to increase and the pace of software deployment must quicken in line with customer demand and market competitiveness, discovering flaws at the end of the design process just isn’t an option.

With developers and security teams responsible for vast amounts of code, product resilience on delivery is crucial and ensuring a robust DevSecOps culture is the route to success.

June 17, 2022
Game On: Secure Coding Virtual Summit 2021
Agile organizations are looking for ways to win at security without slowing down their release cycles. That’s where DevSecOps comes in. The days of a hands-off security approach for developers are over. Organizations implementing DevSecOps to integrate security into their DevOps framework are able to release secure software faster. Developers test code for potential security vulnerabilities earlier in the pipeline to fix security issues in real time to avoid costly delays.

At Secure Coding Virtual Summit 2021, industry-leading AppSec and DevSecOps practitioners, analysts and visionaries will come together to share their best pro tips and power ups to level up your code security. The agenda for the virtual event, taking place March 24 from 10 a.m. to 6 p.m. ET, features a mix of topics including AppSec, threat modeling, API security, container security, case studies and more.

The most brilliant security luminaries from OWASP, Okta, Microsoft, Secure Code Warrior, WhiteSource and many other well-known IT companies, will discuss:
- How to level up your secure coding strategies
- How to run an AppSec program with open source projects
- The best practices for securing your APIs, the attack surface of an API and common authorization problems
- The concept of threat modeling, its objectives and its role in the SDLC
- How to transform developers into security people
- How easy (or not) it is to get a container or Kubernetes cluster hacked on purpose
- How to create an AppSec pipeline with containers in a short period of time (demo)
This year’s Secure Coding features outstanding industry leaders, such as:
- Vandana Verma Sehgal, global board of directors at OWASP
- Simone Curzi, cybersecurity principal consultant at Microsoft
- Keith Casey, API problem solver at Okta
- Matias Madou, CTO and co-founder at Secure Code Warrior
- Matthew Coles, senior principal product security engineer at Dell
- Sarah Young, security architect at Microsoft
- Chris Romeo, CEO and co-founder at Security Journey
- Dr. Phillipe de Ryck, web security expert and founder at Pragmatic Web Security
- Richard Greenberg, founder and CEO at Security Advisors LLC
- Izar Tarandach, principal security engineer at Squarespace
- Jeroen Willemsen, principal security architect at Xebia
- Shiri Ivtsan, director of product at WhiteSource
- Justin Hutchings, director of product management at GitHub
- Matt Tesauro, senior partner at 10 Security
- Matthew Butler, principle engineer at Laurel Lye
Attendees will have access to useful resources and will be able to interact with sponsors to power up their secure coding strategies. There will be live Q&A chats with keynote speakers to get your burning questions answered. Attendees will also have the opportunity to hunt for Easter eggs to boost their player score for a chance to win a PlayStation 5.

To see the full agenda and to register, please visit the Secure Coding website.
March 1, 2021
How to Secure the Intangible — Cloud Native Security in the New Age
People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.

Companies aren’t interested in managing IT; they’re more interested in results. They want to deliver software quickly and focus on their core product or service. This is where the concept of cloud native computing comes in—and why securing it has become critical.

Traditionally, companies had many servers and resources. Today we’re moving toward a simpler reality. Developers are focusing on what’s needed to deploy business logic, regardless of what it’s deployed on. That’s why it’s particularly appealing to move to software without the server and the added complex management of IT overhead.

If a company can push its offerings without hardware, patch management, storage and so forth, and it can do it more affordably and faster, it’s a great win.

The Paradigm Change

2012 was the golden age of IT, where admins ruled the world and developers got in line. Moving from that era to 2016, we come to the age of the cloud, where developers were kings.

For many years, the IT department led—and perhaps stifled—innovation within organizations. Developers’ paths for innovation were limited to the area which they had control, i.e., the application layer. Anything beyond that was the IT department’s call. This included hosting, load balancing, database management and whether to adopt virtualization or advanced networking technologies.

With the emergence of NFV and cloud computing, that changed. There has been a continuous erosion of the abstraction layers that developers were faced with in the past. In 2020, developers are the masters of their own destiny, pushing their organization toward innovation. All of this is possible not only due to virtualization and cloud computing, but also to the relative simplicity of a developer setting up a full application stack on their own laptop.

In many organizations, the CTO focus has moved from an infrastructure orientation to an application focus. Developers are the new golden children of these organizations. They hold the keys to increasing company profits.

What Cloud Native Brings to the Table

There are many numbers being thrown around about the efficiency of cloud native. Whether it’s 300% reduction in deployment time or a mere 30%, the reality is that the time savings are huge. Many developers will never see a traditional data center again in their lives. In fact, new applications are developed as microservices or at the very least as containers, simply because they’re faster.

There’s no going back. This new approach enables developers to invest in scalable solutions without making companies preallocate unnecessarily large sums of money. Both applications and infrastructure can scale up or down quickly, using the right amount of resources to provide the best service.

Businesses that are seasonal or peak-oriented gain a lot from the movement to cloud native architecture. Users also stand to gain from the move, as they receive the best service possible, without downtime. Everyone comes out on top.

A Look at the Future

This movement to broader use of cloud native architectures is a trend that will continue to grow over time.

By 2025, VMs and bare metal will be as anachronistic as mainframe and token ring networks are today. In fact, most medium-to-large organizations already have some kind of a migration project from VMs to containers in progress. Many developers don’t need to spin up VMs anymore, since they can have a whole application stack running on their laptop using containers. When they are done, they simply lift and shift it to staging and production environments.

In addition, on-premises and cloud environments are becoming a single entity rather than two separate infrastructures. People used to think that the entire data center was going to move to managed clouds for economical reasons. Today, however, most deployments are becoming hybrid. Organizations are opting to keep some of their on-prem systems (mostly legacy applications that cannot be easily moved to the cloud). IT administrators are starting to think about the deployment in the cloud as an extension of the on-prem data center rather than a separate network that needs to be managed.

This trend will most likely continue, making it all the more important to understand the changing expectations around how to secure the hybrid network environment. The rate of change for cloud native environments is monumentally faster than on-prem, initiating code in milliseconds.

Most legacy solutions weren’t built to cope with ephemeral networks and compute entities that go up and down within seconds, one million times a day. So, what’s the best way to future-proof risk management in this ever-changing environment? There is no singular answer, but in general prevailing advice suggests you consider the long view, exploring the options best suited for your approach and then look at each through a one, three and five year lens.

Cloud Native Security

When thinking about the future of security, the basics stay the same and the threat modeling concepts stay the same. However, there are a number of security issues to consider, including policies, permissions and authorizations. As networks are converging, the security tools are as well. Looking forward, only solutions that can provide a genuine single pane of glass to control your digital estate will have a real impact on security.

When looking at solutions to help apply security to cloud native architectures, ask the following questions:
- Can I improve visibility in my cloud service? Applications may be deployed over multiple cloud instances and on servers in different sites, and even different regions, making it more difficult to define clear security boundaries. The right tool can help you to understand the scope and layout of your cloud resources, particularly if it automatically discovers applications on your cloud deployment and maps the data flows between them, making it easy to understand applications that you have running in the cloud and how they interact with one another.
- Can I achieve a single view of multiple environments? The tools used to apply security need to adapt to be able to control hybrid networks across on-prem and multicloud organizations. For example, if your architecture requires policies to be deployed to the edge, how is it managing convergence? Numerous network solutions are barely aware of layer 7 process level, let alone containers.
- Can I set and maintain policies across these environments? Consider how solutions address network policies and understand potential challenges from both a technical and procedural point of view. Securing application traffic within cloud native architectures or between applications and external networks is a good start, but in the cloud, it’s necessary to implement micro-segmentation so you can define policies at the application level. By defining which applications are allowed to interact and the types of interactions that are permitted at a granular level, it’s possible to provide the level of security necessary for applications operating in the cloud. Look for tools that provide automatic policy recommendations that can be effectively applied on any cloud infrastructure, streamlining your organization’s security policy for deployments.
- Can I future proof my cloud native security posture? When planning your future roadmap, think about what your network is going to look like. What type of workloads and network constructs are going to be used? Make sure the security vendors you select provide full coverage for your roadmap.
When implemented correctly, modern micro-segmentation techniques can offer a simple way to secure a cloud native environment, including solving the unique challenges of containers and providing the ability to create dynamic application policies down to process level. Look for tools that provide a single view and foundational visibility, automatically discovering all network flows and dependencies. This allows your business to take advantage of the best of serverless computing without increasing risk or complexity for security.
May 15, 2020
How to Secure Online Coding Platforms
Threat Modeling for Online Coding Platforms

The evolution of DevOps teams and a greater reliance on cloud-based computing has completely changed the coding process. Now, with Integrated Development Environments (IDEs), coding can be done entirely online. This is convenient, but are online IDEs secure? To answer this, we will focus on two popular cloud-based IDEs: AWS Cloud9 and Visual Studio Online.

In online coding, the IDE is rendered inside your browser, the browser JavaScript engine uses WebSockets to initiate an Secure Shell (SSH) connection to your linked device in the background—e.g. virtual private server (VPS)—providing you with the familiar terminal interface to execute commands. The environment—meaning the linked cloud VM/VPS or SSH-accessible device—includes tool configurations (like which tokens are included, or cloud configuration files), a copy of the source code, compilers and other tools that you want to use.

Figure 1. Local versus cloud-based IDE. Source: Trend Micro.

The main difference between local and cloud-based coding platforms is where the bulk of the environment resides. In cloud IDEs, the environment is a virtual machine instance inside your cloud provider. In terms of security, this means you are delegating trust to the cloud provider, but you are responsible for preventing any backdoors from opening or introducing misconfiguration issues to the VM. In the case of using your own device with AWS Cloud9, you are responsible for configuring the device securely.

Linked Devices/VMs Are Not Always Secure

What is running on the backend often dictates whether linked devices and VMs are secure. As previously described, an SSH-linked device is necessary to use these online coding platforms. In the case of Visual Studio Online (still in preview mode as of this writing), we can find a Visual Studio (VS) Code server running on the machine.

The code server itself is a Node.js application to which your browser will connect. You can also download the whole ~/.vscode-remote folder and run the server inside your local environment.

As the owner of the linked device, you have permission to promote yourself to root and install or configure whatever you think you will need. You also have, by default, both Docker and Git pre-installed.

In the case of AWS-hosted Cloud9, the situation is a little more complicated. The backend necessary for platform communication is located inside the linked device while the frontend remains hosted on a different location. But, like in VS, you can also promote yourself to root.

This brings us to our first security concern: How secure or private are linked devices/VMs?

The linked device contains confidential information—access tokens, application configurations, source code, etc., which should be protected against unauthorized access.

By default, the platform is secured by the provider. However, you should keep in mind that, together with your root access availability, you are also responsible for preventing misconfiguration issues, especially when using third-party plugins. AWS does not provide plugin support for plugins not developed by them.

There are possible misconfigurations you might make that can lead to security issues. For example, if you set your IDE to be accessible from outside, either intentionally for ease of sharing, or unintentionally, that change can have major consequences.

In addition, it is not common for access tokens to be stored in encrypted token vaults. A lot of them can be viewed via plaintext configuration files. Without additional security measures, your access tokens can end up exposed to outsiders.

Once unauthorized access is acquired by cybercriminals, they can compromise your code for their own gain. An example would be the supply chain attack against a software company that modified software updates with malware.

Browsers Can Introduce Malicious Extensions or Vulnerabilities

The next security concern is the browser itself. As online coding platforms are accessed from web browsers, you should be very careful when accessing these sites from public, non-domain, shared or unprotected computers.

Malicious browser extensions are a well-known phenomenon. While an untrusted computer possibly infected with malware presents an obvious risk, it is also possible for an attacker to steal code using a malicious web browser extension.

Code Extensions and Plugins Can Also Contain Malware

The main advantage of Visual Studio Online and, generally, the VS Code platform, is the number of extensions available. This in and of itself is yet another possible attack surface.

Let’s imagine a malicious VS Code extension—a useful-looking extension with an embedded backdoor. The lack of permission checking (such as disk access, network access, process access, etc.) for extensions during installation or use, becomes a security problem. The extent of security checks during extension publishing is limited to having a valid publisher ID and a few image-related restrictions. This means you have to trust the extension developer entirely.

No Software Application Is Error-Free

The ever-present possibility of vulnerabilities in any kind of software must be considered as well. In the case of online coding platforms, they can be affected by web-class vulnerabilities since IDEs are web applications. For example, a vulnerability that allows an attacker to execute their own JavaScript code can have control of the IDE or remote linked devices.

A recent vulnerability affecting the Visual Studio Live Share extension, which is also available for VS Code, shows that we can expect to see another vulnerability affecting online coding platforms in the near future.

Securing Cloud IDEs Is a Must for DevOps

Threat modeling allows us to understand the different factors at play that can affect the overall security of a computing environment. Cloud IDEs should be no different from other software, if not more critical to secure.

Here are some recommendations for each of the security issues we raised:
- For linked device security — Install trustworthy software. Keep that software updated. Don’t indiscriminately open ports to the internet.
- For browsers — Work inside trusted and secured environments. Try to avoid using shared computers. Install browser extensions from trusted vendors only.
- For VS Code extensions — Avoid installing extensions from unknown sources or authors.
- For vulnerabilities in general — Make sure your environment is updated to the most recent version.
— David Fiser
April 1, 2020
What Developers Must Know About Threat Modeling
Threat modeling is a process that far few developers seem to pursue, but it is a process that helps you and your team to model all potential threats to your application. Essentially, threat modeling is your thinking through all of the potential threats against an application. Doing so is virtually as easy as putting together a list of threats in a structured manner that lets you assess any perceived risks, allowing you to formulate how you are going to respond to the threats.

Ultimately, through threat modeling, you are optimizing network security by identifying objectives and vulnerabilities and creating measures to prevent the effects of threats to the system. Through this definition, anything described as a threat has the potential to be malicious to your organization and data systems; for example, incidental occurrences like the failure of a storage device–which can compromise the integrity of the entire enterprise.

The reasons for threat monitoring may be pretty obvious, but any lack of progression here is quite common.

Threats are one of the significant factors that led companies to spend $89.1 billion on enterprise security solutions. Gartner predicts threats will reach $96.3 billion by the end of 2018. According to Raytheon’s 2018 Study on Global Megatrends in Cybersecurity, 36% of senior IT and cyber professionals identified malicious or criminal insiders as a top cyber threat. Even with that knowledge, many organizations lack insider threat policies and policy enforcement tools, and they struggle to align security and IT responsibilities to tackle the threat effectively.

Threat monitoring allows you the ability to determine which threats might exist for your application. Knowledge is power, and it’s always better to know beforehand what dangers might await you. Understanding these threats lets you decide whether you will accept the risk.

For a threat to exist, there must be a combination of the following where the combined likelihood and impact are significant enough in which to do something. A framework for understanding threat modeling, includes: asking what you are working on, what might go wrong and what to do about it, as well as if a job is well done.

According to the Open Web Application Security Project (OWASP), threat modeling is a process that lets you continually refine your processes based on what you have done so far: “Starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a consequence. Therefore, it’s generally best to start with the factors that make a lot of difference.”

Those steps include assessment scope, identity threat agents, existing countermeasures, identifying vulnerabilities, prioritizing identified risks and identifying countermeasures to reduce the threat.

In the assessment scope, you’ve got to understand the price of what’s at stake. Identifying tangible assets, such as databases of information or sensitive files, is usually straightforward, and realizes the capabilities provided by the application.

Next, identify possible threats or attacks. A crucial part of the threat model is characterizing different groups of people who might be able to attack your application–this may include insiders and outsiders, performing both inadvertent mistakes and malicious attacks. During this phase of development, consider existing countermeasures that allow you to determine what possible exploitable vulnerabilities exist that must be addressed. Through your search, look for weaknesses and connect any attacks you’ve identified to the negative consequences you’ve identified.

When identified, risk management can be prioritized. For each threat, determine possible outcomes and the impact of those to understand how to mitigate these issues. Next, look for ways to reduce any future risks.

While many of the threats might appear to be security related, many others have more natural explanations. Threat assessments can include power outages or even a flooded server room. These and other factors can lead to severe threats to your organization.

When to Model the Threat?

Threat modeling is often best at the beginning of a project, but it’s better to conduct a threat modeling project halfway through a project or even at the end than not at all. Threat modeling at the end of a project can have benefits, such as understanding the architecture and how data flows through it. However, threat monitoring at the end of a project can lead to finding more work may be required to fix poor design decisions not caught at the beginning.

For those entering into threat modeling, conduct your first session on an existing project, letting you experiment with a threat modeling session so that you can familiarize yourself with everything required. This way, you’ll be better prepared to analyze all assets and flow of data to assess the risks. Once the process is pounded out, you’ll have a better chance of succeeding in your threat modeling of a new project. You’ll also be able to better prepare for threats that may exist in the design phase of the project. From here, over time, you’ll begin to take into account threats during the initial design of a new feature.

Approaching the Threat Model

Each method of approach depends on the organization and its goals. Large organizations usually have previously established processes for threat modeling. Smaller organizations new to threat modeling can begin by hiring in experience to initiate the task or seeking outside support from experts or those who can advise the program.

Next, you need to understand who the users are within the system–regular users, administrators, outsourced contractors and perhaps hackers with apps or other tools looking for vulnerabilities within your network. There are also other actors, including disgruntled former employees.

Defining the user actors is important since missing a group can mean you might be missing an entire category of threats. Also, consider the various types of hackers or groups of hackers in your models.

Data and Information Flows

At this point in the threat modeling process, track each of the various data flows running through the system. For each of these, you need to know where the data goes. What does it interact with or encounter along the way? Then look to identify where data can leak or where it might be exposed. More data components create more opportunities for a hacker to gain access to the information.

Individual data means the information flows differently based on the architecture and the specific situation. One example might include a request from a user’s browser where the cookie is sent through and interacts multiple components as it does.

For each data flow, search opportunities for any actors to gain hold of valuable information. If anything makes you frown, step back through the process and move that threat through until you can mitigate the frowning moment.

Threat List Complete

When the threat list is observed and complete, prioritize the list from very unlikely to improbable to not likely. No matter the probability of the risk, work through the risk as a real possibility. Do so to consider the real impact of the threat and what it may mean to the organization. Is the company going to crash and burn completely? Will every bit of data get pulled into a ransom situation? Place a number or priority of the impact, such as low, medium and high.

When you have your risk list, manage the risks by:
1. Accepting: If the risk is quite low, accept the potential impact. It’s also possible you’ll find the potential negative user impact is more important. You can also reassess later.
2. Transferring: Perhaps another team is responsible for managing a particular risk. If that team can pick up the defense easily, outsource it.
3. Avoiding: Don’t do this. If you must, consider complete structural changes to your data flows to avoid altogether avoiding risk. This might mean architectural changes are required or killing a particular feature altogether so as not to avoid danger.
4. Reducing: Take actions to lower the risk by lowering the likelihood or impact of the risk. You may need to take multiple steps to reduce the threat. No matter the action, effort is required to reduce the risk.
After threat modeling is complete, don’t stop. Keep working because threats and actors change. List all potential issues or risks that must be addressed and work them into your plan.

Finally, remember you should be careful with whom you share your threat modeling plan. You never know where that information might end up otherwise, or who might be a threat to your organization and its data.

One last note: The final result and usefulness of threat modeling depend almost entirely on the parameters established. Defining the values for the probability of a threat and impact may be subjective, but let your experience, input from colleagues and experts, and your gut guide you.

— Jeroen Boks
October 14, 2019