Today, software is being developed at a breakneck speed. Agile development and the aggressive adoption of DevOps is leading to an abundance of functionality and feature sets, or pieces of code pushed out to consumers at a record pace. These one-click opportunities may indeed get us what we want, however, the game remains the same. The Achilles Heel is security vulnerabilities, regardless of technology maturity or speed of release. Vulnerabilities pound organizations at a pace matched only by a John Bonham, Moby Dick drum solo. Regardless of complexity, budget, or organizational size, software continues to be released with too many vulnerabilities. How do security practitioners help fight the good fight and aid in the reduction of vulnerabilities introduced into production software? Simple. Push left!
What is pushing left?
Pushing left is moving the introduction of security activities from the end of project phases (verify, release, etc.) to the beginning phases (plan, design, etc.) ensuring that each phase has a list of security activities embedded within, promoting the likelihood of a secure software release. This concept of pushing left locks security into its much deserved and underappreciated position of shot-gun, increasing process maturity and ultimately moving towards a Secure Software Development Life Cycle (S-SDLC).
For a quick review, the Software Development Life Cycle (SDLC) is a framework that uses well-defined steps for building and deploying software. The SDLC is primarily centered around three implementation approaches: Waterfall, Agile, and DevOps. The adoption rate and longevity of each approach has been influenced by consumer demand and market competition. The foundation of each approach is comprised of the following phases: Plan, Design, Implement, Verify, Release, and Respond. It’s understandable that organizations might use different terminology and additional steps in their SDLC processes. S-SDLC is fluid and can either be expanded or streamlined even when pushing left.
Why push left? Regardless if its functional or security related, fixing bugs early in the SDLC has proven to be dramatically cheaper than waiting until the verification or release phase. This type of cost savings is known as the S-SDLC Cost-Justification Curve.
Stereotypes don’t help
Even though cost savings may be the most compelling reason to push left, there are other benefits. And yes, releasing more secure software is an obvious one, but there are still others. Relationships between developers and security practitioners have always been strained. Stereotypical idealisms are abundant. Developers tend to be protective of their code (as they should be) and typically don’t want non-developers informing them that their code is “broken”. Furthermore, it’s said that security practitioners “don’t understand” software development and should stick to testing. We have all been subject to these stereotypes.
Establishing and fostering a collaborative relationship between developers and security practitioners is a fundamental culture shift that enables success for everyone. When these two integral components of the organization work together it enables progress and attainment of the overall goal. More secure software is released.
Increasing awareness and exposure
An additional benefit of pushing left is increasing security awareness within the workforce. Involving security practitioners earlier in the process increases their exposure. This gives other roles within the organization an opportunity to understand where their decisions impact the overall security of the product.
Education is key
Along with exposure, education is paramount to creating secure software. For maximum success, security training should be provided at minimum annually and optimally twice a year. Anyone that is involved in the S-SDLC should be required to take security training. Training can be tailored to the specific roles in the S-SDLC.
As an example, developers can focus on secure coding best practices. With other roles focusing on security activities like threat modeling, writing security requirements, and incident response plans. It is also important to track your training efforts to measure your investment. Metrics provide key decision makers an insight into the quality of the training program and its effectiveness. Of equal importance is the ability to focus on engaging the intended audience. Training models can be gamified or tailored to specific roles as mentioned above to keep employees engaged.
Key takeaways
Here are some key takeaways when trying to incorporate the push left mentality in S-SDLC:
- Buy in. To succeed in pushing left, it is critical that there is full management buy-in and support from all levels within the organization. Equally important is having buy-in from the development team. Without either of these stakeholders on board, the task of “baking in” security will be a tough sell and will likely fall flat. Pushing left is a culture change and requires early support from both the management and development teams. Buy-in from these two groups is NOT mutually exclusive.
- Identify a security champion. It is important to identify an individual that will champion the process of introducing security activities into the S-SDLC. This person will serve as the S-SDLC owner, working directly with the development and application security teams. As recommended above, the security champion must have support from management and the development team. The development team must feel ownership over secure coding guidelines with the security team supporting, guiding, and approving standards. The security champion is tasked with being the S-SDLC owner and should have strong change management acumen, but by no means is the only person involved with implementing security activities in the S-SDLC.
- Chunk it. As with any major paradigm shift, it is vital to start small and create an environment that will lead to a successful proof of concept. Find a small program or new functionality that needs to be added to an existing program and start there. Assembling a team of innovators and early adopters that are primarily tasked with this proof of concept is key in pushing the organization left. Once a successful proof of concept is delivered, you will see early majority and late majority groups come on board. Always start with small wins when trying to change the culture. There will be doubters that are continually looking for the proof in the pudding.
- There is no security silver bullet. Implementing security activities into the SDLC phases will vary from company to company. Each company will have to determine which activities it deems crucial towards releasing secure software. Most security experts will argue that there are certain security activities that should not be left out of the SDLC. Other activities can be done as an out-of-band activity that happens simultaneously but not directly tied to an iteration, sprint, or release. The challenge from a security standpoint is being able to incorporate security activities into fast-paced release environments like Agile and DevOps without slowing down development and deployment.
