5 practical ways your organization can benefit from DevSecOps

It’s right there in the moniker: DevSecOps , a portmanteau of Development, Security and Operations,  implies introducing security early on – as a part of a comprehensive, agile Software Development Life Cycle (SDLC) used by your organization, rather than doing so iteratively or waiting until after a release.

Given how security breaches and vulnerabilities have become everyday news, it makes little sense for developers to ignore the seriousness of secure coding anymore. Here’s a little secret though: developers are often not the most security-oriented folks for obvious reasons. It is not their primary duty. The priority for a software developer is to build an app, have it carry-out the intended tasks nicely and perhaps account for the overall user experience (UX) and satisfaction. If they are being diligent, they may incorporate basic ‘security checks’ as a part of their coding processes – such as not blindly trusting user input and sanitizing it, but beyond that, a developer may not alone have adequate bandwidth or expertise to incorporate the most superior security checks in an app.

A moment of honesty: despite working in DevSecOps for Sonatype I did not understand upfront what the buzzword meant for quite some time. I often questioned myself, “where does the benefit lie for organizations in this? Is this all a marketing fad?”

Over time, I have observed a trend and upward push in the industry to implement some sort of inherent ‘security’ as a part of their development workflow and here are the 5 benefits that immediately come to mind.

1. Spot vulnerabilities and bugs early on

While a developer may do their due diligence with regards to implementing basic-level security checks, nobody can know in this vast open-source ecosystem with millions of repositories, as stated by GitHub, how many software packages contain a security vulnerability and in which of its versions. Provided the huge volume, it is just impossible to be aware of it without having some sort of security automation in place.

The National Vulnerability Database (NVD), a U.S. NIST initiative, which by no means is a comprehensive or accurate list, just crossed their 100,000^th vulnerability in 2018, with more vulnerabilities being added every day. This does not always include the “security exploits” and issues being posted on GitHub or ExploitDB.

An integrated DevSecOps solution or workflow which supports some automation can help developers spot if they are unintentionally using any open-source libraries with known vulnerabilities, before they even begin coding the rest of the modules of a software project, only to realize they need to start over.

2. Leverage open source with increased confidence

Since the open-source community traditionally has welcomed contributions from ‘anyone’, this also opens a door for abuse by malicious actors. In 2019, multiple reports of malware having been disguised as legitimate open-source packages came to light. While npm’s representatives were able to spot and “remove” these components from their servers, the process has not always been a quick one. An unsuspecting developer already using one of the compromised components would have no means of knowing this, unless an automated tool was in place to be able to constantly scan their project and point out any malicious open-source components. This is where IDE-integrated solutions can save the developers and an entire organization from blunder and embarrassment that may follow after making a release.

3. Save costs on resource management

As a former software developer, I can authoritatively reflect on how “dependencies” pose a problem during software development and critically shape the rest of the workflow. In layman’s terms, if your application requires a certain library A which depends on yet another library B, which further depends on yet another library C, version 2 – which is vulnerable – it would naturally mean you can’t use any of those three libraries unless library A and B supported a non-vulnerable version 3 of library C…provided such a version even existed.

You can see how this can get tedious. Imagine having to make this decision of accepting potential security risk for 20 or more components for a mid-to-large scale software project or exploring alternative open-source libraries.

For project managers and devs, having this knowledge upfront and being able to assess the risk early on can mean being able to search for better alternatives and design secure software from the start, rather than waiting until after a release, when a vulnerability assessment may in future, reveal a critical vulnerability. In practice, this means saving tremendously on manhours and resource management costs.

4. Make developers security-aware

Your developers are busy and tasked with implementing a certain functionality out of code for your users. Security may not always be their number one priority due to limitations imposed by meeting deadlines and even developer’s own lack of security expertise. However, with DevSecOps software solutions, the constant ‘reminders’ about excluding certain components from software builds, along with credible reasoning which warrants so, makes your developers a little more interested in and aware of security every time they see such an alert, for example.

In the long run, this may habitually reinforce in the developer’s mindset of avoiding altogether an open-source component which has a reputation of containing security flaws in multiple versions.

5. Reduce risk and legal liability

Organizations often state, “we take your security and privacy seriously,” but not many live by it. Had they did, the current climate of frequent cybersecurity breaches would be non-existent. Either way, any such damaging news severely impacts an organization’s brand reputation negatively and may lead to potential lawsuits and fines. Following security practices at every aspect of your software project – even when a simple website, is more likely to reduce such a risk and impact that may arise from having an otherwise complacent attitude towards security.

In conclusion, there is never a way of knowing whether your application or project is totally secure from all directions: after all, we can’t claim to predict or rule out the unknown risks. But following best practices and automation as outlined by the fancy term DevSecOps can tremendously reduce your risk arising from using software components with known vulnerabilities, right from the beginning.