It would be unfathomable to discuss the direct impact of code quality, bugs and UX issues on the company turnover and reputation without engaging in code security. With the acceleration of digitalisation across all industries, we have discovered how vulnerable our companies are to cyber attacks and data leaks. Yet, a survey administered on developers, application security experts and devops in the corporate environment uncovered that a staggering 89%* of them find that a strong disconnection between developers and cybersecurity teams is at the source of significant decreases in productivity. In the past few years, in the wake of the development of the shift left approach, code security experts started to assess how early code security vulnerabilities detection could help better control a company's risk and cost management.
As early as 2010, IBM’s System Science Institute shared figures that were already underlining the parallel between code security and shifting left: “the security defects identified in the testing phase are 15 times more expensive than the design phase”**. The industry is now becoming more at ease with the term shift left security and the idea that moving security control to the earliest possible phase of the development life cycle has become the new best practice to follow.
Shift left security is an approach to the software development lifecycle aiming to increase the security of a software while decreasing the time spent by the organisation on securing software, this is made possible by catching security flaws as early as possible in the development process.
Shift left security is a concept born in the wake of the rise of shift left testing and the growth of the devsecops mindset. DevSecOps aims to unify development, operation and security as a unique process in the Software Development Lifecycle. It puts back in the hand of developers more security related tasks.
Shift left security moves the security control which was initially handled by security teams past the deployment (on the right if we visualize the lifecycle as a linear timeline) to the developers hands much earlier in the life cycle (you guessed right: to the left of this timeline). This allows security to get embedded in the software development rather than at the end of it and be part of conception, design, develop, build, and test. It enables engineers to spot and resolve vulnerabilities faster and more efficiently and relieve some of the weight of late flaw discovery off of the security team's shoulders. Through shift left security and the set of security checks automation that goes along with it, developers can detect security threats early and consequently protect the user experience and the business profitability.
Even security teams are still key to successful software manufacturing (more about that down the line) they were creating a bottleneck for increasingly agile teams. The new risks introduced by cloud technologies coupled with the new empowerment of software developers thanks to devops practices created a new paradigm where security teams were no longer efficient in their traditional working methodology.
At an organisation we already mentioned a few benefits such as: faster delivery, improved security, reduced costs, greater business success. But let’s take a minute to explore the benefits of shift left security for your team specifically:
Better velocity thanks to automation. Automatic scanning of the code source to find vulnerabilities (such as SAST or DAST defined further down this post) is a very efficient way to increase code security at scale.
Faster deployment of flawless code. By detecting security flaws early on you reduce the feedback loop for the engineer. When flaws are spotted in production it forces heavy and stress-inducing task-shifting for software engineers in charge of fixing them which damages the efficiency of the software development lifecycle.
Refocused security teams. Shift left security does not sign the end of your security, far from it, it enables them to refocus on high level tasks. While the back and forth between engineers and security team regarding small security patches decreases the time and attention engaged in penetration tests, Role based access control can increase. The security team can also invest more into building guidelines and leading the shift left security changes amongst the engineering teams.
Shared accountability. By putting some accountability regarding code security back into the hands of developers you can nurture the sense of shared responsibility regarding code quality and code security across the organisation which ultimately impacts your product, your company culture and your reputation.
The three key topics around shifting left your security are the follow
The set of practices and tools to shift left is ever evolving but a few easy questions to get the first actions towards it should be:
Finding vulnerabilities, classifying them, identify trends and patterns in your code and strengthen your application layer security: there is so much that shift left security tools can help you with. We have gathered a non-exhaustive list of the type of tools that you can use on your shift left security journey. Get accustomed to your new lexicon. 😃
• Static Application Security Testing (SAST) - automatically scan your codebase to detect known vulnerabilities. This test does not require code to be compiled and it can be applied to code as it is being written
• Dynamic Application Security Testing (DAST) - detects vulnerabilities in running applications. It can help you find common security issues such as SQL injections or runtime errors.
• Interactive Application Security Testing (IAST) — a mix of DAST and SAST. It deploys in the runtime environment, observes attacks and identifies vulnerabilities.
• Runtime Application Self Protection (RASP)—It scans when the application starts running and tries to protect against malicious actors by analyzing the behavior of the application.
• Software Composition Analysis (SCA) — Or origin analysis. It analyzes all the libraries and sourced software components in order to find the latest updates and patches available for known security flaws.
• Static scanning based tools
• Container scans
• Compliance scans
• Secret detection
• Dependency scans
According to a survey from Gitlab, 70% of programmers are expected to write secure code, but only 25% think their organisation’s security practices are “good.”*
Ok enough said! Let’s share a final few pieces of advice as you are evolving through your shift left security project.
⭕️ Identify your company software development lifecycle — Each company has their own specificities, make sure you and all stakeholders of software development at your company have a clear and common vision of this lifecycle. Knowing where you come from will make it easier to know where you are going.
⭕️ Define a shift-left strategy — Build a master document with the key elements of your strategy. One reference to define the why, what, who, how, when and where of your shift left (& shift left security) approach. This will make it easier to refocus in times of doubt and to onboard new stakeholders to your project.
⭕️ Automate where you can — Agile pipelines and continuous development can only be supported by an increasing support through automation as well as code quality & code security focused tools. Getting help with these tasks will free up developer time and enable them to refocus on high value steps and incremental innovation.
⭕️ Create systematic checkpoints to find code defects — Checkpoints at all stages to find defects and vulnerabilities is a key element to shifting left. Many tools out there can support your effort to do so. The famous saying “test early and test often” should be your software bumper sticker. The goal is to build processes supported by automation where developers can check code security and quality as they code, get feedback as fast as possible and have tools to remediate vulnerable code efficiently. This will lower the productivity-killer context switching implied by developing new features and fixing bugs and vulnerabilities in code and in production at the same time.
⭕️ Shifting left is a matter of company culture — Your DevOps team can be the ambassador of security and quality awareness for your developers. Cooperation should be the source of a smooth transition from your existing lifecycle to the new shift left approach.
⭕️ Work with your team to invest in proper tooling — While the software engineering team can feel reluctant to change and uncomfortable getting outside of their comfort zone, they still can still be great advisors when picking the right tools. Your priority should be to enable your developers to create secure quality code without using more time or resources. Shifting left without overbearing your developers is important to create new habits and maintain the new code quality and code security standards brought to them by the shift left approach.
⭕️ Empower software engineers with access to knowledge — Shifting left is an ever evolving process, while new tools and new processes are created every day, it is critical to provide your team with continuous training in high quality and secure coding methods.
⭕️ Beware of Alert Fatigue! With the increasing amount of bug detection applications and code quality tools out there you are at risk of an overbearing amount of notifications and alerts. This could kill the software engineering team's productivity and result in missing out on the truly important alerts.
As we now know code security is a never ending challenge that the biggest Silicon Valley players and the smallest startups are constantly challenged with. We never seize to discover more about the source of flaws in our code. Lately the sheer number of libraries, open source dependencies, Infrastructure as code and technologies that software engineers use in their process has opened a new door to vulnerabilities at a scale we have never experienced before. That’s why the deep impact of shift left security over your company culture, your staff awareness for code security and the overall relationship of all team members regarding preventing security threats is the best weapon you can build towards the safety of your software now and in the future.
Code security is no longer a choice! It’s an obligation we have towards our users, our team members and our business… So? Are you ready to shift left?