# Threat Modeling Developer Behaviour: The Psychology of Bad Code - Tanya Janca

## Executive summary

Security vulnerabilities are often predictable patterns of human behavior rather than purely technical flaws. The talk advocates for shifting AppSec focus from merely enforcing secure coding standards to understanding and modifying developer psychology using principles from behavioral economics. Key strategies include setting 'secure defaults,' embedding security activities into every phase of the SDLC, and implementing cultural changes (like community practices) to make secure development the path of least resistance.

## Key takeaways

- The Shift from Intentions to Defaults: Since 'secure intentions' require constant effort and willpower, organizations should implement 'secure defaults.' This means structuring tools and processes so that the secure path is the automatic, easiest choice (e.g., using an ORM framework that enforces parameterized queries instead of allowing raw SQL concatenation).
- Addressing AI-Generated Code Risks ('Vibe Coding'): A major risk is 'vibe coding,' where developers rely on AI to write nearly all the code without thorough manual review. Mitigation requires using Retrieval Augmented Generation (RAG) servers that reference secure internal guidelines and enforcing mandatory human code reviews.
- Systemic Process Improvement: Instead of blaming individuals, security failures should be viewed as systemic issues. Solutions must involve embedding security activities (like threat modeling) into requirements gathering and design phases, making it a continuous part of the SDLC.
- Behavioral Nudges over Mandates: Effective change comes from 'nudges'—subtle changes in environment or process that guide behavior without restricting options. Examples include automatically enrolling employees in retirement plans (opt-out) or adding documentation debt to sprint reviews.

## Technical details

- Cognitive Biases & Shortcuts: Common insecure behaviors are linked to biases such as: **Automation Bias** (over-trusting AI output), **Present Bias/Hyperbolic Discounting** (prioritizing immediate deadlines over future security risks), **Authority Bias** (assuming code from popular forums like Stack Overflow is safe), and **Tragedy of the Commons** (neglecting shared resources like documentation or refactoring).
- Secure Development Lifecycle (SDLC) Integration: Security activities must be integrated into every phase: **Requirements Gathering** (defining security requirements), **Design** (conducting threat modeling/whiteboarding), **Coding** (using IDE tooling to flag risky functions), and **Testing** (making unit tests a gating requirement in CI).
- Tooling & Automation Checks: Recommended technical controls include: **Pre-commit hooks** that scan for secrets/hashes; **Static Analysis Tools** and **Linters** to flag missing error handling or poor quality code; and **CI/CD checks** that can block merges if unit tests fail.
- Secure Coding Practices: Developers should prioritize using Object Relational Mapping (ORM) frameworks to enforce parameterized queries, avoiding manual string concatenation of user input into database queries.

## Practical implications

- Implement secure defaults in development tooling and frameworks to make the safe choice the path of least resistance.
- Mandate security review checkpoints (e.g., threat modeling) at the start of design phases, not just at the end.
- Integrate automated checks (pre-commit hooks, CI/CD gates) that enforce code quality and test coverage before merging.
- Shift training focus from memorizing vulnerabilities to fostering behavioral change through community practices and positive reinforcement.

## Topics

Behavioral Economics, Threat Modeling, Software Development Lifecycle (SDLC), Secure Coding Practices, Cognitive Bias Mitigation, CI/CD Security, OAS Top 10, securemyvibe.ca

Source: https://www.youtube.com/watch?v=F0TTj2zeBM0