It’s Cybersecurity Awareness Month! To kick things off, we are taking a look back at the conversation that Sonar founder and co-CEO, Olivier Gaudin, had with Information Security Media Group’s Tom Field at Black Hat USA this year. The two chatted about Clean Code, what it is and why it’s important to security, as well as the recent announcement of deeper SAST.
TOM: Hi there, I'm Tom Field. I'm Senior Vice President of editorial with Information Security Media Group talking about Clean Code. It's my privilege to welcome to the studio Olivier Gaudin, he's the founder and co-CEO of Sonar.
OLIVIER: Thank you so much.
What is Meant by “Clean Code”
TOM: So, we're going to start with this term, Clean Code. When you say “Clean Code,” what exactly do you mean?
OLIVIER: Okay, so what we mean is a code that is not dirty.
TOM: I would say that settles it.
OLIVIER: And how we define it is, we define it by saying that Clean Code should be consistent, which is, if you want your developer team to be able to actually manage a code, to own it collectively, to not waste time, etc., you need to have some consistency. So we're talking about style constructions, your code has to be idiomatic, etc. It has to be intentional, any you know — without going too much into details — any resource which is not released, any user input which is not sanitized, any contradicting statement is not something you intended, so we are trying to catch this to show it to you. Code has to be adaptable, which is, you need to be able to change it. By definition, everybody expects that software will be changed. Otherwise, you should call it something else. And, code should be responsible. Should not have hard-coded secrets in the code, you shouldn't steal code from others, etc. So this is really the definition of Clean Code: consistent, intentional, adaptable, and responsible.
What’s at Risk Without Clean Code
TOM: And, we know it isn't universal these days. It's a great term but it's not broad. It's not as broadly embraced as it should be. Talk to me about what's a risk when you don't have Clean Code.
OLIVIER: Yeah, so it's all about, if you think about software, I mean, code is a main asset of software. Apart from code, you have parts that are disposable commodities, but the code is the most important asset in your software. If your code is not clean, you are actually not going to have an asset, you are going to have a liability. You are going to have something which is difficult to change which takes a long time, which every time you change, it breaks. Which the security teams are not happy about, infrastructure teams are not happy about. So basically, we talk about productivity, velocity, risk, and fragility of your application — so lots of consequences.
The Clean as You Code Approach
TOM: Talk to me about your Clean as You Code approach and the benefits that can be found from that.
Olivier: Yeah, so we started Sonar 15 years ago — three founders, three software engineers — that was the topic of our lives and it has since then. And what we realized very quickly is that we were having an approach to Clean Code that was not working. Even as three guys in the garage, we couldn't actually reach our objectives and we started to wonder what was wrong in our approach, and we started to wonder whether there is a business, there is a domain here that we should continue to explore. And at some stage, we realized that the way we look at the problem is not right.
OLIVIER: We were looking at running analysis, getting some reports, and then figuring out how to fix it. And when you do that, you leave a lot of space for actually failing, and this is what happened to us. Every release we were doing, we had certain objectives, which were reasonable, ambitious, but still achievable, and we couldn't reach them. We had to kind of massage the numbers or kind of work to make the numbers, and we felt that, if we cannot do it, nobody can do it. So we started to think about what are we doing here, are we really looking at the right problem? And we realized that we are not. What we were doing, and what a lot of companies still do, is you look at the state of your code jointly and you try to improve the overall state. And this is a problem. I'm going to make a comparison — if you have a water leak at home, what do you do first?
TOM: Find it?
OLIVIER: Yes.
TOM: And stop it.
OLIVIER: Yes, and then you, you will mop the floor, right? You wouldn't stop mopping the floor if you haven't fixed the leak, right? Very logical, yes. When you talk about code, it's the same. Which is, you look at the state. There is water which is already on the floor, and immediately you're like “Oh my God we need to fix this, we need to fix that, we need to fix this.” And you're engaging to this, and what happened at the same time is you still have 2,000 developers who keep pushing stuff. So once we started to realize this, and when I say this way, very obvious.
TOM: Yes.
OLIVIER: It took us here probably a year and a half to actually realize this, and then it becomes super simple. The most important thing we should be doing is fixing the leak. Which means basically, making sure that whenever developers change code or add code, this code is going to be clean. And when you do this, suddenly, the new code — what we call the new code — is clean. But it has also a big upside, which is, because we keep changing software, we actually remediate the past. And this is what we call Clean as you Code. Which is, it's a very simple systematic but powerful way of basically remediating code throughout your application. You are paying back the legacy technical debt with this.
Optimizing the DevOps Workflow with Clean Code
TOM: So tell me how DevOps workflows then can be optimized.
OLIVIER: So, my definition of DevOps is, it's a set of tools on processes that will enable development, to produce code linearly. And what happens is that, if you don't do Clean Code, you're going to be able to do that once, twice, you are going to be able to do one iteration, two iterations, three iterations. But at some stage, when you will want to add features, you are going to be stuck with your technical debt. Which is, you want to change something but it's breaking something else, it's difficult to read, people don't really understand the code anymore. So basically, if you have, if you deliver Clean Code — preferred approach is Clean as You Code, the most efficient one — you will be able to have a sustainable, continuous delivery.
TOM: Yeah, presumably your developer productivity and speed and delivery can be enhanced as well.
OLIVIER: Absolutely. There are two big upsides — one is really what I call the throughput, which is you can do more with the same number of people or you can do the same with less people. And your risk management, which is, you don't want that when you send your application to production, it crashes or it can be hacked. Basically, these are the two big upsides.
Taking a Deeper Look into SAST
TOM: So, now you've made an announcement in advance of Black Hat. Can you tell me some of the details, please?
OLIVIER: Sure. So, what we announced is that we have released what we call deeper SAST, which is a deep version that goes deeper when doing security analysis. So, if you think about the, the world of application security today, you really have two parts. One is, you analyze a code. And then the second part is you play with, I mean you, you interact with, with the application at runtime. So we focus by definition on the first. And in that, in that world of analyzing code, there are again two parts. One is to look at your own code, so you basically do static analysis to kind of understand where you have introduced vulnerabilities. On the other part is what's called dependency management SCA, OSA, etc.
OLIVIER: And to me, one of the things that has always been very weird is both parts are code, but we look at them differently. On one side, we analyze. On the other side, we just create databases that are going to reference vulnerabilities. Why do we do this? I think historically, it's due to issues with technology performance, etc. but there is no real reason to do that anymore. We believe we should analyze both parts as being code because, at the end of the day, the libraries are just an extension of your own code — this is code you don't rewrite, you reuse basically. So this is what we do now, we analyze the whole code at once and we can find vulnerabilities that could not be found before.
Sonar’s Differentiation
TOM: Now Olivier, the conversations you've had for years are conversations that many security leaders are having just now. This is a marketplace where software security is now embraced. In this marketplace, how does Sonar differentiate itself from other competitors?
OLIVIER: If you have been to Black Hat and have gone around in the expo hall, you're gonna find that messages are very similar in all booths. But if you take a little step back and you think a little bit more about how people engage, it's actually very visible in messaging. Most vendors, they actually declare that they are developer friendly, they declare that they are shifting left, and they declare that sometimes they help to put developers at the service of the security team. And I think this is really what they do, which is most vendors, they actually come into play when security is being reviewed. And because there is so much friction, they realize — friction in terms of, this is coming too late and developers are also pushing back on fixing stuff — they are trying to get more into the development part. We took the totally opposite approach, which is, we are coming from the dev. Which is, we serve developers. And as a very nice side effect, it actually has a big impact on security. So it actually benefits the security team. So to me, this is the biggest difference and as we have done that since ever, we basically had to be able to please developers. Which is, our product is super fast, super well integrated, and has very few false positives, because you know what? Developers, they don't like false positives. When they see one false positive and then another one, and then a third one, the next issue — which is going to come — is going to be like, “I'm not even looking at it, it's a false positive.”
TOM: Very good. Appreciate your time, appreciate your insight. Thank you so much.
OLIVIER: Thank you very much.
TOM: The topic has been Clean Code. You can look at the shirt — code better. My delight is speaking with Olivier Gaudin, founder and co-CEO of Sonar. For Information Security Media Group, I'm Tom Field. Thank you for your time and attention today.
Related Blog Posts
- Security Guy TV Interview - Going Deeper with SAST and Clean Code
- What is deeper SAST in JavaScript?