it makes sense to look at a generic web application.
What happens from design to deployment?
What exactly happens?
Take this Globomantics developer who works with Maeve.
He develops code and pushes it to a repository.
A build server pulls the code and builds artifacts from it.
Those artifacts can be binaries, but also container images.
A standard continuous integration continues delivery pipeline, so to speak.
And those artifacts,
deliveries are sent over the network to the production environment,
a standard deployment.
This is a generic lifecycle of a microservice or web application.
So first we have the code in the repository,
then we have the containers, the build artifacts,
which will be deployed to the infrastructure,
and this partitioning helps us to see what can be tested.
First, we have the code, then we have the containers,
and then we have the infrastructure.
Let's look at the code first.
What can be tested?
We can test the code for readability.
Now, you might think, what has readability to do with security?
Well, more than you think.
A developer writes code once, but you read it much more often,
so it's very important to make sure that the code is readable.
Unreadable code introduces security vulnerabilities,
so it makes sense to check the code for readability because
difficult to read code can lead to security issues,
maintainability and clarity, also something you can check the code for.
And again, this has to do with security vulnerabilities.
Insecure patterns.
You can check the code for SQL injection vulnerabilities or
cross-site scripting vulnerabilities,
These are insecure patterns which you can test the code for.
Then you can check for hardcoded secrets,
and using, for instance, automated vulnerability scanners,
you can check for insecure third-party libraries.
So these are all items you can check the code for.
Then you have containers.
You can check containers for poisoned images.
Are the images you're using for your production
environment not secretly modified?
Are they valid?
Do they run insecure third-party software?
And again, this is something you can test containers for.
Are the containers hardened enough?
And the container itself,
check the verification and the integrity of the container
before pushing it out to production.
These are all valid security tests for containers.
And then we have the infrastructure.
You can test the infrastructure for hardening.
You can test it for configuration errors,
say, for instance, network ports that are open.
Another example would be an open administrative interface of a web server,
things you should be easily able to catch using automated security testing.
And you can test the infrastructure for server and network vulnerabilities.
These three are all items you can test the infrastructure
for using automated security testing.
These are all concepts, and in the following course,
Performing DevSecOps Automated Security Testing,
you'll actually see tools in action, which tooling to use and how.
In the next clip,
we'll look at where to test in the software development lifecycle.