Contrast Security this week added a Route Intelligence module to a Contrast Assess vulnerability assessment that automates the code scanning process.
Surag Patel, chief strategy officer for Contrast Security, said Route Intelligence employs sensors in the form of lightweight agents to instrument applications so IT teams can more easily identify where vulnerabilities are located within code being developed. Those sensors allow the Contrast Assess platform to not only continuously assess applications for vulnerabilities as they are built and updated, but also prioritize which vulnerabilities need to be addressed first based on their potential severity, said Patel.
The overall goal is to advance the adoption of best DevSecOps processes in a way that generates the least amount of friction, he added. Today much of the remediation process is painstakingly slow because once cybersecurity teams identify a vulnerability they spend an inordinate amount of time looking for all the places in their code where that vulnerability might exist.
Route Intelligence provides developers with the equivalent of a map to identify all the instances of a specific vulnerability within their code, said Patel.
That approach goes beyond simply shifting responsibility for application security left on to the shoulders of developers; it also extends the reach of DevSecOps to the right by instrumenting application code in a way that makes it easier to discover vulnerabilities, said Patel.
Instrumentation of software is, of course, one of the core tenets of a best DevOps practice. Contrast Security is simply making a case for extending instrumentation and observability to include cybersecurity as part of embracing DevSecOps, Patel said. IT teams can also leverage REST application programming interfaces (APIs) to integrate Contrast Assess within their continuous integration/continuous delivery (CI/CD) platforms.
It’s unclear at this point to what degree DevSecOps will become a discrete set of tasks and functions within a DevOps process or simply become a natural extension of any application quality assurance process. The current focus on DevSecOps may only serve to highlight how much work needs to be done in this area as the volume of cyberattacks being launched against applications continues to increase. Organizations are, of course, more dependent on software than ever, so each successful attack is causing a lot more damage than it might otherwise have just a few years ago.
Right now, however, DevSecOps is much more of an aspiration than a reality within most organizations. Cybersecurity teams have always viewed developers with suspicion because most of the vulnerabilities that are exploited by cybercriminals originate with developers. At the same time, overworked developers are not able to address every vulnerability discovered by a cybersecurity team. Developers need more context to strike a balance between the amount of time they spend on bug fixes and building new code. In many instances, developers have, rightly or not, come to view the cybersecurity team as a hindrance to their ability to deliver more code faster. In an ideal world, developers would be rewarded more for delivering more secure code faster. However, to achieve that goal organizations are going to need to put a framework in place that enables their IT teams to move beyond continuing to issue the occasional DevSecOps platitude.
— Michael Vizard