DevSec Station

Your AI agent can read files, execute commands, install software, connect to external services, and maybe even deploy to production. But should it have permission to do all of those things?In Season 2, Episode 3 of DevSec Station, Tanya Janca (SheHacksPurple) explores one of the most important principles in AI agent security: least privilege.After Claude unexpectedly published, executed, and scheduled Tanya's little "Hello Queen" application, she started asking some serious questions about what AI agents should actually be allowed to do.In this episode, we cover:Permissions vs. instructions: Why telling an agent not to do something isn't the same as preventing it from doing it.Least privilege for AI agents: How to give agents only the access they genuinely need.Human approval: When an agent should ask permission before taking consequential actions.Sandboxing and isolation: How to limit the damage when an agent makes a mistake.The bigger architectural question: Does this task even need to be an AI agent?Because not every damn thing needs to be an agent! Sometimes ordinary software, a scheduled job, or a narrowly scoped AI feature is the better solution.Your challenge this week: Pick one AI agent you're using and examine its permissions. Does it need access to all those files, tools, credentials, and external services? If not, take away at least one unnecessary permission.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Two critical PHP vulnerabilities have been disclosed, and even applications written with secure coding practices may be affected.In this special bulletin of DevSec Station, Tanya Janca (SheHacksPurple) explains PHP2Shell, why vulnerabilities in the underlying PHP runtime can put otherwise secure applications at risk, and what developers and organizations should do to protect their systems.In this episode, we cover:Why secure application code alone cannot protect against vulnerabilities in the underlying runtimeWhat developers and operations teams should check in their PHP environmentsWhy patching, rebuilding containers, and redeploying applications matterWhy a web application firewall is not a substitute for applying security fixesWhat WordPress.com has announced about protections for its hosted websites, and why people using other WordPress hosting providers should check separatelyThe key takeaway: secure coding is essential, but we also depend on the security of the languages, runtimes, libraries, and infrastructure our applications run on (also known as our software supply chain).A big thank you to the PHP maintainers, security researchers, and hosting teams doing the work to keep the ecosystem secure.Resources:PHP official website and security releases:https://www.php.net/PHP Foundation:https://thephp.foundation/WordPress.com:https://wordpress.com/blog/This is a special security bulletin, separate from our regularly scheduled Season 2 episodes.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

I asked Claude to build me a little application that would greet me every morning.Nothing complicated. Just say hello, call me a Queen, give me a compliment, and share an inspirational quote. Cute, right?Except Claude didn't just write the code.It built the application, published it, executed it, scheduled it to run on my computer, and connected it to an external API I hadn't vetted.But... I hadn't explicitly asked it to do all those things.And the application was missing some rather important security controls, including authentication, authorization, and input validation.WHAT?!?!In Episode 2 of DevSec Station Season 2, I'm sharing what happened when I brought this example into my secure coding classroom and we started threat modeling it together.We explore:•The difference between asking an AI agent to do something and giving it the technical ability to do it.•Why an agent's effective permissions matter more than its instructions.•The security implications of agents accessing external services, executing code, and scheduling tasks.•Why developers remain responsible for the security of applications built with AI.•How to think about limiting what an AI agent can do before giving it access to your development environment.One thing to do this week: Look at an AI agent you're using and examine its actual permissions. What files can it access? What commands can it execute? Can it install software, call external APIs, or make changes without asking you first?Because what your agent can do matters just as much as what you asked it to do.Follow or subscribe so you don't miss the rest of Season 2!#AISecurity #AIAgents #AppSec #SecureCodingDevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

What happens when your AI assistant does exactly what you expect 59 times... and then does something completely bananas on the 60th?While teaching a secure coding class, I watched nearly 60 students use the same AI assistant, programming language, and prompts. For 59 of them, everything went as expected.But one student's AI-generated Python code included instructions to suppress linting checks, followed by code that leaked secrets to an external file.The AI hadn't escaped a sandbox. It wasn't even an agent. It was simply generating code within the boundaries we'd given it.And that's what makes the story so interesting.Welcome to Season 2 of DevSec Station! In this episode, Tanya Janca explores why AI's unpredictable behaviour becomes a security problem when we give it access to files, credentials, tools, infrastructure, and deployment capabilities.We'll discuss:- Why successful AI runs don't guarantee the next run will be safe.- Why better prompts aren't a substitute for security controls.- Least privilege, independent security checks, and human approvals.- How to limit the blast radius when an AI system does something unexpected.** Your one thing to do this week **Pick an AI assistant or agent you're using and ask yourself: What's the worst thing it's technically capable of doing with its current permissions?Not what you've asked it to do. What it can *actually* do.Because we don't need AI systems to be perfectly predictable. We need to engineer systems that can safely survive a surprise.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Security problems don't generally happen because developers 'don't care' or lack skill. They happen because no one clearly defined what "secure" meant in the first place. When security expectations are left implicit, developers are forced to guess. And that's where vulnerabilities are born.In this episode of DevSec Station, Tanya Janca explains what security requirements are, why they're one of the most overlooked secure development practices, and how developers can start adding them to projects today. You'll learn how clear, testable security requirements eliminate guesswork, improve collaboration, and help teams build secure software from the start. You'll learn: what security requirements are (and what they are not)  why vague security expectations lead to recurring problems  how security requirements improve design, code reviews, and testing  examples of effective security requirements developers can write today  how to add security requirements to features without creating bureaucracy Tanya walks through a familiar scenario where a feature works exactly as intended, only to be criticized later because security expectations that were never documented are missing. She explains why this isn't a developer failure, it's a communication failure, and shows how a few clear requirements can prevent expensive misunderstandings before development even begins. If you do just one thing after listening to this episode:Add two or three security requirements to a feature you're currently working on.For example, consider requirements like: who should be allowed to access the feature  what inputs must be validated (spoiler alert: all of them!) what sensitive data must never be logged  how the application should behave when something goes wrong Then document those requirements somewhere your team will actually see them: the project requirements document (the best place) a ticket  a pull request description  or somewhere else in the project's documentation When security expectations are written down, developers don't have to guess. They can build the right thing the first time.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Threat modeling has a reputation for being complicated, full of diagrams, and requiring long meetings. In reality, most developers already do it, they just don't realize it. The difference is that doing it intentionally helps you catch security problems before they become security incidents.In this episode of DevSec Station, Tanya Janca breaks threat modeling down into a simple five-step process that any developer can use while designing a feature. You'll learn how to identify what you're protecting, where trust boundaries exist, and how to ask a few simple questions that uncover security issues early; before they're expensive to fix. You'll learn: why threat modeling is can be simpler than most people think  how to threat model a feature in about fifteen minutes  how to identify assets, entry points, and trust boundaries  three practical misuse questions that reveal common insecure design mistakes  how to turn identified threats into concrete security controls Tanya walks through a practical, developer-friendly approach to threat modeling that doesn't require diagrams, special tools, or security approval. Instead, she demonstrates how asking a handful of structured questions during design helps developers build more secure software from the very beginning. If you do just one thing after listening to this episode:Threat model one feature you're currently building.Follow these five simple steps: describe the feature in one sentence  identify what you're protecting  identify the entry points and trust boundaries  ask what could go wrong if the feature is misused or fails unexpectedly  identify at least one security control that should be added or verified Write your notes somewhere your team can see them; a ticket, pull request, markdown file, or design document. You don't need a formal process. You just need to think about security before the code exists.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Secure code review isn't about finding obscure vulnerabilities or thinking like an elite hacker. It's about verifying that the security controls your application depends on are actually present, in the right place, and correctly implemented.In this episode of DevSec Station, Tanya Janca explains how developers can perform effective secure code reviews without being security experts. You'll learn what security controls to look for, how trust boundaries help you focus your review, and a simple framework for turning security review from "vibes" into a repeatable engineering practice that meaningfully increases the security of your code. You'll learn: why secure code review is about verifying security controls, not hunting for clever vulnerabilities  how trust boundaries help you focus on the code that matters most  the four areas every developer should examine during a security review  why security issues are often missed during otherwise well done code reviews  how a simple checklist can make security review faster, more consistent, and more effective Tanya walks through a realistic pull request that passes every normal review, yet still introduces security problems because no one explicitly checked authentication, authorization, input validation, or error handling. She explains why these omissions are process problems (not developer failures) and how focusing on security controls makes reviews far more effective. If you do just one thing after listening to this episode:Add a short security checklist to your team's pull request template. Copy this one! Seriously, right now. Do it. Does this change introduce new inputs or trust boundaries?  Does it change who can access something?  Does it touch sensitive data, secrets, or credentials?  What happens if this code fails?  Are the expected security controls where they should be and correctly implemented? You don't need a twenty-point checklist. Three to five thoughtful questions are enough to turn secure code review into a repeatable habit instead of a gut feeling.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Security bugs aren't usually caused by 'bad developers'. More often, they're the result of good developers making rational decisions under deadlines, competing priorities, and imperfect systems.In this episode of DevSec Station, Tanya Janca explores why common secure coding mistakes are often incentive problems rather than knowledge problems. You'll learn why insecure patterns emerge, why simply telling developers to "be more careful" doesn't work, and how changing your development environment can make secure coding the easiest path forward. You'll learn: why good developers still introduce security vulnerabilities  how deadlines, delivery pressure, and operational complexity influence coding decisions  why 'shame and blame' doesn't improve software security  several practical examples of how to replace insecure patterns with more secure ones  how to identify recurring shortcuts and improve them instead of fighting them Tanya shares several real-world examples of secure coding shortcuts that teams make every day (from copy-pasted authentication checks to inconsistent secret handling) and explains why these decisions are understandable in the moment, even though they create security problems over time (also known as 'security drift'). She also demonstrates how small changes to defaults, shared libraries, and team patterns can eliminate entire classes of recurring mistakes. If you do just one thing after listening to this episode:Identify one insecure pattern that keeps showing up in your team's code base and ask why it exists before trying to eliminate it. If you don't know the why, you can't fix it. Then replace that shortcut with an easier, more secure path.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Security training has its place. But if training alone solved security problems, we wouldn't keep seeing the same vulnerabilities appear over and over again. The real problem usually isn't that developers don't know what to do; it's that the easiest path is often an insecure one.In this episode of DevSec Station, Tanya Janca explains why secure defaults are one of the most effective security controls you can implement, why relying on memory and willpower rarely works under pressure, and how small changes to your development workflow can prevent the same mistakes from happening again. You'll learn why better systems consistently outperform good intentions. You'll learn: why training alone isn't enough to improve security  how insecure defaults quietly create recurring security issues  why developers naturally follow the path of least resistance  how secure defaults reduce mistakes without slowing teams down  practical ways to improve security by changing one default at a time Tanya walks through a familiar day in the life of a busy developer, showing how insecure defaults become "normal" simply because they're already there. She explains why this isn't a developer problem (it's a systems design problem) and how thoughtful defaults can improve security for every future decision. If you do just one thing after listening to this episode:Choose one repository you actively work on and improve a single insecure default.For example: update a configuration file so it starts with more secure settings  enable security checks in your CI pipeline to run every time  improve a project template so authentication, logging, or validation are included automatically  replace scripts that rely on plain text secrets to perform proper secret management instead You don't have to redesign your entire development process. One better default today can prevent countless mistakes tomorrow.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca

Security tools are supposed to help developers build safer software. But sometimes it seems like they create more frustration than security.In this episode of DevSec Station, Tanya Janca explains why many security tools overwhelm developers with alerts, how alert fatigue erodes trust, and why "more findings" doesn't mean "more security." You'll learn how to tune your classic AppSec tools so they surface meaningful issues instead of creating noise that everyone eventually ignores.You'll learn:• why classic AppSec tools often optimize for coverage instead of developer workflows• how alert fatigue develops and why it leads to missed vulnerabilities• why developers ignore noise (not security)• how to improve signal-to-noise in your existing tools• practical ways to make security tools work with your development processTanya walks through a familiar scenario: running a security scan that produces hundreds of findings, spending valuable time triaging alerts, then eventually starting to ignore the noise. She explains why this isn't a developer failure; it's the predictable result of tools that don't distinguish between theoretical issues and meaningful risk.If you do just one thing after listening to this episode:Pick one security tool you already use (SCA, SAST, or a secrets scanner) and tune it to better respect your time.For example:• prioritize high-severity, reachable findings• highlight newly introduced issues instead of historical backlog• filter or downgrade specific types of findings your team never acts on• configure the tool to surface issues as early as possible in your workflowThe goal isn't to ignore security, it's to make the important signals very loud and visible.DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.Train with Tanya: Want to bring practical, hands-on secure coding, application security, or AI security training to your team? Learn more at SheHacksPurple.Follow Tanya:https://newsletter.shehackspurple.cahttps://linkedin.com/in/tanya-jancahttps://youtube.com/@shehackspurplehttps://shehackspurple.ca