Technical

When shifting security left falls off a cliff

Michael Burch
Michael Burch
Linkedin Icon
Application Security Engineer

Developers know that identifying security problems early requires fewer resources and lower costs to remediate. It is often a quick fix to remediate a problem found by a security scanning tool during a code commit. It is not such an easy task to refactor code that is about to be released to production.

When dev teams take a limited view on security testing and wait till late in the development lifecycle, they can become blind to the mounting technical debt and associated costs. Any good application security testing plan involves a training plan, a balanced approach, and security tests throughout the development process. Achieving the correct balance of testing to development means automating everything possible and building a culture that prevents security flaws rather than focusing on finding them after the fact.

<blog-teal-text>Traditional Testing<blog-teal-text>

A traditional Software Development Lifecycle (SDLC) looks something like this:  

  1. Requirements
  1. Planning
  1. Design
  1. Development
  1. Testing
  1. Deployment
  1. Maintenance  
  1. Repeat

There are dozens of different flavors and approaches to the SDLC, depending on who you talk to, but they generally follow this structure. Even in an Agile and DevOps world, this doesn't change much. An Agile methodology usually involves short sprints to ensure continuous delivery, but testing is considered a step you take after you are finished coding, right before release. Often, application security testing ends up being only a tiny fraction of the tests that need to happen. Most of the focus is on functionality, leaving developers hoping that the one security solution the security team added to the CI/CD pipeline catches everything.

<blog-cyan-text>Shifting All Security Left Doesn't Work!<blog-cyan-text>

On the other side of the spectrum are the Shift-All-Security-Left advocates. While it reduces the potential impact and cost to find vulnerabilities early, there is often an increase in development time and security-related costs the more teams shift left. For example, it doesn't make sense to run multiple static and dynamic security tools and conduct a penetration test on your application for every commit. It would take half a week to push code and significantly restrict development teams' ability to deliver value to the customer. Of course, this testing approach is an exaggerated scenario. Still, the point is that teams cannot shift all their security testing to the left without risking falling off the proverbial production cliff and not meeting the business objectives.

<blog-cyan-text>Two-Prong Solution<blog-cyan-text>

The solution is investing in prevention over finding vulnerabilities and having a diverse testing portfolio that is automated and balanced throughout the development lifecycle. Developers often see security teams as an impediment, not an enhancement to completing a project. The culture needs to change so that developers see themselves as a part of the security team, and companies need to invest in their developers to facilitate that culture shift. Development teams can achieve a balanced and automated testing portfolio by implementing a well-thought-out security testing framework that fits their company's needs. Only through the two-prong approach of using education and a security testing framework can we tackle a problem as complex as implementing security testing programs appropriate to modern application threats.

<blog-cyan-text>Education == Prevention<blog-cyan-text>

Investing in training developers on security issues is the single most important thing a company can do to prevent security vulnerabilities as early as possible. It reduces the number of vulnerabilities written from the start of a project and establish developers as a part of the security team. In the same way that the development team and operations team become a cohesive unit in DevOps, developers must adopt security with the same passion. Companies need to invest in their employees ' capabilities through training programs and incentivizing them to embrace a security culture.

<blog-cyan-text>What about the STLC? <blog-cyan-text>

With all the different tools, approaches, and guidelines published about testing, it can be difficult for a development team to find the perfect fit. Many articles are available on how "testing teams" should implement the Software Testing Life Cycle (STLC). However, the STLC separates the development team from the testing process, and it focuses on business objectives and not security. It defines how quality assurance teams should conduct testing, but it doesn't address how application security testing integrates with the SDLC. That's where the Software Security Testing Lifecycle (SWSTL) comes to the rescue.

<blog-cyan-text>Software Security Testing Lifecycle (SWSTL)<blog-cyan-text>

The SWSTL is a framework that incorporates security testing throughout the development lifecycle.  

Using SWSTL, testers can transform into application security testers, stopping the reactive cycle and focusing on incorporating security testing throughout the SDLC. SWSTL views the SDLC and the Secure Development Lifecycle (SDL) through the eyes of an application security tester.

<blog-teal-text>1.<blog-teal-text>Know the security requirements

You cannot test what you do not know. The individual testing the software is not usually the person defining the application security requirements. The SDL handles defining security requirements for the application. It is the tester's responsibility to understand the security requirements so that they can identify what is considered a security vulnerability based on those requirements. This knowledge enables the tester to be a productive participant during threat modeling and a more efficient tester.  

When testers understand the security requirements, they are better informed about the target of their testing.

<blog-teal-text>2.<blog-teal-text>Participate in threat modeling

Testers have a unique perspective on identifying threats; they gain detailed knowledge of why specific threats were identified, which allows ​for more efficient testing. This perspective is invaluable during threat modeling. Also, having the tester participate in threat modeling gives the tester more intimate knowledge of the threats facing the application and security controls chosen to mitigate the threats. The information gathered while threat modeling facilitates the tester in building a focused and comprehensive security testing strategy.

Involving testers in threat modeling will lead to identifying more threats and give the tester intimate knowledge of the application, chosen security controls, and the potential threats to test against.

<blog-teal-text>3.<blog-teal-text>Build a security testing strategy

A security testing strategy is a systematic way to define security tests based on the threats and security controls identified during threat modeling. When building the security testing strategy, the first step is to identify the scope of responsibility to test. Once the scope is defined, the tester reviews the artifacts from threat modeling to determine the threats and security controls to evaluate. The tester then selects the appropriate people, processes, and technology to conduct the different tests. Finally, the security testing strategy must focus on validating the effectiveness of the selected security controls at mitigating the identified threats.  

Using the threat model to build a security testing strategy enables testers to conduct effective and focused testing on the areas that matter for a particular application.

<blog-teal-text>4.<blog-teal-text>Build tests and review

It is common practice to write unit tests during development. However, these tests frequently only test functionality, and the focus is often on code coverage and not on test quality. The solution is to include well-thought-out security unit tests during development. A security unit test takes the smallest piece of testable software in the application and determines if its security control is effective. The security testing strategy identified where developers need to write security unit tests based on the security controls chosen during threat modeling.  

Testers can ensure that security controls are working at the moment of development using effective security unit tests.

Software development teams usually enforce peer reviews on code commits before integration into a production product. Likewise, application security testers should adopt the same practice for their testing strategy. Allowing peers to review a chosen testing strategy and individual security tests catches edge cases and logic flaws that an individual tester might miss. A tester peer review is also an opportune moment for testers to collaborate on new testing strategies and exchange information about the latest threats.  

Security testing peer reviews ensure that the maximum amount of knowledge from the testing team is applied when evaluating the security posture of an application.

<blog-teal-text>5.<blog-teal-text>Automate testing

Automating testing tasks reduces the chance of human error and allows more time for other testing tasks. Test automation includes using dynamic application security testing (DAST) tools, interactive application security testing (IAST) tools, and Fuzzing tools. These tools find vulnerabilities not identified during threat modeling. The results from these tools need to be verified by the tester to eliminate false positives and create a remediation plan.  

Security testers do not have enough time to effectively test everything manually. Test automation ensures testers can focus their attention more where it is most productive.

<blog-teal-text>6.<blog-teal-text>Validate security findings and controls

The final step of SWSTL is verification of the security findings produced by the automated tools and assessment of the security controls that security unit tests or automation tools cannot check. Automation tools can create a lot of noise, and the security alerts need to be verified by the tester before trying to fix the problem. Confirming the security findings reduces wasted effort on false alerts, and it gives the tester a chance to conduct root cause analysis to ensure the selected solution is appropriate.  

Some security controls established during threat modeling are challenging to test using security unit tests or automation tools. Therefore, the security testing strategy should determine what tests require a manual approach. Then, the tester uses the same technique to validate security findings for verification of security controls that other methods miss.  

Testers cannot expect that all automated tools will find all the vulnerabilities in an application. It is essential for security testers to become proficient at validating security findings and controls.

<blog-cyan-text>Not a one size fits all solution!<blog-cyan-text>

SWSTL is flexible and incremental unlike many frameworks that lack flexibility in process implementation. Therefore, when adopting SWSTL, testers should customize it to fit their environment while ensuring integration of security testing throughout the development processes. It is also not required to implement all steps of SWSTL at once. If nothing else, start with the first three steps because you cannot secure what you do not understand.  

Final Thoughts

The concept of shifting security left is a good start if done correctly. Prevention is always better than remediation and requires cultivating developers and testers to be part of the security team. An effective security testing strategy requires integrating security testing into every phase of development. Use the Software Security Testing Lifecycle framework to find vulnerabilities early and reduce remediation costs while developing more secure applications.

Need more information about Security Journey? Get in touch.

Ready to start your journey?

Let's Talk