Let's take a closer look at the types of security testing.
Static application security testing.
An example of static application security testing
is static source code analysis.
So this is where I use a tool to analyze the source code
without running it because it's static.
Another example would be linters, where you check the code,
for instance, for formatting or readability consistency.
Another example of static application security testing
would be the checks on secrets in code.
Are you inadvertently using variables and hard-coded secrets?
These three are examples of static application security testing.
Then we have dynamic application security testing.
Examples of those are dynamic source code analysis.
This is where you actually run the code,
you execute it, and you to try to find security issues.
Another example would be fuzzers,
where you try numerous different inputs and to see how the code,
the running code, reacts.
Another example of dynamic application security testing would be attack proxies.
For instance, the open source security scanner OWASP ZAP.
That's an example of an attack proxy who tries to attack running code.
It tried to find security issues in the code by performing various tests.
These three are examples of dynamic application security testing.
And after the static and dynamic application security testing,
we have the vulnerability scanners.
First start with looking what a vulnerability is.
The definition for vulnerability that I always use is
a weakness that can be exploited.
You have bugs in code, weaknesses,
and a vulnerability is a weakness that can be exploited.
That's what make a weakness a vulnerability.
So an automated vulnerability scanner,
on exactly which vulnerabilities does it scan?
Well, it only looks for known and published vulnerabilities.
And for more information about vulnerability scanning,
I can recommend you to the Pluralsight course,
Securing Coding: Using Components with Known Vulnerabilities.
That course dives deeper into the subject of vulnerability scanning.
An automated vulnerability scanner perform three different steps.
First, it tries to fingerprint all the assets that are in use.
It can do this, for instance, by using checksums on source code.
Then it ingests the lists of known vulnerabilities.
So this is where a vulnerability scanner contacts other sources on the internet,
having list of published vulnerabilities.
And then it compares the assets that has fingerprinted in the
first step with the list of known vulnerabilities.
And if there is a match,
then the automated vulnerability scanner has found a vulnerability.
Examples of automated vulnerability scanners are,
for instance, a network vulnerability scanner,
when you scan the network for known vulnerabilities.
Another example would be a container vulnerability scanner.
This is where you scan containers for known
vulnerabilities that they might contain.
Another example would be a third-party library scanner.
Almost all software make use of third-party libraries.
With a third-party library scanner,
you can test whether the libraries you're using,
or including in your code, contain known or published vulnerabilities.
These are all examples of automated vulnerability scanners.
In the next clip, we'll dive deeper into manual versus automated testing.