Open Source Tern Locks Dockerfile to Container Image
The team behind the open source Tern tools for scanning container images has released an update that adds the ability to lock the base image of a Dockerfile to the packages installed. Every subsequent package installed is then pinned to a specific Dockerfile.
Originally developed by VMware, the 2.0 release of Tern addresses a Dockerfile issue that occurs when the base digest changes because the packages that make up the base image have changed. As a result, a container image build from a Dockerfile installed a few months ago can end up building a very different container image a few weeks later.
Additionally, Tern 2.0 now includes the ability to map data generated by code scanning tools from ScanCode into Tern’s data model, in addition to expanding test coverage and allowing users to set the working directory on the command line.
Nisha Kumar, an open source engineer at VMware, says the goal should be to make scanning of container images a natural extension of any DevOps process built on top of a continuous integration/continuous delivery (CI/CD) platform. As that capability becomes more common, organizations increasingly will embrace best DevSecOps processes to make containerized applications more secure, she says.
As part of that effort, future work for Tern is focused on adding support for language package managers and support for multistage Docker builds, she adds. That work is now going forward under the auspices of the tern-tools project led by the Automated Compliance Tool (ACT) working group, which is part of The Linux Foundation.
One of the biggest challenges when it comes to adopting DevSecOps is providing developers with the tools required. Open source tools such as Tern are readily accessible to DevOps teams. The challenge is figuring out how to extend CI/CD pipelines to incorporate those tools within DevOps workflows. The good news is that it’s much easier to rip and replace containers that have vulnerable code than it is to patch an entire monolithic application. As organizations focus more on DevSecOps, it’s only a matter of time before DevOps teams more widely embrace containers to improve overall application security.
Once the tools are in place to achieve that goal, the next biggest challenges are cultural. As developers assume more responsibility for implementing cybersecurity controls, the cybersecurity team needs to focus more on defining controls and verifying they are implemented. Of course, that assumes a level of cooperation between developers and cybersecurity teams that has been rare. Many cybersecurity professionals historically have considered developers to be part of the application security problem rather than the solution. Cybersecurity teams that are chronically overwhelmed by all the potential threats that need to be thwarted, however, have little alternative. There simply isn’t enough cybersecurity to go around.
It’s unclear in this economic climate at what rate modern applications will be built and deployed. Some organizations are pressing ahead with digital business initiatives while others are retrenching. The one thing that is for certain is the more modern an application is, the more security will be baked into it. That doesn’t mean there won’t be a breach, but it does mean the breach is less likely to occur because someone on the DevOps team made a mistake.