Time for cybersecurity teams to stop cleaning up someone else’s vulnerability mess

The fundamental problem with cybersecurity today comes down to the simple fact there isn’t enough time in the day to discover and remediate all the potential vulnerabilities that exist within any IT environment.

A survey of 600 cybersecurity professionals conducted by the Ponemon Institute on behalf of Balbix, a provider of vulnerability discovery tools infused with artificial intelligence (AI), finds 67 percent of respondents admit they don’t have the time and resources required to mitigate all the vulnerabilities in their environment. A full 60 percent admit they don’t even have visibility across all their IT assets. As any cybersecurity professional knows, an organization can’t patch what it doesn’t know it has. In fact, over half (53%) say they only run vulnerability scans either on an ad hoc basis or once a quarter.

Over two-thirds of the survey respondents also acknowledge they are at least a month behind on fixing known software vulnerabilities. In fact, less than half consider patching to be a proactive approach to avoiding breaches.

It’s easy to blame cybersecurity professionals for this mess. But the truth of that matter cybersecurity professionals are not the ones who created this mess in the first place. Most of the vulnerabilities are only discovered in a component of an application after it gets deployed in a production environment. Sometimes a developer might employ a component with a known vulnerability through carelessness. Regardless of how they are introduced, there will always be vulnerabilities in software. The real challenge is finding a way to reduce those number of vulnerabilities to a point where they become manageable.

That’s why there is so much interest these days in adopting best DevSecOps practices. As a discipline, DevSecOps essentially incorporates cybersecurity issues into the quality assurance phase of any application development project. Better still, developers are required to address vulnerabilities as part of a set of DevOps processes enabled by a continuous integration/continuous development (CI/CD) platform. In effect, responsibility for implementing patches is removed from the cybersecurity team. That team still need to discover those vulnerabilities. But once they share that information with developers, the cybersecurity team can focus more of their efforts on identifying potential threats and hunting for known vulnerabilities.

In effect, developers now have a much higher vested interest in cybersecurity. As a result, many developers are quickly adopting a microservices-based approach to building applications using Docker containers that allow them to more easily rip and replace components of an application without having to patch the entire application. Now that developers are being truly held accountable for cybersecurity, necessity has not surprisingly once again become the mother of invention.

Continually cleaning up someone else’s mess does not provide the right set of incentives for getting them to change their behavior. By shifting more responsibility for cybersecurity to the proverbial left, the number of vulnerabilities any cybersecurity team should have to help clean up should begin to decline over time. Legacy applications are not going to go away any time soon so there will always be a need to patch an application for the foreseeable future. But any time someone in the organization starts talking about replacing one of those legacy applications with a modern application that is going to be fundamentally more secure thanks to containers and DevSecOps, the cybersecurity team should do everything in their power to encourage that transition.