DEVOPSdigest

Secure or insecure code starts in development. Poorly written, unmaintained source code is prone to larger security attack vectors. And those vectors can cause breaches that could devastate businesses and imperil their end users. According to recent research from IBM(link is external), data breaches cost an average of $4.35 million globally.

Today, many organizations secure their code after it's been written, with a lengthy cycle of auditors scanning large codebases and reporting any issues back to the development teams. Although some elements of security come in after-the-fact, the issues that are deeply rooted in code are best addressed at the source.

Addressing issues in code later is a highly inefficient process for two main reasons. First, it creates a feedback loop with the development team that is lengthy and iterative. And second, asking developers to context switch and spend cycles to debug and fix issues in the code they wrote weeks or months ago tends to be very disruptive (and many times, a frustration) to their ongoing projects.

Security issues are best addressed when the code is being developed. Many companies over the past few years have hopped on the "Shift Left" bandwagon, proclaiming they do all the testing and quality assurance early in the cycle and are thus able to detect issues sooner. However, very few solutions in this space actually shift all the way left — that is, when the code is being written. This is unsurprising since these technologies are not truly created with the developer in mind. As a result, very few are tightly integrated into the developer's everyday workflow.

Truly Shifting Left means embracing a clean-as-you-go approach to software development. It means exactly what you'd think — it enables developers to identify and fix errors in real-time as they create code. When developers are able to clean-as-they-code, they move the security process as early into the software development life cycle (SDLC) as possible — when the code is first being written. You can't shift further left than that.

Ultimately, this approach allows developers to prioritize the most critical potential code security issues, quickly address those issues, and then move on. By avoiding all the disruptions from the typical auditor-driven security method, developers can spend a lot more time focusing on their current code. Security teams, on the other hand, have more time to focus on checks that are best performed after-the-fact. Their bandwidth is freed to provide inputs on expert subjects such as authentication, privileges, cryptography, business logic, and so on.

True Shift Left: A Checklist

This true Shift Left approach — based in Clean Code — embeds security as an integral part of the development process. In practice, this should mean several important things:

■ Insights are provided instantly as code is being developed in the IDE and during the build and commit phases when the developer is reviewing Pull Requests. This allows issues to be addressed immediately before the code is merged.

■ Issues raised are clearly explained in the context of the code being developed. This means the developer gets a clear understanding and guidance on why an issue was raised, why it is harmful, and how they can fix it. All this is adapted to the current code being analyzed.

■ Issues being addressed upfront eliminates the need for any elaborate or extra triaging from the security team. The clean-as-you-code approach intrinsically handles this.

■ The analysis is fast and accurate with fewer false positives. Instead of raising a large number of issues like many tools do, only issues that require immediate remediation are raised and characterized as critical or high. Other potential security issues will be raised, but are categorized as less urgent. The primary should be the current code (new or added) that is being developed.

A Boon for Both Development and Security Teams

A true Shift Left approach has benefits for developers and security personnel alike. For development teams, fixing security issues as they appear in code is extremely practical and efficient. Not only does it remove long feedback cycles and context-switching, but it also provides a sense of code ownership as developers are now also in control of the security of the code they develop.

Those efficiencies also extend to security teams. When development teams are fixing issues as part of their workflow, fewer issues reach audit. This allows security experts to focus on other elements of security that SAST cannot detect (e.g., business logic errors leading to privilege escalations). This brings maximum efficiency to security audits.

An analysis of over 500 Github security advisories found that 83% of advisories were caused by coding errors. Coding mistakes are the primary cause of security vulnerabilities, so correcting them quickly and reliably is fundamental to ensuring good code security. Shifting Left is the most effective way to identify and fix those errors. But to truly Shift Left, developers must be able to clean-as-they-code.