DevSecOps is Not a Security Panacea – InApps 2022

Many development teams view security as an impediment to agility and innovation, but efforts over the past few years have tried to integrate security controls and testing directly into DevOps workflows without sacrificing development speed and deployment flexibility.

Known as DevSecOps, this marriage between security and agile development aims to implement core security tasks like event monitoring, patch management, privilege control and vulnerability assessment directly into DevOps processes. This includes dynamic and static vulnerability testing at all levels of the development cycle, so that major flaws can be discovered early on, before the code makes it into production.

According to the results of a March DevSecOps community survey by Sonatype, a software supply chain automation company, almost 60 percent of organizations that have mature DevOps practices have integrated automated security testing.

But while DevSecOps looks great on paper, its benefits don’t always translate into practice, due to human negligence or complex business reasons.

High-Tech Bridge, a Geneva-based web security company, found that two-thirds of companies that have embraced the DevSecOps approach still have at least one critical or high-risk vulnerability in their external web applications. This is based on results from the company’s vulnerability testing platform that combines automated vulnerability scanning powered by machine learning with manual testing.

Even when DevSecOps security requirements and policies are well integrated, business reasons like the pressure to get a product out before a competitor can cause employees to either skip or superficially pass through testing or validation procedures, High-Tech Bridge CEO Ilia Kolochenko said. Another problem is that in very large organizations, certain development tasks are performed by small teams working remotely from different regions of the world. This makes it very hard to coordinate and enforce DevSecOps policies, especially with new people joining projects all the time and different countries having different holidays and other cultural differences, he said.

As the code matures and the flaws become harder to find, bug hunters will move on to newer applications where finding flaws, and therefore earning money, is easier and takes less time.

So, while DevSecOps is certainly useful and can reduce the number of security issues an application might end up with, it’s not a silver bullet and should be complemented with web application firewalls (WAFs), server hardening technologies that can mitigate whole classes of flaws and third-party security audits, especially manual penetration tests.

The Big Picture

It all comes down to a having a holistic approach to security, because no single solution is perfect.

Unfortunately, very few companies do that. Data from High-Tech Bridge’s free web server security test tool, shows that only 2.5 percent of web servers makes use of all available security-hardening technologies. This includes HTTP response headers like X-Frame-Options, which protects against clickjacking attacks; X-XSS-Protection, which blocks reflected cross-site scripting (XSS) exploits or the Content Security Policy (CSP) header, which protects against a variety of code injection attacks.

Web application firewalls can detect and block SQL injection, XSS and other common types of web application attacks, but hackers often find ways to bypass such firewalls and get to the underlying flaws.

Some critical vulnerabilities are often the result of flawed application business logic, improper access controls or misconfigurations that WAFs do not protect against. In fact, according to High-Tech Bridge, WAFs do not block the exploitation of such flaws in almost 90 percent of cases.

According to Kolochenko, manual security testing by a qualified person is very important, because automated vulnerability scanners can miss up to 50 percent of flaws, even the most widely known ones from the Top 10 list maintained by the Open Web Application Security Project (OWASP). This can happen because many vulnerabilities might require exploitation chains that involve providing a valid client ID, being authenticated or solving a CAPTCHA challenge, which automated vulnerability scanners won’t do on their own.

Running a public bug bounty program can be a solution and it’s a good way of keeping an open communication channel with independent security researchers, but more often than not, the quality and number of reports received through such a program will decline over time. That’s because, as the code matures and the flaws become harder to find, bug hunters will move on to newer applications where finding flaws, and therefore earning money, is easier and takes less time.

That’s not to say that bug bounty programs are not valuable, especially if you’re a company that’s constantly releasing new products or is putting up new web services for client-based applications.

For example, High-Tech Bridge found that companies tend to pay less attention to the security of their backend services for mobile applications, which are accessible through web-based APIs, than they do to the security of web services that users directly interact with.

The company found that over 80 percent of mobile app backend services from the banking, financial and retail sectors are vulnerable to at least one high-risk vulnerability. This includes serious misconfigurations that can lead to authentication bypasses, insufficient authorization requirements for accessing sensitive data, lack of brute-force protection, as well as flaws like SQL and XML injections that can lead to data theft or remote code execution on servers.

Quite often mobile backend services are not protected by web application firewalls, Kolochenko said. “I don’t know why, but some people probably think: ‘Nobody will try to hack this’ or ‘WAFs are for websites and not for APIs’.”

Another problem is that many applications inherit vulnerabilities from third-party components, but according to the Sonatype survey, only a third of organizations maintain control over what components are used in development. That’s concerning, because around 80 percent of a typical application is now made up of open source development frameworks and components.

Maintaining a software bill of materials and having policies in place to prevent the use of known vulnerable component versions should be part of any organization’s DevSecOps approach, because, according to Sonatype, the number of security breaches related to vulnerable open source components has doubled between 2014 and 2017.

Feature image: “Cover for ‘Oraculo Mignon,’ a Witch Brewing a Potion in a Cauldron,” Metropolitan Museum of Art, public domain.