>> 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]
