DEVOPSdigest

Recent events, including Log4Shell and President Biden's cybersecurity executive order, have placed the software supply chain under scrutiny. Gartner named software supply chain attacks the second biggest threat for 2022 and predicted that 45% of organizations will have experienced one or more software supply chain attacks by 2025. However, in the fight to secure the software supply chain one particular non-malicious risk is often overlooked: the developer.

What Threat Do Developers Pose?

Developers power the software supply chain. They work alongside other professionals in the software development lifecycle (SDLC) to bring new applications, services, and products to market. However, security is often surrendered in the quest for productivity, business growth and innovation, and insecure software can be produced inadvertently.

A recent survey found that software engineers only have about 10 hours of "deep work" time a week due to other responsibilities placed on them. What's more, the industry is currently facing a shortage of talent that places added pressure on existing developers. This lack of time and resources means many do not have the capacity to properly vet the open source software they're using. While the practice of open source is extremely valuable for developers, an average application development project contains nearly 50 vulnerabilities spanning 80 direct dependencies. Being aware of this risk and making the time to review potential security issues is an integral part of creating sophisticated applications and services.

Understandably, developers are struggling to keep up. They also do not often have access to the resources they need to tackle the problem of security. Forrester research revealed that none of the top 50 undergraduate computer science programs in the US require a secure coding or secure application design class. Most professionals therefore enter the industry with little to no training on how to prevent vulnerabilities. Once there, they can encounter a culture that fails to place security-first, with 71% of CISOs claiming stakeholders view security as an impediment to fast development. It is therefore hard to blame developers for neither understanding nor prioritizing security.

As a result, a developer may become a non-malicious insider threat, putting the security of applications at risk and exposing the organization to external threats. This type of insider threat does not commit acts of deliberate sabotage, but they may inadvertently cause security issues every bit as impactful as if they did. When producing code faster than ever before, it is easy for vulnerabilities to be missed or ignored. Many vulnerabilities may go undiscovered for a significant period of time, with some existing in open source code for four years before being detected. By the time a critical flaw is detected, a developer may feel far removed from the code they wrote. When developers can't discover their errors, they also can't learn from them. And the follow-on effect is that insecure code creates costly refactoring for the rest of the development team, delaying the highly coveted speed to market.

What Can Be Done?

It is time that application security is viewed as a people-first problem. Developers have the potential to reduce security hazards and prevent data breaches from occurring through insecure code exploits. They also have the opportunity to embrace security best practice early on in the SDLC to support DevOps with pushing more secure code and delivering a safe product to market, fast. However, they need education to support this. This should:

1. Go beyond ‘check-the-box' awareness exercises

One-off awareness programs are no longer enough; training must be an evolving journey to better understanding and decision-making. It should never be a check-the-box, "one and done" exercise, but instead a programmatic and continuous process. In an era of Zero Day attacks and supply chains that incorporate increasingly complex elements, training must evolve alongside security threats to arm teams with the knowledge they need to become a security resource rather than an uninformed risk.

2. Set measurable goals

To ensure a training program is successful, it is important to gather information that can be used to measure progress. This might be the number of vulnerabilities that appear within a developer's code before and after training, or the number of vulnerabilities they can detect and fix. As developers progress through their training, providing feedback helps to incentivize improvement and ensures employees stay engaged with the program. Providing tangible reports also helps to get buy-in and support from stakeholders. And by sharing proven success, security training doesn't have to be constantly defended to a board of directors.

3. Remain relevant

It is important that training aligns with the day-to-day issues of developers, is delivered in their relevant coding language, and specific to the role they have in the organization. No education will resonate if it's far too advanced, too basic or irrelevant to the language they use each day. What's more, its critical developers are provided with context — not just what the solution is, but why it matters.

4. Incentivize security success

Organizations should be offering incentives and rewards to the people that are consistently applying security best practices in their day-to-day work. These don't have to be monetary, but whatever best suits the culture of a business. The most accomplished developers can be considered Security "champions" who then set an example, engage others and organically improve security culture.

Where Next?

Software developers bear a lot of responsibility within the SDLC. As much as it is important to recognize the potential insider threat they pose to organizations, it's also crucial to realize their value. A developer that is educated in secure coding best practice can be an extremely strong defense against cyberattacks. If they understand the key principles of security — the "big ideas" in secure coding — they will become flexible problem solvers able to apply each of these concepts to novel situations, and therefore they are invaluable assets for the rest of the DevOps team looking to deliver secure software. Yet this can only be achieved through continuous application security education.