Avoiding Common Pitfalls
Whether because of a failure to understand the nature or purpose of shifting security left or because of poor execution in doing so, it is important to recognize where efforts to shift left can go wrong—and, by extension, be proactive in addressing these areas to ensure that they go right. Drastic cultural changes in how security is introduced into the development process, for example, can push the limits of what developers can internalize. They may need external help to be comprehensive in their security testing. Introducing a “security champion”—a liaison with access to security subject matter experts (SMEs)—into scrum teams can go a long way toward easing the cultural transition. Likewise, taking small, actionable steps allows for easier adaptation of security into the DevOps process, with concrete actions that developers and engineers can take right away. Any incorporated technology should be in support of the development team; tools alone cannot implement a shift left in security, and if developers and testers do not use purchased tools, both employee time and organization funds are wasted. Tools should align to processes—not the other way around.
Ultimately, for security to be effective, it must be accommodating. If security measures make it difficult to carry out a task, or if they are too difficult to implement in the first place, they will go unused, and the net effect will be akin to producing an unsecured product.