In software security, the idea of Shift Left is the idea of moving security forward in your software development lifecycle (SDLC) into earlier stages of the process to plan security-in before developing the software. It is the software engineering equivalent of ‘measure twice, cut once.’ Depending on where you already are in your software security processes, this could mean different things for each organization.
Shift Left: Application security responsibility and processes can be implemented earlier in the development lifecycle.
Referring to a typical software development lifecycle, as pictured above, shifting left means moving to the left in the diagram and adding more security considerations to earlier parts of the process. For example, many organizations are testing for security vulnerabilities in later stages of the process using scanning tools such as static and dynamic analysis - then penetration testing when running applications are available. The results are then fed back to development to fix problems found, thus creating rework on existing code and taking time away from development. In this simple case, shifting left would involve either scanning during the development phase as code is written or, even better, training developers on security, so the code is more secure in the first place and scans result in fewer findings and less rework. This is a classic first step in shifting left, but far from what is genuinely needed to increase efficiency while also increasing security.
The example above still sees software security as largely a coding and code-testing problem, but truly shifting left involves going all the way left to the beginning of the process. In the earliest phases, where requirements are written, technology is selected, and software is architected, security should play a role even at this stage. Knowledge and skills are required to build-in security from the beginning, such as creating a threat model to understand how you approach risk in the project and which risks are important. This alone can inform the entire project and allow all participants to focus on the critical threats while not wasting time on unimportant threats - making you more secure and efficient at the same time.
The same is true of architecture. Considering security in your architecture while determining details, including how communications will work among components, how data will be stored and managed, how processes will be divided, and the platform technology will significantly reduce risk and security findings that require rework in later stages. When moving onto the design stage, the security considerations given to requirements and architecture, as well as the threat model, will bear fruit in helping ensure the specific designs consider security. Of course, techniques and skills should also be brought to bear on the design. For example, if data security includes encryption, what algorithms will be used, and how will they be implemented?
As you can see, in each stage of the process security can be considered, and the earlier it is, the better off you will be. Of course, if you have been thinking about shifting left for security, you need to train your software teams on what that means and how to do it. This first step is planning what shift left processes you will be doing. You will likely have to take a piece-by-piece approach instead of massively reworking what you are doing in one big push. Changing your processes is a process in itself and will happen over time as you integrate each new concept and review the results obtained.
Start by picking one or two areas to focus on, train the appropriate teams involved in those areas and then implement the plan. For example, if you are already scanning, focus next on training coders on secure coding techniques to prevent rework after scanning. If you have moved down that path and are already training coders, move on to training the team on something that can make the next most significant difference, such as threat modeling. The whole team should get some training here. The senior architects producing the threat model will need the most in-depth training, but others across the cycle will need the training to understand and know how to consume it for their area. Incremental change with training for that change before each step will help build good habits into the process and ensure that you are actually using the training you deploy. Training everyone, everywhere, on everything all at once will likely result in teams being overwhelmed and putting it aside so they can get the software they committed released.
Finally, after all that shift left talk, we also must talk about shifting right. Software security has traditionally been in the middle of the process with coding and testing. As we have moved into a DevOps model, where the software team is responsible for deployment and monitoring, security must also be a consideration at the tail of the process. While IT teams learned about infrastructure security long ago (hopefully), DevOps teams may be coming to the infrastructure they are responsible for without this knowledge. Here too, the approach needs to consider security from the left part of this right side of the process. The DevOps team needs to design secure deployment processes, create secure infrastructure configurations, and plan for monitoring security issues, among other things. Then those plans must be executed. Gaining the knowledge and skills to do this means training on security specific to these roles and risks – and specific to the technology platform being used.
As you can see, shifting left for software security involves a great deal of training outside of just the development role and secure coding. If you are going to shift left, you need to partner with a provider with that content and capability. At Security Innovation, we have been training developers on software security for over a decade and going beyond the code to train everyone involved in the SDLC from the beginning. Shift left isn’t new to us, and our training, labs, and cyber ranges reflect that capability and philosophy. So, if you are considering reducing your risk and increasing your efficiency by shifting left for software security and know you need the training to do it, check us out!
About Fred Pinkett, Senior Director Product Management
Fred Pinkett is the Senior Director of Product Management for Security Innovation. Prior to this role, he was at Absorb, Security Innovation's learning management system partner. In his second stint with the company, he is the first product manager for Security Innovation's computer-based training. Fred has deep experience in security and cloud storage, including time at RSA, Nasuni, Core Security, and several other startups. He holds an MBA from Boston College and a BS in Computer Science from MIT. Working at both Security Innovation and Absorb, Fred clearly can't stay away from the intersection between application security and learning. Connect with him on LinkedIn.
