Let's list some of the advantages of automated security testing.
And the first one is probably very obvious.
It's scalable.
You set up the automated security testing once,
and then whether you test one component or
microservice or tens or hundreds of them,
it scales.
The second one is also pretty obvious.
It's repeatable.
Each time you run the same test with the same input,
you will get the same results.
Although, the results can vary over time, as we shall see.
The third one also makes sense.
You can automatically block a build when a security test fails.
So this means that if your component is insecure,
or actually flagged as insecure by the automated security test,
then you can prevent it from being deployed to other environments.
No manual steps necessary.
And because developers get immediate feedback on their build process,
security becomes a habit.
Developers need to specify the security requirements
beforehand because you need those in order to set up the
automated security test; therefore,
it becomes more ingrained in the whole culture.
Another advantage is that the test results can change over time,
even if the code or the build process doesn't change.
Now, what does this exactly mean?
Because we said earlier on that the process is repeatable.
Well, security degrades over time.
If a component is secure today,
doesn't mean that the same component is secure a year from now.
More and more vulnerabilities are discovered over time.
When you use an automated vulnerability scanner,
as we saw in the previous module,
it will pick up new definitions with vulnerabilities,
and those vulnerabilities are continuously being published.
So if you use the same scanner for the same component,
it will yield different results over time.
Something which is flagged as secure today might not be flagged as secure
tomorrow because it might contain a new discovered vulnerability.
So automated security testing automatically keeps you up to date.
With automated security testing set up correctly,
you don't need to do any manual steps.
Just as in real life, it's not all sunshine and roses.
There are some disadvantages of using automated security testing.
Scans can take a long time, which means it might hamper the development process.
If developers need to wait until a test finishes, it can slow things down.
Most of the tools are generic, which means yes,
they test some security features, but no,
they're not testing your custom application.
And the more bespoke your application is,
the more difficult it will be for a tool to actually
scan for security vulnerabilities.
An often-heard complaint is that false positives get in the way.
Nothing drives morale down more easily than
continuously having to verify false positives.
Worse, people stop relying on your security scan results.
So it could actually negatively impact your security.
And even though we said in the previous slide with the
advantages that it's kind of fire and forget,
well, not entirely.
Because not only tools change, the application also might change.
And because you need to customize the tools to test them for you,
it also means that when your application changes,
you also need the configuration of the tool,
so that's actually a continuous cost and often a hidden continuous cost.
Especially combined with the false positives, you need to maintain your tools.
And finally,
we'll see the same item here in the disadvantages
as we saw earlier on advantages.
Security is not static.
And with this, I mean that when your application changes,
you should also change the test parameters.
If you add, for instance, new input boxes or new upload functionality,
you might have to add that to the tool because tools are generic.
So, overall, not everything is a candidate for automated security testing.
It's not a one-size-fits-all approach.
And yes, I said one size fits all.
After having looked at the pros and cons,
in which situations makes sense to use automated security testing?
Well, security is always a tradeoff,
and if that what you're protecting is worth a lot,
then it makes sense to invest a little bit in automated security testing.
It also makes sense in those situations where delta scans are easy.
What are delta scans?
As we saw before,
one of the disadvantages of automated security testing is that it takes up
a lot of time or actually can take up a lot of time.
If the changes,
if the security testing can be done in an incremental way that only the
new changes are tested for security vulnerabilities,
then it makes sense to use automated security testing.
So if your development process is very iterative,
then it is very useful to use automated security testing.
Another great reason to implement automated security
testing is just to comply with standards.
Think of the PCI DSS standards.
Some of those standards have mandatory security testing,
and implementing automated security testing makes sure that
you actually comply with those standards.
It's also useful to implement automated security testing
in order to get a security baseline,
which gives you an approximation of where your company,
or your components, or your development team stands with regards to security.
How does it do with regards to the competition?
Therefore, if you're interested in your status,
then it makes sense to implement automated security testing.
Having said that,
when is automated security testing not useful or at least less useful?
Well, the same reason as the previous reason, investment versus reward.
Security is always a tradeoff.
So if that what you're protecting isn't worth that much,
then should you actually invest money into
implementing automated security testing?
Only you can answer the question.
If the application you're trying to protect has a lot of complex business rules,
then it might be difficult to implement automated security testing.
You might end up spending a lot of time implementing
rules in order to test it properly, and then it doesn't make sense.
It might make more sense to keep on testing stuff manually because,
of course, you still should test, just not automated.
If the environment you're testing changes rapidly,
then it also doesn't make sense because then you're
continuously trying to keep up the tooling set.
And again, I can't stress this enough, security is always a tradeoff.
And if your application uses a mix of frameworks and languages,
then the tooling might not be efficient.
Tooling is usually built for one specific framework or language,
and when you have a mix of that,
there aren't that many polyglot tools available right now.
Of course, it might change in the future,
but overall,
if you need to spend too much time configuring and
testing your automated security tools, then it just doesn't make sense.
And when you're using tools, not all tools are equal.
If you use a tool, try to use more than one tool for the same kind of test.
Then you get a better test coverage.
And speaking of choosing tools, let the team experiment with different tools.
Ideally, you want tools carried by the team and not enforced from above.
The reporting format can make a difference.
And with that, I mean the form in which the security testing report is delivered.
Is it a PDF file?
Is it just a binary yes or no, it's secure?
And a report is something that developers needs to digest.
So the better the format is for the developers, the better the tooling is.
It can really make a difference in which tool you're using.
Implement what works best for the team.
Again, don't try to enforce specific tooling for the team,
but try to facilitate and not mandate specific tools.
You want to make sure that all tools are supported by the team.
And then one final tip.
Before you start scanning,
know what to do with non-compliancy results before implementing the scans.
If you don't know what you're going to do with all the results,
then it just doesn't make sense to implement it.
Because the whole reason you're implementing automated security
testing is to make your application more secure.
In the next clip, we'll summarize this whole module.