DevSecOps has fundamentally changed the way in which organizations approach security in modern software development. The role of developer security champion was created to meet the need for security to be tightly integrated into DevOps and DevSecOps practices. Read on to learn more about what developer security champions are and how they help promote secure coding best practices as organizations work toward continuous integration and delivery.
Developer security champions are developers who promote security and coach other developers on the adoption of security best practices throughout their development team. They are the go-to person when any security issues arise during the development process, and they act as a liaison between the developer team and the security team.
Developer security champions are responsible for a wide range of security activities. These include helping create security-related policies, building threat models, performing security reviews, defining security best practices, and sharing their knowledge with other developers to promote an organization’s security culture.
So how did the role of developer security champion come to be? The answer is it all began with DevOps.
More than a dozen years ago, the DevOps movement arose as a response to the perceived dysfunctional way software was being developed. The developers who created software and the operations teams who were responsible for deploying that software often had conflicting demands and didn’t communicate with each other. Instead of working together to ship the best product possible, developers and operations managed their own fiefdoms and often found themselves at odds with one another. The results were bungled releases and unhappy customers.
The DevOps movement was born as an effort to break down the development and operations silos to fix this fractured process. DevOps encompases every phase of the software development life cycle (SDLC). It involves the planning, developing, testing, releasing, and feedback of software in all its iterations. DevOps is designed to smooth the process of software development and deployment so that development and operations form one cohesive and streamlined task. Though the promise of DevOps is great, it is not without its challenges.
A couple of years after the adoption of DevOps, security professionals realized that the way application security traditionally had been handled wasn’t working within the new DevOps paradigm. Not wanting to be left out of this process, security professionals raised their hands to ask, “What about us?” With shortened release cycles, it was no longer efficient to scan software after the development process was completed. Security simply couldn’t function at the speed required when it occurred as a discrete function after development was done. It needed to be better integrated into the development process for DevOps to work. This desire to shift left gave rise to the DevSecOps movement.
DevSecOps (sometimes called SecDevOps) is DevOps with security built-in from the start. Under DevSecOps, security is an integral component of the DevOps pipeline, from the design to coding to the deployment stages. Perhaps the most important shift under DevSecOps was the idea that everyone – not just security professionals – is responsible for security. In addition, DevSecOps contended that security detection and remediation must happen at the same scale and speed as development and operations.
The DevSecOps movement faced many challenges. Eventually it became clear that application security testing couldn’t scale to meet these new demands. Security teams weren’t big enough or structured in a way to be everywhere at once. Compounding this issue were major skill gaps – developers didn’t have sufficient experience to handle security themselves. For DevSecOps to be truly successful, a more collaborative approach that brought together the development, security, and operations teams was needed.
The role of developer security champion was created to achieve the goal of increased collaboration. Moving security responsibilities to a developer security champion who was already part of a development team was an effective way to help close the security skill gap. When your security champion is already a developer on the team, your security efforts are more likely to be adopted. Not only do developer security champions already speak the same language, but they have a deep understanding of the current project and can communicate security initiatives in a way that will be readily accepted by their teammates. In addition, empowering an existing team member who is already well known and trusted by their peers to act as a mentor for security best practices proved to be an efficient way to scale security.
Software developers are hired to write code and develop new features. For developers, success in their job is defined by their ability to ship product. Security is seen as yet another distraction from their main job responsibilities. Developer security champions work to change this perception by making sure other developers on their team understand their organization’s policies and how to use security tools that have been deployed, such as SAST, DAST, IAST, or software composition analysis tools, to adopt secure coding best practices.
Developer security champions work hard to increase the adoption and efficacy of security protocols. One of the ways champions accomplished this is by strengthening the relationship between developers and the security team. When this relationship is strong, friction is reduced, walls come tumbling down, and a security-first culture is adopted throughout the organization.
Developer security champions work closely with the security team to ensure that security protocols are being followed. In this model, the security team coaches developer security champions to implement the tools and processes responsible for secure coding. Often, the security team does not directly engage in security vulnerability detection and remediation, but works with the developer security champion to implement vulnerability management policies to reduce security debt.
Implementing a developer security champion program has many benefits. Here are our top five:
Not only are security professionals in short supply, but your organization’s security budget probably isn’t big enough to staff your org the way you’d like. By using your existing security pros as coaches, they can influence more developers, increasing their reach and impact.
More and more developers are responsible for the security of the code they produce, and that’s unlikely to change anytime soon. Empower your people with the knowledge and skills to perform their own security checks. Not only do developer security champions help you close your developers’ skill gap through coaching, but you’re creating a security-first culture throughout your organization.
Security has shifted left. By placing a dedicated security resource in every team, you are further streamlining your security process. The more streamlined your security process is, the more likely you are to get developers on board with it. It’s a self-fulfilling prophecy, but in a good way.
The security process works better when there is communication and collaboration between developer and security teams. Identifying a developer security champion in every team ensures the steady flow of information and reduces friction.
The bottom line is the bottom line. Fixing a security vulnerability in development costs an average of $80. That same vulnerability costs upwards of $7,600 to fix if detected during production. Developer security champions help shift security left, which saves money, time, and resources.
By now, you should be convinced that developer security champions should be part of your security arsenal. Developers have been taking over AppSec for a while, this trend just confirms it.
Security champion programs do require planning and investment, but the long-term benefits are worth it. Not only does this method of delivering security reduce friction between teams, speed production, and save money, but it also benefits developers even more directly. By writing better and more secure code during the development stage, logjams associated with the security review stage are greatly reduced or eliminated. This gives your developers the freedom to spend more time working on high-value activities, which results in happier developers and higher-quality software. It’s a win-win for everyone.