Summary of Making the OWASP top ten in the vibe code era

Overview of Making the OWASP top ten in the vibe code era

In this episode of the Stack Overflow Podcast, Ryan Donovan talks with Tanya Janka about the latest OWASP Top 10 update, how the list is built, and why software security is shifting in the age of AI-assisted “vibe coding.” The conversation covers the new categories added to the list, why some old issues dropped off, what data OWASP relies on, and what developers should do today to reduce risk across the software supply chain and in error handling.

What changed in the OWASP Top 10

Tanya explains that OWASP actually updates the Top 10 every three years, not every year, because collecting trustworthy data is difficult.

Major changes in the latest list

• Software supply chain replaced the narrower category of “using outdated and vulnerable components.”
  • This broadens the focus from package updates to the full development ecosystem:
    • IDEs
    • CI/CD systems
    • code repositories
    • dependencies and maintainers
• Mishandling of exceptional conditions replaced the vague bucket of “poor code quality.”
  • Tanya argues that “poor code quality” was too broad to be actionable.
  • The new category focuses on concrete failures like:
    • bad error handling
    • unsafe recovery behavior
    • failure to close securely
    • weak resilience in the face of unexpected conditions

What fell off the list

• Some older items, like cross-site scripting, no longer appear as separate entries.
• Tanya frames that as a success: the industry improved enough that some vulnerability classes became less dominant.

How OWASP gets its data

A major theme of the interview is that OWASP security rankings are only as good as the data behind them.

Main data sources

• Anonymized reports from penetration testing shops
• Data from static analysis and dynamic analysis vendors
• Community input on what risks are showing up in real systems

Why OWASP uses CWEs instead of CVEs

• OWASP tracks CWEs (Common Weakness Enumerators), which describe vulnerability patterns.
• They do not mainly use CVEs, which describe specific vulnerabilities in specific products.
• This makes sense for custom software, where the same weakness can appear in many unique codebases.

Data Tanya wishes OWASP had

• Postmortem reports from real security incidents
• Better insight into:
  • how the vulnerability was introduced
  • whether it came from a human developer, AI assistant, copied code, or dependency
  • what actually happened during an attack

Her point: lots of organizations don’t even know when they’ve been attacked, let alone have clean incident data to share.

Practical advice on supply chain security

Tanya spends a lot of time on how teams can reduce dependency and package risk.

Dependency management recommendations

• Avoid blind auto-update
• In development, update dependencies that are at least 7 days old
  • This gives time for malicious packages to be detected and removed
• Test updates before promoting them
• Pin versions after validation
• Check in a lock file
• Promote the pinned version up the delivery chain to avoid surprise changes

Tooling she recommends

• Software Composition Analysis (SCA) with reachability
  • Not just “this dependency has a vulnerability”
  • But “is the vulnerable code actually reachable from your application?”
• Dependency health tools
  • These look beyond known CVEs and assess project health:
    • number of maintainers
    • activity level
    • whether the project looks abandoned or at risk of takeover

Why this matters

She points to examples like malicious dependency takeovers and maintainer burnout, arguing that open-source infrastructure is often maintained by volunteers while being relied on like professional-grade production software.

Error handling, logging, and secure coding basics

A big portion of the conversation is about how bugs and attacks often meet in the same place: bad exception handling.

Tanya’s core guidance

• Always handle exceptions
• Don’t catch and ignore errors
• If a transaction fails, roll it back and start over
• Prefer fail closed, not fail open
• Log useful security events:
  • timestamps
  • attempted action
  • success/failure
  • validation and control outcomes

Why this matters

• Attackers and pentesters often use fuzzing to explore how apps respond to malformed input.
• Differences in error messages, timing, or behavior can reveal weaknesses.
• Weak exception handling can expose systems to:
  • brute force
  • injection
  • authorization flaws
  • hidden probing that goes unnoticed for months

AI, “vibe coding,” and why Tanya says it belongs on the list

The episode spends significant time on AI-assisted development and security.

Tanya’s position

• “Vibe coding” is a real security problem and should be discussed openly.
• Even if OWASP didn’t have enough hard data to justify it as a formal Top 10 item, it still deserved visibility.

Why she worries

• AI tools can:
  • remove important error handling
  • expose stack traces
  • generate insecure defaults
  • produce code that looks plausible but is unsafe
• Developers who don’t know secure coding may accept this output without realizing the risk

Her response: secure prompts

Tanya created free resources to help people ask AI for safer code:

• securecodingguideline.com
• securemyvibe.ca

She also distilled her book into prompt templates for:

• secure code review
• secure coding guidance
• serverless app generation
• other AI-assisted development workflows

Her goal is to make security requirements part of the prompt, not an afterthought.

Broader takeaways

Key themes from Tanya’s perspective

• Software security is still under-practiced, even in 2025.
• Many developers still receive little or no secure coding training.
• Supply chain risk is no longer just about dependency updates; it includes the whole toolchain and the humans behind it.
• Security is easiest when it’s built in from the start, not bolted on after incidents happen.
• Open-source maintainers need support, not blame.

Mentioned projects and resources

• OWASP Top 10
• Secure Coding Guideline: securecodingguideline.com
• Secure My Vibe: securemyvibe.ca
• Tanya’s podcast: DevSec Station
• Tanya’s online presence: She Hacks Purple

Final note

The episode is both a technical update and a call to action: modern application security now has to account for the full software supply chain, stronger exception handling, and the risks introduced by AI-generated code. Tanya’s message is clear: if teams want safer software, they need better data, better defaults, and better secure coding habits now.