DevSecOps Red Flags: Avoid These Implementation Mistakes

Posted April 16, 2020 in Business Agility & Software Engineering Excellence
DevSecOps Red Flags

Integrating security into the DevOps practice gives you DevSecOps (development, security, and operations). Elite and progressive DevSecOps teams share some very common traits. Unfortunately, DevSecOps teams that underperform on security implementations share some key traits as well.

According to a 2019 study by Sonatype, a San Francisco, California, US-based supply chain automation firm, companies that can deliver on the main goal of automating security early in the software development cycle outperform companies that don’t on multiple benchmarks:

  • On DevOps automation: Elite DevSecOps practices are a whopping 700% “more likely” to have fully integrated and automated security practices across the DevOps pipeline. The same companies “also have increased feedback loops that enable security issues to be identified directly from tools.”

  • On open source controls: 62% of survey respondents with high-profile DevSecOps programs “have an open source governance policy in place where automation improves adherence to it, compared to just 25% of those without DevOps practices.”

  • On container controls: 51% of managers surveyed in companies with elite DevSecOps practices say they “leverage automated security products to identify vulnerabilities in containers, while only 16% of those without said the same thing.”

  • On training: Companies with successful DevSecOps practices are “three times more likely to provide application security training to developers than those organizations without DevOps practices.”

  • On preparedness: 81% of companies with high-end DevSecOps practices “have a cybersecurity response plan in place compared to 62% of those without DevOps practices.”

DevSecOps Team Mistakes Compared to Successful Teams

When it comes to DevSecOps, errors of omission are even larger than errors of commission. What companies fail to do proactively when addressing data security needs is likely to sink DevSecOps efforts and create a greater chance of organizational threats and risks. With this in mind, below are some of the areas where “unforced errors” showcase the most prominent red flags with companies that struggle with DevSecOps implementations:

  • They waited too long to initiate data security implementations. Too many companies procrastinate in rolling out DevSecOps initiatives. According to the Sonatype study, 24% of survey respondents “suspected or verified” a data breach tied to open source components before responding with a company-wide data security campaign of their own.

  • They don’t make data security a priority. Data software developers are generally aware of the need for stronger software security — they just don’t act on that awareness. The survey reports that 48% of companies questioned about data security said they “don’t have time to spend” on DevSecOps campaigns.

  • They farm their data security efforts out. According to the survey, 50% of companies that have cloud infrastructures say they don’t handle their DevSecOps efforts themselves. Instead, they rely on their cloud service provider to handle the task.

  • They don’t do enough on the encryption front. Companies that face an uphill climb on their data security efforts don’t take encryption seriously enough. The Sonatype survey notes that 46% of organizations without a DevOps practices “do not have application level credentials encrypted, while 75% of elite DevSecOps practices do” have those credentials.

Other Key Areas of Concern

The above omissions aren’t the only mistakes companies make that leave their software data open to breaches, theft, and other threats. Some of the other mistakes include:

  • Team implementation failures. The failure to create a single DevSecOps team to address data security efforts is a common issue when data security strategies are found wanting. Without a single team working off the same playbook, company data security campaigns tend to lose focus, which leads to system-wide implementation failures in key areas like automation, quality, and system stability.

  • Speed over safety. Another primary reason why companies struggle with DevSecOps rollouts is they sacrifice safety and quality for speed. Yes, getting products out into the market quickly is a primary foundation for organizational success. Key DevSecOps strategical mistakes like data software testing are kicked to the side, as they tend to slow down product lifecycle times. But if you’re not testing, you don’t know where your vulnerabilities lie — vulnerabilities that will crop up somewhere down the line if left unchecked.

  • Lack of integration. Perhaps the most compelling requirement for a successful DevSecOps strategy — building data security teams that integrate well and are headed by managers with deep familiarity of data security risks and vulnerabilities — often isn’t handled correctly.

Too many companies rely on a solo approach to handle data security management. With one team working on getting data software out as quickly as possible and another team tasked with testing software and probing system vulnerabilities (tasks that require patience and discipline, and that can’t be rushed), too often the result is missed deadlines, missed opportunities, and missed outcomes. 

The fact is, when key stakeholders in the DevSecOps campaign process are spread too thin, it limits their ability to communicate and work together on the same mission, and teamwide unity suffers. This scenario lowers the odds of a successful data software security campaign, increases the chances of mistakes in coding and testing, and places any company’s data software system at considerable risk. And that’s a risk no company should take.

About The Author
Sridhar Jayaraman
Sridhar Jayaraman is a Vice President of Engineering at Qentelli. With experience in delivery, consulting, and solution engineering, he helps potential and existing clients to solve their business problems through an engineering mindset.