The term "shift left" has captivated the application security industry. From CISOs and developers to industry strategists and analysts, the powerful concept has gained traction for its ability to help migrate modern software security despair. Thus, it's no surprise that a recent report revealed that 80% of organizations are "doing shift left.” However, 60% of these companies say that the practice has become a burden on development teams.
Therein lies the key problem. While there is no storage of details surrounding the 'why' for shift left, there's little explanation of the 'how.'
We sat down with Scott Gerlach, CSO and co-founder at StackHawk, to talk about how organizations can successfully implement a shit-left security strategy. What is the number one mistake organizations make when trying to implement a shift left security practice?
One of the main mistakes organizations can make is overlooking the ‘people’ aspect of implementing a shift left security practice. We see a lot of organizations that don’t take the time to engage the development organization in the decision-making aspect of the shift left process; skipping this step makes the shift left strategy and implementation ineffective. As with any organizational change, it’s important to ensure the people, process, and technology involved are all on the same page and working together simultaneously. When organizations and security teams don’t engage developers in the shift left process, they disregard the opinions of the people who are responsible for implementing and using the technology on a day-to-day basis, making collaboration and success nearly impossible to achieve.
Considering shift-left requires significant cultural changes, how have you seen this successfully carried out across organizations?
Organizations that see success with shift left understand the importance of recruiting multiple stakeholders to engage in the process and adopt new technology best practices. It's no different than the adoption of DevOps and how champions of working together became the catalysts for improved strategies. While process and technology drive change, it's much easier to see success with a fundamental market shift when you have people that equally understand the importance and will advocate on behalf of the business to drive that change.
As an example, it's better to get buy-in from the teams and people that will actually be responsible for implementing and using the tooling. Oftentimes tooling fits a specific need and we forget the part of actual implementation. Soliciting input and opinions from various stakeholders not only sets up the solution and strategy for success, but builds stronger relationships across the teams that matter most when it comes to implementing a practice like, shift left.
Which processes do organizations need to reconsider or redesign when implementing a shift left practice?
The main goal of shifting left is to provide faster feedback loops to identify and FIX security mistakes as they’re being written and before they are deployed. Organizations seeking to implement a shift-left strategy, however, need to ensure the right people, processes, and technologies are in place and design their approach accordingly. This is often referred to as the three-legged stool of organizational change and, in this case, shift-left is the process. For the adoption of new processes, like shift left, to be successful, organizations should determine an internal champion on the development team that will equally carry as much responsibility for the shift left process and implementation that the security team does.
It’s also important to identify the core team of individuals who will be responsible for automation, engineering and security processes and define clear roles and responsibilities early on. Working agreements should be defined and documented to highlight key orders of business including when to test, where to test (local, CI/CD, or pre-production), what to fix and when to fix (SLAs). It’s critical to design your process around normal application behaviors, and not outliers.
What are the table stakes for shift-left tooling?
Though the people and process are key aspects of implementing a shift left strategy, the proper technology is just as important for success. However, not every solution is created equal. First, you need to verify that your chosen technology has capabilities to run automation in CI/CD. Next, you need to check what it tests for, as shift left technology should have coverage for all modern API protocols and automation of common attacks and common vectors. Then, you need to consider the developer experience. Your shift left tools should have the ability to recreate findings and retest locally, correlate SAST & DAST findings to prioritize fixes, describe vulnerability details in language that’s built for the developer to understand, and integrate with the entire development ecosystem. Lastly, shift left technology should enable the security team to do their job with complete trust and verification.
How do you see shift left practices evolving in the next 5 years?
With the adoption of Generative AI tooling and solutions, I expect to see the feedback loop refined even further for efficiency. Generative AI will be able to provide developers with prescriptive feedback on what security issues to fix in terms of the specific language and frameworks they work with. Not to mention potentially contribute to the fixing process itself. This doesn't mean developer jobs will go away. Instead, the people in those roles will spend less time comprehending security issues and figuring out a solution, and more time validating and ensuring that the fix aligns with the business logic and features of the application.
###