4 hours 39 minutes
for less in 3.5.
I'm just going to a demo of spot bugs just to kind of give you a perspective of from the developers what they would be seeing and, you know, prevent. So this is part of the preparedness state stages, giving them the tools to work on the bugs fixem or find me
identifies writing secure code before he actually run it in the test that we can fix these bugs early.
So the objective looks that just gonna go through demonstrate spot bugs and then explain the steps to go through actually fixed one of the bugs, just kind of given example so you can see the perspective of it.
And here is that you take a look at this is the website for spot bugs and and, uh, Eclipse so eclipses the integrated development environment. The i d Do we call it that the developer could be working in and spot bugs or just a plug in for it later on? When actually run it in our pipeline? That's it's a
It's a self running program that will provide results back to Jenkins. But this is getting like fixem fixing the books early
it's over. This demo just gonna kind of go through the
eclipse using spot bugs. This is gonna be a little bit depth. It's a lot of coding. I just want to kind of you follow along. If you don't understand the concept, it's fine. It's really just understanding how we can help the developer and provide tools to them within the integrated development environment here of Eclipse.
So the 1st 1 I have the job of vulnerable ab our lab opened up
with the What they had developer would do is say OK, I have spot bugs here, take a look.
Let me go through here and find all my bugs
I went to see down. Here is for each one of these job of files. There's now a in parentheses showing that the number of spot bugs that are the number of possible bugs that spot books has found,
so there's a couple ways they can go through it. Um,
if you're not going by the file, you can actually drill down and see, so they're scary. Troubling of concern. There. Five scary ones. You could actually open these up
and then keep drilling down to you See So, for example, this one says I have an http response. Splitting vulnerability
drill down again and they can actually click on it.
Tonight's it pops up the. So this one's called the Open Java file is the one that actually has the issue here, and you'll see there's a little bug right next to it, and that tells them Here is the issue So you can click on this
drill down and give this but some information about it. So forget this bug is HD primer directly written toe header output,
and this is, ah, split header issues so they can if they want to split response.
You can actually click on a link here, and they can get some information. This one is Wikipedia gives him a little official information
again. You can read further down here.
But so, for example, what it might be interested in doing is that they want they want to fix a specific file. So this is an email check file
Scroll down here. What's the issue? This is a sequel. Injection.
Um, that says
read it and says this method invokes, execute or add batch method on a sequel statement with a string that seemed to be dynamically generated. Consider using a prepared statement instead, more efficient and less vulnerable to sequel injection
so they could maybe go about and read it. So
But that would be fun. Here is, if we actually fix it
again, there's gonna be feel like coding. But you can kind of see, just want to show you how the developer would be working. So they would say, instead of just a regular statement, I want to do a prepared statement.
I'm gonna call my variable prepared statement,
and I'm gonna make it equal to instead of see, this was just connection. Create statement when I wanted to be is
Groups like a spell.
That's what it's gonna look like. I'm gonna fix a little bit here. We have to fix this import.
just in Java, you have to stay with. Explain where you got that method from, and it goes and finds a library for you.
Um, so instead of
I put this in here and I explain what we're doing.
I see Hope so. I spent the wrong repair statement. I prepared um so So the issue has probably explained Here is that this email right here this variable was taken directly from the Web server or so the application server and put right into a sequel statement. This is the classic
sequel. Injection is you take
text or you take a variable directly for an application service that the user sent most time it works, but a malicious user could put semi colon. Who knows what else in there and directly inject into your sequel statement.
That's what it there
the spot bugs did not like or found. So what we said here, instead of putting that email variable, I'm kind of a question mark in here cause it's just wait the way Prepared statement works. Prepare
dot set string, which is where I'm not gonna put that thing that variable in here dot email.
So the prepared statement has ways of combating sequel injection doesn't work perfectly. I would probably do some other filtering, but we're just for this example. That's what we want to do.
So I'm gonna
I'll start clearing some of this out or commenting out to show you to find a
once we conclude unclear the bugs. I just wanna kind of show this
real time. So our results that
instead of the statement like we're above, I'm gonna call my prepared statement much I just created.
And then I'm gonna execute the query
Everything looks good. I've still got the bug here.
So let me comment out that bug.
Let me come it out. That issue,
and it saved the file.
And now our bug is gone because we fixed it with a prepared statement.
This is Ah, You see, this is the way the developer but would be working fixing these bugs
on then, obviously fixing it in the I d. And in the lot quicker than waiting till we get deeper and spot, but later have to go back and re code it. Find any issues like that.
And again, you can kind of they kind of go through here and fix someone at the time. Um, when I go through all these, but you can kind of see how again, Just drilling down. They could do this. Open up the problem. I see you got another sequel injection finding here.
But that's what it looks like for that from the developers perspective.
At this point, I just have a question for you.
Can you see the value of developers fixing bugs during the coating
of the ideas? It's cheaper to fix it before you go through the building. Maybe even the test phase and then changing require me looking. Their requirements are at anything like that. If you do it right in the I. D developer couldn't be writing see the bug, go research, fix it before it even gets to the pipeline where we have to. Then
security people have to look at it. You created issue any of that
a cycle of additional people additional time
and also can help the
teach them as they're writing, they could see vulnerability like Oh, let me go research to see how to find it and then the next time the writing it they may not, There may not make the same issue again. Or see it was like already seen. I've already seen this bug on how to fix it.
Did this model it? Take a look at spot bucks. You can see how the developer would be using security while the weather coating and next we'll take a look at how we can help security learn Dev ops