DEVOPSdigest

For the last decade, the concept of shifting security left has surged exponentially among practitioners, as the results of this approach are astounding. The ability to deliver secure code faster, reduce vulnerabilities in production, and drive efficiencies across application security and development teams are a clear win for any organization, right?

A recent report revealed that 80% of organizations are "doing shift left." However, despite this vast uptick in adoption, 60% of these companies say that the practice has become a burden on development teams. Herein lies the problem. While security teams have been inundated with details surrounding the urgency for shift left practices, little guidance and clarification on successful implementation exists. As a result, many security teams are experiencing some heavy roadblocks with their developers and have yet to see any return on investment.

What many fail to understand is that shift left is not a turnkey solution, but rather a process which requires a mindset shift (no pun intended, or was it ...), a clear collaborative approach between development, security, and operations teams. Ensuring that both developer and security teams' productivity remains at the forefront has become a primary barrier to shift left success due to a lack of partnership and cooperation among teams.

Like any other organizational change process, the three-legged stool approach, which encompasses people, process and technology, is a solid foundation that can be used to help design a robust execution strategy for optimal shift left success. Organizations that achieve prime success with shift left understand the importance of recruiting multiple stakeholders to engage in the process.

First and foremost, the development team must be heavily involved in the shift left decision-making and agree to the process. Perhaps the most critical component is that developers need to help with and accept the design of process and selection of tooling, as well as set ground rules for working agreements on how to best partner with security teams.

A common mistake security teams make is not letting developers make decisions about security vulnerabilities regarding prioritization and false positives. This mistake creates another roadblock for developers, reinforces the lack of trust between teams, and hampers the security team's ability to keep up. A better approach is to allow development teams to make and document security decisions, so they can move fast, while security's role is to observe and verify the decisions they make.

When security teams fail to 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 daily basis. People, process and technology are what enable change. We often forget the people part of this formula when it comes to developers and shifting left. The process must be designed to interrupt developers less and help them get software out as quickly as possible.

The next key stepping stone to success involves identifying, defining and establishing clear roles and responsibilities for the shift left process. Organizations must identify the individuals responsible for automation, engineering, and security processes. Security teams must work together with developers and engineering teams to ultimately agree on when to test, whether it be local, in CI/CD, or pre-production. This step is essential for creating cross-team cohesivity.

While people are fundamental to a successful shift left strategy, so is effective technology. Unfortunately, not all solutions are created equal. Technologies chosen to aid shift left processes must have the capabilities to run automation in CI/CD and should provide coverage for all modern API protocols and automation of common attacks and vectors. Organizations should also evaluate how developer-friendly prospective solutions are. Shift left tools should have the ability to recreate findings and retest locally, correlate SAST and DAST findings to prioritize fixes, describe vulnerability details in developer language and integrate with the entire development ecosystem. Chosen technology should also enable security teams to perform their tasks with complete trust and verification.

Overlooking the human aspect of implementing shift left security practices can prove detrimental. Failing to involve the key shift left stakeholder — developers — in the design and initial implementation stages will cause conflict and frustration and limit productivity. Impractical in today's fast paced application development cycles. Thus, taking a developer-first approach to shift left design processes and technology selection can significantly improve its success rates and ROI. Organizations must focus efforts on securing buy-in from these individuals that will be directly responsible for driving shift left implementation daily and utilizing the applicable tooling. Cross collaboration among teams will also ensure that processes are streamlined and avoid productivity loss and fatigue from developers. Soliciting input and opinions from various stakeholders not only sets up a shift left strategy for success, but also helps foster the creation of stronger relationships across the security and development teams.