7 Places to Do Automated Security Tests

When working in a DevOps environment, security professionals are sometimes overwhelmed with just how fast the Dev and Ops teams are moving. We’re used to having more control, more time, and more… time!

Personally, I LOVE DevSecOps (the security team weaving security throughout the processes that Dev and Ops are doing). Due to my enthusiasm, I am often asked by clients when, how, and where to inject various types of tests and other security activities. Below is my list of options that I offer to clients for automated testing (there’s lots more security to do in DevOps — this is only automated tests). They analyze the list together and decide which places make the most sense based on their current status, and choose tools based on their current concerns.

Seven Places for Automated Testing

1. In the IDE:
   • Tools that check your code almost like a spell checker (not sure what this is called, sometimes called SAST)
   • Proxy management and dependency tools that only allow you to download secure packages
   • API and other linting tools that explain where you are not following the definition file
   • Software Composition Analysis to tell you that perhaps those packages are not so safe to use
2. Pre-commit hook:
   • Secret scanning — let’s stop security incidents before they happen.
3. At the code repository level:
   • Weekly schedule: SCA and SAST
   • Linting
   • IAC scanning
4. In the pipeline: Must be fast and accurate (little-to-no false positives)
   • Secret scanning – again!
   • Infrastructure as Code scanning (IaC)
   • DAST with HAR file from Selenium, or just passive scan (no fuzzing)
   • SCA (again if you like, preferably with a different tool than the first time)
   • Container and infra scanning, plus their dependencies
   • Scanning infrastructure as code for poor policy, configuration, and missing patches
5. Outside the pipeline:
   • DAST and fuzzing — automate to run weekly!
   • VA scanning/infra — should be done weekly
   • IAST — install during QA testing and pen tests, or in prod if you feel confident.
   • SAST — test for everything for each major release or after each large change, then do a manual review of results.
6. Unit tests:
   • Take the devs' tests and turn them into negative tests/abuse cases.
   • Create unit tests from penetration test results to ensure we don't repeat our mistakes.
7. Continuously:
   • Vulnerability management. You should be uploading all your scan data into some sort of system to look for patterns, trends, and (most of all) improvements.

You do not need to do all of these, or even half of these. The purpose of this article is to show you several possibilities in hopes that you take advantage of some of them.

Do YOU do testing in more places than this? Where, when, and how? Do you have other tools you use that you find helpful? Please comment below and let us know!