Code security for software engineers

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

with agents and giving away more control. There is a new threat here because it's not just about the dependencies you're using or your machine security in general, but also making sure that the agent you're using is doing the right thing. How do you think AI is changing code secure?

security and also security in general. Today what we are seeing is As software engineers, what should we know about writing secure code? To answer this question, I turn to Johannes Daas, 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 assistants 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 season sponsor. So, Johannes, welcome to the podcast. Thank you. So, we're gonna talk about cybersecurity today. I wanted to

get to know how did you get into cybersecurity and w when was this? It must have been like uh twenty years ago. I I remember I got hacked basically, my computer got infected. Uh I think it was the Sasa one back in the days and Uh I was super frustrated, right? And then also super intrigued, like how could someone uh get access to my computer? And so that led me into, you know, playing with securities things like Trojan horses and that stuff at school time.

And um then I moved to Bochum, a city here in Germany, uh where you could study IT security and it was exciting. And so uh they played capture the flag competitions, right? Those are hacking competitions where university teams connect.

online in an isolated environment and they tried to hack each other to to to get points and uh uh I got really obsessed playing those competitions and and that was the best learning experience for me, you know. And Uh this led then into, you know, me getting getting into professional penetration testing. Uh writing tools to assist uh the the vulnerability hunting and and uh this letter into a startup which got acquired by Sona where I am today. How can we imagine penetration tests?

So penetration testing is um uh yeah, simulating an attack basically, right? So you are um kind of like a company hires you as a as a hacker basically and you you have to uh find out vulnerabilities in a given you know, time scope and and and uh scope of uh 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? Uh where you just do that for winning points in games to do then

uh you know kind of like earn money uh with that as a student uh to to also look for security issues uh as a professional. And I I understand that

You know, like yes, you can ha now hire penetration testers, right? As as the company, I can hire teams that do this. But uh did you do some of this? Did you do professional penetration testing? Yes, absolutely. Uh for a couple of years uh doing this as a freelancer and uh for big companies basically right uh uh looking for security issues they they have and always trying to to get into um their network um typically by by exploiting vulnerabilities and software.

uh applications they're running and then documenting this, right? Not going further, not destroying something, doing something malicious, but basically reporting then uh this is how an attacker could get in so they can fix it. How does the penetration test look like from when the company says like, all right, come and penetration test us. How do you actually go around? Do they actually give you access to some of their systems or or you need to just assume no knowledge? How does that work?

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

uh 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 from uh using that application and then trying to figure out what could be vulnerabilities here, right? What could be something a developer uh forgot to do. And by experience you you learn a bit like what are typical mistakes and and then you you go from there.

uh trying to always you know exploit something where you can uh steal files or or get access to the database or something where there is some data, uh something, you know, that could be sensitive to the business, uh that

D do you bring your own tools there? Do you have like methodologies? Like I I I I I guess, you know, like it's very basic, but I 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 uh they can figure it up uh w a server incorrectly or or or maybe correctly you can get through. But what what kind of tools that do do you come with?

You you do use uh tools in in in as a penetration tester. I think mostly for uh kind of like mapping out what's available, right? Uh that's I think the biggest part you automate

um so you don't, you know, test for all the endpoints or ports as you said. But I think then once you found um a good landscape of what's out there, you you go in manually. Uh at least I used to do uh that manually uh to to uh you know, try to to poke and and see what what breaks when you touch it and when when when you play around with it and Um, that's also the most exciting part I think. You know, in in the real world.

we're gonna be sitting, you know, as 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 gonna be attackers uh outside. It's gonna be like script kids or like, you know, like like people just like malicious like playing around, poking around. And there's gonna be professionals as well who will be uh trying to get financial gain, whatnot.

Now inside the company. Who should own code security? You know, the in the industry today what we're seeing is um that this is a shared responsibility, basically, right? Uh so we talked about the penetration tests and typically security teams are involved in that. Um and then there is uh still developers um you know adding and writing code, right? And

I think predominantly in the industry d the i it the the view is that the security team should should own all that security, right? It's i it's in the name of the team. But I see it quite the other way around. I I think, you know Uh every software vulnerability basically manifests in code and and developers are the only ones writing the code in in organizations and changing the code, right? And they're the only ones who can fix security issues.

And so I think they uh 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 uh you have great education available and great tools available for developers. So uh I think that ownership uh should be with developers on on the code security problems. I hear what you're saying on dev should own code security. But then W why have a security team?

Or at what point should you have a security team? Again, you you now work with a lot of different companies and sizes, and previously you also worked as a as a s as a security engineer. At what point do do companies bring in a s uh 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, they they That's their name, right? Like as a developer, like security as a whole, like to make your your service

hundred percent secure, that's pretty daunting. Yeah, so I I don't think that secure teams are useless, right? Not at all. I we we talked about the the penetration test. That's that's typically something run by secure teams. And so

I think the the field of you know application security is just much more broader than than code security, right? Um so you have maybe compliance requirements uh that you that you need to look after and and some, you know, organization wide initiatives, security initiatives or there are vulnerability reports coming in from a penetration test. or uh new threads um are are available.

And so security teams I think should look at this broader application security field and and um it's it's good to have a security team for that. And the larger the organization uh uh gets, right, you I think you need a security team.

I just think that when you write software and when organizations, you know, deploy software, the security team shouldn't waste their time in in looking into every single security issue that happens during development, right? And I think that part should be fully owned by

by developers, right? I think it's uh 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 some fancy exploit and risk assessment where SC developers could just, you know fix issues as they code and move on. And that also allows then security teams to

to have more time to actually focus on bigger problems on 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 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, you know, platform teams typically build platforms where engineers can build on and they have a specialized expertise. It might be a massive database platform, like for 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 two petabytes of data and up like, okay, here's different ways you can do it. So do I understand correctly that you're kind of saying security teams will also be this 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. Yeah, exactly. I think it's a good comparison, right? Um, definitely helping um But also leaving, you know, the majority of ownership there with developers so they can basically have security as part of the process of development and not just something that is. you know, attached to or ad hoc run. Um and whenever the security teams uh decides, right? I think it should be really part of the process of development and and that must be then owned by developers to really

you know, um engage in security issues and and fix them uh because that's what makes you secure in the end. I will challenge though that historically I don't think software engineers owned security or were expected to own. And can we talk about how this changed over time over your twenty years, how 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 and

What 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 uh a lot slower than today, right? You would have your

a quarterly release and then there would be before that there would a security team come in and and do a final audit, right? And then you would release. And and today we're just moving at a much more faster pace. Uh releasing a couple of times a day or per hour, right? And you have uh AI coding assistance and so

We are moving at um a lot faster now. 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 increasingly 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 safe focus. 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 meeting.

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 project.

This is the beauty of using Linear. It helps Hypergo companies stay focused, spend more time building, and less time coordinating. If your team cares about tools that remove additional work for the team instead of adding extra to it, check out linear at linear.app slash pragmatic.

And now let's get back to fast moving engine teams and security reviews. You cannot have this disconnected security review that you do afterwards. Um 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? Um and and and then with that there is a different product philosophy that that comes with uh security product

Because as a security auditor basically you want to know about every single potential issue, right? You wanna turn every stone and and and better look twice than never to find out what's you know, what could go wrong.

And then now if if you apply this to this new pace of uh of fast development, that doesn't work anymore, right? Because you cannot get interrupted all the time with findings. It's it's it's too noisy, right? Uh I like to compare this with uh you know, if you drive a car and you have a security guy in your passenger seat and he would scream and yell at you at every single thing that could go wrong all the time, that's uh maybe interesting the first uh fifty meters but then get so

super painful and annoying. I think with that we see a change in the industry that, you know, I think developers should own code security issues, but also the toolings around code security issues must be owned and and for developers. Um and then there are other application security tools and and application security as a broader thing that should be still owned by security teams. So so far you've mentioned

Two different things, or if I caught it correctly. One was code security and then application security. And you said that application security is a lot more than code security. So it's a you know, like it's a superset of of it. What is

code security. I mean this this is one of your your e expertise as as I understand, but How do you define that? You know, where does it start? Where does it end? Because it it does sound like something that as a software engineer we we should be aware of it, right? Yeah, for lack of a better definition, I would say it it it it's basically code that is you know, free of security issues, um, free of anything that, you know, can be leveraged by an attacker to

uh exploit it your application and then uh you know get access to some of your data and and put your business at risk. But with that simple definition I think the the the complexity is a bit, you know, what are security issues um when we say code is free of security issues and I think here the... Uh we think typically as vulnerabilities, right? SQL injection is a vulnerability and and

I think it's much more than this, right? If you think about uh bugs like uh I don't know null pointer exception where your application crashes, then your application is in in an unintended state and this can be abused by attackers in some scenarios.

Or maybe a more obvious example would be, you know, memory corruption problems in C C plus plus, where as an attacker you can uh you know, do a buffer overflow um and then execute code on your server and so I think here the the lines get more blurry and and um then are also more logical things

Like if you um write an application where you can upload a profile picture, you you shouldn't forget that, you know, an 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 uh things. And so it's it's basically technical depth, right? It's 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. And uh I think from that perspective it's also more clear why that's a developer problem um and and should be owned by developers. I understand, yeah. We should be owning.

you know, code security, but it is it's a pretty uh pretty mushy subject, as you say. It it's it's a lot of things from from the n the obvious null pointer exceptions to mate the maybe not as so obvious. buffer overflows, which are a little bit harder to work with if if you're not aware of it. Of course, sometimes use languages and and that solves for it. As a software engineer, what are code security basics that every software developer should know?

In in your mind. You just mentioned buffer warflows. I think The the the key here is, you know, for developers in those basics, um they need to only understand uh 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 uh without necessarily needing to uh run the full chain. And I think some of the

I think the first thing that comes to my mind is to to really know and understand what your code is doing. And maybe that sounds a bit silly and obvious, but that 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 um or overlooked. And maybe in the time of uh, you know, AI accelerated uh development and uh using libraries and open source code, that's not so obvious anymore.

Uh, 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 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 and how could an attacker uh modify something here, right?

Uh the industry has been talking for a long time about this input validation, input sanitization, right? Maybe that's a good example here where ne never never trust the input, right? Any input. Yes, exactly. And and um this can be also a bit more subtle, right? Like if if you upload a video to to YouTube. uh and someone passes with their application the YouTube video titles, then that's that's that's input basically, right? Because you you modify the

the the YouTube uh title name. But then really making sure we think about this um where is all that You know, get parameters, post parameters, cookies, uh external input used and where am I using this in my file operation? Which you know could uh be modified to open arbitrary files from attacker or you know, traditionally in a SQL query you have a SQL injection in your HTML response page, you have cross-site scripting and and on those typical things. And and

I think we are still seeing those uh issues, right? They're the most critical ones and they're have been around for for for a long time, but uh we still see those issues. And then secret leaks I think is a is another you know, basic thing that is in i involved in in many popular data breaches

you know, where the developer hard coded basically, maybe just for testing purp purposes, temporarily added like hard coded into the code like a little API token. So so like the sec secrets like API token well, like all sorts of tokens, right? That that should typically live y in your like local environment for variables.

Exactly, exactly. And it can be API access tokens or cryptography tokens or or a password for the database or whatever. Attackers nowadays they crawl the public GitHub repo repositories, right, and and and steal those sequence and try if they 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 another basic thing uh we should be uh aware of and and not do and it still happens um because we are humans, right? So these were the kind of I guess the basics to cover like As a developer, is there like a checklist I I I could go through?'Cause 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 the parameters, SQL injections, secret leak.

and su some some other things. Like do you 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 no.

if they will be applicable. It changes a bit over time. Also, you know, we are evolving and and we are learning more about um certain security issues and and certain types of issues we we do less. And then maybe new types are uh becoming more prevalent, maybe also because how the landscape changes or how development changes.

But again, I think those those basic ones we talked about have been around for for a long time and and and they they we don't we still see them. Uh they don't go they apparently they don't go away. And what about the more advanced things that could go wrong? Because these were the basic ones, right? Like I I think we just covered the basic ones, but you must have seen some more exotic Security issues that

uh maybe would have not been as easily preventable or a lot more creative ones. So they're more advanced things. in in the terms of maybe expertise what is needed. Um if we talk about cryptography things, right? If if you know you're encrypting something and an attacker is still able to decrypted or there is some, you know, authentication logic or access privileges or um password reset functionality is is also something where typically w you know often things can go wrong.

I think the um the key here as a developer is to for those more complex features, security features, is to not try to reinvent the wheel and just uh use um, you know, solid frameworks or libraries, uh, something that is vetted by the open source community and and trusted and I think here again a security team can can help you with that, right? One of the th recent security issues that 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 or a or a the downstream dependency of that package, uh they can be impacted. I think we we we've seen a crypto related issue like this. In in your view, who who could best protect against these issues? Would it would it need to be a security team who decides on things like pinning certain versions of packages or scanning updates for it?

Or b basically as as a developer, if I'm if I'm depending on third party packages, what are good practices I could I can do to try to avoid some of these You know, dependency security issues w which are now

becoming more widespread. That's a tough one, right? Because everyone uses dependencies and your dependencies are using dependencies and and uh so it's uh quite hard to 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 and then, you know, um um

uh a dependency get backdoored, uh you have almost no chance in uh uh uh having a security problem when you pull in that dependency. You you you cannot not use dependencies. I think the only thing what you can do here is to

uh have tools in place and this is like software composition analysis is is a thing here that basically observe and and and check your dependencies, you know, for known uh threats, right? At some point, luckily like uh the the NPM package you mentioned became known to be vulnerable or malicious or backdoored and then uh those tools uh basically get uh updated on a very frequent basis to to look

Um what are the threats and what are dependencies you shouldn't be using in a specific version and then warn you about this uh and what what is the the the the next version you should use or that you should get rid of that uh dependency basically. And what is software composition analysis? So software composition analysis is um called scar, is is basically a a technique where

You know, we look at uh 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 uh security problems, right? So those are called the CVEs. Those are not the the zero day vulnerabilities we talked about earlier that you typed into your code, right? That someone else in some maintainer Had a security problem, someone found that problem, reported it, it's documented in a database, and then you know you can basically with software composition analysis map.

uh that this specific log4j version of your library is 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, uh worry about it. It's run by Mitre, right? Like the US government. Uh there is some change happening here. Um, so that's the the the common vulnerability enumeration uh is the C V E list. And it's a database where uh it used to be kind of like the central database for documenting known vulnerabilities and

I think it's just too many vulnerabilities reported every day. So I think there's a bit of a bottleneck there. And so there are also other databases evolving or places revolving where security issues are collected and and and gathered and SCAR tools typically use that CVE database, um, but also other resources to collect all kinds of known vulnerabilities, uh to make sure they they know about all potential threats.

And as a software engineer strictly focusing on, you know, I'm trying to make my code secure, do you see value in kind of trying to keep up with uh with C V E's, with new vulnerabilities, or or do you see this being more of something that you really need someone who

is is dedicated, focused on this. May this be a security engineer. I'm just talking from a practical perspective, you know, if if I'm if I'm working at a scale up where we have a mid sized team, maybe have one security engineer and I really, really wanna, you know, do my best

work to try to security is important in in our domain. Do I take some of this on on me? Uh or do I say like, hey, let's let's if if we really need about this, let's get more resources, dedicated folks who can help with uh you know, the the kind of depths of the industry. Yeah, I I would use a tool for this, right? It it it's uh it's a problem that you can automate and um I I wouldn't um uh hire um more security uh um uh team members for this.

So you can use software composition analysis. You know, it will automatically check all the dependencies. There are I think in the database like over two hundred thousand uh CVEs and and every day d I think there's like fifty new CVEs coming out, not necessarily I think in in open source libraries, right? Also in known products, etc.

But I think it's um not a good use of your time as a developer, but also not as a security team member to to look at um you know, every single C V E that comes out. I think you should then have a good Um, 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.

Uh the important thing is that you can also fix this and get some advice on on on how to fix this. Johann has just talked about how it's a no-brainer to all with 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, Statsic, comes in. Statsik gives engineering teams a tool good 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 infra 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, Static 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, Atlash, and Umbrex use TASIC for safer deployments with enterprise grade security. Statsek has a generous free tier to get started and pro pricing for teams starts at one hundred and fifty dollars per month. To learn more and get a thirty day enterprise trial, go to static dot com slash pragmatic.

With this, let's get back to code security with Johannes. And recently, you've produced a state of code security report, which is a pretty comprehensive one, as I understand. What are things that you found there?

Yeah, so at Sonar we we scan seven hundred and fifty billion lines of code daily, right? So there's our analyzers see quite a lot of code and we we we studied like a subset of this uh and we we took eight billion lines of code. uh that was written by one million developers of forty thousand organizations uh globally. So quite a data set. And then we looked at uh what are the issues uh we we see. And um

I think one finding was that every about one thousand line of code uh we we see a security issue and that reflects kind of well my uh my my feeling of when I manually uh audited code. So every one thousand line of code an issue is

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 uh lock injection, cross side scripting, SQL injection, hard coded passwords, the typical things that that um that go wrong.

I think some s surprises were in there about regular expressions, for example, was was uh something that Uh 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 uh so that would be uh something more out of the lines. Yeah, the the basic ones are still very prominent today in code. It's very interesting because you

Like you're saying every one thousand lines of code roughly one security issue. That's funny because lines of code we always argue about is it a good measurement of things, you know, complexity, work, whatnot, or or is it not? But I I I guess, you know, you're you're still using this heuristic, right? I mean it's it's it's a statistic we built for the report, right? But I think yes, I think what comes

uh down to that is is that quality here is really connected um to to security, right? I mean you could uh solve certain problems with, you know, more lines of code or with less lines of code. Um and I think Air quality is something here um that, you know, is very related in terms of um when you have more lines of code, right, there's more, you know, code to review basically.

And uh it's it's harder to spot security issues in the end while if you if you do it in a well maintained and and and structured way. Exactly. But this was exactly my feeling on on this. So like what would you say how is the quality of code related to security. Did you see any findings on this? Yeah, I I think it's super related, right? And I think it's it's totally underrated in in the industry today. Um we

I mean we talked about the the null pointer exceptions or these slow regular expressions, right, uh that can lead to security issues and and that's more maybe the obvious. um examples of bugs. Um, but also if you think about unreadable code, not well maintained code, right? There'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 um 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, you know, attacker window stays open longer. At some point you have to to fix the issues. And so

I think here code quality is super related to code security, especially now with AI generated code, where we see typically uh poor quality of code, right? And that becomes a problem for security. When we look at code security. How does that relate to cybersecurity as as as a whole? So there are many fields of security, right? Data security, cloud security, network security, forensic

As a larger organization you kind of need all of them. Um and they are all interconnected and they build multiple lines of defenses. From my perspective, from an uh you know, offensive security uh perspective, I found application security always the most interesting field because if you think about Uh, you know, every organization today basically deploys software. They 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 twenty four seven, right? And they're available to to me as an attacker and that's the you know, at the forefront of security and and typically the first entry point into the network. Um and so that's makes it so so critical or so interesting for attackers, the the application security field. Whereas the other areas, you know, more pr try to prevent the lateral movement. Once an attacker is in

Uh, 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 lateral movement?

Yeah, so typically as an attacker you would um, you know, gain your first entry point into a network and then maybe you wanna 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 uh from there, you know, you are in the internal network and try to see what other services can I reach.

What other internal things can I access? And then you need a security strategy basically in the broader cybersecurity uh strategy to prevent that lateral movement between uh internal services. One idea that comes to me about lateral movement. with the advent of AI assistants, MCP servers, it's probably gonna 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 MCP server that says it does something, but secretly it does something else. It runs locally. Boom. I get access to this developer's machine. As developers and as as security professionals, how much should we worry about this? Uh and are are you seeing any worries about this specific attack vector? Because I feel until now developers' machines were kind of

A little bit off limits. Or were they off limits? Yeah. I mean developers' machines I think are not off limits, right? I think supply chain attacks is a a big Yeah, a big topic where I mean, developers are building software and then software is deployed on 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, uh you can

uh compromise uh 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 uh is not back to it because some developer uh got back to it and Uh yes, I think also with uh uh uh agents and and giving away more control, there is a a new uh threat here because it's not just about the dependencies you're using or your machine security in general, but also

uh making sure that the the agent you're using is uh doing the right thing and doesn't has the privileges to do something accidentally uh or on purpose, as you said, uh to do something harmful like if the if the agent passes a gyra ticket and something is, you know Someone can create a malicious gyra ticket that instructs basically the agents to add a backdoor and just in instead of just solving a development problem, uh, then you suddenly have a new

you know, type of security problem to think about. You previously mentioned that if you can automate things uh as for for code security or application security, you should try to do that. What are the common code security tools that you you you keep seeing engineering teams use for security hygiene? Like what are the categories that I can think of? I think every developer uses an IDE, right? So there is 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 that in a IDE typically you don't have such a broad or in-depth security coverage built in, right? There's some IDE extensions you can use. But then typically you stay at the linting side. That means some syntactical and semantical checks. Um 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 uh static application security testing tools, SAS tool. that um can go more into um a deeper level of of code analysis, right? So and 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 uh simulating static analysis is simulating what could happen here at runtime, what um it's not executing the code, right? But but analyzing this and uh connecting what we talked earlier about. user inputs, for example, how are they uh flowing uh in terms of data flow through through all your code paths and simulating what what could go wrong here to find Um different issues.

And and can you just give us a high level of of of what is happening? Because this sounds super interesting. What I understood, and you know, tell me if I if I got it right, is you you take your code and you kind of turn it into like maybe a graph or or of of some sort and then uh you can try to figure out kind of inputs, how they can flow, how they can get to com

components? Yeah exactly. So your your code is is transformed into a big graph model. This can be any dimensions. Uh yes, right. So so um every Basically every um file of your code base, every function, every uh if else basically um 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, you know, your variable assignments, which which create data flow basically uh where is user input uh received in that application and then passed on with you know data assignments uh through different if else and function f uh um calls And where does it end up in something security sensitive, right? And this can be very, very long uh data flow paths and uh very complicated.

to do right and also to do that efficiently, right? Um it it used to be uh taking days and and now we can do that in minutes and that's a very hard problem to solve. But it helps you to automate that that that process, right? What we talked about earlier where You should um be be mindful of what is user input. It it helps you to automate that and find even very tricky and long uh uh connections between user input and something security sensitive.

Okay, so we talked about the kind of linters inside IDs, uh the SAST as S A S T. Scanners that you said. Are there other tools worth knowing about? I mean secret detection, we talked about hard coded passwords or um so there are secret detection tools. There is um infrastructure is code. Scanning, right? If you think about code more broadly, it's uh also infrastructure as code or your GitHub Actions file can be code, right? And they're

They are tools to scan this. Typically, if you have a good SAS tool, that's all covered by by static analysis basically, right? Because everything can be considered code here. And then we talked already about uh software composition analysis as another tool. uh for developers where you find those known vulnerabilities, those C V E's dependencies. I guess this is a layered approach, right? So the the more security you'd like, the more of these layers you would

set up, but do I do I f sense that there's a trade-off between them? It's going to be maybe complexity, time to run. uh those kind of things. Like what what 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 if I'm a one person startup, right? Like why would you not recommend that? If if you would not recommend it. yeah i think i mean for the

The basic static analysis tools, I would definitely recommend uh 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 uh you know interesting for security teams from an all perspective, but uh deadly for your product. uh uh um development, uh uh you know, productivity where uh you shouldn't be annoyed and and and um

I think that's something to watch out for. But and so and then there are differences, you know, for SAS tools and SCAR tools if they are more f for the security teams or for developers. But uh I would def definitely recommend I think at all levels to to run uh static analysis and software composition analysis to have your your basic uh 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 of of the idea that, you know, as your code runs, as your servers operate. that dynamically try to test uh or or or just do funky stuff. Absolutely. So there's dynamic application security testing. We we talked about penetration tests, right? And and and a DAS tool.

tries exactly to automate this, right? What is dust? Dynamic application security testing is um uh testing from the outside as a black box when your application is already running on a test server or in production. And it 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 uh is there an uh delay? Is it behaving weird or throwing an error message and then this way um trying to automate such a human penetration test to find out if there are uh issues it can detect. Um and then there's also on the dynamic side uh fuzzing, which is similar to Dust, basically, where it's more for embedded software, uh you know, 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. Um so that that works very well. Um I just think that, you know, those more dynamic tools are not so much for developers uh uh um today. Because uh you are a bit disconnected from your coding and you know

You're you have to contact switch basically because you cannot find things as you type. You need to kind of like finish what you're doing, deploy it on the test server, uh get it run, and then the feedback loop is just a bit longer. And so um I think for for developers it's it's more inefficient, but for security teams is it's uh it's a great tool to have.

uh to to additionally uh maybe uh run uh a dust or a fuzzing, right? Yeah, and as you say, like it's it sounds like a bunch of setup uh to do. Just one more thing. Like I can I can see why you're saying that it's it's more for a security team. One thing you haven't mentioned, but I I was waiting if you would mention, AI security review.

These are, you know, popping up everywhere. There's there's a lot of different tools, a lot of different vendors, some 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 to see, right? Uh and and also impressive what uh AI can uh can can find today. You know, as with static analysis or every other technology, to me, it's it's not necessarily all about just finding issues. Uh a at least when you wanna, you know, use that in a systematic way as a as a developer.

Uh, here you have to get into a good balance of am I not only finding things, but how often do am I reporting things that are actually not a true or a meaningful issue? Um and and can I scale this to half a million lines of code, etcetera, right? So Um I think what we're seeing more today is uh, you know, security research agents uh that go in and and randomly find um uh issues. You know, it's it's a great tool for security teams here.

Uh but as a developer you wanna have I think something a bit more systematic that that finds all code security problems. You mentioned maybe the um the the you know, to me there's another aspect of being deterministic versus non deterministic, right? Uh here.

uh the the uh AI basically is non-deterministic And I think you know, again for a security team that's not so important, but as a development organization you you need to have basically like a a quality gate and that's consistent across your team and all the other teams. that always has the same output and uh you cannot fail your gate, 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 it a bit of a contradiction if you think about most or or a lot of code is written by AI itself, right, depending on who you are. And um if you then use AI to review AI generated code, that's a bit uh, you know, uh having students grade their own homework.

uh where you you you could 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 and that is not AI to verify then basically this AI generated code. I I 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 L M? Like

But I I we're we're still not you know, we're just chasing one another. Like we're 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 the lines of code per per security issue.

Can you go a little bit into more detail and and what you're seeing, observing? What what what does low quality mean in in this sense? Or is it the verbose nature of that we're sometimes seeing? So for example, at Sona we did um great studies of the Uh most popular uh LLMs, um like Cloud Sonet, GPD four, five, um Lama, open coder, etc. and we looked at

the what we call personalities of them, right? How do they um what kind of issues do they produce and what kind of quality are they producing and then measure what comes out of of of that and study this. And one interesting finding to me was for example that um, you know, if you if you use the reasoning mode of GPD five, it it actually decreases, not eliminates, but decreases the number of security issues you find.

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

um uh by your peers uh or later on and it's less maintainable and and you know leads to a security problem. This reminds me of there's this like old saying before AI, the Hub 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, uh a 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 ta taking your statistic of one security issue per thousand lines of code, let's just take it for now. Like yeah. Like you know, like you you would want to have if if kind of an efficient lines of code, right? Like you you do wanna spend that time and effort of of uh getting to a system that is simple, clear responsibilities.

uh concise. I think this is something for if that developers or you know and and engineers look at

uh today already, uh not just uh to to vibe code and uh accept all the code, but to actually make sure um the the code makes sense and is is well structured for all kinds of purposes, right? To maintain a good architecture in your in your code base, right? And and to have a good maintainable code, etc. outside of the security world, that that's already a big code quality uh problem and and I think developers are aware of this.

Uh but then yes, it it it adds for that uh uh to you know, security problem. Uh on top of that, uh there was a nice survey by I think it was Stack Overflow. Where I think uh only three percent of the developers ask basically uh said they they they trust uh their AI generated code and I I think uh that's uh that's very reasonable.

Yeah, I mean w when I'm using uh AI to like build myself my APIs and test and 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 of building software, I know that it's just gonna get a mess. I'm not gonna 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 I guess this doesn't change or and and maybe the people who are vive coding 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 AI is changing code security? Uh 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 um it's it's very powerful and helpful. So um even if if you run deterministic algorithms like static analysis to detect issues, Uh you can still enhance that deterministic algorithms with AI, right? So for example Yeah, 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 um and that's definitely changing, I think, the static analysis, but also dynamic analysis and and auto security tool uh areas. And then what we're also seeing is

you know, fixes uh work quite well. Like if you throw half a million line of code, you know, into um uh the the the context window it's it's not working so well. Um but If you just throw in if you have a very specific task, if you say here's a deterministically found security issue, here are the twenty lines of code, and that's the problem.

And then AI is very good in in fixing those issues, right? Um so so that's very helpful um uh because it's about fixing and not just detecting and AI is uh super powerful here. We we also see um Like a change in how code and applications are built, right? So

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

And that's becoming then the you know, sort of threat landscape changes and attackers adjust for it and and certainly the tools and the the industry. uh adjust to is and um that's that's maybe taking a bit of time, right? If you think about all the COBOL code we are still seeing. Yeah, but I I guess we can add

prompt injection right up we can pin it up there with CQL injection. In fact, who knows prompt injection might become even more uh of a three security issue. Yeah, I think as uh you know uh text becomes um code, right? I think uh um uh prompt injection is kind of like the new code injection, right? The human language is the new code, and so if you inject human language then suddenly uh that's that's your new code injection. So that's interesting from a security perspective.

And what about uh recoding assistants? Uh are you seeing things A change with in terms of how we think about code security? I mean, I think the the the big problem in terms of security is that you you uh you know, produce just uh code much more faster and and 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 that it's actually secure.

And uh if you 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 uh challenge for for security or code security, how do you verify all of that uh faster produced code at scale and at speed? And what is your take on what is working so far? I mean the the obvious thing that I'm hearing a lot of

engineers and engineer leaders say is like, well, we need to scale code reviews. We need to figure out ways where humans can look at code reviews, you know, like more of them, meaning let's add tools to them, let's add additional context.

But outside of that, d do do you see some other maybe promising areas where where we could actually verify from strictly from a security perspective, like is this code secure? Yeah, I think you mentioned already the the key things uh right to to to add tooling to to automatically verify uh code as you produce it.

I think there are also areas where um and and Sonasur is pioneering something here in the field where you basically look at how are L LMs trained and uh you make sure the data set that an LLM is trained on is actually free of uh common security issues, right? And if you do that and train your LLM on high quality uh code, on high quality data. uh free of security or quality problems, you you are producing from the beginning, right, a much more um uh secure code. And that's maybe uh another

uh thing where in the future we will see more of this. And speaking of of this, like again, because you 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 then?

humans would do. Especially because we know that LMs are trained on, you know, human code in the end. I think they're doing the same mistakes for for the reason you mentioned. Maybe the the prevalence changes of certain issue types, right? The issue types don't don't change so much. But uh what we are seeing, for example, slop squatting is a good example where

you know, AI a pro uh uh proposes to use a library that doesn't even exist, right? And then so an attacker can register uh in in NPM or Maven Central that that that package. a non-existing package and then with that you suddenly include a malicious package and 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

that a um developer um you know mistypes a dependency while with AI that's that prevalence changes suddenly, right? There is an acceleration of that. While other issues maybe uh decrease, right? I could imagine uh I'm not seeing this for now, but I could imagine uh hard coded passwords, like some some issues that are just one liner issues. uh maybe decrease a little because AI is able to learn that, you know, I shouldn't do that. And um uh then we could see uh reduction of of of um you know

uh those issues. Uh still human developers can add them, but maybe uh the more AI generated code is used, um, we see m 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. um that is then not so easy for AI to to uh to to grasp and so

um definitely, you know, some changes in the prevalences of of what we know of already today. What are some commonly misunderstood things about the security industry? Uh things that you know we we c we could call them fallacies.

I mean I come from the security industry, right? And I I moved uh more to the developer side of the over the years, uh I would say. And and now, you know, stepping a bit back for a moment and looking at the security industry, it's it's quite fascinating how we have this separated

industry and community from the developer community, right? Where we we 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 And so they are a bit distinct somehow and separated. Uh that's that's interesting to me. And um I think one fallacy that comes out of this is uh you know that the

security industry is all fascinated about the the security problems and then is selling products basically um that that that promise, you know, you can have security just as a product, right? And and Um, I mean there's a lot of money in that industry and it's it's driven by, you know, compliance and fear of data breaches. Um and and so I think as a CISO you have a hard time knowing, you know, what product should I should I uh use and and and buy. And uh 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 uh you must do. Yeah, and not have a tool that finds you yet another one thousand issues if you hit the scan button, right? Uh but something that embeds into the process finding issues, but then engaging developers and and and uh helping you fix things and uh I think that's the the biggest

uh fallacy to me. We talked about the the ownership that comes with that, maybe, right? I think there is a bit of this. mysterium about security and it can only be owned by experts who are top-notch hackers, etc., where Um I think the lines are a bit more blurry here. And um 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 and finds fascinating. And I myself

you know, uh uh and guilty here and and find fascinating. Lastly, maybe this you know, there there is no perfect security. If you get the understanding of the security industry, then maybe that's a fallacy here that uh, you know, there is No perfect security, unfortunately. This thing about vendors selling products promising

You know, your your your organization will be secure, your code will be secure. It trying and and the fact that the reality is a lot more it it doesn't really work like that. Like you need teams, you need people who care about it. Uh sometimes you can I guess you can have a team that uses zero security tools producing

really secure code because they're just experienced engineers or working in the domain that they understand. And you can have the other way around as well. Like you can have a team that has all these scanners and whatever and their code is is still

like not great 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 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 some some areas, you know, developer productivity is one, security. Maybe maybe software is just hard. It is, right? I I I think the more complex software you write, um, it uh and every developer knows this, right? Uh that the more problems you have, heart problems you have, um uh you know, bugs you have.

And also the the more security problems you will run into. Um and that's just natural. Um we you know, we have a great vulnerability research team at Sona and and uh so those guys are They are picking the 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, etcetera.

And um it's it's fascinating to me. Every time they they they choose such a, you know, high profile target, they they go in and and and they still find something, right? If you uh you know, if you're motivated enough and um, you know Yeah, look hard enough. I I I think you you can find something.

Um and and unfortunately that's that's that's the that's the reality, right? As a software professional, as a security professional in the field for twenty years, what can you advise to me as an engineer uh 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, uh there will be differences between if I'm a one person, you know, tiny business, a mid sized company at a very large company.

How would you advise engineers to think about, you know, good enough security? Okay, I can move on. This is good. Let's 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 and how can you solve this I think using tools is a i is the first thing you you you should use, right? I I think um, you know

It's like a bit like securing your house, right? Like y you should make sure you you shut your windows and doors um um and and have some basic hygiene. Uh it doesn't mean that a, you know, highly skilled or funded attacker can can break in.

But you can make sure you you shut those windows and doors. I think with software the 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 um I think you need some automation for that uh to have your basics right. Um, and then I would recommend basically you can start with a initial assessment where 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, um and and get them fixed. Um 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 debt that or and and quality problems that in the long run lead to security issues. And I think here automation is key basically.

Um and then, you know, after a quarter or something, you can run that assessment again and and look at where am I standing. And uh hopefully you have been, you know Very productive as a developer and adding new features that didn't slow you down. Uh, but also you you increased your security posture um at that point. It's a never-ending story. And and it's a growing field, right? Like we always need to be aware of the latest.

uh changes right now lms and prompt injections you'll probably need to ask yourself as is my if I'm building on top of LMs or I'm invoking APIs can they go in there? And then you know the next thing will come out come again and the next and the next and the next

I I guess keeping an eye on the OWASP uh top ten is never a bad thing, just to cover the very basics. Yep, I agree. Now as a closing question, uh I'm gonna put you on the spot here. Which programming language do you think is the most Secure. you are very happy either as using it or observing as like, okay, this is the the language itself seems to help prevent a bunch of security issues to start with. I think the newer languages, uh

are more secure. I I like Gove is a is a is a good example. I think uh, you know, by default things are just, you know and new languages learned uh from the past, from from older languages. uh what uh 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 uh it's uh quite secure to use.

Um so so that would be my answer here. No, I I I like that you dropped go. It's it's it's getting pretty good traction with startups as well, th in including for now even building web stuff. It's picking up so it's I I guess it's all all all down to people's tastes, but it's good to hear.

So Johannes, this was uh really interesting. Thanks for coming on the podcast. Yeah, thank you. My pleasure to be here and uh thanks for the invite. Well thanks very much for this. Thanks a lot to Johannes for taking us deeper into the topic of code security. The thing that I found the most interesting is just how hard it is to see.

Exactly what makes code secure, because there are simply so many impossible attack vectors. From using a dependency that gets compromised to AI generating code with glaring security vulnerability, like not validating inputs, to accidentally leaking credentials. The list just goes on. Security feels like this invisible thing across software. As long as there's no security issues discovered, it doesn't get much attention.

But once there is, then there's a scramble on what to do. As a professional software engineer, we need to keep ourselves up to date with common security vulnerabilities and how we can defend against them, including the new ones that AI tools introduce. For more details on security engineering

The Pragmatic Engineer Deep Dives linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you on the next video.