Clean Code Movement to Improve Application Security – Thomas Chauchefoin, SonarSource

This is techstrong tv. Hey guys, thanks for the thrill. We're here with Thomas Shone, he's a security researcher with Sonar, and we're talking about clean code and the need to improve our software security supply chains.

Thomas, welcome the show. Hello. Thank you for having me.

Mike, What do we mean by clean code? I mean, a lot of people would be walking around and saying, you know, are you saying my code's dirty? So what exactly does that mean and how does it apply to application security?

Yeah. Nobody wants to write dirty code, right? It's, nobody wants to make tape or typo either, but it just happens.

And, uh, by clean code, we kind of, uh, try to, so we, we, we enable develop developers to write clean code. So we want, uh, developers to have code thats fit for production. That means that you can run in productions at robust at six, secure that secure.

And for us, it's the most important. For me, it's the most important point as want to researcher to help you write secure code. And also we, we think about, uh, clean code in the way that it should be fit for development, which would be clear, consistent, well structured and, uh, battle tested.

So how do we get that? Because the people who write code are all too human and mistakes get made. So what's involved in actually creating that code and making it clean?

Um, so for us, it goes through static analysis tools. Um, so, so we also call it, uh, SaaS, I guess in, in this market. Um, and we basically, we analyze your code as soon you write it in your I d E, uh, you already get suggestions to make, uh, cleaner code, um, regroups all the, uh, premises I just told you, clear, consistent, structured, robust, secure, uh, compliant with many standards.

And, um, as you push it to production, um, you can also scan it with our tools. Um, so in your C CIC pipeline, uh, to get a green mark that says, yeah, it's clean, it's compliant to the IO standards that we, uh, have designed with static tools. We've had these kinds of tools for a while and they are used with, uh, intermittent lesion, shall we say.

So what is the challenge with getting developers to kind of use this analytics tools to clean up their code? Um, sometimes, you know, we've been going in this shift left, uh, ing for a long time now, uh, but we still, uh, see many of these tools run only on T I C D and so kind of already too late, right? Um, as a developer, I've been specifying my new feature, my new, uh, bug fix.

I've been developing it, and now I do my pre request. It's getting reviewed by my peers and I'm, uh, getting review on my C I C D, and it's so late. I want all the suggestion to come earlier, um, like for instance, directly in my id, but still I have the same capabilities and the same fulfillments, uh, when I scan my code in my ID and in my C I C D.

And, um, with Sauna, you get the same results. Uh, in both cases. Do you think that developers just want somebody to fix and form automatically?

We've seen all these kind of generative AI tools that are floating around out there, but how much control do the developers really want over the fix? Um, I think for us, we, we did not really, um, we did not develop new AI based, uh, features to our developers to fix a code. Um, we have a few ideas, um, being worked on, uh, but definitely we think that developers, uh, they own the code.

They, they just wrote it. So they are the best experts, uh, to know how they should fix it. So what we do in our case to help developers to address this issues we just just found is a code that we gave them, um, all the best resources, the best links, um, basically some kind of education educational content directly in the I D E and later in the C I CD pipeline so they can understand what's wrong with this code, how can I fix it?

We provide suggestions, um, based on the current frameworks they're using, the current language they're using, um, but we don't automatically apply batch for the developers. Um, I think it's already, you know, we've seen many models nowadays, uh, chat g pt, which is not made for to generate code at all, but still, people try to get some good result visits. We've seen code pilots, uh, it is like great tools, but we still think there is, um, I think some things that the developers that we still don't have, which is, uh, logical thinking and being honors of this code.

Hmm. Um, What is the challenge with shifting left? Because we've been talking about it for a while.

Everybody goes to the same meeting and nods their head in agreement, and then everybody seems to just go back and do what they always did before. So how do I drive this level of change? Um, I, I think it's, first thing should be easy for developers.

It shouldn't be a burden to say, um, okay, if, if I scan my card and it's always finding so many issues, I cannot just fix everything every time. It's, if I see it as a waste of time and it's, it's not bringing me any benefits, I have no reason to shift left and do it myself, right? Um, and for secretive develops, uh, sometimes it's just, it's tricky to just understand, like, or it could be exploited, and you don't need to be aware of everything.

You just need to be aware that something's wrong and or should I fix it? Um, so with a solution, we really want to help developers to do it, uh, as a code and also to every time they make a change, uh, like, okay, uh, uh, I have many issues. I have a legacy code base integrate, so solution, um, and as I will develop new features, I will rewrite previous code, and if every time I touch some kind of feature or some, some file, I, uh, try to apply also recommendations at the same time.

Um, over time, I will have just like my, my code base will change a lot, um, over I think three years. I, it's gonna change for about like, uh, 40, 50%, uh, but if I clean every time I do a change, um, over time, my cut base is gonna be clean. Uh, and also I will f I will fix all the potential secretive limits I could have.

I found along the way, I will have make everything more robust, uh, maybe more compliant. Um, I know, you know, in the sea world, compliance is, um, it's the end goal for many things are many frameworks and, uh, and, um, end goals you can fight to reach. Um, so this is also not only for web developers for everybody, basically.

Mm-hmm. If I fix it on the developer side, do I also have to scan once I get the bills going through the C I C D process? Because will there be additional opportunities for errors to be made or in, or can I just do it once and forget it?

Um, so I think first when you, um, when you develop, I think in modern companies, when you develop software, uh, when you Singapore requests, all your peers will review it. So there will be, uh, recommendations. People will say, oh, maybe you, uh, did type A or maybe you should rebox this thing.

Um, and if I fix it in my I d e, it doesn't prove to the others that it was, um, like, it's clean or maybe I just want to rush. I need to go, uh, take a train and I didn't fix everything. So I think getting this check on the C I C D um, step also guarantees others that my god, this clean and I didn't forget anything, right?

It's all, um, uh, simple happens, right? Every, nobody wants to, uh, write 30, 30 code, but it still happens from time to time. Uh, we don't always have control of everything.

How do we get started down this whole path to make sure that developers, uh, wanna participate in this process? Yeah. And kind of get them engaged because, you know, a lot of them don't view security as maybe, you know, core to their job.

Yeah. So, um, so as a security expert, it's easier for me because I know, uh, what would be the impact of security availability. I could also permit technically fun to understand you could exploit it, but for developer, they don't need urgent information to fix it.

Um, because if we, if we tell them, okay, there is a here fix it, you only need to use this other api, or you need to take care of sanitizing the value before using it in some given context, um, you don't have as much information overhead, uh, to address availability. So it's, it's not doing security, I would say it's more like doing secure cards. And for this, you don't need to be available researcher.

You don't need to be an application security expert. Um, it's something that should be done by developers, uh, because it's easy and you don't need to know about everything. You only need to know how to do it right for once, and then all the next times, hopefully you're gonna get it right for the first time.

Do I need to have some guardrails in place to make sure that people aren't uploading code that they didn't scan? Because it seems like a lot of times there's developers who, um, have either had a bad experience with a SaaS tool or they're worried about too many false positives, but how do I kind of make sure that despite everybody's best intentions, that the right things are actually done? Yeah.

So now in most, um, C I C D platforms, and I mean for some of them, like for on GitHub, so CI CDs already integrated into GitHub. You have a dev integrion of what you call GitHub actions and workflows into, for instance, fully cross process. So you can simply add a sauna solution, um, as a check, as a step, uh, to your poll requests and say that if this, uh, step fails, like if one critical validity was found or if too many bug were found, and this a threshold can be configured what you call credit gates, um, if the query gate fails, because for one, one of the reasons I just explained, um, zip poll request should not be merged.

So obviously in case of an emergency, in case of, I don't know, you have a production incident, you need to deliver something quickly, you cannot wait for a scan. You cannot wait for review. Um, most companies have already override, they can enable, um, to quickly ship things for prediction, but it's only in a case of emergency.

And on day-to-day basis, um, every code will be scanned, and if it fails, you're cannot just click send and merge it and into prediction. You're gonna have to wa apply the feedback and fix, uh, critical. So most critical findings, so obviously for small cut smells, uh, if it's only small, small things, um, the credit gate would not trigger.

So it would not be red, it wouldn't fail. Um, but like for the biggest vulnerability other, the one we classify as major critical, you can say, okay, if I find any of these vulner routines, the new code being introduced in the database, in the database, um, it should fail. And you should not send this code to prediction because who wants to send vulnerable code to predictions?

Right? It seems to me at least that 90% of the things that are getting through in terms of vulnerabilities are fairly routine things that we all know about and for whatever reason we don't seem to be able to catch them. But, um, from your perspective, is a lot of it just because, you know, we're not paying enough attention?

No, I think it's hard. Like, um, we've been seeing secret injections for so long now, and it's, we have ways to do it safely. Um, but the way to do it safely every time in all contexts, uh, in all languages, sometimes it's not so easy to know how to use the right api, and they're al always like, small, quick such, just make it vulnerable while you think you just did everything right and you've been following all the information on the inter internet I just told you, you are doing everything right.

And, um, as researcher, what I see, um, often is that thanks to the technology tools, we have less and less lowering fruits. Um, because everything is being scanned with solutions. Like in our case, we have more than 7 million developers using solution.

Um, so a lot of are being scanned with the tools. So all the lowering fruits, let's say all the simple two injections, they're all gone. Uh, but what's left, it's only the most tricky, logical issues or just like language clicks, uh, that can still intrus vulnerabilities.

So it's never gonna be, um, I don't think we are gonna see a world visa articulative vulnerabilities, uh, but hopefully we can at least remove the longing fridge so we can raise a bar and make it more complex for attackers to be able to compromise the systems. We've been talking about application security issues for years now, and I guess the question I have is what, why the focus now? Is it just that the regulators have kind of figured all this out and they're bringing a lot of pressure to bear?

And so are we at a point now where whether you like it or not, you kind of have to up your game? Yeah, yeah, exactly. Uh, I think it's the first time we've been seeing regulation apply to software such, such poorly, um, stable department defense, reducing new regulations.

Um, I've been seeing already like, um, ideas, and I don't think certain thoughts yet, but ideas that any software containing public CVS shouldn't be used, uh, by government systems. Um, so it's, it's hard for companies to say, my product doesn't have any cv. And the easiest way to don't have any CV in your product, like any non, um, to avoid distributing software with nons is to avoid penalties in the first place.

So at least if we can, uh, like I was saying, remove all these slowing fruits, uh, it's gonna be easier than to integrate and keep up with the, uh, increasing, uh, demand for security. And I also think we have been, um, making security easier in a way. Uh, we have more tools to do security.

We have, we also have more knowledge, uh, SQL injections nowadays they look fairly easy. Like yeah, a kid could do a SQL injection, but, um, even 15 years, 15 years ago, it was not a thing. We didn't have all the knowledge we of today to find, remediate and exploit secret injections.

So I think as we als also gain knowledge and discover new ways, uh, to compromise applications, uh, we have to keep up and, uh, always raise a bar to make it harder to act into applications. Do we also have a massive amount of technical security debt? Cuz we weren't paying as much attention as we are now, and do we need to go back and revisit all those applications that are already running?

Yeah, uh, mate, I mean, a good example if, uh, I started with solar solution, I scan my legacy project, my, I don't know, my trustee php, uh, app that my business has been running for, for 20 years. Obviously I'm gonna find so many things, so many bug, so many co smell, so many things that, okay, we used to do things even 10 years ago, five years ago in a way. Uh, but today it's not possible anymore.

We have to keep up with new frameworks, we have to use safe APIs, we have to avoid secret injections, for instance. And, um, our approach, and that's what you call, uh, what that we call clean as code as that. Every time you change something, like you add a new feature, you do a new pool request, you touch something, um, all the code you are introducing is gonna be clean and over time, over a few years, you will have written your half of your code base with clean codes.

So over time, um, by going like baby steps, uh, pull request, Bible request, you will clean your code. But obviously if you start hiring somebody to look into this, uh, like 20,000 vulnerabilities, it's gonna be, uh, hard time for this, uh, employee and it's not really gonna improve the data of, of the system if you keep on introducing unsafe code. All right, folks, I guess what we're saying here is it's time to clean up Barack.

Like it or not, it has finally arrived. Thomas, thanks for being on the show. Thank You much.

All right, back to you guys in the.