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 & 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
2. Pre-commit hook:
   • secret scanning, let’s stop security incidents before they happen
3. At the code repository level:
   • weekly schedule: SCA & SAST
4. In the Pipeline:
 Must be fast and accurate (no false positives)
   • secret scanning – again!
   • Infrastructure as Code scanning (IaC)
   • DAST with HAR file from Selenium or just passive
   • SCA (again if you like, preferably with a different tool than the first time)
   • Container and infra scanning, + their dependencies
5. Outside the Pipeline:
   • DAST & fuzzing, automate to run weekly!
   • VA scanning/infra – weekly
   • IAST – install during QA testing and PenTests, or in prod if you feel confident
   • SAST – test for everything for each major release or after each large change – manual review of results
6. Unit-Tests:
   • take the dev’s tests and turn them into negative tests/abuse cases
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. But please do some of them. WHP will try to put out a course on this later on in the year!

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!