>> Hey, good news. Today we're joined by Victoria,
who's going to help us get right into the nitty gritty
of the tools necessary to get going in DevSecOps.
[MUSIC].
>> Welcome to the Azure Enablement Show
where we will be discussing
the challenges you and
our other text-heavy customers have encountered.
Together, we're going to be talking with
experts to find out how they think about these problems,
recommended tools and best practices and tips
stabler and from years of experience that you can use.
Today we're very lucky to have Victoria Almazova,
a Senior Security Architect.
Today we're going to talk a little bit
about really deep into
some of the tools that are involved in this.
In order to do that, I'm going to go back to
customer mode and I'm going to become a customer again.
Excellent. Victoria, thanks for
being willing to talk with me again.
Last time we were talking about DevSecOps
and this time you agreed to help
me get into the intricacies of nuts and bolts of it.
But just to make sure I understand,
can we just go over that DevSecOps thing one
more time just so I get what we're doing in the first place?
>> Yeah, let's do so. Let me show my slide, please.
Last time we spoke a lot about
implementing security into DevOps or DevSecOps,
which may contain a lot of
the things like starting from the flat modeling and I
think before the continuous monitoring
when we are in the production.
We agreed that we need to start somewhere.
As we are quite close in the development,
let's start with the CI/CD pipeline
in this particular case and let's focus there.
Specifically let's focus on the few things, for example,
dependency management and the security scanning.
Does it make sense?
>> Yeah, it makes perfect sense.
Why would you want to just do this small part here?
>> I tend to say you need to follow the Pareto principle, 80-20,
focus on the 20 percent of
your tasks which will cover 80 percent of your needs.
In this particular case,
according to the statistics for example, in the development,
we use more than 75 percent
of first-party libraries and
they may contain a lot of the vulnerabilities.
If we look into that part,
we're going to cover a lot of the vulnerabilities.
Then if we will do, for example,
the security scanning of your application,
we may cover almost top 10 or
the Open Web Application Security Project,
top 10 listed most common security vulnerabilities.
If you will take only these two practices,
we will cover a lot of the potential security threat.
>> I'm all for it then. Just to make this a little less abstract.
Is there any way you could actually see how this has really done?
>> Yeah, let me try to show you.
Here we're looking on the development from the linear perspective,
but let's look from the developer side.
When you do the development,
you write your code in your favorite e-dev
or intelligent development environment
like Visual Studio code and
then you do your development in your branch.
It depends on your branch strategies.
Once you feel that the code is
pushed and is ready, you compile it.
In this particular case,
I want as well to focus on the organization
because in today's world we do a lot of
the docker containers and we
push the images as well we compile the images.
In this particular scenario,
we push the image into
the docker registry and then we go to our Dev stage.
Once we play around as a developer,
we feel that we've wrote
our functionality or that we're recovering the use of story
and we feel that it can go to the main branch.
We just push our development branch
to the main and the process repeats itself.
Only we have the difference,
but it goes to the QA stage and
once the testing is
done and everyone is happy we go to the production.
In this particular case,
I want to focus today on the two things.
On our source code,
where we have our libraries and on our environments.
In this particular case,
I want to look into the applications which
we have developed and on the docker.
>> Super. PowerPoint is awesome,
but I would be even more
interested to see how it's sort of done in real life.
Do you have any way of showing me that?
>> I fully agree with you. Let's go to the Azure DevOps.
So David, I have created for
you the example Pipeline in Azure DevOps,
but you can achieve pretty similar concept as well in GitHub.
In this particular case,
we do have the Java application which we compile and
then we build it and push it to the container registry.
All other tasks or the steps,
what I have added on the top are focused purely on the security.
Like I mentioned, there are some areas which I want to focus.
Obviously we want to look into them
or source code and try to find if there
are some hard-coded usernames
and the passwords because that's not a good practice, correct?
>> Right.
>> Then I did the example for you like
when we look into our packages or the third-party libraries,
we can do it with the different tools.
We have the commercial or the open source.
In this particular case,
I do have the WhiteSource Bolt,
which looks into our third party applications for
the security vulnerabilities and for the licensing and as well
that open source solution which coming from
the same organization which doesn't do
only the writing the guidelines of top 10,
but as well, the community will add
some security tools which allows you to detect the rules,
a threat during your development.
In this particular case,
this is dependency check.
I'm publishing a code that
the dependency check results in the test.
Once the code is compiled,
I want to be sure that my application at least
doesn't have the overs top 10 security vulnerabilities.
That's why I'm running against to the my application ZAP scanner,
which does the scanning in
this case against to the security vulnerabilities.
Does it make sense so far?
>> Yeah, it makes total sense. The reason why
the ZAP thing is coming later is,
I'm a little just confused about that
because it looks like you're scanning before you built it.
Why is ZAP after you build it?
>> That's a good question. In the security world,
you can look into your application in the two ways.
One is what is called the static security
analysis and another is the dynamic security analysis.
In this case, I wanted to show you the letter,
the dynamic security analysis.
For that, the tool or the scanner
needs to have all the compiled and running application. Yeah.
What it does, it just takes your compiled application
and spin it up in
the container together with
that security scanning tool, and scans it.
>> Okay. Now I understand,
but it looked like there was another stage of the pipeline,
I saw it lower there.
Once all the scanning is done?
>> Yeah. Once the scanning done,
I want to have these results somewhere.
What I'm doing, I'm publishing them as a test results,
and we will look into that just in the few seconds.
The last step as well,
I want to focus on my docker image,
because you shouldn't assume
that if you put your application in the Docker image,
that it's already in the secure environment.
Because when you configure your image,
you may contain some security threats as well in the image itself,
so it's quite important to look into that path as a wholesome.
For that task, I have chosen the Anchore,
but there are plenty other security tools
available on the marketplace,
so you can play around and choose what fits perfectly for you.
Good, how does it
look for the pipeline for you, everything is clear?
>> Yeah, it makes total sense.
Now I have to admit I'm curious,
if it finds anything,
what does it look like, how do I know?
>> Yeah, that's a good point.
Once you run the pipeline, the first thing,
what we can focus is our credentials scanner,
because we want to start from there.
In this particular case,
I'm having the result in the logs, and you see,
it seems we do have some credentials in our code,
hardcoded, which is not good, we need to fix it.
As you can see, I'm placing these
in the log and I'm not breaking the pipeline,
because it is quite important
when you introduce the new security tool,
not to cause additional friction,
because the developers need to have the time to
learn and understand how the tool works.
That's why I'm not breaking the build pipeline here.
Of course, later when you get more comfortable with the tool,
you would add the task,
but once the vulnerability has been found,
please break the build pipeline. Does it make sense?
>> By break you mean the pipeline stops at this point,
and doesn't continue on to build and put
in or to deploy or whatever, it just stops right here.
That's what mean you mean, you don't mean
the pipeline itself stops functioning,
you mean it ceases
right at the moment where it discovers a vulnerability.
>> Correct. The build fails,
it will not be successful.
So then, it's pretty similar when you do the code quality checks.
For example, we have the SonarQube or other tools,
and if it doesn't satisfy,
you just break the build.
>> I understand. Okay, so that's the cred scan results,
are there are other results that we get out of this?
>> Yes. The next area where we want to
focus is all about these first party libraries.
This output is from the WhiteSource Bolt,
which actually creates the separate tab under the Azure DevOps,
where it represents all the findings,
what it found in your application,
like the source code, like what type
of the libraries have been involved.
As you can see, luckily,
we don't have the high risk findings,
but we do have the medium.
If you look into the details,
we can see not only which library contains them,
but as well what type of the security issue is there,
and as well, there's some top fix instruction.
That makes life for the developers easier,
because then I understand what do I need to do.
Like I mentioned, for your particular case,
I wanted to create another example
of representing these findings.
In this case, let me
maybe a bit zoom-out to show you the full picture.
In this case what I did,
I have implemented or I'm publishing
the dependency scanning results as a part of your test results.
As well, I do this with the application scanning.
We have the dynamic application scanner, which we did,
we've OWASP scanner, and as you can see,
we do have the findings.
It may sound like the rate is pretty decent,
but still we have the findings here,
as in test results.
You may choose which way
you want to implement these security tools.
Maybe this way is better because you
tend to check all the test results
and you already are familiar with this part.
We have looked on our application and we found some of them,
OWASP top 10, practices are not followed,
so we need to fix them.
That's just as example or
another way to showing the same first-party libraries findings.
I guess we have left the last one, the Container scanning.
In this case, what we have,
I have configured in a way that container scanning results may end
up being as an additional artifact
with the separate reporting document.
Why it's needed, because sometimes the security teams want to
have these type of report at their own place,
and may want to take them for the
after usage and helping you maybe to improve and so on.
We have published our Anchore results,
and the example of them looks following.
As you can see, even in our example,
we did not do a lot of the configuration of our image.
We just took the default
one which is available from the repositories,
and we found out that a lot of the libraries or
the system libraries were not up to date.
That means we will need as well to focus on our overall images,
or should I say, Containers.
This is a quite short example which I wanted to share with you,
to show how you can implement some of
the security tools with the same developer experience.
>> That's super useful.
It's nice to see it really practical,
and exactly the way I'd expect to see
it since I'm in the ADO all the time,
in Azure DevOps all the time.
I think with that stuff,
that gets me where I needed to go to get started,
it gives me a sense of what it's going to look like.
I think with that, what I'm going to do
is switch back to host mode.
Okay, back to host mode.
I just want to thank you Victoria,
and I want to thank all of you who are watching this,
for watching this episode of the Azure Enablement Show.
Please don't forget to like, comment, and share,
and subscribe, and join us again
for more of the Azure Enablement Show.
[MUSIC]