What are code security basics that every software developer should not really know and understand what your code is doing? Maybe that sounds a bit silly and obvious, but that's how security experts find basic key security issues in your code. I'll set up an NCP server that says it does something, but secretly it does something else. It runs locally with agents and giving way more control. There is a new threat here because it's not just about 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, as software engineers, what should we know about writing secure code? To answer this question, I turn to Johannes Donz, who has been a security expert for 20 years and is currently VP of code security at Solanar. 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 analysis. How AI coding systems 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 Statsig, the unified platform for flags, analytics experiments and more. Check out the show notes to learn more about them and our other seasoned sponsor. So Johannes, welcome to the podcast. Thank you, it's a 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 was infected, I think it was a SaaSa one back in the days and I was super frustrated and also super intrigued, like how could someone get access to my computer and so that me into playing with security things like Trojan horses and that stuff at school time. And then I moved to Bournemouth City in Germany where you could study IT security and it was exciting. And so they played Capture the Effect competitions, right?
Those hacking competitions where university teams connect online in isolated environments, and they try to hack each order to get points and I got really obsessed playing those competitions and there was a best learning experience for me. And this led into getting into professional penetration testing, writing tools to assist the vulnerability hunting and this led into a startup which got acquired by Sonar, where I'm today, how can we match up penetration testing? So penetration testing is simulating in a tech 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 application 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 and games to do then kind of earn money with that as a student to also look for security issues as a professional. And I understand that you can now hire penetration testers as the company, like an hire teams that do this, but did you do some of this? Did you do professional penetration testing? Yes, absolutely. 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 by exploiting vulnerabilities in 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, all right, come in penetration testers, how do you actually go around to actually give you access to some of their systems or you need to just assume no knowledge? How does that work? Yeah, the 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.
Now you typically 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 get access to the database or something where there is some data as something that could be sensitive to the business that is then security critical.
Do you bring your own tools there? Do you have like methodologies? Like I guess, you know, like it's very basic, but I do know of the concept called port scanning where you write up 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. But what kind of tools do you come with? You do use search tools in SAP administration testing. 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 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 try to poke and see what breaks when you touch it and when you play around with it.
That's also the most exciting part, I think. In the real world, we're going to be sitting 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 people just like playing around poking around and 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? In the industry today, what we're seeing is, that is a shared responsibility basically, right? So we talked about penetration tests and typically security teams are involved in that. And then there is still developers 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 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 the 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 also worked as a security engineer. At what point do the 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? As a developer, 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. I tend not at all. We talked
about the penetration test that's typically something run by secure teams. And so I think the field of 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 organization-wide initiatives, security initiatives or the vulnerability reports coming in from the 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 to, I think you need a security team. I just think that when you write software and when organizations
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's part should be fully owned by developers, right? I think it's a waste of time to look at every single new cross-site scripting issue again and again and try to exploit it and build some fancy exploit and risk assessment where as developers could just fix issues as they code and move on. And that also allows them to secure 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 their expertise for developers. So I'm kind of hearing some similarities between the kind of feature teams or program teams and platform teams, where 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 a large data storage company and then engineers that kind of use the APIs, but they don't need to know all the details, but when they do, they can just go to a platform team saying, hey, how do I store, you know, like two petabytes of data and there are different ways you can do it. So do I understand
correctly that your kind of 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 devs to like self-service or share common things to watch out for. Yeah, exactly. I think it's a good comparison, right? Definitely helping but also leaving the majority of ownership there was developers, so they can basically have security as part of the process of development and not just something that is, you know, attached to what Attock run and whenever the security team 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 all that historically. I don't think software engineers owned security or were expected to own. Can we talk about how this changed over time, over your 20 years, how you've seen changes happen? Because I do feel it's shifting left on onto 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 with the security team come in and do a final audit, right? And then you would release and today we're just moving at a much more faster pace, releasing a couple of times a day or a hour, right? And you have AI coding assistants and so we're moving a lot faster now.
Johanna just talks 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 slide 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 seasoned sponsor, Lineer, can help dev teams stay focused. Sierra is an AI
power 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 Lineer as their operating system of the company and wired all of their work into the platform. Today, project-obbasing Lineer rippled through Slack, customer requests are logged in Lineer, and SaaS from Lineer 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 HyperGo, 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 Lineer wanting to know what individuals they don't get in a week. They wanted to know what was accomplished in service of which projects. This is the beauty of using Lineer. It helps HyperGo companies stay focused, spend more time building, and let's time coordinating. If your team cares about tools that remove additional work for the team instead of adding extras to it, check out Lineer at Lineer.app.pragmatic. And now let's get back to fast
moving engineering teams and security reviews. You cannot have this disconnected security review that you do afterwards. In the industry, what's also changing here is the tools that you need for this. Historically, the tools are built only for security teams. With that, there is a different product philosophy that comes with security products. As a security audit store, you want to
know about every single potential issue. You want to turn every stone and better look twice. They never have to find out what could go wrong. If you apply this to this new pace of fast development, that doesn't work anymore. You cannot get interrupted all the time with findings. It's too noisy. I
like to compare this with if you drive a car and have a security guy and passenger seat and he would scream and yell at you at every single thing that could go wrong all the time. That's maybe interesting the first 50 meters, but then gets super painful and annoying. I think with that, we see a change in the industry that developers should own code security issues, but also the tooling around code security issues must be owned and for developers. Then there are other application security tools and application security as a broader thing that should be still owned by security teams. So far, you've mentioned two different things, or if I caught this correctly. One was
code security and then application security. You said that application security is a lot more than code security. It's a super set up of it. What is code security? This is one of your expertise as I understand, but how do you define that? Where does it start? It does sound like
something that as a software engineer, we should be aware of it. Lack of a definition, I would say it's basically code that is free of security issues, free of anything that can be leveraged by an attacker to exploit your application and then get access to some of your data and put your business address. But with that simple definition, I think that the complexity is a bit what are security issues when we say code is free of security issues. I think here, we think typically as vulnerability is equal injection, vulnerability. I think it's much more than this. If you think about bugs like an
output exception where your application crashes, then your application is in an unintended state and this can be used by attackers in some scenarios. Or maybe a more obvious example would be memory corruption problems in C++ where as an attacker, you can do a buffer overflow and execute code on your server. I think the lines get more blurry and they are more logical things. If you write an application where you can upload a profile picture, you shouldn't forget that an attacker couldn't be able to upload a shell to your server and those kind of things. I think we are realizing that code security is much more than just vulnerabilities and in the end those are just bugs. Those are
either things you forgot about in your code or those are miss-specified things. It's basically technical depth. It's not so much different than order bugs in your code that you have in your backlog and you just need to fix as a developer. 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, we should be owning code security but it's a pretty mushy subject as you say. It's a lot of things from obvious
no point or exceptions to maybe not as obvious buffer overflows which are a little bit harder to work with if you're not aware of it. Of course sometimes use languages and that's all for it. As a software engineer, what are code security basics that every software developer should know in your mind? You just mentioned buffer overflows. I think the key here is 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. You can patch things without necessarily needing to run the full chain. 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 AI accelerated development and using libraries and open source code. That's also obvious anymore to say that we all the time know what our code is doing and how it interacts with our code base. 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. The industry has been talking for a long time about this input validation, input sanitization, maybe that's a good example here where it never truss the input. Yes, exactly. There can be also a bit more subtle. If you upload a video to and someone passes with their application, the YouTube video titles, that's input basically because you modify the YouTube title name. But then really making sure we think about this,
where is all that get parameters, post parameters, cookies, external input used, and where am I using this in my file operation which could be modified to open arbitrary files from the attacker or traditionally in a SQL query or SQL injection in your HTML response page, your cross-site scripting and those typical things. I think we are still seeing those issues. 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 a not a basic thing that is involved in many popular data breaches. We are developing a hard code that basically, maybe just for testing purposes temporarily, added hard codes into the code like a little API token. So like secret secrets like API tokens, well, all sorts of tokens,
that should typically live in your local environment variables. Exactly, exactly. And it can be API access tokens or cryptography tokens or passwords for the database or whatever. It takes us nowadays, they crawl into public GitHub repositories and steal those secrets and try to see if they are still valid. Even if you delete your code, it's in the Git history and it gets passed. So I think
that's not a basic thing. We should be aware of it and not do it. It still happens because we are humans. So these were kind of the basics to cover. As a developer, is there a checklist I could go through?
Because again, you list a bunch of them and depending on your level, you'll see these are super basic or what are these things? But the parameters, SQL injection, secret leaks and some other things. Do you have a go-to list of go 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, 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 away. And what about the more advanced things that could go wrong? Because these were the basic ones, right? I think we discovered the basic ones that 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, you encrypting something and the attacker is still able to decrypt it or there is some authentication logic or access privileges or password reset functionality is also something where typically often things can go wrong. I think the key as a developer is to put those more complex security features to not try to reinvent the wheel and just use solid frameworks or libraries or something that is vetted by the open source community and trusted. And I think here again, a security team can help you with Searchlight.
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 a 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 some developer of that dependency and maintain that gets compromised and then it depends on you 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 software composition analysis is a thing here that basically observe and check your dependencies for known threads, right? At some point, luckily, like the NPM package you mentioned, became known to be vulnerable or malicious and were back towards and then those tools basically get updated on a very frequent basis to look at what are the threads and what are the 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, 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 not the zero-level
vulnerabilities we talked about earlier that you typed into your code, right? Someone else, some maintainer had a security problem, someone found that problem reported it, it's documented in the database and then you know you can basically with software composition analysis map that this specific log4j version of your library is vulnerable to the log4 shell vulnerability that is 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 Mitra, right? Like the US government, there is some change happening here, so let's see
the common vulnerability enumeration is the CVE list and it's a database where it used to be kind of like a central database for documenting known vulnerabilities and I think it's just too many vulnerabilities before the dev today 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 scattered to 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. 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 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 you 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 the depths of the industry. Yeah I would use a tool for this right it's a 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, I think in the database like over 200 thousand 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 etc but I think it's not a good use of your time as a developer but also not as a security member to look at you know every single CVE that comes out I think you should then have a good 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.
Yohan is just talking about how to know when you're taught of being 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 StatSick comes in. StatSick gets engineering teams that's so good for safer deployments, feature gates, gradual rules and experimentation these are built into your release process so you ship changes to 10% of users then expands to the remaining 90% you value 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
StatSick includes product and 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 with strict data governance or security requirements StatSick also offers warehouse native. Your user level data stays in your data warehouse, snowflake, BigQuery, Databricks, whatever you use. Full control inside your security boundary and you get to deployment safety and observability without shipping sensitive data to external systems. Companies like Microsoft and Laskion are used to save for deployments with enterprise security.
StatSick has a generous free tier to get started and pro pricing for teams starts at $150 per month. To learn more and get a 38 enterprise trial, go to statSick.com slash pragmatic. With this, let's get back to code security with Johannes. And recently you've produced the state of code security report which is a pretty comprehensive one as I understand. What are things that you found there? Yeah so it's not only we scanned 750 billion
lines of code daily rights, our analyzers seek 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 to quite a dataset and then we looked at what are the issues we see. And I think one finding was that every about 1000 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 line of code and issues is quite a lot. So I think in 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 log injection, cross-site scripting,
SQL injection, hard code passwords, the typical things that go wrong. I think some surprises were about regular expressions for example was something that we are typically or more often apparently we have a slow regular expression or insecure regular expression which can lead to the nail of service attacks and so that would be something more out of the lines. But the basic one that's still very prominent today in code. It's very interesting because you're saying every 1000 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, complexity, work, whatnot or is it not. But I guess you're
still using this heuristic right. I mean it's a statistic we built for the reports right but I think yes I think what comes down to that is that quality here is really connected to security. You could solve certain problems with more lines of code or with less lines of code and I think equality is something here that is very related in terms of when you have more lines of code. There's more code to review basically and it's harder to spot security issues in the end while if you do it in a well maintained and structured way. Exactly but this was exactly my feeling on this.
What would you say how is the quality of code related to security? Did you see any findings on this? 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 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 also obvious at first maybe how does this connect to security but then if you think about that code is not easy to comprehend it's not easy to review and you do peer 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 them back to you and you as a developer have to fix it think about if that's you know not well maintainable codes you cannot fix the problem the security problem so quality suddenly becomes a security issue in the sense that the you know attack our windows days 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 a i-generated code where we see typically a poor quality of code right and that becomes a problem for security. When we look at code security how does that relate to cyber security as a whole so there are many fields of security right there's data security cloud security network security forensics is 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 you know 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 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 so critical also 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 or 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're 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 lecture for just thinking as an attacker hey let me try to get access to that developers 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 developers machine as developers and as security professionals how much should we worry about this and are you seeing any worries about this specific attack factor 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 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 developers machine basically right and then from there you can compromise a super popular dependency right or if your 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 to it and yes i think also with agents and giving way 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 it 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 gyro ticket and something is you know someone can treat a malicious gyro ticket that instructs basically to agents to add a back door 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 co-security or application security you should try to do that what are the common co-security tools that you you keep seeing end dreams 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 like because as you type you find issues and you can resolve them just in an IDE typically you don't have such a broad or in-depth security coverage built in right there's some id extensions you can use but then typically you stay at the linting side that means something tactical and semantical checks and typically in the current file 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 that can go more into a deeper level of code analysis right so and depending on a sasterly use there is for example symbolic execution or taint analysis techniques where your code base is transformed into an abstract model basically and then it's simulating static
analysis simulating what could happen here at runtime what 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 it just sounds super interesting what i understood and you know tell me if i got it right is you take your code and you kind of turn it into like maybe a graph or of some sort and then you can try to figure out kind of inputs how they can flow how they can get components yeah exactly so your code is transformed into a big graph model this can be any dimensions yes right so so every basically every file of your code base every function every if else basically so whenever the control flow of your application changes every function called 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 you know your variable assignments which create
data flow basically where is user input received in that application and then passed on with you know data assignments through different if else and function records 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 needs to be taken days and now we can do it in minutes and that's a very hard problem to solve but it helps you to automate that process right and 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 limter inside IDs the SAS SaaS T scanners that you said are there other tools worth knowing about I mean SQL detection we talked about what coded passwords or the secret detection tools there is infrastructure is 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 there there are tools to scan this typically if you have a good SAS tool
that's all covered by bistatic analysis basically right because everything can be considered code 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 layer 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 trade-off 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 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 setting analysis tools I would definitely recommend to do that I think here what you should be careful of is choosing something that is you know intended to be used by developers and not by security teams right we talked about the noise level that is you know interesting for security teams from all perspective but that leave for your product development you know productivity where you shouldn't be annoyed and I think that's something to watch out for but and then there are differences you know for SAS tools and SCAR tools if they are
more for 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 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 of that you know as your code runs as your servers operate that dynamically tried to test or just do funky stuff absolutely so there's dynamic application security testing we talked about penetration tests right and and a dust tool tries exactly to automate this right what is that dynamic application security testing is it 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
you can detect and then there's also on the dynamic side fuzzing which is similar to dust basically where it's more for embedded software you know binaries CC plus plus libraries or applications where typically you pass complex formats or protocols like file formats and then you want to flip every single bits 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 context switch basically because you cannot find things as you type you need to kind of like finish what you're doing deployed on the test server get a run and then the feedback loop is just a bit longer and so I think for developers it's more inefficient but for security teams it's a great tool to have to additionally maybe run a dust or fuzzing right yeah and as you say like 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 will mention AI security reviews these are 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 can can find today you know as we're studying analysis or every other technology to me it's not necessarily all about just finding issues at least when you want to you know 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 etc 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 that finds all code security problems and you mentioned
maybe you know to me there's not an aspect of being deterministic versus non-deterministic right here the the AI basically is non-deterministic and I think you know again for security that's not so important but as a development organization you 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 gates you know 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 you know having students create their own homework where you you would think that you know if AI didn't you know could prevent actually generating a security issue why would it later on the tech that's a security issue so I think we need to have good guard and verification in place that is not AI to verify that basically AI generated code
I can see where you're coming from although I can also see some some people might say like well what if it's a different AI what is a different LLM like a different thing but I we're still not you know we're just chasing one another 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 for security issue can you go a little bit into more detail and what you're seeing observing what what does low quality mean in this sense or is it the verbose nature of that we're sometimes seeing so for example it's not our we did great studies of the most popular LLM's like also named GP4 or 5, llama 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 you know if you use the reasoning mode of GP5 it actually decreases not eliminates but decreases the number of security issues you find but it's it's using more of both you know outputs 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 all those nibets of your code or it's harder to review by your peers or later on and it's less maintainable and you know leads to a security problem this reminds me of there's this like old thing before AI that code is a liability the more code you have the more liability you have and this was a reason that you know back in the day as an experienced 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 you know like you you would want to have kind of efficient lines of code right like you do want to spend that time and effort of of getting to a system that is simple clear responsibilities are concise i think this is something for if developers what you know
and engineers look at today already not just to 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 in your code base right and to have a good maintainable code etc outside of the security world that that's already a big code quality problem and i think developers are aware of this but then yes it did ask for that to you know security problem on top of that there was a nice survey by i think it was like overflow where i think only three percent of the developers asked basically said they trust their i generated code and i think that's very reasonable help yeah i mean when i'm using a i to like build myself my api's and testing all those things i also find myself like i give it instructions and every now and then i also tell it to refactor 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 dot t s 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 gonna get a mess i'm not gonna be able
able to navigate and for me it's important that i need to understand my code and i need to have a structure for that so i guess this doesn't change or and maybe the people who are vibrating they're gonna come around to learning the same lessons that you know we we all learned the hard way yes i guess but how do you think ais changing code security and also security in general what impact do 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's a big change in the sense that it's 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 or your deterministic analyzer needs to have a lot of knowledge about all the libraries and frameworks that are there and they are millions right and so ai can help you with gathering knowledge and information and feed that into a deterministic algorithm right so you can combine technologies and that's definitely changing i think the static analysis but also dynamic analysis and in order security tool areas and then what we're also seeing is you know fixes work quite well like if you throw half a million 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 deterministic 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 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 back and front end and in the back end 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 back end then you will 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 logic or the output and that's becoming then you know the straight line-scape changes and attackers adjust for it and certainly the tools and the industry adjust to it and that's maybe taking a bit of time right if you think about all the code we are still seeing yeah but i guess we can add prompt injection right up we can pin it up there with a SQL injection in fact who knows prompt injection might become even more of the
security issue yeah i think it's you know text becomes code right i think prompt injection is kind of like a new code injection right the human language is the new code and so if you inject human language then suddenly that's the new code injection so that's interesting from a security perspective and what about a coding assistance are you seeing things change with in terms of how we think about code security i mean i think the the big problem in terms of security is that you you know produce just code much more faster and and writing code is not a challenge anymore and so suddenly the new bottleneck is how are you verifying all that code right that's in your bottleneck not to get your code done but to verify that's actually secure and if you don't then it leads to security issues or quality issues which then on the long run leads to security problems right so i think that's the big new challenge for 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 engineering 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 from 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 code as you produce it i think there are also areas where and so on so it's pioneering something here in the field where you basically look at how are LLM's trains and you make sure the data set that LLM is trained on is actually free of common security issues right and if you do that and train your LLM on high quality code on high quality data and free of security or quality problems you you are producing from the beginning right a much more secure code and that's maybe another thing where in the future we will see more of this and speaking of this like again because you 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 LLM's are trained on human code in the end i think they are doing the same mistakes for the reason you mentioned maybe the prevalence changes of certain issue types right the issue tips don't 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 that package that's not existing package and then with that you suddenly include the malicious package and there's a back door and so this security issue was known before and we had the pan and see confusion but it's just less likely that a developer you know mistypes the pan and see 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 a hard code of passwords like some 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 complicated issues right issues where you need to combine multiple codes in a bit so each other to form a security issue that is then not so easy for AI to to grasp and so definitely you know some changes in the prevalence of what we know of already today what are some commonly misunderstood things about the security industry i think that you know we we call them phalluses i mean i come from the security industry right and i moved more to the developer side of the over the years i would say and and now you know stepping a bit back for a moment and looking at the security industries it's quite fascinating how we have this separated industry and community from the developer community right where we both talk about code and bugs basically but one side is maybe more about building things than the other about attacking and destroying and and so they are a bit distinct somehow and separated and that's 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 that promise you know you can have security just as a product
right and 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 and so i think as a sees we have a hard time knowing you know what product should i should i use and and buy and often i think a mistake here is to to look at security as a product and not as something that you're building into the process of development right because i think in reality that's that's what you must do and not have a tool that finds you get another one thousand issues if you hit the scan button right but something that embeds into the process finding issues but then engaging developers and and helping you fix things and i think that's the biggest fallacy to me we talk about the the ownership that comes with that maybe right i think there is a bit of this mysterious 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 and it's 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 you know and guilty here and find fascinating
lastly maybe this you know that 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's no perfect security unfortunately yeah this this thing about vendor selling products promising you know your your organization will be secure your code will be secure it's right and the fact that the reality is a little more it doesn't really work like that like any 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 are working in the main 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 great not good and unsecure it's right to develop a productivity term like how productive are my engineers and again there's vendor selling all these tools saying hey measure this and you will get this and we just see the same thing so i 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 you want to build a productivity is one security maybe maybe software is just hard it is right i think the more complex
software you write it's in every developer knows this right the more problems you have hard problems you have you know box you have and also the more security problems you will run into and that's just natural we you know we have a great vulnerability research team at sonar and so those guys are they are picking the most popular open source projects in the world that are you know deployed everywhere with great communities great maintainers back bounty programs where people get paid if they find something etc and it's fascinating to me every time they choose such a you know high-profile target they go in and and they still find something right if you you know if you're motivated enough and you know look hard enough i think you you can find something and unfortunately that's that's that's the reality right 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 good enough security okay i can move on this is good let's let's do the other stuff yeah it's tough because we said it's it's um you know perfect security is is um is hard but then to the question what is good enough and how can you solve this i think using tools is uh is the first thing you you should use right i i think um you know it's like a bit like securing your house right like you should make sure you you shut your windows indoors um and and have some basic hygiene it doesn't mean that a you know highly skilled or funded tucker can break in but you can make sure you shut those windows and doors i think with software the challenges a bit you're adding you windows and doors every day basically like with the new features you're adding and so i think you need some automation for that to have your basics right um 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 you know 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 quality problems that in the long run lead to security issues and i think your automation is key basically um 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 that's another ending story and it's a growing field right like we always need to be aware of the latest changes right now all of them is in prompt injections you'll probably need to ask yourself as is like if i'm building on top of lms or i'm invoking api's can they go in there and then you know the next thing will come up come again and the next and the next and the next i guess keeping an eye on the owasp but a top 10 is never a bad thing just to cover the very basics yeah i agree as a closing question i'm gonna put you on the spot here which programming language do you think is the most secure the the one that you 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 in newer languages are more secure i like go is a good example i think you know by default things are just you know and new languages learned from the past from all the languages which goes wrong but i think also all the languages are evolving i think Java is you know we see that a lot of enterprises and i think it's uh it's quite secure to use um so w my answer is no i i like that you dropped go it's it's getting pretty good traction with startups as well including for now even building web stuff it's picking up so it's i guess it's all down to people's tastes but it's good to hear so jhana this was really interesting thanks for coming on the podcast yeah thank you my pleasure to be here and thanks for invite well thanks very much for this thanks a lot to jhana's 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 a i generating code with clairing security vulnerability like not valuing inputs it's accidentally concredentials 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 if you 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 in the next one