Shift Left for DevSecOps Success
Not long ago, developers built applications with little awareness about security and compliance. Checking for vulnerabilities, misconfigurations and policy violations wasn’t their job. After creating a fully-functional application, they’d throw it over the proverbial fence, and a security team would evaluate it at some point – or maybe never.
Those days are gone – due to three main shifts.
First, the pastoral pace of the traditional “waterfall” software development method – linear, monolithic, slow – has been replaced with the urgency of DevOps, in which software is released modularly, continuously, and fast.
Second, all businesses have become software businesses, as organizations’ operations and data get digitized across the board – and consequently become vulnerable to software glitches and cyber attacks.
Finally, brazen and devastating hacks have become increasingly common and sophisticated, prompting CEOs and board directors to declare that cyber security is everybody’s business, and something that can’t be overlooked, as their companies’ integrity and viability are at stake.
As a result, developers can no longer remain blissfully oblivious to the security of the software they build. Enter the concept of “shift left” – the call for security issues to be detected, analyzed and addressed as early as possible in the development process.
In this blog post, we’ll explain why “shift left” has become the cornerstone of secure DevOps – also known as DevSecOps – why you should adopt “shift left” and how you can put it in practice using the JFrog DevOps Platform.
The Price Of Unsafe Software
More than $2 trillion. Yep, that’s “trillion” with a “T.” That was the cost to U.S. companies in 2020 of what the Consortium for Information & Software Quality (CISQ) calls “poor software quality.” Most of the $2.08 trillion cost came from operational software failure, estimated at $1.56 trillion, which is caused primarily by unmitigated flaws, mostly unpatched known vulnerabilities.
Once again: Your software depends – it’s built upon – other people’s software, and if you use faulty and unsafe software components, your software’s quality will suffer – and your business along with it.
In its report, CISQ determined that software problems are a whopping 10 times more expensive to fix after an application has been released, than it is to remediate these issues during development.
The Software Supply Chain Under Attack
Cyber criminals have realized that compromising these software building blocks offers them a stealthy and highly efficient way of distributing their malware via legitimate and trusted channels, so they’re ramping up their efforts to infect components upstream in the supply chain.
That was the tactic used in the devastating SolarWinds hack in December 2020: Hackers injected malware into the software build process of the Orion Platform of SolarWinds, an IT monitoring software vendor.
For months, SolarWinds inadvertently shipped product updates with the vulnerability, designed to let hackers compromise customers’ Orion servers. About 18,000 customers received tainted updates, and dozens got breached, including multinationals and U.S. government agencies.
In fact, supply chain attacks have become such a critical vector for cyber attacks that, at the urging of the White House, the U.S. government has launched formal and comprehensive efforts to secure it.
Meanwhile, the EU Agency for Cybersecurity predicted that software supply chain attacks would quadruple in 2021, after noticing that 66% of cyber attacks reported in 2020 and the first half of 2021 had targeted software supplier code.
“This shows that organizations should focus their efforts on validating third-party code and software before using them to ensure these were not tampered with or manipulated,” the agency recommended in its report “Threat Landscape for Supply Chain Attacks.”
The weak links are evident everywhere, with the most recent example being the Log4Shell zero-day vulnerability discovered in December in the ubiquitous Log4J open source library, an earth-shaking event that sent businesses scrambling globally to find and fix the issue.
Recently, JFrog’s Security Research team has discovered multiple issues affecting the software supply chain, including issues with Apache Cassandra, Node Package Manager (npm) packages, the H2 open-source Java SQL database, and the PyPI open source repository.
In 2020, almost 28% of organizations reported 20 or more supply chain disruptions, according to Forrester Research, which predicts that this year 60% of cyber security incidents will result from issues with third parties.
“With cyberattacks targeting smaller vendors and suppliers, third-party incidents will increase and SolarWinds-style headlines will plague firms that don’t invest in the risk management trifecta: people, process, and technology,” Forrester Research analysts wrote.
How Early Do You “Shift Left?”
Developers are now expected – and, with the right tools, they’re able to – check for security and compliance issues right from their preferred IDE (integrated development environment.) That’s how far “left” in the development process these assessments must – and can – start.
If that seems overkill, think twice. Developers pull most of the software they use from public open source and commercial repositories, blindly trusting that they don’t contain security and compliance issues. Guess what? Most of these third-party components have vulnerabilities and other security problems – and over 30% of them are ranked as High or Critical by the National Vulnerability Database CVSS score.
In other words, security risks begin the moment your developers start downloading libraries from the internet to use them as building blocks in the software they’re creating. It’s the first link in what’s called the software supply chain – and it’s often the weakest.
And the checks must continue throughout your development lifecycle – all the way to software that’s already running, because you must fix vulnerabilities discovered in components deployed in production.
Does Shifting Left Slow Down DevOps?
By integrating and automating security and compliance checks natively into your DevOps processes, you’re able to release software faster and more confidently, because fixing issues is easier and less costly when you catch them earlier.
Security and compliance tests become a bottleneck that slows down DevOps when they’re isolated from the DevOps cycle, and are tacked on at the end, right before software is ready for deployment to production.
When security is treated as an afterthought, it’s often not assessed correctly – if at all. In this scenario, the risk of releasing software that’s tainted with vulnerabilities and policy violations is extremely high, putting your organization and your customers in danger of data breaches, ransomware attacks, IP theft and more.
That’s why “shift left” is such an important concept to grasp and implement into your DevOps strategy.
How JFrog Can Help
The JFrog DevOps Platform streamlines and automates security and compliance checks across the software development lifecycle (SDLC) – from developers’ IDEs all the way to production environments.
With the JFrog platform, and in particular with JFrog Artifactory the binary repository manager and with the JFrog Xray DevSecOps tool, developers can easily shift left and comprehensively scan their software for vulnerabilities and license violations – starting from the moment developers pull third-party components from the internet.
The JFrog platform gives DevOps teams full visibility of all the components that make up their software distribution, and makes it easy for them to “shift left” and remediate issues early and often across their SDLC.
For more details about how you can “shift left” using the JFrog DevOps Platform, watch our webinar “Shifting Left for DevSecOps Success.”