Suggestion: Provide Developers with security scanning software (such as OWASP Zap), teach them to use it, and ask them to fix everything it finds before sending it to QA.
You can add automated security testing into your pipeline, specifically:
- VA scanning of infrastructure (missing patches/bad config - this is for containers or VMs, but you often usually use different tools)
- 3rd party components and libraries for known vulnerabilities (SCA)
- Dynamic Application Security Testing (DAST) - only do a passive scan so that you don’t make the pipeline too slow or use a HAR file to automate which parts are tested and which are not.
- Static Application Security Testing (SAST) - do this carefully, it can be incredibly slow. Usually people only scan the delta in a pipeline (the newly changed code), and do the rest outside of a pipeline.
- Security Hygiene - verify your encryption settings, that you are using appropriate security headers, your cookie settings are good, that HTTPS is forced, etc.
- Anything else you can think of, as long as it’s fast. If you slow the pipeline down a lot you will lose friends in the Dev team.
During the testing phase I suggest doing a proper Vulnerability/Security Assessment (VA) or PenTest (if you need management’s attention), but early enough that if you find something you can fix it before it’s published. More ideas on this:
- Repurpose unit tests into security regression tests: for each test create an opposite test, that verifies the app can handle poorly formed or malicious input
- For each result in the Security Assessment that you performed create a unit test that will ensure that bug does not re-appear
- Ensure developers run and pass all unit tests before even considering pushing to the pipeline
- Perform all the same testing that you normally would, stress and performance testing, user acceptance testing (hopefully you started with AB testing earlier in the process), and anything else you would normally do.
Penetration testing is an authorized simulated attack on a computer system, performed to evaluate the security of the system. The idea is to find out how far an attacker could get. This differs from a security assessment or vulnerability assessment, in that they are prioritizing exploiting the vulnerabilities they find, rather than just reporting them. If you want to shock management and get some buy-in, a PenTest is the way to go. But if just you want to find the things wrong with your app, and ensure lower risk to your systems, I would recommend a security/vulnerability assessment instead. It depends on your situation.
Up next in this series we will discuss what a formal AppSec program should include, followed by AppSec “extras” and special AppSec programs, which will end this series.
