Pentesting & DevOps: From Gatekeeper to Enabler

Fast and frequent code changes are a reality of today’s business landscape: if you want to remain competitive in the sink-or-swim world economy, agile development is practically a must. Whether to launch new products or add extra features, DevOps sprints are getting shorter, sometimes lasting only 24 hours (or less!). Echoing these trends, our most recent State of Pentesting report showed that more than a third of surveyed security practitioners work at companies which release code weekly or daily.

This is great news for innovation, but as far as security is concerned, many AppSec leaders are faced with a seemingly impossible challenge: keeping up with the pace. Practitioners are left struggling to adapt to the ‘new normal’ and seeking ways to maintain a proactive security approach, when the reality is that they’re caught in reactive mode. This raises the question: how can security professionals adapt to an ever shrinking development cycle?

Here are some of the most common setbacks that slow security teams down:

• Lengthy testing setups deliver insights that are 2-3 iterations behind the latest code (a traditional pentest engagement can take weeks to get up and running)
• Test findings are rarely integrated in DevOps workflows, which lowers the chances that engineers will act on them
• Remediation efforts are often a one-off exercise and rarely inform future code developments, leading to the same vulnerabilities reemerging at a later stage
• Security leaders come across as ‘gatekeepers’, rather than ‘consultants’, which adds strain to workflows and relationships within the company

Resolving these pain points comes down to two core challenges: speed and communication.

Challenge #1: Speed

Take the following DevSecOps pipeline designed by Larry Maccherone:

Testing can happen at several pre-production stages, but here’s the catch: try to fit a pentest into a 24-hour sprint and you may find yourself multiple iterations behind by the time vulnerability findings come back.

What’s even more troubling is that by the time you finish handling remediation from the first pentests, the same vulnerabilities have likely appeared in more code developed in parallel. If engineers are not informed of errors from the start, addressing them down the line can easily spin out of control.

Part of the problem lies in the test setup. With the traditional pentesting model, providers typically need weeks or months of advance notice. This is far too rigid for DevOps practices. We recommend considering more flexible on-demand pentesting models that leverage both automation and human expertise. Cobalt’s particular solution to this challenge is to provide a PtaaS platform that combines the best of both worlds.

Challenge # 2: Communication

Say you’ve effectively addressed the first hurdle — you’ve set up a recurring pentesting program that is delivering insights on a regular basis. First, take a moment to congratulate yourself — you’ve already taken a huge step in the right direction! The second challenge lies in acting on those insights. Security can help find vulnerabilities and advise on remediation, but code and software won’t get more secure until engineers do something about it.

While this is a tale as old as time, misalignment in the DevOps context becomes even more detrimental for companies’ security posture, leaving remediation in the backlog rather than integrating it into initial development.

We think part of the cause lies in how a typical testing process pans out:

There are many things wrong with this approach. Most notably, there is no attempt by the security team to integrate requests with engineering workflows. There’s no obvious channel for engineering to seek guidance on how to resolve issues, or even clarify what the issues are. Since traditional penetration tests tend to be one-off engagements, it’s also unlikely the original testers will be available to provide support.

Rather than position security teams as collaborators and a rich source of feedback on the product’s security, this workflow pushes them towards the role of ‘gatekeepers’ who inhibit innovation and growth. That’s not where we need to be.

How to Address Both Challenges

In order to add ‘Sec’ into the DevOps methodology, we must reposition our feedback as timely and actionable insights that help other teams reach their objectives. Making this happen depends on two tasks:

1. Sourcing on-demand pentesting options that don’t balloon your budget;
2. Integrating findings within engineers’ workflows in a way that enables better, faster and more informed coding practices;

To help you solve both, we produced “Pentesting in DevOps: A How-To Guide”, where we explore the following:

• How pentesting can transform from a development blocker to a value-adding program that provides periodic feedback
• What on-demand pentesting is and how it can lead to more timely vulnerability findings
• The value pentesting can bring to engineering teams with different levels of DevOps maturity
• Which pentesting models can improve communication between security, engineering and pentesting teams
• What steps to take to streamline remediation and guide future code development