Loading summary
Transcript124 lines
- [00:00]
Podcast Host
What are code security basics that every.
- [00:03]
Interviewer / Co-host
Software developer should know, really know and.
- [00:05]
Johannes Das
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.
- [00:12]
Interviewer / Co-host
I'll set up an MCP server that says it does something, but secretly it does something else. It runs locally.
- [00:18]
Podcast Host
Boom.
- [00:18]
Johannes Das
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.
- [00:31]
Podcast Host
How do you think AI is changing.
- [00:33]
Interviewer / Co-host
Code security and also security in general?
- [00:35]
Johannes Das
Today, what we are seeing is as.
- [00:37]
Podcast Host
Software engineers, what should we know about writing secure code? To answer this question, I turned to Johannes Das, who has been a security expert for 20 years and is currently the VP of Code Security at Sonar. 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 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 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.
- [01:20]
Interviewer / Co-host
So, Johannes, welcome to the podcast.
- [01:22]
Johannes Das
Thank you. Big pleasure to be here.
- [01:24]
Interviewer / Co-host
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?
- [01:32]
Johannes Das
It must have been like 20 years ago. I remember I got hacked. Basically my computer got infected. I think it was the SASSA one 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 security things like Trojan horses and that stuff at school time. And then I moved to Bochum, a 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 try to hack each other to get points. And I got really obsessed playing those competitions and that was the best learning experience for me. And this led into me getting into professional penetration testing, writing tools to assist the vulnerability hunting. And this led them into a startup which got acquired by Sonar, where I am today.
- [02:31]
Interviewer / Co-host
How can we imagine penetration testing so.
- [02:33]
Johannes Das
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 kind of like earn money with that as a student to also look for security issues as a professional.
- [03:07]
Interviewer / Co-host
And I understand that, 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?
- [03:20]
Johannes Das
Yes, absolutely, for a couple of years, doing this as a freelancer and for big companies, basically looking for security issues they have and always trying to get into their network, typically by exploiting vulnerabilities in software applications they're running and then documenting this, 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.
- [03:48]
Interviewer / Co-host
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?
- [04:02]
Johannes Das
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. You treat it as a real attacker, like, with no knowledge, 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, I forgot to do. And by experience you learn a bit, like what are typical mistakes? And then you go from there trying to always, you know, exploit something where you can steal files or get access to the database or something where there is some data, something, you know, that could be sensitive to the business that is then security critical.
- [04:59]
Interviewer / Co-host
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 a software where it tries all the different ports, it sends messages, and you hope that if they configure a server incorrectly or maybe correctly, you can get through. But what kind of tools do you come with?
- [05:23]
Johannes Das
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 test for all 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. And that's also the most exciting part.
- [05:57]
Interviewer / Co-host
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 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.
- [06:27]
Johannes Das
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 every software vulnerability basically manifests in code and developers are the only ones writing the code in organizations and changing the code, 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.
- [07:29]
Interviewer / Co-host
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 a 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.
- [08:02]
Johannes Das
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 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 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, 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 in looking into every single security issue that happens during development. And I think that's part of, 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 the developers could just fix issues as they code and move on. And that also allows then 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, or authentication logic or things like this, where they can then also be very helpful with the expertise for developers.
- [09:32]
Interviewer / Co-host
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 the platform team saying hey, how do I store you know like, like 2 petabytes of data? And they'll be 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 like specialized expertise where they can help you with a bunch of stuff and they will try to do tools as well for, for devs to like self service or, or you know, share common things to watch out for.
- [10:18]
Johannes Das
Yeah, exactly. I think it's a good comparison, right? Definitely helping. But also leaving 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 attached to or ad hoc 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 engage in security issues and fix them, because that's what makes you secure in the end.
- [10:49]
Interviewer / Co-host
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 a shifting left onto developers. But what was the historic context here and what is changing now?
- [11:10]
Johannes Das
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 life cycle 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 release. 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.
- [11:44]
Podcast Host
Johannes just talked about how engineering teams today are moving at a much faster pace than before, especially teams using AI coding assistance, 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 seasoned sponsor, Linear, can help Dev's team stay 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 hyper go 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.
- [13:07]
Interviewer / Co-host
Of adding extra to it.
- [13:08]
Podcast Host
Check out Linear at Linear app Pragmatic. And now let's get back to fast moving engineering teams and security reviews.
- [13:16]
Johannes Das
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's, you know, 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 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'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 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.
- [14:37]
Interviewer / Co-host
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 expertise, as I understand, but how do you define that? 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?
- [15:06]
Johannes Das
Yeah. For lack of a better 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, 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, 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, right. 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 memory corruption problems in C C, 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 there 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 misspecified 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.
- [16:50]
Interviewer / Co-host
I understand we should be owning code security, but it's a pretty mushy subject, as you say. It's a lot of things from the obvious null pointer exceptions to the 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 you code security basics that every software developer should know in your mind.
- [17:18]
Johannes Das
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, 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 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.
- [18:39]
Interviewer / Co-host
Never trust the input, right? Any input.
- [18:41]
Johannes Das
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 get parameters, post parameters, cookies, external input used and where am I using this in my file operation which. Which could be modified to open arbitrary files from attacker or traditionally in a SQL query you have a SQL injection in your HTML response page, you have cross site scripting and 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 basic thing that is involved in many popular data breaches where developer hard coded basically, maybe just for testing purposes, temporarily added hard coded into the code like a little API token secrets like API token.
- [19:53]
Interviewer / Co-host
Well, all sorts of tokens that should typically live in your local environment variables.
- [20:00]
Johannes Das
Exactly, exactly. And it can be API access tokens or cryptography tokens or passwords for the database or whatever, whatever attackers nowadays they crawl the public GitHub repositories, right. And steal those sequence 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?
- [20:29]
Interviewer / Co-host
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 either 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 through all these things and make sure you understand each of these things and you can check your code or know if they would be applicable.
- [20:57]
Johannes Das
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. Apparently they don't go away.
- [21:25]
Interviewer / Co-host
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.
- [21:43]
Johannes Das
So there are more advanced things in the terms of maybe expertise. What is needed if we talk about cryptography things? Right? If you're encrypting something and an attacker is still able to decrypt it, what 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, for those more complex features, security features, is to not try to reinvent the wheel and just use solid frameworks or libraries, 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?
- [22:28]
Interviewer / Co-host
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.
- [23:19]
Johannes Das
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, you know, some developer of that dependency, a maintainer gets compromised and then you know a dependency get backdoored, 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 backdoored. 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 the next version you should use or that you should get rid of that dependency, basically.
- [24:29]
Interviewer / Co-host
And what is software composition analysis?
- [24:32]
Johannes Das
So software composition analysis is called SCA is basically a technique where, you know, 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, that someone else, some maintainer, had a security problem, someone found that problem, reported it, it's documented in a database. And then you can basically with software composition analysis, map that this specific log4j version of your library is vulnerable to the log4shell vulnerability that is known and then it can warn you.
- [25:18]
Interviewer / Co-host
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?
- [25:31]
Johannes Das
It's run by Mitra, 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 data evolving or places revolving where security issues are collected and gathered. And SCA 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.
- [26:14]
Interviewer / Co-host
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, if we really need about this, let's get more resources, dedicated folks who can help with the kind of depths of the industry.
- [26:58]
Johannes Das
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. 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 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, 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.
- [27:59]
Podcast Host
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 our presenting sponsor statsec comes in. STATSIC gives engineering teams a toolkit for safer deployments, feature gates, gradual rollouts 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, statsig includes product and info 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, statsig 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 the deployment safety and observability without shipping sensitive data to external systems. Companies like Microsoft, Atlassian and Brex use STATSIC for safer deployments with enterprise grade security. Static has a generous free tier to get started and pro pricing for teams starts at $150 per month. To learn more and get a 30 day enterprise trial, go to static.compragmatic with this. Let's get back to code security with Johannes.
- [29:32]
Interviewer / Co-host
And recently you've produced a state of code security report, which is a pretty comprehensive one, as I understand.
- [29:39]
Podcast Host
What are things that you found there?
- [29:40]
Johannes Das
Yeah. So at sonar, we scan 750 billion lines of code daily. Right. So our analyzers see quite a lot of code. And we studied like a subset this, and we took 8 billion lines of code that was written by 1 million developers of 40,000 organizations globally, took 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 lines 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 log injection, cross site 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.
- [30:55]
Interviewer / Co-host
It's very interesting because you're saying every 1,000 lines of code, roughly one security issue. It's funny because lines of code we.
- [31:04]
Podcast Host
Always argue about, is it a good.
- [31:06]
Interviewer / Co-host
Measurement of things, you know, complexity, work, whatnot, or is it not? But I guess you're still using this heuristic, right?
- [31:15]
Johannes Das
I mean, it's a statistic we built 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 equality 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, while if you do it in a well maintained and structured way.
- [31:54]
Interviewer / Co-host
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?
- [32:04]
Johannes Das
Yeah, I think it's super related. Right. And I think it's totally underrated in the industry today. We, I mean, we talked about the null pointer exceptions or These 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 code, 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, you know, not well maintainable code, you, you, you cannot fix the problem, the security problem. So quality suddenly becomes a security issue in the 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.
- [33:24]
Interviewer / Co-host
When we look at code security, how does that relate to cybersecurity as a whole?
- [33:31]
Johannes Das
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 every organization today basically deploys 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, 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, 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 not move from one server to the other?
- [34:36]
Interviewer / Co-host
What is lateral movement?
- [34:37]
Johannes Das
Yeah, so typically as an attacker, you would 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 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.
- [35:09]
Interviewer / Co-host
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 developer's machine. You know, I'll set up an NCP 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?
- [35:50]
Johannes Das
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 developer's machine, basically, right? And then from there you can compromise a super popular dependency. Right? Or if you're a software vendor, you better make sure the software that is shipped to thousands of organizations maybe is not backdoored because some developer got back to it. 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 JIRA ticket and something is, you know, someone can create a malicious gyro ticket that instructs basically the agent to add a backdoor. And just instead of just solving a development problem, then you suddenly have a new type of security problem to think about.
- [37:13]
Interviewer / Co-host
You previously mentioned that if you can automate things 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?
- [37:29]
Johannes Das
I think every developer uses an IDE, right? So there is some basic linting available in IDEs. And that's great because as you type you find issues and 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 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, SAS tools that can go more into a deeper level of code analysis. Right. So depending on the SAS 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, 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.
- [38:48]
Interviewer / Co-host
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 turn it into 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.
- [39:10]
Johannes Das
Yeah, exactly. So your code is transformed into a big graph model.
- [39:14]
Interviewer / Co-host
This can be any dimensions.
- [39:16]
Johannes Das
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 calls. 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 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.
- [40:29]
Interviewer / Co-host
So we talked about the kind of linters inside IDs, the SAST S A S T scanners that you said, are.
- [40:37]
Podcast Host
There other tools worth knowing about?
- [40:39]
Johannes Das
I mean secret detection. We talked about hard 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 as code. Or your GitHub Actions file can be code. Right. And there are tools to scan this typically if you have a good SAS tool that's all covered by static analysis, basically.
- [41:02]
Interviewer / Co-host
Right.
- [41:02]
Johannes Das
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.
- [41:15]
Interviewer / Co-host
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 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 one person startup? Right. Like why would you not recommend that if you would not recommend it?
- [41:41]
Johannes Das
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 denoise level that is interesting for security teams from an audit perspective, but deadly for your product development 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 SAS tools and SCA 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.
- [42:33]
Interviewer / Co-host
So these are static tools 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, of the idea that as your code runs, as your servers operate that dynamically try to test or just do funky stuff.
- [42:53]
Johannes Das
Absolutely. So there's dynamic application security testing. We talked about penetration tests. Right. And the DAST tool tries exactly to automate this. Right.
- [43:03]
Interviewer / Co-host
What is dast?
- [43:04]
Johannes Das
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 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, fuzzing, which is similar to Dust, basically, where it's more for embedded software binaries, C C 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 those more dynamic tools are not so much for developers today because you are a bit disconnected from your coding and you have to context switch basically because you cannot find things as you type. You need to finish what you're doing, deploy it on the test server, get it 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 a fuzzing. Right?
- [44:43]
Interviewer / Co-host
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 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?
- [45:13]
Johannes Das
I think it's super fascinating and fun to see. Right. And also impressive what AI can find today, 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 security research agents that go in and randomly find issues. 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 again for 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 gates because randomly a new issue is popping up or disappearing, etc. So I think that doesn't really work well for developers today. And lastly, to me, from a developer perspective, 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 grade their own homework where you would think that, you know, 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.
- [47:27]
Interviewer / Co-host
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 student. But we're still not, we're just chasing one another, like we're still not changing.
- [47:42]
Podcast Host
The core problem here.
- [47:43]
Interviewer / Co-host
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 in what you're seeing, observing? What does low quality mean in this sense? Or is it the verbose nature that we're sometimes seeing?
- [48:03]
Johannes Das
So, for example, at Sonar, we did great studies of the most popular LLMs like CloudsOne, GPT4, 5, Llama, OpenCoder, etc. And we looked at what we call personalities of them, right? 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 GPT5, it actually decreases, not eliminates, but decreases the number of security issues you find. But it's using more verbose, 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.
- [49:11]
Interviewer / Co-host
This reminds me of there's this 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 experienced engineer would sometimes spend a day or two reducing the lines of code, refactoring, compressing it, bringing single responsibility, removing 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 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, concise.
- [50:01]
Johannes Das
I think this is something for that developers and engineers look at today already. Not just to wipe 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. To maintain a good architecture in your code base and to have a good maintainable code, et cetera. Outside of the security world, that's already a big code quality 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.
- [50:54]
Interviewer / Co-host
Yeah, I mean, when I'm using AI to build myself, my APIs and testing all those things, I also find myself like, I, 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, I just see something is getting bloated. You know, I have an index TS 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 to 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 or. And maybe the people who are vive coding, they're going to come around to learning the same lessons that we all learned the hard way.
- [51:36]
Johannes Das
Yes, I guess.
- [51:37]
Interviewer / Co-host
But how do you think AI is changing code? Security and also security in general? What impact do you see it's already having?
- [51:44]
Johannes Das
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 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. Right. So you can combine technologies. And that's definitely changing. I think the static analysis, but also dynamic analysis and other security tool areas. And then what we are also seeing is fixes work quite well. Like if you throw half a million line of code 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 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 back end, 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 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. If you think about all the COBOL code we are still seeing.
- [53:52]
Interviewer / Co-host
Yeah. But I guess we can add prompt injection right up. We can pin it up there with SQL Injection. In fact, who knows, prompt injection might become even more of a security issue. Yeah.
- [54:03]
Johannes Das
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 sudden that's. That's your new code injection. So that's interesting from a security perspective.
- [54:20]
Interviewer / Co-host
And what about with coding assistants? Are you seeing things change with. In terms of how we think about code security?
- [54:29]
Johannes Das
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 the new bottleneck. Not to get your code done, but to verify it it'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?
- [55:09]
Interviewer / Co-host
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?
- [55:37]
Johannes Das
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 Sonar 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. Right. 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 a much more secure code. And that's maybe another thing where in the future we will see more of this.
- [56:22]
Interviewer / Co-host
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 LLMs are trained on, you know, human code.
- [56:40]
Johannes Das
In the end, I think they're doing the same mistakes for the reason you mentioned 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, a 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, you know, 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 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 some changes in the prevalences of what we know of already today.
- [58:21]
Interviewer / Co-host
What are some commonly misunderstood things about the security industry? Things that we could call them fallacies.
- [58:27]
Johannes Das
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 stepping a bit back for a moment and looking at the security industry, 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 and the other about attacking and destroying. And so they are a bit distinct somehow and separated. And that's interesting to me. And I think one fallacy that comes out of this is that the security industry is all fascinated about the security problems and then is selling products basically that promise you can have security just as a product, right? There's a lot of money in that industry and it's driven by compliance and fear of data breaches. And so I think as a ciso you have a hard time knowing 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 1000 issues if you hit the scan button, 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, et cetera, 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, you know, am guilty here and find fascinating. Lastly, maybe this, you know, 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.
- [60:45]
Interviewer / Co-host
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 a lot more, 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 a 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 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.
- [61:49]
Johannes Das
It is, right? I think the more complex software you write in, 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, 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, bug bounty programs where people get paid if they find something, etc. 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.
- [62:51]
Interviewer / Co-host
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, 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.
- [63:21]
Johannes Das
Yeah, it's tough because we said perfect security is hard. But then to the question, what is good enough and how can you solve this? I think using tools is the first thing you should use. I think it's a bit like securing your house. You should make sure you shut your windows indoors and have some basic hygiene. It doesn't mean that a highly skilled or funded attacker 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 the 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 a 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 and quality problems that in the long run lead to security issues. And I think here automation is key basically. And then after a quarter or something you can run that assessment again and look at where am I standing? And hopefully you have been very productive as a developer and adding new features that didn't slow you down, but also you increased your security posture at that point.
- [65:03]
Interviewer / Co-host
It's a never ending story and it's a growing field, right. We always need to be aware of the latest changes. Right now, LLMs and prompt injections. You'll probably need to ask yourself as my, if I'm building on top of LLMs or I'm invoking APIs, can they go in there and then, you know, the next thing will come, come again, and the next, and the next and the next. I guess keeping an eye on The OWASP top 10 is never a bad thing just to cover the very basics.
- [65:28]
Johannes Das
Yeah, I agree.
- [65:29]
Interviewer / Co-host
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, the language itself seems to help prevent a bunch of security issues to start with.
- [65:49]
Johannes Das
I think the newer languages are more secure, like Go is a good example. I think by default things are just new languages learned from the past, from older languages, what goes wrong. But I think also other languages are evolving. I think Java is, you know, we see that a lot in enterprises and I think it's quite secure to use. So that would be my answer here.
- [66:18]
Interviewer / Co-host
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. But it's good to hear. So Johannes, this was really interesting. Thanks for coming on the podcast.
- [66:35]
Johannes Das
Yeah, thank you. My pleasure to be here and thanks for the invite.
- [66:38]
Interviewer / Co-host
Well, thanks very much for this.
- [66:40]
Podcast Host
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 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 the against them, including the new ones that AI tools introduce. For more details on security engineering, see the Pragmatic Engineer Deep Dives linked in.
- [67:27]
Interviewer / Co-host
The show notes below.
- [67:28]
Podcast Host
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.
- [67:35]
Interviewer / Co-host
Thanks and see you on the next one.