SheHacksPurple: July 2026

Big projects, book streams, and travel

Author

Tanya Janca
July 01, 2026

The SheHacksPurple Nerd-a-licious Newsletter

💜 Hit ‘reply’ to send me a message. Thank you for subscribing! 💜 

Hello everyone.

It has been a surprisingly big year already. And it’s only July.

Over the past year I left Semgrep, returned to running my own business full-time, launched DevSec Station Podcast, joined and published the OWASP Top 10 2025, continued speaking and teaching around the world, started thinking more deeply and differently about behaviour change and education, and kept pushing forward on my secure coding advocacy work with the Canadian government.

When I look back on it, I'm kinda surprised by how much has happened in such a short time.

With so much going on, I have been asking myself a hard question: how should I spend my time?

I've been reviewing all the things I do each month and trying to determine which activities create the most value for all of you, and which ones might need to… go.

One example is my book streams. I've enjoyed doing them, but attendance has been disappointing. I'm not upset about it. People's interests change, schedules get busy, and AI has changed what all of us consider ‘normal’. What I'm trying to figure out is whether those hours would create more value elsewhere.

If you've attended a book stream, I'd love to hear what you got out of it. If you've never attended one, I'd love to know what would make you interested in joining. Should I keep doing them? Change the format? Or focus on something different entirely? Please hit reply to answer.

That question has a flip side, though. It's not just about what to stop doing. It's helped me decide what I want to do next.

For the past several months I've been carefully planning a new project that I'm incredibly excited about. It's bigger than a conference talk, a training course, or a blog series. I'm intentionally taking my time. Rather than rushing into ‘doing’, I've been thinking very carefully about what I want to create, who I want it to help, and how I want it to fit into the rest of what I do.

Now that some major pieces have finally fallen into place, I'm about to start building something, and that is very exciting for me.

As we head into the second half of the year, I'm looking forward to what's next. I'll share more once there's something real to show you. 😀 

Tanya

The $50K per hour network downtime dilemma

Infrastructure downtime can cost teams upwards of $50,000 per hour.

What’s standing in the way of a faster, more coordinated response?

On July 15th, join Netskope and Tines live for a session on bridging the gap between detection and resolution in modern, hybrid environments.

You'll learn:

  • The hidden cost of manual network operations

  • A 5 step roadmap to building a secure network operations strategy

  • What “great” actually looks like in secure network operations with use case examples

New Content!

Events!

  • July 2, 9:00 am PT: Join Gavin Klondike and I for chapter 4 of Alice and Bob Learn Secure Coding! Register here, or just join us live on YouTube, LinkedIn or Twitch. Virtual

  • August 3 (Monday) Black Hat - My training was cancelled. My talk was rejected. I won’t be a part of Black Hat.

  • August 5: Coffee Meetup #1, 12:30 - 2:30 PM, in person, Mandalay Bay, Las Vegas, at the Starbucks just outside the entrance to Black Hat - I will be hanging around and drinking mochas, come hang out! (no pass required)

  • August 5, 3:00-4:00 pm, Booth #4917: Book signings with ESET in the Black Hat Expo hall, free books! (expo pass required) Las Vegas, NV

  • August 6: Coffee Meetup #2, 11:30 - 1:30 PM, in person, Mandalay Bay, at the Starbucks just outside the entrance to Black Hat (no pass required) Las Vegas

  • August 6, 2:00-3:00 pm, Booth #4917: Book signings with ESET in the Black Hat Expo hall, free books! (expo pass required) Las Vegas, NV

  • August 8-9 - Def Con - AppSec Village - my Supply Chain workshop was just accepted! Date and time TBD. Las Vegas, NV

  • August 15, 11:00 am PT: Join Katie Paxton-Fear and I for chapter 5 of Alice and Bob Learn Secure Coding! Register here, or just join us live on YouTube, LinkedIn or Twitch. Virtual

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

  • September 12-18, Aurora, CO, CPPcon - Cancelled (I cancelled my appearance, the event is still on). The conference is amazing though, you should still go.

  • November 3-6 OWASP Global AppSec in San Francisco - My 2-day secure coding training was just accepted, and hopefully one of my talks will be accepted too. This will probably be my last public event for some time.

Article

This is a series. Previous posts: #1, #2, #3, #4, #5, #6; this is the seventh. Share it.

The Psychology of Bad Code is a framework, developed by Tanya Janca, that maps common secure coding failures to the specific cognitive biases that drive them, paired with structural fixes for each. 

Repetitive code reuse and lazy error handling happen because developers rely on satisficing (choosing "good enough" over optimal), optimism bias (assuming past success predicts future behavior), and anchoring bias (sticking with the first solution that worked). The fix isn't just training, it's secure defaults, environmental tooling, friction at the right moments, and a culture that talks about failure as openly as it celebrates success.

- Tanya Janca

The behaviour: Repetitive Code and Lazy Error Handling.

This post is a mash up of two intertwined issues. The first is repeating old code patterns we know are not great, but the second is not doing a good job of handling exceptional conditions (error handling) in a strict and proper way. Looking back upon my notes and my talk slides, I am honestly not sure why I choose to combine these two (I didn’t document it, see what I did there? From the previous post!). I suspect that because both were caused by the same biases and heuristics and the solutions where also the same that it would be more efficient to just write one post.

What does lazy error handling actually look like in code?

  • Copying and reusing the same code patterns over and over because they worked before

  • Handling errors with something simple like returning null, printing a message, or ignoring it entirely (try, catch…. nothing.)

  • Catching exceptions without actually doing anything meaningful with them

  • Assuming the same inputs, conditions, or environment will always apply (especially if it hasn’t had real testing, you don’t know otherwise)

  • Writing “good enough” logic to get things working, but not thinking through failure/abuse cases

We don’t necessarily know we’re doing this. It feels safe. It feels like enough.

This often shows up when we’re moving fast, solving a problem we’ve seen before, or trying to unblock ourselves.

Behavioural biases at play

  • Satisficing: We choose something that is “good enough” instead of the best or safest solution

  • Optimism bias: We assume things will continue to work the way they have in the past

  • Anchoring Bias: We stick to the first solution that worked and keep reusing it, even when the context changes.

These are all incredibly common.

In most cases, reusing what worked before is efficient. And most of the time, systems do behave the way we expect them to.

Until they don’t.

Why this behaviour makes sense in the moment

We’ve seen this pattern before. It worked. It was fine.

We’re trying to move quickly, not reinvent everything from scratch.

Error handling often feels like:

  • Extra work

  • Edge cases that “probably won’t happen”

  • Something we can come back to later

Also:

  • The system might not fail during testing

  • The happy path works perfectly

  • There’s pressure to ship, not to explore every possible failure

So we move on.

This is not careless. It’s efficient, in the moment.

The security risk

When we reuse patterns without thinking, we also reuse their weaknesses.

  • Missing or weak error handling can leak sensitive information

  • Systems can fail in unpredictable ways when assumptions break

  • Attackers often look for exactly these edge cases and failure paths

  • Silent failures can hide security issues entirely

And with duplicated code:

  • Fixes don’t get applied everywhere

  • Vulnerabilities get repeated across the system

  • Inconsistent behavior creates new attack surface

This is how small, “good enough” decisions compound into larger problems.

Solutions:

Training

You can't train someone out of time pressure. You also can't expect developers to think through every edge case manually, remember every past lesson, or revisit every reused pattern on their own.

When the system rewards speed and reuse, that’s what people will optimize for.

Secure Defaults

Provide safe, reusable patterns. If developers are going to reuse code (and they will), give them approved error handling patterns, standardized ways to deal with failures, and shared utilities instead of copy-paste duplication. Make the safe thing easy to reuse.

Environmental Design

Use tools to surface issues automatically: IDE warnings for unhandled exceptions, CI/CD checks for missing error handling, and detection of duplicated logic where possible. Catch problems where they happen, not months later.

Friction

Add just enough friction to make people think. Require meaningful error handling before merge, flag empty catch blocks or ignored errors, and encourage developers to answer "what happens when this fails?" Not every edge case, just the important ones.

Social / Cultural

Normalize thinking about failure. Talk about how systems break, what happens when assumptions fail, and why error handling matters. Right now, most teams celebrate success paths. We should also talk about failure paths.

Conclusion

Reusing code and writing "good enough" logic isn't the problem. Doing it without thinking about failure, context, or long-term impact is.

Most of the time, things work. Security problems show up when they don't.

We end with a meme.