We've come to the final topic of this course: How to Approach
Implementing Automated Security Testing.
And this clip is not about the actual implementation,
but how you could start using automated security testing at your company.
So see it more as tips for the future when you want to start
with implementing automated security testing.
When you want to start with implementing automated security testing,
let the team pick its own tools.
Don't try to enforce using any tools.
The team members select and pick their own tools.
When selecting tools or a part to use for automated security testing,
start with the quick wins first.
That way you get the biggest return on investment.
As we saw, security is a tradeoff,
so use tooling there where it makes most sense.
For some companies,
it could be something as simple as checking for hardcoded secrets.
For other companies, it could be using attack proxies.
Automated vulnerability scanners for third-party libraries
might also be a good fit for most companies.
When you start using a tool, invest some time in setting a baseline.
Discuss with team members what you expect from the results.
What is a good result, and what is a bad, insecure result?
Take some time to discuss the initial results.
And this invested time will pay out dividends in the long run.
When starting out, don't use hard-quality gating.
Let the tools generate reports, but don't block a build just on security flags,
not just yet,
not before the tool is completely configured and you
have trust in the whole build system,
you have trust in the results of the automated security scans.
And plan time to configure and weed out false positives.
You're using automated security testing in order to
improve the security of the product,
but you also don't want to impede the whole process.
In an ideal situation, you want the whole team to trust the results; therefore,
make sure that the people actually can trust the results.
Then you'll get the best returns.
The process itself should be iterative.
You select the tool, then you implement the tool,
analyzing its results,
and this maybe could mean that you want to use a different tool,
and you improve upon the tooling set.
Yes, and it can and probably will increase the security of your product.
Yes, it can and will probably save you lots of time.
But it's not just a fire and forget.
It's not just a one-time exercise where you start the whole process and
then just hope that everything will turn out for the best.
You really need to put in time and effort in order to make this a success.
Think of it this way: Automated security testing is a process and not a product.
It's a continuous process, the same as with security.
You're never done.
Join me in the last clip of this course, the summary.