The definition or what is automated security testing?
Well, in order to look at what automated security testing is,
it makes since to first look at what security testing is.
And we divide security testing in three different parts in this clip.
First, we're going to take a look at test paths,
then add testing methods, and finally,
we'll be looking in this clip at security testing types.
When talking about security testing, most people test-driven security.
test-driven security is a bit comparable to test-driven development.
First, you define the security requirements,
so you come up with requirements with what your application should comply to.
After defining the requirements, you start with writing a test per requirement.
And when you have written a test and try the test,
you'll probably see that the first test initially fails,
of course, only when it isn't implemented yet.
Otherwise, it will pass.
So, when it fails, you implement the control or the mitigation,
and then you verify that the test passes.
And this process continues until all tests are written for each of the
security requirements that you have defined before.
So this is the model of test-driven security And it's more or
less similar to test-driven development.
First you write a test, the test initially fails,
you implement the feature or control, the test passes,
and you repeat this process until all requirements are met.
The advantage of test-driven security is that it forces the
team to think of security beforehand.
You need to have a list of security requirements for your application.
Therefore, the security itself has to be defined.
And this is obviously a good thing because it forces
you to think of security beforehand.
Test-driven security is also a form of happy path testing.
And happy path testing, you might ask, what exactly is that?
Well, there are two different test paths.
There's positive testing, and there's negative testing.
Positive testing is also known as the happy path testing.
You're testing whether a given input yields a given result.
So the input is known, as well as the result.
An example would be entering a valid username and password
and verifying whether the user can log on.
On the other hand, negative testing is known as a sad path or a bad path.
That's when something happens which you didn't expect.
Either you get an error message back in the bad path,
or you don't get any error message at all,
a sad path.
This is also known as failure testing.
So at the left-hand side, positive testing,
you have used cases where you expect an intended output,
and on the right-hand side, negative testing and use cases.
You try to let the application do something it's not intended to do.
The disadvantage of negative testing is that it's difficult
because how do you know what it's not suppose to do?
When you compare it to happy path testing,
you know the input, and you know the expected outcome.
But with negative testing, there isn't an expected outcome.
You either expect an error, or you expect not the happy path output.
When you don't see the happy path output, is that good, or is it bad?
How do you know?
So instead of a set of inputs for the happy path,
for negative testing, there are an unlimited number of inputs which you can use,
an infinite number.
What makes negative testing also difficult is that the
output not always shows the error.
So even though the application does something it's not intended to do,
it's difficult to prove that based on the output.
It's kind of blind testing sometimes.
We looked at two different testing paths,
the happy path and the sad path, or bad path.
You also have two methods of testing.
There's static testing, as well as dynamic testing.
With static testing, nothing is executed,
so you use as input, for instance,
the source code with a source code review or the configuration,
for instance, of a web server.
You can see without running the application whether the web
server already adheres to some kind of policy.
With dynamic testing, you actually run the code or the application.
An example of dynamic testing would be dynamic application security testing.
That's when you actually fire up the application and
you directly talk to the application.
An example of dynamic testing could be network vulnerability scanning,
where you actively scan your network on vulnerabilities
based on the running configuration.
We looked at the test paths.
We look at the testing methods.
Now let's take a look at the types of security testing.
Broadly speaking, you'll see the same categories.
The first one is static application security testing,
the second one is dynamic application security testing,
and the third one is vulnerability scanning.
Sometimes you also hear about different types of security testing,
but broadly speaking, these three categories encompass everything.
And as a reminder,
the course Performing DevSecOps Automated Security
Testing will deal with the tools itself.
That course contains lots of demos.
Right now, we're looking at the concepts.
And to circle back to test-driven security,
which we saw in the beginning of this clip.
So, security testing is a little bit more than just this.
Test-driven security is happy path testing,
and with happy path testing, you don't test everything.
That's why it's necessary to use different types of testing.
In the next clip, we'll dive deeper into static application security testing,
dynamic application security testing, and vulnerability scanning.