Transforming Software Security Testing With Self-Learning AI – Sergej Dechand, Code Intelligence

This is Textron tv. Hey guys, thanks for the throw. We're here with Sergey Deshaun, who's c e o for Code Intelligence, and we're talking about how AI is gonna be applied to make security testing better for us all, and we hope cross our fingers and we'll see where we go from here.

Sergey, welcome to the show. Hi, uh, hi. Hi, Michael.

Thanks for having me. All right. We have seen thousands of AI product announcements in the last few weeks, and I guess everybody's kind of genuinely impressed, but no one seems to have a good handle on what all this means, what the implications are.

So in the case of security testing especially, how do you see AI playing a role and what will be the role of people versus the machines? Yeah, in, in the end, uh, we will still need people because, um, if we are looking on how AI operate, obviously they need some training data based on the training data the AI can learn. There are self-learning, uh, algorithms.

We will dive into that, uh, in a bit. But still, uh, even with the self-learning algorithms, you still need some human input, human judgment, someone has to tell the AI what is right and wrong. Um, so in the end, we will still need a human in the loop, but the people will get more productive.

So if we are, uh, uh, taking for instance, the developer side, and right now it is expected a lot from what a developer should do. They should write new features, they should do software testing. Now with the DevSecOps movement, they are even responsible more for security and have to fix more.

And, uh, they have to be an expert in a lot of different areas. And, uh, this costs just a lot of time. And with all those AI tools emerging, be that on the co-generation side or, uh, on the security testing side, you are, uh, uh, so the AI will help, uh, the developer, uh, in the end so that the developer will take mostly the things where the AI cannot judge, give feedback to the ai, what is happening, and, uh, in the end achieve more, in less time.

How many different types of algorithms are there and how many, uh, tools am I gonna need to harness these? Are all these algorithms gonna show up in one tool, or do I need to have a collection of tools? I think people are trying to figure out what is my workflow gonna look like?

Yeah, I mean, we see two different brands, uh, at the same time. So there are platforms which kind of offer an all in one solution, and I think it's a great way to start with an all-in-one, uh, solution because, uh, in a way you get to results pretty fast, even if it's, uh, security and so on. And then depending on where you are in the market where, uh, what kind of product you have, uh, you at some point will need more specialists and uh, uh, uh, then obviously if you are, uh, developing software and have this global tool, so there is GitHub and GitLab, uh, uh, uh, which are using AI and help you to develop software, but at some point you will add additional security products because the one, the security features which are already included in those platforms are not that much specialized.

And uh, here is where you bring in all the different vendors depending on the need. So I don't think that there will be a one size fits all solution. And, and it will be similar as we know in the DevOps space right now, where you have the platforms and the specialists, you will have the same in the security space and ai, um, yeah, you Were, no, sorry, lemme try that again.

You raised an interesting point, right? If I think this through, a lot of folks are using AI to write code or help them write code, but that AI platform is based on, uh, data and code samples collected from all over the internet. And so it may generate more vulnerabilities than I had before because the AI is just using, you know, the least common denominator and there are mistakes made for many years now.

So am I gonna need an AI to essentially keep an eye on the AI that's writing my code? Yes. Uh, and in the end, there are even studies that the code, uh, producing, uh oh.

So, uh, the AI producing the code produces more vulnerabilities compared to a developer, even though the people using the generated code trust the code more than their own. So there was a study on that. So it basically means we have a, an enormous factor, and I think some companies, uh, advertise something like an 80% boost, how much code, uh, uh, you are able to produce.

Uh, and this code has more vulnerabilities compared to the developers. It basically means that you have to implement a software testing or security testing process, uh, protecting against, uh, those vulnerabilities. And there will be used different types of ai and ideally they are not too much interconnected because if you do the verification, you probably want to have other angles on that, uh, uh, compared to the ones who are producing it.

And, um, ideally you are using the different AI aspects here. Are we gonna learn this lesson the hard way? It seems like we have a lot of, uh, people embracing AI to help them write code, but I don't think we've kind of thought through the whole security side of that equation.

So might we wind up with more insecure code in a year than we currently have? Um, it might definitely happen. I mean, uh, we have seen that with, um, dependencies for instance.

So, uh, with lock four J, there has been a lock four J until everyone kind of realized, okay, there is no way that we can operate without a dependency checker. Because what happened, uh, when, uh, the lock for, uh, shell were vulnerability basically, um, came out a lot of different operations teams and a lot of development teams started to dig where are the dependencies? What is affected?

Uh, we don't have as bomb and so on. And they learned it the hard way. And after lock four J, um, they started to implement, uh, dependency checkers.

If we are looking now from the code security side, from the security product itself, basically if I am a company and I write my own code, uh, I will probably learn it also the hard way. Yeah. Longer term though, to be more hopeful about things, we may wind up one day with more secure code than we historically have had if we use the right AI platforms to double check the code created by the other AI platforms, and we have that little separation of church and state.

But you know, I guess I'm asking you, are you optimistic about the future of application security? Yes. To be, to be fair, I am optimistic because if we compare the state where we are with IT security right now, it's far better, uh, than like 10 or 20 years ago.

And it, it's not just, uh, uh, from the code testing side, if we are thinking about all the phishing attacks and, uh, all, uh, those scam with all the, uh, different, uh, uh, different viruses you can get, um, people or attackers start to attack open source software and other types of vulnerabilities because it's not that easy to get into the companies now. And obviously there is an education going on and we see a lot of movement, uh, because the big tech companies already advanced a lot of money in security. And, uh, uh, what you already see is if we compare it earlier, hey, there is definitely a much higher security level, uh, right now, um, because every company, almost every company has a dependency checker right now, and we will see that progress.

Uh, so I'm more optimistic, uh, to the future because at some point, and this is all about how much, uh, the attackers have to invest, um, and uh, the higher the threshold will go, um, the, the more attackers maybe will go out. Because if you have a certain knowledge to bypass all that, maybe you are in a different legal business, but it, it's obviously speculation. Mm-hmm.

One of the, I think, dirty little secrets of our industry is that developers don't have an infinite amount of time to go and remediate vulnerabilities, and as a result, they might only get to 10% of them. And we have a enormous amount of vulnerable code running in production environments, uh, that we, uh, sometimes quain refer to as technical debt. But, um, do we need to go back in and look at all those applications and examine that code and figure out maybe if we can automate some of this, we can get after a lot more the vulnerabilities that are already in our production environments?

Yeah, so my personal opinion on this is, um, so you have the ones who write software and you have the attackers. And the question is always, how do I make it cheaper for me to test? So if you think about penetration testers, we are exactly in that problem.

So if we pen test, how much time do we invest? What if the attacker invests double time or triple time? So basically, uh, uh, and then it's a kind of cat mouse game.

And the question is what can you do as a company? What kind of knowledge do you have, what the attacker doesn't have that you can become more efficient? And this is something what we, uh, foster as code intelligence because, um, so what our assumption is based on that, I, if I am writing my own services, I have access to my own code, I have, uh, so if I deploy the application in my cloud, I have the full control what's going on.

And if we are looking on how our AI works, it's basically during runtime, we see what is happening inside the application because we have access to the source code, we see what is happening live and based on that, the AI can predict a lot of different inputs to reach more different states, more edge cases and so on. So because we have this access to our service and we have access to our code, for us, it's far, far cheaper than for the attacker to test our own applications. And I think that there are even more ways how you can get the advantage, uh, from your side if you are developing software compared to the attacker.

Because so far, and this is the current focus, uh, of the industry, it's a kind of, hey, we do penetration tests and we assume that we invest enough time on that. And then there is always a question, when will it be become more attractive for the attacker to attack it? But if the, the advantage is us in Coronas, because you have so much more knowledge, you can automate so much more and the attacker has to go other lengths, uh, uh, to attack it, you will always be on the safer side.

And I definitely see that in the next year we will see more, uh, developments on that side and it's not just for product security, we can see it, uh, for the, for other, um, layers of our IT infrastructure as well. So How far left should we be shifting application security testing in general? Because to your earlier point, the developers are not experts in the space.

They, um, maybe if I give them some guidance on a particular line of code for a SQL injection attack, they might not write that in the first place, which would be great. But, um, do we need testing at the, in the build process? And after we deploy, what is the spectrum of testing looking like these days?

Yeah, I mean, so we definitely see a trend that a lot of static analysis. So basically where, uh, uh, you scan through the code and you get hints what is good or bad practice goes into the I D E because almost every I d E has a kind of plugin where you have static analysis as a developer that you can check in the code. But with static code analysis, some developers are annoyed if it's running in the C I C D pipeline.

And the main disadvantage are the false positives because what, when you develop in your I D E and you get those warnings, you basically react, oh, this is correct, this is incorrect. But if you would be blocking the pipeline or if you would address that, it will become uh, uh, very annoying. And where we see a lot of advancements right now is in the dynamic analysis space, um, where you do dynamic white box testing in a way, and there you don't have false positives.

Yeah, there are some but almost no false positives and those things will be running in the pipeline, Hey, the same way as with unit tests. And we always, we are even integrating into J unit and all those kind of, uh, test frameworks. Um, so that ideally for a developer, um, a security tests is the same thing as a functional test.

Uh, and it integrates even in the same frameworks. So in some points we are already there. In some other points we are missing the gaps.

But, uh, I mean, uh, uh, here I am as, as c e o of a company. We are working on a lot of those, uh, parts and others are too. There seems to be a lot of regulation floating around that all has a common theme which basically says, we're gonna hold you more accountable for security vulnerabilities.

Um, they're not quite law yet, but um, various, um, federal agencies are moving in this direction. EU is moving in this direction. So do you think that this will ultimately force all these issues where organizations are gonna have to deal with them eventually?

So maybe sooner is better? Yeah, this is a trickier question because it depends how you do the regulation. Because from what we observe is, let's call it checkbox security.

You kind of go through all the check boxes you have to do and uh, implement that. But there are two ways to do that. So some companies, they go to their developers and say, look, we have to do the following, so we need to comply with these things.

What do you have in your development process? How do you address it that we can report on that automatically? And this is like an approach where you would actually be fixing the bugs and then report, hey, and we are compliant at the same time.

But what happens in a lot of enterprises is that the people who are responsible, uh, for those regulation things, they kind of force it down on their development team and then the people kind of meet and they have even conflicts like, hey, this is slowing us down. And uh, uh, in the end open it results something like, Hey, we implemented that checkbox without actually fixing the technical issue. And the question is, how do you write a regulation?

And this is super hard because uh, uh, uh, you have to be generic enough that it's applying for a lot of different use cases, but at the same time, you have to be specific enough to say, oh, in the end you need to take care of their insecurity features. And in the different standards, I have seen good pieces where there are even recommendations. And it sounds funny, uh, yeah, a standard doesn't enforce it and people won't do it.

But what we actually see is if there are recommendations to use certain toolings companies start using that. So basically you enforce, you do some vulnerability scanning and for vulnerability scanning you can do the following methods. What we see is the companies start responding on that, and um, maybe we will get better regulations, uh, based on the experience, but what is coming in the first years probably will be more on the checkbox security side, and then the improvements will actually tackle, uh, the problems.

So, uh, it will resolve over time, but I don't think in the next one or two years. So ultimately, what's your best advice to organizations as they kind of look at all this AI stuff and they clearly all have the same end goal, right? I'm trying to get to more secure or higher quality applications, but um, how do I get from point A to point B?

Yeah, so what we observed, what works quite well is if you go to the developers and say, we want to fix those certain issues. So basically there are regulations, we want to fix it because we actually want to avoid those kind of hacks happening. Um, and from the development side, uh, they can bring something in the process and ideally it exports.

So from the development process, you get exports basically telling whether you have taken care of the certain things or not. Um, so instead of bringing it top down and then trying to hack in a way kind of try to make the compliance bottom up. So we have seen that in a few companies working.

Um, and, uh, it seems like to be a good advice for now where the regulation is still a lot vague where you can be compliant with checkbox security without actually bringing security. All right, folks. As always, it seems like things that are driven from the bottom up stick better than things that are driven from the top down.

And application security testing appears to be no different. Sergey, thanks for being on the show. Okay, thank you, Mike.

Thanks for having me here. All right. And back to you guys in the studio.