loading...
Microsoft Azure

Pushing Left, Like a Boss - Part 8: Testing

shehackspurple profile image Tanya Janca ・2 min read

Testing can happen as soon as you have something to test.

It is my belief that testing should be done throughout the development lifecycle, and not only during the testing phase. We want feedback as soon as possible, to ensure we make a high-quality product that customers actually want. Below I will lay out some strategies for security testing.
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.

Add automated security testing into your pipeline, specifically:

  • VA scanning of infrastructure (missing patches/bad config - this is for containers or VMs, but you use different tools to scan them)
  • 3rdparty components and libraries for known vulnerabilities
  • Dynamic Application Security Testing (DAST) - only do a passive scan so that you don't make the pipeline too slow
  • Static Application Security Testing (SAST) - do this carefully, it can be incredibly slow, you can only scan for one type of bug at a time and if it's still too slow then do it outside the pipeline
  • Security Hygiene - verify you encryption status, that you are using appropriate security headers, 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.

Q&A at #DevSecCon Seattle, 2019

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 regressive security 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 aren't necessarily spending their time finding every issue for you to fix; they are prioritizing exploiting your systems. If you want to shock management and get some buy-in, a PenTest is the way to go. But if you want to find all of the things wrong with your app, I recommend a security/vulnerability assessment instead.

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.

Discussion

pic
Editor guide