Our co-founder and CEO, Olivier Gaudin, and our Head of Research and Development, Johannes Dahse, met with Security Guy TV’s Chuck Harold during Black Hat USA 2023 to discuss Sonar’s announcement of deeper SAST and the importance of Clean Code.
CHUCK: Hi everybody, welcome back to Black Hat USA 2023. This is episode 2988. My next guests – Mr. Olivier Gaudin, he’s the CEO, and Johannes Dahse, he’s the Head of Research and Development for sonarsource.com. Welcome gentleman, welcome to the show.
JOHANNES: Thanks, Chuck.
Sonar deeper SAST - Advanced detection analysis
CHUCK: Now today's topic, discovering hidden security issues in code with Sonar deeper SAST. Great conversation, a lot to learn about this. You guys recently announced a powerful deep analysis to find hidden security issues in code on August 2nd. It’s referred to as deeper SAST. Its new advanced detection and it addresses the issues that traditional SAST tools miss. We’re gonna talk about that today. Let's start by asking what is unique about deeper SAST.
JOHANNES: We think, all kinds of issues in code, right, that could make your codebase unhealthy, and security issues are one important part of the issues we detect. And the challenge for security issues is typically that they can be everywhere in your codebase. And when we mean everywhere in your codebase, we are talking about issues that can be a combination of multiple code pieces, and those code pieces can also be in dependency code. And traditionally what happens in the market is that we scan code only for the codebase of the developers, what they coded. But every software project includes many, many dependencies and now we are able to also find security issues that come from an interaction with this dependency code.
CHUCK: Now, this sounds a little different to me. So, what is Sonar doing differently than others in the market for this space?
OLIVIER: Yeah, I think if you think about the way that other vendors have looked at this so far there is a clear separation between the code that you write and the code that other people write. And the code that you write has traditionally been, okay, we must analyze this code to see whether there are any flow issues, whether anybody can input data in the application and it wouldn't be sanitized. And when it comes to dependency, the approach of the market has been to kind of go through to go through the various dependencies and various libraries and review manually whether there is an issue or not. And these two worlds, they exist, but they exist separately. What we think at SonarSource is that, at the end of the day, whether you write code or whether somebody else writes code, this is code, and it deserves to be analyzed holistically by a tool. And this is really what we do with what we call deeper SAST which is, we actually look at the code that you write, we add up the code of libraries and then we analyze the whole thing and we find issues that we weren't able to find by looking at our own code or by looking at the database of vulnerabilities. Does that clarify?
CHUCK: Yeah, it does. It makes sense to me. Now, I started doing this a long time ago, like nine years ago. I’m really self-educated in cybersecurity. What I learned was that most code is open source. I think back in the day it was as much as 80% of code was taken from open source. Is that still the case? Are we still at a high appearance of open source coding and how do you, or do you address that the same way? I mean like you said, code is code. I think that’s a brilliant way to say it.
JOHANNES: So I think today it's over 90% of software using dependencies. Developers don't want to write every code feature again. They want to spare the rework and reuse this existing open-source code, right? And the problem with that is that developers really don't know what is in this open-source code. They don't have the time to verify the code that they are using, and whenever they use and interact with a piece of code and dependency code, this can lead to a critical vulnerability. This doesn't mean that every dependency is vulnerable or whenever you do that, your code becomes vulnerable. But every once in a while when you combine your code in a unique combination with a piece of code of a dependency, it can create a critical security vulnerability and that is exactly what we can detect now with deeper SAST.
Defining Clean Code
CHUCK: Now let's define Clean Code. I think that definition may have changed over the years, that's what it sounds like to me. Remember how we used to say “this is in real time” and 10 years ago, real-time meant a day. And now, real-time is closer to real-time. Does Clean Code mean something different than it did 10 years ago?
OLIVIER: I don't think it does but I think we have now come up with a much better definition. So, the way we define Clean Code is really code that is consistent. Which is, if you want a team to look after the code, you have to have consistency in terms of style but also in terms of how do we solve certain problems, about code constructions. So the whole code should be consistent. The second thing is the code should be intentional which means any logical error, anything that is not being used, any information, any user input that is not sanitized, any resource that is not released after being used, is not considered as being intentional and should be fixed. But we also need the code to be adaptable. Which is we need the code to be changeable, basically. Which is, if you, if we can not change the code anymore, we cannot consider that we are writing software anymore. It is something else but you cannot call it soft. So, we need to make sure that the code keeps the flexibility, to be changed. And finally, the code should be responsible which means we shouldn't steal code to build software, we should not hard code passwords, etc., so there are a whole set of things that need to be looked after to keep the code responsible. And this is how we define Clean Code which is consistent, intentional, adaptable, and responsible.
Deeper SAST - a Part of Achieving Clean Code
CHUCK: So I come from a physical security environment, that's where I started. I was a police officer and worked at the studios and I had my first computer in 1984, maybe even before both of you guys were born, possibly. So, I see this progression of cybersecurity as coming from, here’s the internet with basically no passwords, to now we have all these security issues, right? I've always thought of it as basically, as a state of cyber hygiene. We should do better at that and I'm looking at what you do as a state of cyber hygiene, keeping Code Clean. That’s kind of how I picture it in my head if that makes sense. So, how does deeper SAST, how does it support organizations in achieving this state of Clean Code? And it is a state, right? It’s like a state of readiness. You always have to be prepared to have something launched into your application or your time to market, and if it's not clean and you're not ready to go, you're not ready.
JOHANNES: I think deeper SAST is one part of what it needs to have Clean Code, right? So, in the end, we want to find all kinds of issues that make your code unclean you could say, and security is one important part. We find all kinds of code causes. But the consequence for security issues is dramatic sometimes for organizations, right? And so what Olivier mentioned is the intentional part, this is really where, if you use code pieces of dependencies, you should be very intentional about what you are doing. And often the developer doesn't have time to really figure out what every piece of code from a dependency is doing, so we make sure it is intentionally used and securely used to achieve a state of Clean Code in your codebase.
CHUCK: Now, you said something interesting to me — there's other issues with the code. You know, could be a programming error or something. Do you find that most of the issues are a combination of regular programming errors and a lack of secure coding? Do they lean one side or the other?
JOHANNES: I think they can be all very interconnected and that's why we also believe Clean Code is so important. If you look at what Olivier just mentioned, let’s say consistent or adaptable code, you cannot really fix your security problems. What we keep on talking about here in the security industry, you cannot continue fixing your problems if you have unmaintainable code for example. Or another example is, if you have buggy code then it can lead to crashes, but those crashes can also lead to security problems and that’s why we believe that all those different pillars of Clean Code are very interconnected and very important to address collectively, so you don't have security problems.
Sonar’s Differentiation
CHUCK: Now, I got to say fellas, I've done a lot of shows, over 3,000 technically. Sonar sounds different to me. Am I hearing that correctly? Sounds like you do something different than most people and to me, frankly, it sounds more thorough. Is that a good way to describe it?
OLIVIER: We have been developing the product based on engineering needs starting from our own needs. But, also, we have a super large community. So I think one of the things that is remarkable at SonarSource is how aligned we are with our market which is, it’s not like sometimes we are a little bit early and then our community catches up, and then they drive it into a certain direction… So if it feels very authentic as a product, it's probably because of this.
OLIVIER: I just want to come back on one thing you said earlier, which to me is very, very right. You talked about hygiene, and I think this is really what it comes down to which is if you don't, if you don’t have a good hygiene with your code, at the end of the day, your software is not going to be an asset. It’s going to be a liability. Because your code becomes a liability, your software is going to become a liability. So we are really trying to address this at the engineering level, which is this all, this hygiene should happen during the development phase. It shouldn't happen afterward. Afterwards, you want to really go for like, complex problems, threat modeling, etc. The security team should focus all their time, expertise, and energy onto this more complex problem. Not running analysis tools to see whether an okay job was done during the development phase, if that makes sense.
Impact of AI on Code
CHUCK: It does make sense. You know, and our new challenge is AI, ChatGPT. I’m not picking on ChatGPT, but let’s just use that as the example. Do you find that this advanced AI now is going to cause new challenges in your side of the industry? Is it going to help; Is it going to hinder?
OLIVIER: I mean, I think for SonarSource, I would say it’s a real opportunity. For the industry, I think it can be a challenge indeed. And at the end of the day, I think with AI, generative AI, what we are going to see is that more code is being written. Whether it’s because developers become more productive or whether it's because people who are not developers are able to write applications, at the end of the day, there will be more code. And that code is not going to be clean for sure. Some of it may be locally clean, but overall, this code is going to have to be reviewed and I think this is where, for us, it's a great opportunity.
CHUCK: Excellent conversation my friends. So glad you came on the show. Olivier Gaudin and Johannes Dahse, sonarsource.com at Black Hat USA 2023. Good luck to you guys and hopefully I’ll see you in person next year. Going to try and make it back in person for the show. Thanks for coming on Security Guy TV.
OLIVIER: Thank you.
JOHANNES: Great, thanks, Chuck.