New JFrog Workload Inspection Tool Points to a Post-Container World
At the dawn of the containerization era, the methodology discussion at the high end of the scale was about how containers changed developers’ perception of the nature of workloads. Then came some cautionary notes from HashiCorp founder Mitchell Hashimoto and others, warning that the conceivable means to contain workloads were all varying means toward a common end — and to that extent, we should stop treating the container as the architecture, and look toward implementation-agnostic workloads.
Evidently the workload orchestration industry has taken heed. On Monday, JFrog, whose Artifactory repository has already been devised to integrate the code products of a variety of development tools, took another major step forward toward decoupling workloads from the formats that contain them. Answering Docker Inc.’s launch last week of its container vulnerability scanner, as well as Twistlock’s release of its newly adapted container behavior analysis system, JFrog is releasing Xray. It’s an inspection system that reveals the deep dependencies applications have with the OS kernels and code libraries that support them — in whatever form that may be.
“Everyone needs to take care of their software on the binary level,” said Shlomi Ben Haim, JFrog’s CEO, in an interview with The New Stack, “otherwise there is no way to automate it, and there is no DevOps without it. And it should be universal.”
What’s Being Scanned and Why
Much of the early criticism around containers — or “Docker containers,” as they were known before the formation of OCI — centered around how the exploitability of the format appeared to be an open issue. Docker Inc. has since addressed those concerns on multiple occasions, including with its own Docker Trusted Registry, and most recently with Docker Security Scanning.
But there is a wider scope of the open source ecosystem, to include packages in formats such as JAR used by Maven for Java projects, and the npm package manager used by Node.js. Whatever security issues may affect the exploitability of OCI containers may, in that light, equally affect the same characteristics of other package formats that contain dependent — or even non-dependent — code components that may include vulnerabilities.
In a way, through the release of Xray, JFrog renders the problem no longer Docker’s to resolve, so much as everyone’s. Ben Haim told The New Stack it will conduct a deep scan of packages, collect an extensive log of their contents, and produce a dependency graph that visually depicts the dependencies between code components, in a format that developers may more readily interpret. It then will produce an impact analysis report, giving developers a worst-case scenario of the exploitability of those packages — OCI containers or otherwise — based on JFrog’s previously amassed information.
“The biggest thing today is, when you ship a container or distribute a package, you basically don’t know what you have inside,” said Ben Haim. “There are all kinds of security vulnerability, licenses, and compliance databases. While you have all this information, they don’t provide you with a graph of dependencies of what is included in these images. And on top of that, they cannot provide you with one of the most important things for DevOps and for automation: the impact analysis.”
JFrog’s goal with this release, Ben Haim continued, is not to clone one of those green-light / red-light security scanners so common in the SMB world of IT, but to give developers a genuine report of how their code interacts with the software dependent upon it. This way, developers may take the opportunity to streamline their code, and reduce dependencies where they can.
More Credence for Unikernels
Ben Haim said Xray will write to common logging databases such as Black Duck, WhiteSource, and VersionEye — the latter of which will be included with Xray. The new tool will, of course, integrate with JFrog’s Artifactory to collect build information in real-time, to render the dependency graph before a build is committed to production. That graph, the CEO stated, would include the specific points of impact in production environments that would be impacted when potentially vulnerable code is pushed to production.
“The one thing that DevOps engineers are now suffering from is that, while containers are a great way to distribute your software packages,” he told us, “you still need to know, and you’re still required to report, what this container image includes… It’s not just a problem with containers, [which is] one of the things people are now pointing at. It’s also relevant to all kinds of packages. Once you push something, you want to know what it includes, what dependencies come with it, and know exactly where you pushed it in the past and where you’re going to push it in the future.”
The potentially complex graphs that JFrog Xray will produce may also speak to the case for unikernels — a style of workload packaging where the full OS kernel, however, miniaturized, is replaced with libraries containing just the dependent code a package may need. Dependency graphs may provide visual evidence that trimming software distributions of their unused or useless code may simplify the organization of applications as they are deployed in data centers. The fewer dependencies that packages contain, the lesser the chances of their exploitability, including well into the future.
Docker is a sponsor of The New Stack.
Feature image: an X-ray photograph of two frogs, circa 1896, by Josef Maria Eder and Eduard Valenta, in the public domain.
