We've taken a look at automated security testing,
what it is, the pros and cons, and we just saw what you can test.
Now we're trying to answer the question,
where can you perform automated security testing?
Have you heard yet of shift left, the latest and greatest buzzword?
What is shift left?
Let me try to explain you.
This is the usual standard software development lifecycle process.
You define something, then it gets designed,
it will be developed by a team, deployed to production,
and then maintained.
So far, so good.
And when is security testing usually performed in this?
Currently, at most companies, it's the last phase, when it's in production.
Then security tests are being performed in the form of penetration testing.
The shift left paradigm says try to perform security
testing earlier in the lifecycle, shifted to the left.
For instance,
we can use dynamic application security testing during the deployment phase,
or, even more to the left,
we can perform static application security testing during the development phase.
What shift left is saying is not wait until the last
possible moment to perform security testing,
while it's already being maintained and live in operations,
but try to do it earlier on during the deployment
phase or the development phase.
The advantages of shifting security testing left are numerous.
It gives you better accountability, because what happens?
Well, when a developer pushes code to a build server,
how cool is it if a developer gets instant feedback on his or her code quality,
on how secure or insecure the code is.
It gives better accountability for everyone involved.
It also means that code can be fixed earlier.
Vulnerabilities are found earlier; therefore, it's cheaper to fix them.
They aren't rolled out to production yet.
Another advantage of shifting security testing left is that it
codifies security requirements earlier on.
Because when you define the tests and when you hang the test
in your software development pipeline, you codify the requirement,
what you exactly need when software passes a test
and when it doesn't pass a test.
Let's go back to the developer in Maeve's team.
Where can we perform tests?
When the developer wants to commit code,
he performs a commit on his local workstation,
and that's where the pre-commit hook on his local repository comes in handy.
During the pre-commit phase, locally, you can already run security tests.
Then you have to commit, where the commit is pushed to the central repository.
This is not a location where you can perform automated security tests.
Then you have the build step,
where the build server pulls or the repository pushes code to the build server.
And then you have the deploy phase,
from the build server to production environment.
And in each of these phases you can perform automated security tests.
Let's start with the pre-commit phase.
What kind of checks can you perform here, locally, on your workstation?
Linters, mainly.
Linters can help you with the readability and clarity,
as we saw in the previous clips, which are so important.
They can help you with formatting.
Pre-commit hooks also can help you finding hardcoded secrets or
actually preventing you from committing them.
The next location where you can add automated
security testing is the commit phase, and here I can use the same tricks.
You can use linters in order to check for formatting.
You can also check here for maintainability,
for instance, with security integration tests.
You can also check for clarity, the formatting, how the code is structured.
And the commit phase is perfect in order to spot insecure patterns in the code.
This is, for instance, where you can run static source code analysis tool,
which pick up insecure patterns in your code.
And of course, the same as we did with the pre-commit hook,
this is also a phase where you can spot hardcoded secrets.
The commit phase is also the location where you can run automated
security tests in order to find insecure third-party libraries
using automated vulnerability scanners, as we saw in the previous module.
Then we have the build phase.
In the build phase, you can run dynamic scanning tools like,
for instance, attack proxies.
In the next course in this path, we will see OWASP ZAP,
an attack proxy in action exactly in this phase.
The build phase is also perfect for fuzzing tools.
Try numerous inputs in order to find a set path or a negative path.
And the build phase is the location where you check for configuration errors,
be it in network, software, or other components.
During the deploy phase, you can check for compliance checks.
Think of hardening steps,
whether you inadvertently deployed documentation to
your site or other test points.
This is also the location to check for runtime defense tools and hardening,
network, as well as applications.
So to be clear, in this phase, the deploy phase,
that's where I usually use dynamic application security testing tools.
You use automated security testing tools against the
deployed application while it's running.
In the next clip,
we'll see how to approach setting up automated security testing.
See you there.