A DevSecOps Controversy? Failing the Build with Jenkins in SAST
Aug 16, 2023
A DevSecOps Controversy? Failing the Build with Jenkins in SAST
This video by Nithin Jois explores failing the build with #Jenkins in #SAST. https://appsecengineer.com/devsecops- …https://www.jenkins.io/ https://appsecengineer.com/devsecops- …https://twitter.com/AppSecEngineer https://www.linkedin.com/company/apps …
Content
0.8 -> Hey everyone welcome back to another
video by AppSec Engineer. In this video,
5.28 -> we're going to be looking at probably one of
the most controversial topics in DevSecOps.
9.76 -> And that's failing the build. We're going
to look at how you can go about failing the
13.12 -> build when you absolutely have to. Failing the
build can be tricky with SAST scans because the
17.68 -> possibility of false positives is pretty high.
This is why it's critical to choose the right
22.32 -> tool for your application. When it comes to open
source tools, we typically recommend choosing a
26.88 -> tool that provides both severity of the issue,
as well as the confidence score. The confidence
31.76 -> score essentially tells us the likelihood
or the certainty of that particular issue.
36.16 -> Using that as a filtering mechanism, along with
the severity of the issue, can help reduce the
41.76 -> possibility of failing the builds that are
sometimes cost due to the false positives.
58.08 -> If this is the sort of content you'd like
and enjoy, please consider subscribing to
62.32 -> this YouTube channel. And also
like the video are also active
65.44 -> on LinkedIn and Twitter where we are going to be
constantly posting updates on Kubernetes security,
70.48 -> Cloud security, AppSec,
DevSecOps and a whole lot more.
76 -> On my Jenkins instance, I'm
going to create a new item and
79.12 -> I'm just going to name this failing build.
And this is going to be a freestyle project.
82.88 -> So once the Jenkins job has been created
successfully under description, I'm just
87.28 -> going to write down failing build based on
severity and confidence score provided by
92.16 -> the tool. And in this case, we're going to be
using Bandit. Which is a SAST tool for python.
96.8 -> So now I'm going to scroll down to the source code
management section, and I'm going to select Git.
101.76 -> And in here, I'm going to give it my repo URL of
the intentionally vulnerable app that I am going
106.88 -> to be scan. And once that is done, I'm going to
scroll down further to the build section and I'm
111.28 -> going to select execute shell. Now this is where
I'm going to be running the bandit command. So I'm
116 -> going to paste in my bandit command right here.
So I'm going to be scanning the app directory,
120.64 -> which is inside my repository and going to be
generating JSON file output. And the output file
125.52 -> name is going to be "bandit-result.json"
Now typically bandit fails as soon as it
130.72 -> finds any issue. And we definitely do not
want that happening. So I'm just going to
134.56 -> pipe the output to be through at all times.
So no matter what results are found right
139.2 -> now in this particular step its going to go ahead
and essentially pass the build. But in this lab,
144.08 -> our intention is to go ahead and fail the
build. So what I'm going to do is I'm going
148.16 -> to add an additional execute shell right
here. And I'm gonna paste in my script.
152.72 -> So, lets quickly, go through this and
understand what's happening. So I'm going
156.08 -> to be creating a new variable called Issue.
And I'm going to be using the JSON processor
161.12 -> to go ahead and process the bandit result that
we generated in the previous step. So using that,
166.72 -> I'm going to start parsing this particular JSON
report, and I'm going to look for issues with
171.84 -> the severity that is either medium or high,
and the issue confidence to be equal to high.
177.04 -> So this variable is going to be populated only
for issues with high confidence score and that
182.96 -> either a medium level or high level severity. So
once that is done, I'm essentially going to have
188 -> a condition where I'm going to stage that,
if there is nothing in this issue variable,
192.24 -> then it's going to echo out no issues found.
But if there is something, then it's going
196.4 -> to print out, build failed because of high
or medium severity issues. And then it's
200.88 -> going to go ahead and exit as well. So with that
complete, I'm going to apply it and save this.
205.92 -> And now we can go ahead and build this
particular job. So, while its building,
209.68 -> I'm going to look at the console output. As
we can see the job is completed already. It
214.64 -> was able to successfully clone in my repository.
It also ran the scan and once the scan was done,
220 -> it essentially looked at our bandit result output.
And it found only issues with high confidence
226.08 -> score and either medium level
severity, or a high-level severity.
229.92 -> And finally it went ahead
and failed our build as well.
Source: https://www.youtube.com/watch?v=xhJcX3CAk44
