Look DevOps and DevSecOps, this is a really, really large topic. It takes a lot
of people
many, many months or years to really wrap their head around it. So don't feel
bad if
this is a set of content that you got to watch a couple times. Whole careers
are built around
just managing CI/CD pipelines, let alone adding security into the mix. But you,
as a security
professional, need to be aware that in software development environments where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
professional, need to be aware that in software development environments where
the application
itself is the product, this is definitely something you're going to be doing
basically
full time. It's going to be your whole job. So let's think about some scenarios
here.
You're reviewing your business practices for delivering code and you think a
DevOps pipeline
with security might be the solution you need. The manager has asked you
specifically why
you need a DevSecOps pipeline instead of just a normal DevOps pipeline. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you need a DevSecOps pipeline instead of just a normal DevOps pipeline.
Basically, what's
the difference? Which of the following best describes the primary goal of a Dev
SecOps
pipeline? It's actually a little bit of a tricky question. Replace manual QA
testing
with automated unit tests. Well, that's definitely an objective of a regular
DevOps pipeline,
but not a DevSecOps pipeline. Automate infrastructure provisioning with zero
developer involvement,
again, definitely a part of DevOps pipeline, but not DevSecOps. Ensure only WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
again, definitely a part of DevOps pipeline, but not DevSecOps. Ensure only
developers
can deploy code to production. Yep, another DevOps pipeline thing, but not Dev
SecOps.
Integrate security testing and checks throughout the software development lif
ecycle bingo. That's
the one we're looking for here. So with that answer being said, that's the sec
in DevSecOps.
It's all about shifting left, not waiting until the application is deployed to
start
doing security testing. We want to be doing security testing the whole way WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
doing security testing. We want to be doing security testing the whole way
through it.
You're configuring Bandit in a GitHub actions workflow to fail the pipeline. If
any high
confidence, medium or higher severity issues are detected, which of the
following Bandit
command line options would enforce this? Well, Bandit R dot is the start of all
of these,
and that's right. We want to recursively look through all of the folders
starting in
this folder, but it's there is no severity flag, nor is there a confidence flag WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this folder, but it's there is no severity flag, nor is there a confidence flag
. So I
can immediately rule out this one and this one. So that leaves the hyphen L and
hyphen
I. The kicker here is that we want multiple L's and multiple eyes to detect
high confidence
or medium to high severity issues. If we only select one L or one I, it would
only detect WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
only detect
low severity issues. So the correct answer is going to be the third answer on
my screen.
It'll be different on yours because they're randomized, which has multiple L's
and multiple
L's. A developer adds this Python code to their application. We've seen this
one before. When
Bandit flags this, what confidence level will it have? Well, the answer here,
because we
just walked through this example is high. Interestingly, I thought it would
have high WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have high
severity, but it only flagged this as medium severity. So it was a little wrong
on that,
but it definitely flagged it with high confidence that it is an issue. So these
are some ways
that we can start working dev sec ops into our dev ops pipelines.