Seven places to conduct automated security testing

Personally, I like DevSecOps (where security teams weave security throughout the entire process Dev and Ops are executing). Because of my passion, clients often ask me when, how, and where to inject various types of testing and other security activities. Below is a list of options I offer clients for automated testing (there is a lot more security work to do in DevOps - this is just automated testing). Together they analyze the list and decide where it makes the most sense based on their current status, and select tools based on their current focus.

Seven Places for Automated Testing

1. In an integrated development environment:

• Almost like a spell checker Tools to inspect code (not sure what this is called, sometimes called SAST)
• Agent management and dependency tools that only allow you to download security packages
• API and other linting tools that explain where you are Failure to follow definition files
• Software portfolio analysis tells you that maybe these packages are not so safe to use

2. Pre-commit hook:

Secret scanning - let We stop security incidents before they happen.

3. At the code repository level:

• Weekly Task List: SCA and SAST
• Linting
• IAC Scan

4. In the pipeline: Must be fast and accurate (almost no false positives)

• Secret scanning - Again!
• Infrastructure as Code Scanning (IaC)
• DAST with HAR files from Selenium, or just passive scanning (no fuzz testing)
• SCA (preferably using a different tool than the first time if you prefer)
• Container and infrastructure scans, and their dependencies
• Scan infrastructure as code for bad policies, configurations, and missing patches

5. Outside the pipeline:

• DAST and fuzz testing – run automatically every week!
• VA scans/infrastructure – should be done weekly
• IAST — in QA testing and penetration Installed during testing, or in production if you are confident.
• SAST – Test everything after every major release or big change, then manually review the results.

6. Unit Testing:

• Take developer’s testing and turn it into negative tests/abuse cases.
• Create unit tests based on penetration testing results to ensure we don’t repeat the same mistakes.

7. Ongoing:

Vulnerability management. You should upload all your scan data into some kind of system to look for patterns, trends, and (most importantly) improvements.

You don’t need to do all of these, or even half of them. The purpose of this article is to show you a few possibilities and hopefully you will be able to take advantage of some of them.

The above is the detailed content of Seven places to conduct automated security testing. For more information, please follow other related articles on the PHP Chinese website!