Hi Everyone!

I have a gift for you! This month I am including a download for my AI Secure Coding Prompt Library (see download link below). Please feel free to use it at work or for your personal projects to help you create more secure code. Tier 1 can be added to your AI assistant’s memory to run every single time you generate code, tier 2 prompts are for specific actions, and tier 3 is for when you are creating security controls. I would love any feedback you have so I can continue to improve it over time. 😀 As an FYI, the prompt library is under copyright, so instead of sending a copy to friends please 🙏 share a link to download (and subscribe) instead: SecureMyVibe.ca.

Last month I did my first book stream with Gerald Auger for Alice and Bob Learn Secure Coding, which you can watch here (or below). You can also join me live on May 10th with my friend Ray Leblanc (chapter 2), and June 3rd with Scott Helme (chapter 3). Future chapters are as follows:

• July, Chapter 4, Gavin Klondike

• August, Chapter 5, Katie Paxton-Fear

• September, Chapter 7, Seth Law and Ken Johnson

• (the rest are still being planned)

One last thing; I am planning to stop traveling so much. I’m still going to do training, and I’m still going to do ‘the big events’ (RSAC, OWASP, Hacker Summer Camp), but next year I plan to stay home a lot more often so I can focus on building something. I will give you updates as things progress.

Thank you for subscribing and supporting my work!

Tanya 💜

Why Most AI Security Strategies Fall Short

Prompt filters and model guardrails only cover part of the problem with AI security. The real risk lives in the data, permissions, and identities AI inherits. When agents can search, reason over, and act on enterprise data, every dormant exposure becomes active. In Varonis' latest report, Securing the AI Frontier, they outline how inventory, posture management, runtime controls, and data security must work together to reduce AI risk — not just shift it.

New Content!

• Alice and Bob Learn Secure Coding: Chapter 1 - The video is ready!

• DevSec Station Episode 2; The Anatomy of a Modern Supply Chain Attack (video, audio)

• DevSec Station Emergency Broadcast: NPM Worm in the Wild (video, audio)

• I was on Smashing Security with Graham Cluely! (podcast) YouTube Link

• I was on Talk Python To Me, with Michael Kennedy! (podcast) Youtube Link

• Securing the Vibe: Tanya Janca on AI-Generated Code, Mythos, and the New AppSec Reality - with Chris Hughes!

• Security risks from AI, and what to do about them - Short YouTube Video

• Securing Apps Without a Budget: Minimal Viable Security Strategies (a video of me from the OWASP 25th annual Conference)

• The Secure Disclosure Podcast: OWASP Top 10, Vibe Coding, and What Developers Miss

• More fake extensions linked to GlassWorm found in Open VSX code marketplace - Article I am quoted in

• The Psychology of Bad Code Part 5 - Shiny New Tech (in the article section below)

Events!

• May 5-8, 2026 NDC Toronto In person, developer conference

• May 10, 11 am-1 pm PST: Alice and Bob Learn Secure Coding Book Stream: Chapter 2 with Ray Leblanc as special guest, you do not need to RSVP if you do not want to, you can just join us live on YouTube the day-of if you don’t need/want reminders.

• May 15, 9:00 am PT: You've Built a Security Stack. Have You Built a False Sense of Security? - Free Webinar

• May 31 and June 1: B-sides Vancouver, I’m giving a training on the 31st “OWASP API Security Top Ten“ and a talk on the 1st “Threat Modeling Developer Behaviour: The Psychology of Bad Code“

• June 3rd, 8:00 am PST, 4:00 pm BST: Alice and Bob Learn Secure Coding Book Stream: Chapter 3 with Scott Helme as special guest, you do not need to RSVP if you do not want to, you can just join us live on YouTube the day-of if you don’t need/want reminders.

• June 22-26 - OWASP Global AppSec, Vienna, I’m giving training and also a talk on the OWASP Top Ten 2025 with my project teammate Torsten!

• August 3 (Monday) - I’m giving secure coding training in C++ training at Black Hat! OMG THEY ACCEPTED MY TRAINING! I also submitted a talk, maybe the world will turn upside down and they will accept that too? 😛 

• August, 24-26, 2026 Keynote for Sikkerhetsfestivalen (Security Festival) in Lillehammer, Norway! In person

• September 12-18, Aurora, CO, I am booked to train at CPPcon! A software development conference dedicated to C++, where I will be offering a 2-day training on “Secure Engineering in Modern C++: Preventing Catastrophic Failures 2026“ I’m pumped! They expect 50,000 software developers to attend, holy SMOKES.

PS Companies are starting to book me for in-person training around my travel dates. Please email me back if this interests you.

Article

The Psychology of Bad Code Part 5 - Shiny New Tech

This is a series. The first blog post is here, #2, #3, #4, and this is the fifth.

The behaviour: Shiny New Tech

Using a brand-new technology, language, and/or framework, even when it’s not necessarily the best thing to use. Especially if it’s untested, and there’s little guidance or tools available for it. An obsession with using what’s new, over what’s best for the situation.

What this looks like in the real world

• Jumping to a new framework, library, language, or tool because it’s exciting, popular, or “the future”
• Wanting to use something new before fully understanding how it works
• Replacing stable, working systems with newer ones without a clear reason
• Forcing ‘the cool new thing’ as a project requirement, when there’s no technical reason for doing so
• Choosing tools based on hype, not security, maturity, stability, or supportability
• Associating your value as an engineer with how current your tech stack is

This often shows up when we want to stay relevant, have something to prove, or when everyone around us is talking about the same new thing.

Behavioural biases at play

• Novelty bias: New things feel more exciting, more interesting, and often better, even when they aren’t (from a security perspective this is rarely true)

• FOMO (fear of missing out): We worry that if we don’t learn or use this new thing, we’ll fall behind or be left out of something important

• Status signaling: Engineers often (whether we admit it or not) tie reputation to using modern tools. “A 10X engineer would use this, so I will use it.”

• Present bias: We prioritize immediate work over future clarity, even when we know it will cost us later. We use present bias to justify the decision, while one of the first 3 is the reason for the decision.

These biases aren’t bad. Staying current matters in tech. Learning new things is part of the job. We need to be aware of new tech. But they can also absolutely lead us in the wrong direction.

Why this behaviour makes sense in the moment

Tech moves fast. Really fast. Even faster now with AI. Too fast.

New tools promise:

• Better performance

• Less code

• Easier development

• More “modern” architecture

And sometimes those promises are true.

On top of that:

• Job postings tend to reward newer tech experience

• Conferences, blogs, and social media amplify what’s new, not what’s stable, normal, or reliable

• No one brags about “we keep using the safe, boring thing and it’s fine”

• Learning is our lifeblood, and we are technologists, so we love learning new tech

So yeah, of course we chase new tools.

The security risk

Security rarely keeps up with new tech. So, so rarely is it even any sort of priority for those building it. 

New frameworks, by definition:

• Have less real-world testing

• Have fewer security reviews

• Have undocumented edge cases

• Have smaller communities catching issues

• Have less support in every possible way

And most importantly: We don’t even know how they fail yet.

When you adopt something new, you are also adopting unknown risk.

In case that’s not enough for you:

• Security guidance is limited or non-existent for new tech

• Best practices haven’t stabilized

• Developers are learning while building production systems

The combination is… non-ideal.

Solutions:

Secure Defaults

Add a required security review as part of any new tech adoption process. If you do not currently have security review as part of option analysis for projects and tech adoption stop reading right now and add it. This is high value and, in my opinion, mandatory for all AppSec programs.

If you want to bring something new into the stack, great! But first:

• Threat model it

• Discuss known and unknown risks

• Security maturity

• Are there tools available to help us secure this new technology

This is a standard step, not an optional one.

Environmental Design Acceptance Criteria

I don’t know how to design an environment to protect against this issue except to lock things down so no one can install anything... And we know how popular that is! Instead, let’s look at how we decide ‘yay or nay’ on new technologies.

 Create a simple, lightweight “new tech checklist”:

• Is there security guidance available?

• Is this widely used in production?

• Are there known vulnerabilities or concerns?

• Has it been tested? If so, by who? How much? What kinds of tests? Etc. Can we see the results of said tests?

• What’s the documentation look like? Is it well supported?

Make sure there is a process or time made to ask and answer these questions before the decision is made.

Friction

Security needs a seat at this table:

• Require approval for new frameworks/tech in production systems

• Encourage piloting in non-critical environments and lower-risk systems first

• Add extra layers of security to reduce risk until you’re sure it’s safe

Social / Cultural

We don’t want to be a ‘Debbie downer’ and naysay all new technology as bad. If we do this, people will start going around us. We do not want this. I’d rather have them run me over, but know it’s happening, then have them go behind my back. At least then I can prepare.

This means we need to be careful when we discuss new tech. We may need to remind ourselves:

• New tech is not the enemy and it’s not always bad

• This is likely happening whether we like it or not, so let’s figure out how to do it as safely as we can

• Only die on hills that are worth dying on

I asked the AI for feedback and suggestions for this section. It suggested ‘celebrating stability’, but I don’t think starting an unprompted discussion about how nice and reliable .Net is would change any minds about adopting a ‘cool’ new framework. I think it would be awkward and feel forced, but if you disagree, I’d love to hear your thoughts.

Conclusion

Using new technology isn’t necessarily a problem. But we must do so safely, with all the proper security steps.

We end with a meme.

Canada: MY LAST PLEA!

Canadians and permanent residents: the vote should happen in May. This is your last change to make your voice known. Please call your MP if you want to push Canada to have the first secure coding law in the world.

1. Sign the Petition: If you haven't already, please sign here: Petition e-7115.

2. Contact Your MP: Reach out to your local MP to express your support for the petition and urge them to vote YES when it's presented during question period. You can find your MP's contact information by entering your postal code here: Find Your MP.

Please call or write your MP.

Subject: Please Support Petition e-7115 (Secure Coding in Government)

Dear [MP’s Name],

I’m writing as a constituent from [Your Riding] to ask for your support of Petition e-7115, which calls for mandatory secure coding practices across federal departments and Crown corporations.

Right now, much of the software our government relies on is built without consistent, enforced security standards. That creates unnecessary risk, not just for government systems, but for the Canadians who depend on them. We’ve all seen how costly and disruptive preventable vulnerabilities can be.

This petition is a practical step forward. Secure coding standards are well understood, widely used in industry, and proven to reduce risk when applied consistently. Adopting them at the federal level would help prevent issues before they happen, rather than reacting after the damage is done.

I hope you will support this petition and advocate for stronger, proactive cybersecurity measures in government systems.

Thank you for your time and for representing our community.

Sincerely,
[Your Name]
[Your Postal Code]