I remember a project where, after a year, an old vulnerability that had been clearly identified during our initial workshop reappeared. Why? Because our threat modeling remained a snapshot in time, with no follow-up.
That's when I realized the importance of continuous threat modeling. Not just a workshop at the beginning, but a living process, integrated into the development cycle, which evolves with the project.
Integrating Threat Modeling into Everyday Life
15 minutes to secure a User Story
CI/CD integration is essential for catching regressions, but the best defense is still to avoid introducing the flaw in the first place.
Before you start coding a new feature (for example, a user data export), take 15 minutes with the Product Owner and a developer for a "mini-TM." No need for complex tools or UML diagrams: a whiteboard or sheet of paper will suffice.
Quickly map the data flow and ask yourself three simple questions, inspired by STRIDE:
- Spoofing: Who can launch this export? Is it verified on the back end?
- Tampering: Can the export settings be manipulated via the URL or the body of the request?
- Information Disclosure: What data is exported, where does it go, and who can see it?
This ritual allows concrete security requirements to emerge very early on, such as:
- The user ID must come from their session token, not from a client parameter.
- The export must be logged and validated on the server side.
- Column filtering or masking must be implemented if sensitive data is involved.
This approach avoids relying solely on end-of-line testing. Above all, it empowers the product team to identify risks early on.
The threat model is useless if it does not lead to verifiable requirements, and this also allows it to be integrated into the daily lives of developers, code reviews, and CI/CD pipelines. For example, by using tools such as Semgrep or Checkov to automatically detect risky code patterns identified during the initial workshop.
Let's take a demanding regulatory context: **a web application/API within a PCI-DSS scope**, with online payment, card management, and a publicly exposed Angular front end.
Here are some requirements from Threat Modeling that can be verified automatically:
| Threat identified | Requirement | Technical implementation |
| PAN (Primary Account Number) leak in application logs | Systematic masking of sensitive data in traces | Semgrep rule on logger.*(".*[0-9]{13,16}.*"), integration testing + mock logs in CI |
| Low segregation of roles on refund APIs | Strict RBAC/API Gateway control over critical operations | Infra scan with Checkov + POST /api/refund call test as a standard-level user |
| Failure to verify compliance with HTTP security headers (CSP, HSTS, X-Frame-Options) | Mandatory presence of a complete set of security headers in all public HTTP responses | Test in the CI/CD pipeline with curl -I + script to validate expected critical headers |
| Unfiltered outgoing calls from application containers | Detection and restriction of unnecessary outgoing communications | Analysis of the K8s manifest with OPA + runtime testing via output proxy in audit mode |
And in terms of code, it could look like this:
Checking HTTP headers (excerpt from .gitlab-ci.yml)
security_headers_check:
image: curlimages/curl:latest
script:
- |
curl -I https://monapp.exemple.com > headers.txt
grep -q "Strict-Transport-Security" headers.txt || (echo "HSTS missing" && exit 1)
grep -q "Content-Security-Policy" headers.txt || (echo "CSP missing" && exit 1)
grep -q "X-Frame-Options" headers.txt || (echo "X-Frame-Options missing" && exit 1)
only:
- merge_requests
Semgrep test on sensitive logs
# .semgrep.yml
rules:
- id: log-pan-detection
patterns:
- pattern: logger.$METHOD("$MSG")
- pattern-regex: ".*[0-9]{13,16}.*"
message: "PAN potentiellement loggé"
languages: [python, java, javascript]
severity: ERROR
And in the pipeline:
semgrep:
image: returntocorp/semgrep
script:
- semgrep --config .semgrep.yml
allow_failure: false
It's a bit like having a constant reminder: "Hey, remember, this part of the code is sensitive, be careful." And if a new threat is identified, we update the rules, adapt the tools, and continue to learn and improve.
Governance and compliance: a significant bonus
This model aligns perfectly with **OWASP SAMM (Design/Threat Assessment)**, and also meets **ISO 27001 / PCI-DSS / GDPR** requirements. Each automated control becomes proof, an indicator, a guarantee of maturity.
No need to defend your model at the next security review. You show the logs. You show that it's in the pipeline. You show that it's running.
Conclusion
Threat modeling should not be a static artifact, forgotten in a corner. It is a strategic lever, a guide for architectural choices, a bridge between business, technology, and security.
By reconnecting it to the daily routine of delivery—through automated controls, dynamic rules, and continuous vigilance—you restore it to its rightful place: that of a co-pilot. Discreet but essential.
*References:*
- OWASP Threat Modeling: https://owasp.org/www-community/Threat_Modeling
- SAMM: https://owaspsamm.org/model/design/threat-assessment/
- Gitleaks: https://github.com/gitleaks/gitleaks
- Checkov: https://www.checkov.io/
- Semgrep: https://semgrep.dev/
- PCI-DSS v4.0: https://www.pcisecuritystandards.org/
