People, process, technology: How to shift security testing left successfully
The benefits of shift-left security are clear. It puts security testing in the hands of the engineers who write the code, enabling vulnerability fixes to occur before software hit production. This provides fixers with faster feedback loops on vulnerabilities found, as well as ensuring more efficient time to feature delivery and cohesive teamwork between security and development teams. With all the benefits that come with shifting API and web application security left, it’s no wonder that 57 percent of security team members have either already shifted their security strategy left or are planning to do so this year, according to a GitLab survey.
So, how do organizations implement a shift-left security strategy successfully? The answer lies in the popular three-legged stool analogy: assessing the process, people, and technology behind this major organizational change, and how they all can work together interdependently.
In this case, shifting security testing left is the process. When thinking about how to start, it’s important to identify how shifting left will impact your organization. In order to initiate this transition, leaders need to think critically about which teams are responsible for each part of the shift left process and communicate those roles to DevOps, engineering, product, and security teams accordingly. Next, organizations need to decide when testing will occur and at what frequency, how teams will prioritize fixes, and the appropriate timeframe for remediation. The goal here is to empower engineers to not only discover vulnerabilities during the pre-production process, but also fix them in real time. This is why it's essential to design your shift left strategy within existing developer behavior, so your process is designed to work with the way your developers are most familiar.
As with any major organizational change, it’s crucial to think about the people that will not only be implementing the change, but also integrating the effects of the change into their day-to-day workflows. When shifting security left, it’s important to gather and consider feedback from all key stakeholders involved in automation, product, engineering and security. By taking a more interdependent approach and not keeping security strategy siloed to the security team alone, organizations can achieve more cohesive cross-discipline communication for optimal efficiency, coordination, and ultimately, implementation of their shift-left practices.
With this interdependent relationship between all departments, it is critical to establish and communicate clear role definitions for each team involved. For example, many organizations that have successfully shifted left allow their security teams to focus on strategic high-level recommendations while developers own the initial triage and remediation of common vulnerabilities. We often see a higher success rate of shit-left efforts when there is a Development Leadership Champion: someone responsible for executing and maintaining your shift-left strategy across the development team.
Not all API and web application security testing tools are created equally, and because automation, security and development teams will all be impacted by the capabilities of the technology you choose, it’s important to weigh the table stakes of your decision carefully. First look at how the technology runs, meaning assessing its ability to truly authenticate and run in CI/CD. Next, consider its testing capabilities. Does the platform offer coverage for all modern API protocols? Does it offer automation of common attacks and attack vectors? Lastly, one of the most important aspects of shift-left technology to consider is the developer experience. Proper shift left platforms should have the ability to recreate findings and retest locally, correlate SAST & DAST findings to prioritize fixes, offer vulnerability details and descriptions tailored to speak to the developer, and seamlessly integrate with the entire developer ecosystem so as not to disrupt their processes.
Putting it All Together
Shift left is not a turnkey solution but a process that requires collaboration between development, security, and operations teams. A cohesive relationship between all key stakeholders that is fostered through clear communication and shared objectives allows for security and development goals to align. The three-legged stool approach encompasses all aspects of the shift-left journey: people, process, and technology, providing organizations with a robust strategy to shift security left successfully.
Scott Gerlach is CSO of StackHawk.