Oxeye Delivers CNAST Tool to Better Secure Microservices
At the KubeCon + CloudNativeCon Europe 2022 conference, Oxeye today announced general availability of its Cloud Native Application Security Testing (CNAST) tool to pinpoint vulnerabilities in microservices-based applications.
The Oxeye platform requires developers to download an observer tool that is deployed in a single container and scans code for vulnerabilities and secrets. Once identified, the Oxeye platform guides developers through the remediation process without requiring them to inject agent software into every application.
Oxeye CEO Dean Agron says this approach is critical because it enables IT teams to implement DevSecOps best practices across highly dynamic application environments where microservices are regularly added and updated. The CNAST platform can also be employed to automatically generate a software bill of materials (SBOM) to identify all the components that make up a microservices-based application at any given point in time, he adds. The SBOM plays a critical role in identifying where—within a microservices-based application that could be made up of hundreds of containers—a newly discovered zero-day vulnerability might be found.
In theory, responsibility for application security is being pushed further left toward developers as organizations embrace DevSecOps best practices. However, making developers more accountable for security without providing them the tools required to achieve that goal is not likely to improve the overall state of application security. No two developers are ever likely to have the same level of cybersecurity expertise. Oxeye is making a case for a security tool designed to both analyze code for vulnerabilities and explain how to avoid encountering that issue again.
At a time when more organizations than ever are focused on securing software supply chains and in the wake of a series of high-profile security breaches, that capability is crucial, notes Agron. The Biden administration has issued an executive order that requires government agencies to adopt DevSecOps best practices. That edict is likely to be adopted, to one degree or another, by enterprise IT organizations struggling with the same software supply chain security issues.
The core issue, of course, is organizations need to find a way to empower developers to address security issues without slowing down the rate at which applications are built and deployed. Making developers more aware of security issues is, of course, only the first step. However, in the absence of any tools that can be easily incorporated within application development workflows, developers are not going to take yet another application security sermon to heart as they rush to meet yet another application delivery deadline. Many of those developers still tend to view application security as the responsibility of IT and security operations teams within their organization.
In the meantime, there are more guardrails being added to DevOps platforms with the intention of ensuring vulnerabilities don’t make it into production applications. Applications are built by humans, so there is always a chance mistakes will be made no matter how many tools are provided. However, the fewer vulnerabilities that are introduced into an application in the first place, the less likely it becomes one will inadvertently find its way into a production environment.
