The Pragmatic Engineer - Code security for software engineers

Episode Date: November 26, 2025

Brought to You By:•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Statsig are helping make the first-ever Pragmatic Summit a reality. Join me and 400 other top engineers and leaders on 11 February, in San Francisco for a special one-day event. Reserve your spot here.•⁠ Linear ⁠ — ⁠ The system for modern product development. Engineering teams today move much faster, thanks to AI. Because of this, coordination increasingly becomes a problem. This is where Linear helps fast-moving teams stay focused. Check out Linear.—As software engineers, what should we know about writing secure code?Johannes Dahse is the VP of Code Security at Sonar and a security expert with 20 years of industry experience. In today’s episode of The Pragmatic Engineer, he joins me to talk about what security teams actually do, what developers should own, and where real-world risk enters modern codebases.We cover dependency risk, software composition analysis, CVEs, dynamic testing, and how everyday development practices affect security outcomes. Johannes also explains where AI meaningfully helps, where it introduces new failure modes, and why understanding the code you write and ship remains the most reliable defense.If you build and ship software, this episode is a practical guide to thinking about code security under real-world engineering constraints.—Timestamps(00:00) Intro(02:31) What is penetration testing?(06:23) Who owns code security: devs or security teams?(14:42) What is code security? (17:10) Code security basics for devs(21:35) Advanced security challenges(24:36) SCA testing (25:26) The CVE Program (29:39) The State of Code Security report (32:02) Code quality vs security(35:20) Dev machines as a security vulnerability(37:29) Common security tools(42:50) Dynamic security tools(45:01) AI security reviews: what are the limits?(47:51) AI-generated code risks(49:21) More code: more vulnerabilities(51:44) AI’s impact on code security(58:32) Common misconceptions of the security industry(1:03:05) When is security “good enough?”(1:05:40) Johannes’s favorite programming language—The Pragmatic Engineer deepdives relevant for this episode:• What is Security Engineering?•⁠ Mishandled security vulnerability in Next.js•⁠ Okta Schooled on Its Security Practices—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

What are code security basics that every software developer should know? Really know and understand what your code is doing. Maybe that sounds a bit silly and obvious, but that's how security experts find basically security issues in your code. I'll set up an MCP server that says it does something, but secretly it does something else. It runs locally. Boom.

With agents and giving away more control, there is a new threat here because it's not just about the dependencies you're using or your machine security in general, but also making sure that the agent you're using is doing the right thing. How do you think AI is changing code security and also security in general? Today what we're seeing is at software engineers what should we know about writing secure code? To answer this question, I turn to Johannes Das who has been a security expert for 20 years and is currently the VP of code security at Solnar. In today's episode we cover code security basics all

software engineers should know of, common code security tools worth knowing of and using like static application security testing and more advanced tools like software composition and analysis, how AI coding assistance introduce new risks and what we can do about these, and more. If you're a software engineer looking for pointers on how to make your code more secure, this episode is for you. This podcast episode is presented by Statsic, the Unified Platform for Flags, Analytics Experiments, and more. Check out the show knows to learn more about them and our other season sponsor. So Johannes, welcome to the podcast.

Thank you. Big pleasure to be here. So we're going to talk about cybersecurity today. I wanted to get to know. How did you get into cybersecurity? And when was this? It must have been like 20 years ago. I remember I got hacked.

Basically, my computer got infected. I think it was a sasa warn back in the days. And I was super frustrated, right? And then also super intrigued, like, how could someone get access to my computer? And so that led me into, you know, playing with securities things like Trojan horses and that stuff at school time. And then I moved to Bohom, the city,

in Germany where you could study IT security and it was exciting. And so they played Capture the Flag competitions, right? Those are hacking competitions where university teams connect online in an isolated environment and they tried to hack each other to get points. And I got really obsessed playing those competitions and there was the best learning experience for me, you know, and this led them into, you know, getting into professional penetration testing, writing tools to assist the vulnerability hunting. and this led them into a startup which got acquired by Sona where I am today.

How can we imagine penetration testing? So penetration testing is simulating an attack basically, right? So you are kind of like a company hires you as a hacker basically and you have to find out vulnerabilities in a given time scope and scope of the applications that you should test. And it was just like a natural move if you do that as a hobby with the hacking competitions, right, where you just do that for winning points in games

to do then, you know, kind of like earn money with that as a student, to also look for security issues as a professional. And I understand that, you know, like, yes, you can now hire penetration testers, right? As the company, I can hire teams that do this. But did you do some of this? Did you do professional penetration testing?

Yes, absolutely. For a couple of years doing this as a freelancer and for big companies, basically, right, looking for security issues they have and always trying to get into their network, typically by exploiting vulnerabilities and software, applications they're running, and then documenting this, right, not going further,

not destroying something, doing something malicious, but basically reporting, then this is how an attacker could get in so they can fix it. How does the penetration test look like from when the company says, like, all right, come and penetration test us. How do you actually go around? Do they actually give you access to some of their systems,

or you need to just assume no knowledge? How does that work? Yeah, there are different types, right? So there's black box penetration testing and white box, meaning black box, you don't have access to anything. You treat it as a real attacker, like with no knowledge. Yeah, you know, typically you have maybe like a web application running and you go and look at it from the attacker perspective.

and play around with the application from the outside, trying to imagine basically what could be the code behind that application, what could be the code doing that I'm seeing from using that application and then trying to figure out what could be vulnerabilities here, right? What could be something a developer forgot to do? And by experience, you learn a bit like what are typical mistakes and then you go from there, trying to always exploit something where you can steal files or,

or get access to the database or something where there is some data, something that could be sensitive to the business that is then security critical. Do you bring your own tools there? Do you have methodologies? I guess it's very basic, but I do know of the concept called port scanning where you write a software where it tries all the different ports, it sends messages, and you hope that if they configure it up a server incorrectly or maybe correctly you can get through.

What kind of tools that do you come with? You do use tools as a penetration tester. I think mostly for kind of like mapping out what's available, right? That's, I think, the biggest part you automate. So you don't, you know, test for the endpoints or ports, as you said. But I think then once you found a good landscape of what's out there, you go in manually, at least I used to do that manually to, you know, try to poke and see what breaks when you touch it and when when you play around with it.

And that's also the most exciting part, I think. In the real world, we're going to be sitting, you know, as software engineers inside a company and we're going to be building our software. This might be services. This might be apps, websites, and so on. And there's going to be attackers outside. It's going to be like script kids or like, you know, like people just like, like playing around, poking around.

And then there's going to be professionals as well who will be trying to get financial gain, whatnot. Now, inside the company, who should own code security? You know, in the industry today, what we're seeing is that this is a shared responsibility, basically, right? So we talked about the penetration tests and typically security teams are involved in that. And then there is still developers, you know, adding and writing code, right? And I think predominantly in the industry, the view is that the security team should own all that security, right? It's in the name of the team.

But I see it quite the other way around. I think, you know, every software vulnerability basically manifests in code and developers are the only ones writing the code in organizations and changing the code, right? And they're the only ones who can fix security issues. And so I think they should own all those code security issues, right? they should own basically their share of the code and also the problems related to their code. And I think that's also more realistic today because you have great education available and great tools available for developers.

So I think that ownership should be with developers on the code security problems. I hear what you're saying on devs should own code security. But then why have a security team or at what point should you have a security team? Again, you now work with a lot of different companies and sizes, and previously you also worked as a security engineer. At what point do companies bring in the security team? And when they do, what is their role? I'm kind of like, look, if there's a security team, I'm like, come on,

that's their name, right? Like, as a developer, like security as a whole, like to make your service 100% secure. That's pretty daunting. Yeah, I don't think that secure teams are useless, right? Not at all. We talked about the penetration test. That's typically something run by security.

teams. And so I think the field of, you know, application security is just much more broader than code security, right? So you have maybe compliance requirements that you need to look after and some, you know, organization-wide initiatives, security initiatives, or there are vulnerability reports coming in from a penetration test or new threats are available. And so security teams, I think, should look at this broader application security field. And it's good to have a security team for that and the larger the organization gets, right? You, I think you need a security team. I just think that when you write software and when organizations, you know, deploy software,

the security team shouldn't waste their time and looking into every single security issue that happens during development, right? And I think that part should be fully owned by developers, right? I think it's a waste of time to look at every single new cross-ad scripting issue again and again and try to exploit it and build some fancy exploit and risk assessment where as the developers could just, you know, fix issues as they code and move on. And that also allows them security teams to have more time to actually focus on bigger problems, on problems where they can really bring in their expertise like cryptography or authentication

logic or things like this where they can then also be very helpful with the expertise for developers. So I'm kind of hearing some similarities between the, the kind of feature teams or program teams and platform teams where, you know, platform teams typically build platforms where engineers can build on and they have a specialized expertise. It might be a massive database platform, like for large data storage company. And then engineers, they kind of use the APIs, but they don't need to know all the details. But when they do, they can just go to the platform team saying, hey, how do I store, you know,

like two petabytes of data end up like, okay, here's different ways you can do it. So do I understand correctly that you're kind of saying security teams will also be this specialized expertise where they can help you with a bunch of stuff and they will try to do tools as well for for deaths to like self-service or or you know share common things to watch out for yeah exactly i think it's a good comparison right um definitely helping um but also leaving you know the majority of ownership there with developers so they can basically have security as part of the process of development and not just something that is you know attached to or ad hoc run um and whenever the security teams decides, right? I think it should be really part of the process of development

and that must be then owned by developers to really, you know, engage in security issues and fix them because that's what makes you secure in the end. I will challenge, though, that historically, I don't think software engineers owned security or were expected to own. Can we talk about how this change over time over your 20 years, how you've seen changes happen? because I do feel it's shifting left on to developers, but what was the historic context here? And what is changing now? Historically, I think it was clearly owned by security teams, right?

So if you imagine 20 years back, it was all about compliance, driven by compliance, and then also the software development lifecycle was a lot slower than today, right? You would have your quarterly release, and then there would be before that, there would a security team come in and do a final audit, right? And then you would lease. And today we're just moving at a much more faster pace, releasing a couple of times a day or per hour, right? And you have AI coding assistance. And so we are moving a lot faster now.

Johannes just talked about how engineering teams that are moving at a much faster pace than before, especially teams using AI coding assistants, which are most engineering teams, honestly. Here's something surprising, though. As dev teams build more products and features faster than before, coordination is increasing the problem. You now have more Slack channels pop up, more customer feedback to deal with, and you often end up switching between different tools to decide what to build and how to build it. This is where a season sponsor, Linear, can help deaf seem safe-focused. Sierra is an AI-powered customer experience startup.

They were preparing for the next phase of company growth and wanted to find a tool that can help a larger team move quickly without slowing down. They chose Linear as their operating system of the company and wired all of their work into the platform. Today, project updates in linear ripple through Slack, customer requests are logged in linear, and stats from linear are pulled out into company dashboards and into the slides that Sierra shows off as they celebrate wins at all hands meetings. Despite Sierra being in hypergrowth, everyone understands what they're building, why they're building it, and how the work is progressing.

What I love about Sierra's approach is how they didn't set up linear wanting to know what individuals did on a given week. They wanted to know what was accomplished in service of which projects. This is the beauty of using Linear. It helps Hypergo companies stay focused, spend more time building, and less time coordinating. If your team cares about tools that remove additional work for the team instead of adding extra to it, check out Linear at linear.app slash pragmatic. And now, let's get back to fast-moving end during teams and security reviews.

You cannot have this disconnected security review that you do afterwards. And so in the industry, what's also changing here is, I think, the tools that you need for this, you know, historically. the tools are built only for security teams, right? And then with that, there is a different product philosophy that comes with security products. Because as a security auditor, basically, you want to know about every single potential issue, right? You want to turn every stone and better look twice than never

to find out what could go wrong. And then now if you apply this to this new pace of fast development, that doesn't work anymore, right? Because you cannot get interrupted all the time with findings. It's too noisy, right? I like to compare this with, you know, if you drive a car and you have a security guy in your passenger seat and he would scream and yell at you

at every single thing that could go wrong all the time. That may be interesting the first 50 meters, but then gets super painful and annoying. I think with that we see a change in the industry that, you know, I think developers should own code security issues, but also the toolings around code security issues must be owned and for developers. And then there are other application security tools and application security as a broader

thing that should be still owned by security teams. So so far you've mentioned two different things or if I caught it correctly. One was code security and then application security. And you said that application security is a lot more than code security. So it's a, you know, like it's a super set of it. What is code security? I mean, this is one of your, your expertise, as I understand, but how do you define that?

You know, where does it start? Where does it end? Because it does sound like something that as a software engineer, we should be aware of it, right? Yeah, for lack of a bit of definition, I would say, it's basically code that is, you know, free of security issues, free of anything that, you know, can be leveraged by an attacker to exploit your application and then, you know, get access to some of your data and put your business at risk.

But with that simple definition, I think the complexity is a bit. it, you know, what are security issues when we say code is free of security issues. And I think here the, we think typically as vulnerabilities, SQL injection is a vulnerability. And I think it's much more than this, right? If you think about bugs, like a null pointer exception where your application crashes, then your application is in an unintended state. And this can be abused by attackers in some scenarios. Or maybe a more obvious example would be, you know, memory corruption problems and CC++.

Plus where as an attacker you can do a buffer overflow and then execute code on your server. And so I think here the lines get more blurry and then are also more logical things. Like if you write an application where you can upload a profile picture, you shouldn't forget that an attacker couldn't be, you shouldn't be able to upload a shell to your server and those kind of things. So I think we are really realizing that code security is much more than just vulnerabilities. and in the end those are just bugs, right? Those are either things you forgot about in your code

or those are mis-specified things. And so it's basically technical depth, right? It's not so much different than other bugs in your code that you have in your backlog and you just need to fix as a developer. And I think from that perspective, it's also more clear why that's a developer problem and should be owned by developers.

I understand, you know, we should be owning, you know, code security, but it is pretty, it's a pretty, it's a pretty mushy subject, as you say, it's a lot of things from the obvious null pointer exceptions to maybe not as so obvious buffer overflows, which are a little bit harder to work with if you're not aware of it. Of course, sometimes you use languages and that solves for it. As a software engineer, what are code security basics that every software developer should know in your mind? You just mentioned buffer workflows. I think the key is, you know,

for developers in those basics, they need to only understand how to prevent those issues and how to patch them. They don't need to understand the full exploitation techniques to run a buffer overflow attack, right? Like you can patch things without necessarily needing to run the full chain. And I think some of the basics you should be aware of,

I think the first thing that comes to my mind is to really know and understand what your code is doing. And maybe that sounds a bit silly and obvious, but that's how security. experts find basically security issues in your code. They try to look for corner cases and edge cases that you may have forgotten about or overlooked. And maybe in the time of, you know, AI accelerated development and using libraries and open source code, that's not so obvious anymore to say that we all the time know what our code is doing

and how it interacts with our code base, right? So I think one thing we can do here is to really look through the eyes of an attacker. at least when working on security sensitive features, what could an attacker do here and how could an attacker modify something here, right? The industry has been talking for a long time about this input validation, input sanitization, right? Maybe that's a good example here where... Never trust the input, right?

Any input. Yes, exactly. And this can be also a bit more subtle, right? Like if you upload a video to YouTube and someone pauses with their application, the YouTube video titles, then that's input basically, right, because you modify the YouTube title name. But then really making sure we think about this, where is all that, you know, get parameters, post parameters, cookies, external input used, and where am I using this in my file operation, which, you know, could be modified to open arbitrary files from attacker or, you know,

traditionally in a SQL query, you have a SQL injection in your HTML response page, you have cross-hats scripting and on those typical things. And I think we are still seeing those issues, right? They are the most critical ones and they have been around for a long time, but we still see those issues. And then Secret Leaks, I think, is another, you know, basic thing that is involved in many popular data breaches, you know, where to develop a hard code that basically, maybe just for testing purposes temporarily added, like hardcoded into the code, like a little API

token. So like the secret secretes like API token, well like all sorts of tokens, right? That should typically live in your like local environment variables. Exactly. Exactly. And it can be API access tokens or cryptography tokens or or a password for the database or whatever. Attackers nowadays, they crawl to public GitHub repositories, right, and steal those secrets and try to see if they're still valid. Even if you delete your code, right, it's in the Git history and it gets passed. So I think that's not a basic thing we should be aware of and not do. And it still happens because we are humans, right? So these were the kind of, I guess, the basics to cover.

Like, as a developer, is there like a checklist I could go through? Because, again, you listed a bunch of them. And depending on your level, you'll say these are super basic or like what are these things. But, you know, the parameters, SQL injections, secret leaks and some other things. Like, do you have a go-to list of like, you know, go-to? through all these things and make sure you understand each of these things and you can check your code or know if they will be applicable. It changes a bit over time. Also, you know, we are evolving and we are learning more about certain security issues and certain types of issues. We do less and then

maybe new types are becoming more prevalent, maybe also because how the landscape changes or how development changes. But again, I think those basic ones we talked about have been around for a long time and we still see them. They don't go. Apparently they don't go away. And what about the more advanced things that could go wrong? Because these were the basic ones, right? I think we just covered the basic ones.

But you must have seen some more exotic security issues that maybe would have not been as easily preventable or a lot more creative ones. So there are more advanced things in the terms of maybe expertise, what is needed. If we talk about cryptography things, right, if you know you're encrypting something and an attacker is still able to decrypt it, or there is some, you know, authentication logic or access privileges or passport reset functionality is also something where typically, you know, often things can go wrong. I think the key as a developer is to, for those more complex features, security features, is to not try to reinvent the wheel and just,

use, you know, solid frameworks or libraries is something that is vetted by the open source community and trusted. And I think here again, a security team can help you with that, right? One of the recent security issues that is coming up in the node ecosystem

is packages being poisoned where an attacker takes over some packages, they inject malicious code, and whoever is using a package or the downstream dependency of that package, They can be impacted. I think we've seen a crypto-related issue like this. In your view, who could best protect against these issues?

Would it need to be a security team who decides on things like pinning certain versions of packages or scanning updates for it? Or basically, as a developer, if I'm depending on third-party packages, what are good practices I can do to try to avoid some of these dependency security issues? which are now becoming more widespread. That's a tough one, right? Because everyone uses dependencies and your dependencies are using dependencies. And so it's quite hard to do something, right?

If you have this whole dependency chain and it's, you know, some developer of that dependency, a maintainer gets compromised. And then, you know, a dependency get back towards. You have almost no chance in having a security problem. When you pull in that dependency, you cannot not use dependencies. I think the only thing what you can do here is to have tools in place and this is like software composition analysis is a thing here

that basically observe and check your dependencies for known threats, right? At some point, luckily, like the NPM package you mentioned, became known to be vulnerable or malicious or back toward and then those tools basically get updated on a very frequent basis. to look what are the threats and what are dependencies you shouldn't be using in a specific version and then warn you about this and what is the next version you should use or that you should get rid of that dependency basically. And what is software composition analysis?

So software composition analysis is called SCAR. It's basically a technique where we look at manifest files, your list of dependencies, right, depending on the package manager you use. And then this list of dependencies is checked to a database of known security problems, right? Those are called the CVEs. Those are not the zero-day vulnerabilities we talked about earlier that you typed into your code, right? It's someone else. Some maintainer had a security problem.

Someone found that problem, reported it. It's documented in a database. And then, you know, you can basically, with software composition analysis, map that this specific log-4-j version of your library is vulnerable to the log-for-shell vulnerability. known and then it can warn you. And can you tell us about the CVE program? I understand inside Security Circle this is very well known and very useful, but what should I know as a developer about this? And how much should I kind of look it up, check it, worry about it?

It's run by Mitre, right? Like the US government, there is some change happening here. So that's the common vulnerability enumeration is the CVE list. And it's a database where it used to be kind of like the central database. for documenting known vulnerabilities. I think it's just too many vulnerabilities reported every day. So I think there's a bit of a bottleneck there. And so there are also other databases evolving or places revolving

where security issues are collected and gathered. And SCAR tools typically use that CVE database, but also other resources to collect all kinds of known vulnerabilities to make sure they know about all potential threats. And as a software engineer strictly focusing on, you know, I'm trying to make my code secure. Do you see value in kind of trying to keep up with CVEs, with new vulnerabilities, or do you see this being more of something that you really need someone who is dedicated, focused on this, may this be a security engineer? I'm just talking from a practical perspective, you know,

if I'm working at a scale up where we have a mid-sized team, maybe have one security engineer. And I really, really want to, you know, do my best work to try to, security is important in our domain. Do I take some of this on me? Or do I say like, hey, let's, if we really need about this, let's get more resources, dedicated folks who can help with, you know, the kind of depths of the industry. Yeah, I would use a tool for this, right?

It's a problem that you can automate. And I wouldn't hire more security team members for this. So you can use software composition analysis. you know, it will automatically check all the dependencies. There are, I think, in the database, like over 200,000 CVEs. And every day, I think there's like 50 new CVEs coming out, not necessarily, I think, in open source libraries, right? Also in known products, et cetera.

But I think it's not a good use of your time as a developer, but also not as a security team member to look at, you know, every single CVE that comes out. I think you should then have a good tool. tool in place, a software composition analysis tool in place that helps you to detect those, but also helps you in fixing those, right, which is much more important than building a huge backlog of security issues. The important thing is that you can also fix this and get some advice on how to fix this. Johannes just talked about how it's a no-brainer to automate much of

your security analysis, like keeping up with the latest security vulnerabilities. In software engineering, using the right automation and the right tooling means that you get to focus on what matters, like building your product and not spend as much time on infrastructure. This is where a presenting sponsor, Static, comes in. Static gives engineering teams a toolkit for safer deployments. Featuregates, gradual roll-offs, and experimentation, these are built into your release process. So you ship changes to 10% of users, then expand to the remaining 90%. You validate behavior, measure real impact, and scale only when things look good.

If something goes wrong, you can instantly turn it off before it affects everyone. To support this, Statsing includes product and infrared analytics, built in tools for logging and tracing, so you can actually see what your code is doing in production, performance, errors, user behavior, all in one place. Because you cannot secure what you cannot observe. For teams for strict data governance or security requirements, Statsk also offers warehouse native. Your user level data stays in your data warehouse, snowflake, BigQuery, data bricks, whatever you use. Full control inside your security boundary, and you get the deployment safety and observability,

without shipping sensitive data to external systems. Companies like Microsoft at Lash and NMbrex use Statsk for safer deployments with enterprise-grade security. Statsk has a generous free tier to get started, and ProPricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to Statsic.com slash pragmatic. With this, let's get back to Code Security with Johannes.

And recently, you've produced a state of code security, a report, which is a pretty comprehensive, as I understand. What are things that you found there? Yeah, so at Sonner, we scan 750 billion lines of code daily, right? So our analyzers see quite a lot of code, and we studied like a subset of this. We took 8 billion lines of code that was written by 1 million developers of 40,000 organizations globally, so quite a data set.

And then we looked at what are the issues we see. And I think one finding was that every about 1,000 line of code, we see a security issue and that reflects kind of well my feeling of when I manually audited code. So every 1000 land of code and issues is quite a lot, I think. And then the issue types we found and saw were the basic ones we talked about, right? The most in the top five at least, right, there was lock injection, cross-head scripting, SQL injection, hard-coded passwords, the typical things that go wrong. I think some surprises were in there about regular expressions, for example, was something

that we are typically, or more often apparently, you know, we have a slow regular expression or insecure regular expression, which can lead to denial of service attacks. And so that would be something more out of the lines. But yeah, the basic ones are still very prominent today in code. It's very interesting because you're saying every 1,000 lines of code roughly one security issue.

That's funny because lines of code, we always argue about. Is it a good measurement of things, you know, complexity, work, what not, or is it not? But I guess you're still using this heuristic, right? I mean, it's a statistic we build for the report, right? But I think, yes, I think

what comes down to that is that quality here is really connected to security, right? I mean, you could solve certain problems with more lines of code or with less lines of code. And I think a quality is something here

that is very related in terms of when you have more lines of code, right? There's more, you know, code to review, basically. And it's harder to spot security issues in the end. Well, if you do it in a well-maintained and structured way. Exactly. This was exactly my feeling on this. So, like, what would you say?

How was the quality of code related to security? Did you see any findings on this? Yeah, I think it's super related, right? And I think it's totally underrated in the industry today. we talked about the null pointer exceptions or the slow regular expressions, right, that can lead to security issues and that's more maybe the obvious examples of bugs.

But also if you think about unreadable codes, not well-maintained code, right? It's kind of like spaghetti code. Then it's not so obvious at first, maybe how this is connected to security. But then if you think about that code is not easy to comprehend, not easy to review, and you do pair programming

or code reviews in your development team, then in that spaghetti code, you will more likely oversee security problems of your peer. And then also if you think about fixing security issues, right, like now maybe someone found an issue or found later an issue and reports that back to you and you as a developer have to fix it. Think about if that's not well-maintainable code, you cannot fix the problem, the security problem.

So quality suddenly becomes a security issue in a sense that the attacker window stays open longer. At some point, you have to fix the issues. And so I think your code quality is super related to code security, especially now with AI generated code where we see typically poor quality of code, right, and that becomes a problem for security. When we look at code security, how does that relate to cybersecurity as a whole?

So there are many fields of security, right? There's data security, cloud security. network security, forensics, as a larger organization, you kind of need all of them. And they are all interconnected and they build multiple lines of defenses.

From my perspective, from an offensive security perspective, I found application security always the most interesting field because if you think about, you know, every organization today basically deploy software, they ship software as a product

or they deploy some services online to have customers interact with their business. And so those applications are online 24-7, right, and they're available to me as an attacker. And that's the, you know, at the forefront of security and typically the first entry point into the network. And so that makes it so critical or so interesting for attackers, the application security field. Whereas the other areas, you know, more try to prevent the lateral movement. Once an attacker is in, can the attacker maybe not decrypt the data he stole or can the attacker and not, you know, move from one server to the other.

What is that all movement? Yeah, so typically as an attacker, you would, you know, gain your first entry point into a network and then maybe you want to expand from there. So you have a shell on one server. You can control a server or a machine. You can run system commands. And then you would, from there, you know, you are in the internal network and try to see what other services can I reach, what other internal things can I access.

And then you need a security strategy, basically, in the broader cybersecurity, strategy to prevent that lateral movement between internal services. One idea that comes to me about lateral movement. With the advent of AI assistance, MCP servers, it's probably going to be a pretty tempting attack vector for just thinking as an attacker, hey, let me try to get access to that developer's machine. You know, I'll set up an MCP server that says it does something, but secretly it does something else.

It runs locally. boom, I get access to this developer's machine. As developers and as security professionals, how much should we worry about this? And are you seeing any worries about this specific attack vector? Because I feel until now, developers' machines were kind of a little bit off-limits,

or were they off-limits? Yeah, I mean, developers' machines, I think, are not off-limits, right? I think supply chain attacks is a big topic where, I mean, developers are building software and then software is deployed on all the organizations worldwide, right? And that makes it so interesting. So we talked about an NPM package that gets compromised by compromising a developer's machine,

basically, right? And then from there, you can compromise a super popular dependency, right? Or if you're a software window, you better make sure the software that is shipped to thousands of organizations maybe is not back to it because some developer got back toward. And yes, I think also with agents and giving away more control, there is a new threat here because it's not just about the dependencies you're using or your machine security in general, but also making sure that the agent you're using is doing the right thing and doesn't have the privileges to do something accidentally or on purpose, as you said, to do something harmful. like if the agent passes a gyra ticket and something is, you know, someone can create a malicious gyra ticket that instructs basically to agents to add a backdoor and just instead of just solving a development problem, then you suddenly have a new, you know, type of security problem

to think about. You previously mentioned that if you can automate things as for code security or application security, you should try to do that. What are the common code security tools that you keep seeing? engineering teams use for security hygiene? Like what are the categories that I can think of? I think every developer uses an IDE, right? So there's some basic linting available in IDEs, and that's great, right? Because as you type, you find issues and you can resolve them. Just that in an IDE typically, you don't have such a broad or in-depth security coverage built-in,

right? There are some IDE extensions you can use, but then typically you stay at the linting side. That means some syntactical and semantical checks. And typically in the current form, you're working in simply out of performance reasons, right? Because it has to be done in milliseconds as you code and shouldn't slow you down. And then you have static application security testing tools, SAS tools that can go more into a deeper level of code analysis, right? So depending on a SaaS tool you use, there is, for example, symbolic execution or taint analysis techniques used

where your whole code base is transformed into an abstract model, basically. and then it's simulating static analysis is simulating what could happen here at runtime it's not executing the code right but analyzing this and connecting what we talked earlier about user inputs for example how are they flowing in terms of data flows through all your code paths and simulating what could go wrong here to find different issues

and can you just give us a high level of what is happening because this sounds super interesting what I understood and tell me if I got it right is you take your code and you kind of turn it into like maybe a graph of some sort and then you can try to figure out kind of inputs, how they can flow, how they can get to components. Yeah, exactly. So your code is transformed into a big graph model. This can be any dimensions. Yes, right. So basically every file of your code base, every function.

every if else basically so whenever the control flow of your application changes every function call every if else is a part of that big graph model right and then you try to figure out what are all the combinations where your variable assignments which create data flow basically where is user input received in that application and then passed on with data assignments through different if else and function accords, and where does it end up in something security sensitive, right?

And this can be very, very long data flow paths and very complicated to do right and also to do that efficiently, right? It used to be taking days and now we can do that in minutes and that's a very hard problem to solve. But it helps you to automate that process, right, what we talked about earlier, where you should be mindful of what is user input. it helps you to automate that and find even very tricky and long connections between user input and something security sensitive. Okay, so we talked about the kind of linters inside IDs, the SAST SAST SCS-S-T scanners that you said.

Are there other tools worth knowing about? I mean, secret detection, we talked about hot-coded passwords or, so there are secret detection tools. There is infrastructure as code scanning, right? If you think about code more broadly, it's also infrastructure is code or your GitHub actions file can be code, right? And their tools to scan this. Typically, if you have a good SaaS tool, that's all covered by static analysis, basically, right? Because everything can be considered code here. And then we talked already about software composition analysis as another tool for developers,

where you find those known vulnerabilities, those CVEs in your dependencies. I guess this is a layered approach, right? So the more security you'd like, the more of these layers you would set up. But do I sense that there's a tradeoff between them? It's going to be maybe complexity, time to run, those kind of things. Like what is the downside of just like throwing all of these tools onto every single code base I have, even if I'm a one-person startup, right? Like, why would you not recommend that if you would not recommend it?

Yeah, I think, I mean, for the basic static analysis tools, I would definitely recommend to do that. I think here what you should be careful of is choosing something that is intended to be used by developers and not by security teams, right? We talked about the noise level that is interesting for security

teams from an audit perspective, but deadly for your product development or productivity where you shouldn't be annoyed and I think that's something to watch out for. And then there are differences, you know, for

SaaS tools and SCAR tools if they are more for the security teams or for developers. But I would definitely recommend, I think, at all levels to run static analysis and software composition analysis to have your basic security hygiene in place. So these are static tools. They, after you run the code, they can run on them, they can run on CI, they can run with continuous deployment. Are there kind of more dynamic tools? And I'm just kind of thinking of the idea that, you know, as your code,

runs as your servers operate that dynamically try to test or just do funky stuff? Absolutely. So there's dynamic application security testing. We talked about penetration tests, right? And the dust tool tries exactly to automate this, right? What is dust? Dynamic application security testing is testing from the outside as a black box when your application is already running on the test server or in production.

and it's basically shooting all kinds of malicious payloads from the outside against your application to see how it reacts and is it breaking or, you know, is there a delay? Is it behaving weird or throwing an error message? And in this way, trying to automate such a human penetration test to find out if there are issues it can detect. And then there's also on the dynamic side of fuzzing, which is similar to dust, basically, where it's more for embedded software, you know, binaries, CC++ libraries or applications where typically you pass complex formats or protocols like file formats

and then you want to flip every single bit basically in what you're processing to see if something breaks, right? And you can automate that with fuzzing and then find those crashes. So that works very well. I just think that, you know, those more dynamic tools are not so much for developers. today because you are a bit disconnected from your coding and you know you have to contact switch basically because you cannot find things as you type you need to kind of like finish what you're doing deploy it on the test server get a run and then the

feedback loop is just a bit longer and so I think for for developers it's it's more inefficient but for security teams is it's a great tool to have to to additionally maybe run a dust or a fuzzing, right? Yeah, and as you say, it sounds like a bunch of setup to do just one more thing. Like, I can see why you're saying that it's more for a security team. One thing you haven't mentioned, but I was waiting if you would mention AI security reviews. These are, you know, popping up everywhere. There's a lot of different tools, a lot of different vendors, some existing ones.

And they're all saying the same thing. Use this thing. it will make your code more secure. What is your take as a software professional? I think it's super fascinating and fun to see, right? And also impressive what AI can find today. You know, as with static analysis or every other technology, to me, it's not necessarily all about just finding issues,

at least when you want to use that in a systematic way as a developer. Here you have to get into a good balance of, am I not only finding things, but how often am I reporting things that are actually not a true or a meaningful issue? And can I scale this to half a million lines of code, et cetera, right? So I think what we are seeing more today is, you know, security research agents

that go in and randomly find issues. You know, it's a great tool for security teams here. But as a developer, you want to have, I think, something a bit more systematic that finds all code security problems. And you mentioned maybe to me there's another aspect of being deterministic versus non-deterministic. Here, the AI basically is non-deterministic.

And I think, you know, again, for a security team, that's not so important, but as a development organization, you need to have basically like a quality gate and that's consistent across your team and all the other teams that always has the same output and you cannot fail your gate because randomly a new issue is popping up or disappearing, etc. So I think that that doesn't really work well for developers today. And lastly, to me, from a developer perspective, right, there's also a bit of a contradiction if you think about most or a lot of code is written by AI itself, right, depending on who you ask. and if you then use AI to review AI generated code,

that's a bit having students grade their own homework where you would think that if AI didn't, you know, could prevent actually generating a security issue, why would it later on detect that security issue? So I think we need to have good guardrails and verification in place that is not AI to verify then basically this AI generated code. I can see where you're coming from, although I can also see some people might say like, well, what if it's a different AI?

What is a different LLM? Like different, but I, I, we're still not, you know, we're just chasing one another. Like, we're still not changing the core problem here. And earlier you said that AI can generate low quality code. And this could be an issue when we're talking about the lines of code per security issue. Can you go a little bit into more detail and what you're seeing, observing, what does low quality mean in in this sense or is it the verbal nature that we're sometimes seeing.

So for example, at Sonar we did great studies of the most popular LLMs like Claude Sune, GPD4, 5, Lama, open coder, etc. And we looked at the, what we call personalities of them, right? How do they,

what kind of issues do they produce and what kind of quality are they producing and then measured what comes out of that and studied this? And one interesting finding to me was, for example, that if you use the reasoning mode of GPD5, it actually decreases, not eliminates, but decreases the number of security issues you find,

but it's using more robust, you know, output to solve the development problem. It produces more code, actually, right? And this is then, again, something that leads into security problems because you have more low-quality code that maybe have less security issues itself, but then poses a problem maybe combined with other snippets of your code or it's harder to review by your peers or later on

and it's less maintainable and leads to a security problem. This reminds me of there's this like old saying before AI that code is a liability. The more code you have, the more liability you have. And this was a reason that back in the day, an experience engineer would sometimes spend a day or two reducing the lines of code, refactoring, compressing it, bringing single responsibility, moving duplication.

And I wonder if we're kind of forgotten this a little bit, that the more lines of code you have, I mean, just taking your statistic of one security issue per thousand lines of code, let's just take it for now. Like, yeah, like, you know, like you would want to have kind of an efficient lines of code, right? Like you do want to spend that time and effort of getting to a system that is simple, clear responsibilities, are concise. I think this is something for that developers or engineers look at today already, not just to vibe code and accept all the code, but to actually make sure that the code makes sense and is well structured for all kinds of purposes, right, to maintain a good architecture in your code base, right? and to have a good maintainable code,

etc. Outside of the security world, that's already a big code quality, a problem. And I think developers are aware of this. But then, yes, it adds for that security problem. On top of that, there was a nice survey by, I think it was Stack Overflow,

where I think only 3% of the developers ask, basically said they trust their AI-generated code and I think that's very reasonable. Yeah, I mean, when I'm using AI to build myself, my APIs and testing all those things, I also find myself, like, I give it instructions, and every now and then I also tell it to refacture some things, to move things around as I'm watching the output. I just see something is getting bloated. You know, I have an index.t.js that is getting this big.

I'm like, all right, let's pause. Let's refactor. But I do this because, again, you know, like years of building software, I know that it's just going get a mess, I'm not going to be able to navigate. And for me, it's important that I need to understand my code. And I need to have the structure for that. So I guess this doesn't change. And maybe the people who are vibe coding, they're going to come around to learning the

same lessons that, you know, we all learned the hard way. Yes, I guess. But how do you think AI is changing code security and also security in general? What impact you see it's already having? I mean, there's definitely a change, right? I think, I mean, even for our security tools, I think there is a big. change in the sense that it's very powerful and helpful. So even if you run deterministic algorithms like static analysis to detect issues, you can still

enhance that deterministic algorithms with AI, right? So for example, we talked about the taint analysis. Your deterministic analyzer needs to have a lot of knowledge about all the libraries and frameworks that are there and there are millions, right? And so AI can help you with gathering knowledge and information and then feed that into a deterministic algorithm. So you can combine technologies, and that's definitely changing. I think the static analysis, but also dynamic analysis and auto security tool areas.

And then what we are also seeing is, you know, fixes work quite well. Like if you throw half a million line of code, you know, into the context window, it's not working so well. But if you just throw in, you have a very specific task. If you say, here's a deterministically found security issue, here are the 20, lines of code and that's the problem. And then AI is very good in fixing those issues, right?

So that's very helpful because it's about fixing and not just detecting and AI is super powerful here. We also see like a change in how code and applications are built, right? So if you think

about applications traditionally you have this backend front end and in the backend is a database. If you remove that database, then you don't have a SQL injection anymore, right? But if you add an LLM to the backend, then you have a prompt injection, maybe, you know, another vulnerability where the attacker, you know, can modify the system prompt or your prompt engineering and then mess with the LLM's logic or the output.

And that's becoming then, you know, sort of threat landscape changes and attackers adjust for it. And certainly the tools and the industry adjust to this. And that's maybe taking a bit of time, right? think about all the COBOL code we are still seeing. Yeah, but I guess we can add prompt injection, right? We can pin it up there with a SQL injection. In fact, who knows, prompt injection might become even more of a security issue. Yeah, I think as, you know, text becomes code, right?

I think prompt injection is kind of like the new code injection, right? The human language is the new code. And so if you inject human language, then suddenly that's your new code injection. So that's interesting from a security perspective. And what about with coding assistance? Are you seeing things change with in terms of how we think about code security? I mean, I think the big problem in terms of security is that you, you know, produce just code much more faster. And writing code is not the challenge anymore.

And so suddenly the new bottleneck is how are you verifying all that code, right? That's a new bottleneck, not to get your code done, but to verify it, that's actually secure. And if you don't, then that leads to security issues or quality issues, which then on the long run lead to security problems, right? So I think that's the big new challenge for security or code security. How do you verify all of that faster produced code at scale and at speed? And what is your take on what is working so far? I mean, the obvious thing that I'm hearing a lot of engineers and engineer leaders say is like, well, we need to scale code reviews. We need to figure out ways where humans can look at code reviews, you know, like more of them,

meaning let's add tools to them, let's add additional context. But outside of that, do you see some other maybe promising areas where we could actually verify strictly from a security perspective, like, is this code secure? Yeah, I think you mentioned already the key things, right, to add tooling, to automatically verify a code as you produce it. I think there are also areas where and Solar Source is pioneering something here in the field where

you basically look at how are LLMs trained and you make sure the data set that an LLM is trained on is actually free of common security issues and if you do that and train your LLM on high quality code on high quality data free of security

or quality problems you are producing from the beginning right much more secure code and that's maybe another thing where in the future we will see more of this. And speaking of this, again, because you see a lot of code, you do a lot of security analysis,

do you see AI generated code introduce different types of security issues than humans would do, especially because we know that elements are trained on human code in the end. I think they're doing the same mistakes for the reason you mentioned And maybe the prevalence changes of certain issue types, right?

The issue types don't change so much. But what we are seeing, for example, slop squatting is a good example where, you know, AI proposes to use a library that doesn't even exist, right? And then so an attacker can register in NPM or Maven Central that package, that non-existing package, and then with that you suddenly include a malicious package and there's a backdoor. And so this security issue was known before, and we had dependency confusion, but it's just less likely that a developer mistypes a dependency, while with AI that prevalence changes suddenly, right? There is an acceleration of that. While other issues maybe decrease, right?

I could imagine, I'm not seeing this for now, but I could imagine hard-coded passwords, like some issues that are just one-liner issues maybe decrease a little. because AI is able to learn that, you know, I shouldn't do that. And then we could see a reduction of, you know, those issues. Still, human developers can add them, but maybe the more AI generated code is used, we see less of them. And then maybe we will see more of the complicated issues, right? Issues where you need to combine multiple code snippets with each other to form a security issue that is then not so easy.

for AI to grasp. And so definitely, you know, some changes and the prevalences of what we know of already today. What are some commonly misunderstood things about the security industry, things that, you know, we could call them fallacies? I mean, I come from the security industry, right, and I moved more to the developer side over the years, I would say. And now, you know, stepping a bit back for a moment and looking at the security industry, it's quite fascinating how we have to separate.

industry and community from the developer community, right? We both talk about code and bugs, basically, but one side is maybe more about building things and the other about attacking and destroying. And so they are a bit distinct somehow and separated.

That's interesting to me. And I think one fallacy that comes out of this is, you know, that the security industry is all fascinated about the security problems and then is selling products, basically that promise, you know, you can have security just as a product, right?

And I mean, there's a lot of money in that industry and it's driven by, you know, compliance and fear of data breaches. And so I think as a CISO you have a hard time knowing, you know, what product should I use and buy. And often I think a mistake here is to look at security as a product and not as something that you are building into the process of development, right? Because I think in reality, that's what you must do and not have a tool that finds you yet another 1,000 issues if you hit the scan button, right? But something that embeds into the process, finding issues, but then engaging developers and helping you fix things.

And I think that's the biggest fallacy to me. We talked about the ownership that comes with that maybe, right? I think there is a bit of this mysterium about security and it can only be owned by experts who are top-notch hackers, etc. where I think the lines are a bit more blurry

here and it's more about fixing things and not just so much about the exploitation stage all the time that the security industry talks about and finds fascinating. And I myself am guilty here and find fascinating. Lastly, maybe this there is no perfect security.

If you get, the understanding of the security industry, then maybe that's a fallacy here that, you know, there is no perfect security, unfortunately. Yeah, this thing about vendors selling products, promising, you know, your organization will be secure, your code will be secure.

And the fact that the reality is Wolfmore, it doesn't really work like that. Like you need teams, you need people who care about it. Sometimes you can, I guess, you can have a team that uses zero security tools producing really secure code because they're just experienced engineers or working in the domain that they understand. And you can have the other way around as well. Like you can have a team that has all these scanners and whatever and their code is still like not good, not good and

unsecure. It reminds me of the developer productivity term like how productive are my engineers. And again, there's vendors selling all these tools saying, hey, measure this and you will get this. And we just see the same thing. So I wonder if it's just a thing of there are just some things that are just hard because there's a lot of moving parts. You cannot just measure just one thing because we can optimize for that and still the outcome will not be great. I wonder if there's just some areas. Developer productivity is one, security. Maybe software is just hard.

It is, right. I think the more complex software you write, and every developer knows this, right, the more problems you have, hard problems you have, you know, bugs you have, and also the more security problems you will run into. And that's just natural. We have a great vulnerability research team at Sona. And so those guys are, they are picking the most popular open source projects in the world

that are deployed everywhere with great communities, great maintainers, bug bounty programs, where people get paid if they find something, et cetera. And it's fascinating to me. Every time they choose such a high-profile target, that they go in and they still find something, right? If you're motivated enough and look hard enough, I think you can find something. And unfortunately, that's the reality.

As a software professional, as a security professional in the field for 20 years, what can you advise to me as an engineer? How can I know that my software is secure enough or at what point should I stop? And how would you think about this? obviously there will be differences between if I'm a one person, you know, tiny business, a mid-sized company at a very large company. How would you advise engineers to think about, you know, good enough security? Okay, I can move on.

This is good. Let's do the other stuff. Yeah, it's tough because we said it's, you know, perfect security is hard. But then to the question, what is good enough and how can you solve this? I think using tools is a, is the. first thing you should use, right? I think, you know, it's like a bit like securing your house, right? Like you should make sure you shut your windows and doors and have some basic hygiene.

It doesn't mean that a, you know, highly skilled or funded techer can break in. But you can make sure you shut those windows and doors. I think with software, the challenge is a bit you're adding new windows and doors every day, basically, like with new features you're adding. And so I think you need some automation for that. to have your basics right. And then I would recommend, basically, you can start with an initial assessment. Where am I standing today, right?

Like you can hire professionals or use a tool for this and kind of like assess where do I stand today, what are my most critical issues I should fix and get them fixed. And then more importantly, as you're adding features and as you're coding, making sure you're not adding more on top of that, right? making sure you're not adding more security vulnerabilities and also you're not adding more technical depth that in quality problems that in the long run lead to security issues and I think here automation is key basically and then you know after a quarter or something you can run that assessment again and look at where am I standing and hopefully you have been you know very productive

as a developer and adding new features that didn't slow you down but also you you increased your security posture at that point. It's a never-ending story. And it's a growing field, right? Like, we always need to be aware of the latest changes. Right now, LLMs and prompt injections. You'll probably need to ask yourself, as Mike, if I'm

building on top of LMs or I'm invoking APIs, can they go in there? And then, you know, the next thing will come again, and the next and the next, and next. I guess keeping an eye on the OASP top 10 is never a bad thing, just to cover the very basics. Yeah, I agree. Now, as a closing question,

I'm going to put you on the spot here. Which programming language do you think is the most secure? The one that you are very happy, either is using it or observing as like, okay, this is, the language itself seems to help prevent a bunch of security issues to start with. I think the newer languages are more secure. Like Gov is a good example. I think, you know, by default, things are just, you know, a new language. learned from the past, from older languages,

which goes wrong. But I think also other languages are evolving. I think Java, we see that a lot in enterprises, and I think it's quite secure to use. So that would be my answer here. I like that you dropped go. It's getting pretty good traction with startups as well, including for now even building web stuff.

It's picking up. So I guess it's all down to people's tastes, but it's good to hear. So, Johannes, this was really interesting. Thanks for coming on the podcast. Yeah, thank you. My pleasure to be here and thanks for the invite. Well, thanks very much for this.

Thanks a lot to Johannes for taking us deeper into the topic of code security. The thing that I found the most interesting is just how hard it is to define exactly what makes code secure because there are simply so many impossible attack vectors. From using a dependency that gets compromised to AI generating code with glaring security vulnerability, like not validating inputs, to accidentally leaking credentials, the list just goes on. Security feels like this invisible thing across software. As long as there's no security issues discovered, it doesn't get much attention, but once there is, then there's a scramble on what to do. As a professional software engineer, we need to keep ourselves up to date with common security

vulnerabilities and how we can defend against them, including the new ones that AI tools introduce. For more details on security engineering, see the pragmatic engineer deep dives linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you on the next one.