Snyk and Red Hat have aligned their efforts to make containerized applications deployed on Red Hat OpenShift, which is based on Kubernetes, more secure.
Snyk Intel, a proprietary vulnerability feed that identifies open source dependencies in real-time, has been integrated with Red Hat CodeReady Dependency Analytics and Red Hat OpenShift. Developers can now view vulnerabilities surfaced by Snyk via a CodeReady Dependency Analytics tool embedded within their integrated development environment (IDE) while they write code. Developers are being provided access to Snyk data feeds free of charge from within Red Hat CodeReady Dependency Analytics.
Snyk has also made it easier to deploy its tools using Red Hat OpenShift Operator software, which eliminates the need to employ YAML files to manually install Snyk software. In addition to scanning workloads on Kubernetes clusters, Snyk tools provide pod configuration details that help identify potential risks. Those tools are available on the Red Hat Marketplace.
Aner Mazur, chief product officer for Snyk, says as the rate at which containerized applications are developed continues to increase in part thanks to the rise of best DevOps practices, the more crucial it becomes to enable developers to discover vulnerabilities as they develop their applications. Only then can organizations truly embrace best DevSecOps processes in a way that empowers developers, he says.
Naturally, every vulnerability that gets discovered by developers before an application is deployed in a production environment is one less issue the developer or cybersecurity team has to address post-deployment. While containers make it easier to rip and replace code that has vulnerabilities, it still takes time and effort. The least expensive vulnerability to remediate is the one that never existed in the first place.
As cybersecurity tools that can be more easily incorporated into application development workflows become available, resistance to DevSecOps should soften. While everyone in IT obviously wants to see more secure applications being built and deployed, most developers don’t have access to the tools needed to achieve that goal. As a result, many developers are being held more accountable for application security without necessarily being able to do much to improve it. DevSecOps becomes even more challenging when building applications using containers, which are frequently updated. Scanning of containerized applications needs to be a continuous process.
In theory, at least, containerized applications are more secure than legacy monolithic applications. It’s more difficult to patch an entire monolithic application than it is to rip and replace a specific set of containers. As such, containerized applications should have fewer vulnerabilities relative to most legacy applications. The challenge, of course, is not just finding a way to make sure vulnerabilities don’t manifest themselves in the first place, but also setting up the processes that make remediating vulnerabilities based on their severity a natural extension of the application development process.
Developers and cybersecurity teams generally don’t see eye to eye on many things. Cybersecurity teams tend to view developers as being too cavalier about cybersecurity, while developers resent all the processes cybersecurity teams put in place that conspire to slow down application deployments. However, there soon may come a time when the enmity that has existed between both camps might be something everyone involved can laugh about.