A Venify report showed that the number of companies where DevOps is responsible for the security and the number who assign this to their Infosec department is almost evenly split. But should there really be this ambiguity regarding the responsibility of software security?
When you look at the situation on paper, you might say that Information Security should find holes in the apps because they are normally penetration testing the company's running software anyway. But equally compelling is to claim that because DevOps knows how the software works and is likely one of the few units with access to the codebase, they should be at work making sure hackers cannot exploit the software.
From this perspective, it seems that both of these views are right. DevOps should patch their programs - and make sure there are none of those pesky off-by-one errors - while Infosec has the knowledge necessary to send a running program off the rails.
So for you and me, it seems obvious to us what the roles of those two departments should be. But what about who takes responsibility when a cyberattack happens?
I'm not really the one posing this question. Executives often assign this taking-in-charge to either DevOps or Infosec, provided that both exist. We don't see most businesses sharing collective blame when they are hacked, right? So why don't they just make one department responsible for protecting the company from breaches?
That would be a poor approach to the problem because merely pentesting the program for vulnerabilities ignores the fact that hackers can try a completely new attack vector to enter the organization. And while DevOps can guard against basic flaws such as null dereference, they don't have the time that Infosec has to run different tests to catch new vulnerabilities continuously.
I don't believe that incident response should be a blame game and that all departments which play a part in the application interacting process should take responsibility to protect the software they use at their company and write, not only for their own company but for clients that also use the software in their products as well.
This post was originally published on NotATether.com.