Security Should Stop Being a Drag

About a year ago during my talk at the Nexus User Conference, and during a Virtual Session for RSA Conference APJ, I mentioned that a pipeline shouldn’t fail just because a security vulnerability was detected by scanning tools. That statement was met with a few record scratches in the audience but I still stand by the idea today. I think a deeper conversation on the topic may be necessary because my statement is the exact opposite of The Three Ways described in The DevOps Handbook and the Phoenix Project.

Breaking the Build, or Breaking Bad?

Knowing when to break a build is an interesting conversation to have when teams decide to adopt DevSecOps practices. In an effort to “shift left” as much as possible, teams don’t always consider that the product stakeholders can be adversely impacted when the pipeline stalls. Stakeholders come to an opinion that “shift left” means “break often”.

A few adverse effects may occur if a pipeline breaks in the wrong place. An application’s functionality should be available for either automated or manual testing or user acceptance testing. Security vulnerabilities, although extremely important, are in reality non-functional. They don’t alter functionality and really can’t be classified as a pure defect. It’s a subtle difference.

Key stakeholders should review progress and exercise the application as well. What happens when remediation takes longer than expected? Or when the feature delay backs up testing? Stakeholders left waiting for product delivery begin thinking that the engineering department isn’t productive. Fingers start pointing, and then we may as well not even be talking about DevOps.

Risky Business

In general, organizations will (or should) have defined vulnerability remediation SLA’s in their Governance and Compliance tools. For example, there may be SLA’s which state that Critical vulnerabilities need to be (Read more...)