To answer this question we would need to take a quick look at differences between DevOps, QA and Security when it comes to automation issues. I will have to write about things that are probably obvious for any security engineer who was practically involved in traditional AppSec activities such as penetration testing, dynamic or static code analysis.

The problem is that for some security executives who came to security from infrastructure, networking or development domains and have never run a security scan,  it’s not obvious at all.

Since situation when security execs are coming from different non-security domains is rather common (due shortage of security professionals), explanation below is crucial to answer the original question. To put it short, the difference is that DevOps and QA are very much deterministic, while security is not. The picture below illustrates my thought.

Ops: run_script(input) –> $? (0, non-zero)

QA: assert(condition) –> {true,false}

Security: scan(app) –> {HML…,false positive}

where High Medium Low and False Positives are really a human’s decision

In the case of architecture review and threat modeling, which are two other important AppSec activities that are often required by compliance standards such as SOC 2, it becomes even more non-deterministic where the results of analysis could be absolutely unpredictable and very much determined by an assessor background.

Needless to say that automation is nowhere close for this type of activities. The best we can do here is to get rid of unnecessary complexity, pseudo-scientific approaches to evaluating risks (e.g. DREAD) and describe the threats in a simple threat table with severities that everybody would easily understand, i.e. “Low”, “Medium”, “High”.

Not understanding this simple truth leads to euphoria and to setting up wrong expectations, e.g. a CISO who came from networking domain can say that a good networking appliance is all we need to completely automate security, while a CISO with a developer’s background will say that writing a lot of code will make security just as fast as DevOps and CI/CD. Needless to say that both are wrong and will not last long – they will have to leave as soon as their CEO or CTO understand that those promises will never materialize.

Does it mean that there is nothing we can do to automate security and make it faster? Of course not. As security engineers we can and we should, and this is what I’ve been talking about for almost three years by now: first at LASCON 2015, then at AppSecCali 2016 and just recently at  RSA 2017 DevOps event.

However, we should always take into consideration a non-deterministic nature of security and set up expectations right when talk to our execs.

The bottom line, security is seen as an inhibitor to DevOps agility because it is an inhibitor in many ways, but there are always opportunities to improve it by researching new approaches of doing it. In this regard, my big hope is a deeper penetration of AI and machine learning to the security domain. It won’t be easy, but the progress in IDS/IPS space makes me think that it will eventually help automating traditional AppSec activities as well.