DevOps Practice

The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 1)

Today’s organizations are increasingly benefiting from the modernization of the software development lifecycle (SDLC), including the adoption of cloud, DevOps, Agile methodologies, containers and more. Thanks to this modernization, organizations are innovating and releasing updates faster than ever before. But these benefits aren’t without challenges.

Application security arguably tops the list of challenges. Security has inherently manual bottlenecks, and is unable to keep up with the pace of automated DevOps pipelines. The result is that security is often left behind, overlooked or simply ignored in the development process. Developers aren’t willing to slow innovation down today for the potential of security breaches tomorrow.

As a result, more and more applications are being shipped into production with vulnerabilities and security flaws. Today, most of the vulnerabilities are found in post-production either via red teams, bug bounty programs or siloed and irregular code analysis scans. At best, these vulnerabilities are fixed in the next version that’s shipped. At worst, your organization is making headlines for millions of personal records being breached.

However, security in the modern SDLC is becoming more symbiotic thanks to two key advancementsspeed and accuracy. Overcoming these two challenges enables security to be inserted into developer workflows earlier than ever before. By automating security with every pull request, development organizations can finally embrace security without slowing down innovation.  

Automation Security at the Speed of DevOps

These days, many vendors claim to insert security into DevOps pipelines, often during the build. While it’s true that security scans may be automatically started, they still finish in siloed processes that don’t keep up with the pace of releases. We call this “automation for automation’s sake.” It does not measurably improve defect density, slow the accrual of technical debt or reduce mean time to repair (MTTR). The only value that automating this way provides is checking a box on a compliance form.  

So, how can organizations more effectively automate security quality decisions? 

First, security tests and scans need to be dramatically faster. Legacy code analysis takes such a long time that many vendors recommend sacrificing comprehensiveness by scanning only differentials. Even then, they still aren’t fast enough to keep up with CI/CD. It goes without saying that organizations cannot meaningfully automate security into processes such as builds or pull requests, that take just a fraction of the time.

Second, the results need to be more reliable. The goal of security automation should be to fail insecure code. However, historically, code analysis tools are plagued by so many false positives that no code would ever pass any test. Only with reliable results can insecure code be confidently failed. 

Third, security scans must be comprehensive as false negatives lead to vulnerabilities going undetected into production. This is, in part, because developers are not asking the right security questions when scanning their code. Traditional code analysis tools leverage pattern matching techniquesthey look for symptoms of a vulnerability that are common across all code bases. For example, lack of input validation from sources is a classic cause of injection vulnerabilities. However, there are many vulnerabilities that are unique to each code base, such as business logic flaws, data leakage, hard-coded literals and insider threats.

For example, all applications are purpose-built to meet specific business needs, meaning vulnerabilities may go beyond coding errors and present themselves as business logic flaws in the design of an application. Take the First American Financial breach. Thanks to an insecure direct object reference (IDOR), an attacker has the potential to manipulate an internal implementation object. In the case of First American Financial, this was a URL or form parameter. Given the asymmetrical advantage that attackers have, defenders must protect from all possible vulnerabilities, but attackers need to only find one vulnerable route. As such, partial security can be as problematic as no security.

Only when security is completely comprehensivereliable enough to fail with confidence and fast enough to keep upcan it be meaningfully automated into developer workflows without slowing them down.

Yet, comprehensive security scanning is only part of the equation. In the second article of this series, I’ll dig into where these security scans should be taking place in the development cycle to make them most effective.

Chetan Conikee

Chetan Conikee

Chetan Conikee is CTO of ShiftLeft. He is a serial entrepreneur with over 20+ years of experience in authoring and architecting mission critical software. His expertise includes building web-scale distributed infrastructure, personalization algorithms, complex event processing, fraud detection and prevention in investment/retail banking domains. He was most recently chief data officer and GM operations at CloudPhysics. Prior to CloudPhysics he was part of early founding teams at CashEdge (acquired FiServ), Business Signatures (acquired Entrust) and EndForce (acquired Sophos). Chetan earned his M.S. in Computer Engineering from Iowa State University and B.S in Computer Science and Engineering from Bangalore University.

Recent Posts

Building an Open Source Observability Platform

By investing in open source frameworks and LGTM tools, SRE teams can effectively monitor their apps and gain insights into…

3 hours ago

To Devin or Not to Devin?

Cognition Labs' Devin is creating a lot of buzz in the industry, but John Willis urges organizations to proceed with…

4 hours ago

Survey Surfaces Substantial Platform Engineering Gains

While most app developers work for organizations that have platform teams, there isn't much consistency regarding where that team reports.

19 hours ago

EP 43: DevOps Building Blocks Part 6 – Day 2 DevOps, Operations and SRE

Day Two DevOps is a phase in the SDLC that focuses on enhancing, optimizing and continuously improving the software development…

21 hours ago

Survey Surfaces Lack of Significant Observability Progress

A global survey of 500 IT professionals suggests organizations are not making a lot of progress in their ability to…

21 hours ago

EP 42: DevOps Building Blocks Part 5: Flow, Bottlenecks and Continuous Improvement

In part five of this series, hosts Alan Shimel and Mitch Ashley are joined by Bryan Cole (Tricentis), Ixchel Ruiz…

21 hours ago