Veracode today updated its risk management tool to provide integration with Kubernetes runtime environments, increased integration with code repositories to make it simpler to identify the origin of vulnerabilities and, available shortly, an ability to add tags and classifications to help streamline remediation efforts.
In addition, Veracode is now providing early access to Veracode Package Firewall, which makes use of Open Policy Agents (OPA) to enforce policies that prevent the usage of open source software dependencies that have known vulnerabilities using technology the company gained with the acquisition of Phylum earlier this year. It is scheduled to become generally available in June.
Derek Maki, VP product and GM at Veracode, said both additions to the company’s portfolio will enable DevSecOps teams to better secure software supply chains at a time when they are increasingly being targeted by cybercriminals who have developed coding expertise.
The latest extensions to Veracode Risk Manager (VRM), for example, now makes it possible to provide more real time context about threats in container applications both before and after they have been deployed in a runtime environment as part of a larger effort to improve application security posture management (ASPM), he noted.
While a lot of progress has been made in terms of adopting best DevSecOps practices, there remains much work to be done, noted Maki. There has been too much emphasis on shifting responsibility for application security solely onto the shoulders of application developers, he added. Instead of shifting that responsibility as far left as possible to application developers, organizations need a more balanced approach that makes it easier to, for example, identify vulnerabilities in production environments that are actually exploitable, Maki said.
Otherwise, cybersecurity teams wind up creating long lists of vulnerabilities for application developers to investigate that, in the final analysis, reduce the amount of time they have available to write additional code, he added.
Unfortunately, many DevSecOps teams are now trying to analyze data being generated by, on average, 45 different tools that are being employed across multiple silos within their organization, said Maki. The end result is an overwhelming amount of telemetry data that is too difficult for DevSecOps teams to analyze in any meaningful way with a tool such as VRM, he added.
Each organization will need to determine how best to apply limited DevSecOps resources as they best see fit, but the one certain thing is the amount of code moving through their pipelines is only going to exponentially increase in the age of generative artificial intelligence (AI). Not all that code will make it into a production environment, but it will need to be tested for vulnerabilities that could be introduced at multiple points of the software development lifecycle (SDLC).
The challenge, as always, is finding a way to eliminate as many issues as early as possible without inundating application developers who are not cybersecurity experts with a stream of alerts that, because they are not likely to comprehend, will simply be ignored.
