Developers care about the quality and security of their code, and when empowered to help, developers make great security advocates who can help harden your supply chain security while reducing the burden on DevOps and security teams. Introducing security tools that allow developers to own code security within their existing development process can increase early risk identification and simplify the process of mitigating risks, slowing the growth of (or even reducing) vulnerability backlogs.
Developers want to produce secure code
Developers take a lot of pride in the quality of their code, which includes how secure it is. If you wade through the arguments over spaces vs. tabs and which language is the superior one, development forums provide endless examples of discussions around code security and efficiency spanning from how to store passwords to seeking out best practices for secure code.
These examples include knowledge sharing on existing password storage, encryption methods for new passwords, general secure coding practices, and more. The takeaway? Developers consider code security to be a key component of overall code quality, they just want it to be a part of the development process, and not presented as a pass/fail grade after their efforts.
Historically, the developer-security relationship has been defined by the perception that security tooling adds friction and frustration to the developer workflow. Much of this perception can be explained by the timing of the alerts, and “gotcha” feeling of having it presented by a colleague at the end of a development cycle. The reality is that developers are open to security-oriented feedback and even seek it out during development process.
What developers want is a timely and judgment-free process of assessing code security that fits into their existing process and provides helpful context on how to resolve the risk.
Developers are your first line of defense
Security does not start with checks in the build process within your CI/CD pipeline. Long before new code is introduced to the production environment, it goes through local testing on a developer’s machine, and passes through peer reviews when the code is added to pull requests. These represent the first and furthest “left” efforts to identify vulnerabilities as well as the first opportunity for risk mitigation.
Feedback provided at this stage, directly to the developer in real-time, can be acted on quickly and efficiently without requiring the developer to reacclimate themselves with code they wrote weeks ago or any DevOps or security intervention.
Developers have the context to act quickly
Resolving vulnerabilities takes innate knowledge of the existing code as well as the correct way to patch the vulnerability. The longer it takes to identify a code risk, the more complicated the risk is to mitigate. In instances where vulnerabilities are added to a backlog, original developers may have changed projects or left the organization and new features may be dependent on the vulnerable code by the time a fix is prioritized.
In these scenarios, DevOps and security teams are left trying to find one or more new developers to identify and implement the fix, who may have little knowledge of the original code. This process puts strain on each department, slows resolution times, and produces less efficient code fixes – not to mention puts a serious drag on development velocity of new features as the developers are spending cycles reviewing old code instead of writing new code.
Locating vulnerabilities in code as early as possible and empowering the developer to correct those vulnerabilities ensures that the right person is always accountable for mitigating the risk, and that the code is still fresh in the developer’s mind. This means fewer risks are identified in the later stages of the CI/CD pipeline, reducing vulnerability backlogs, and giving precious time back to developers and DevOps and Security teams.
The growing trend of security champions
Organizations are growing wise to the benefits of decentralizing security efforts and incorporating developers in their hardening processes. Some studies have even found evidence that developer-integrated security practices are a sign of maturity seen in successful security organizations. In an annual study, the Building Security in Maturity Model (BSIMM) team found that all 10 of the firms with highest BSIMM scores had implemented satellite teams that augment security efforts, and that these same satellite teams were missing from all 10 of the lowest scoring firms.
A complete approach to supply chain security must include developer security champions. Developers should not only be included in the security process, but they should also be empowered to act on known risks with developer-oriented security tools that work within their existing development process.