Containers – or packages of bundled applications and all of the necessary dependencies, libraries and configuration files needed to run them – have seen rapid adoption in the application development world because of their ability to overcome the problem of getting software to run and operate the same in any environment. In a recent Sonatype blog post, Alyssa Shames illustrates just how popular they’ve become, citing the Sonatype 2020 State of the Software Supply Chain Report:
“Pulls of container images topped 8 billion for the month of January. This means annualized image pulls from the repository should top 96 billion this year. To keep pace with demand, suppliers pushed 2.2 million new images to DockerHub over the past year – up 55% since our last report.”
With containers becoming an essential tool in the Software Development Lifecycle (SDLC), it’s only a matter of time before the hackers and malicious actors that look for AppSec vulnerabilities to exploit start to turn their attention to containers, themselves.
In DevSecOps, we know the key to security is to ensure that it is baked-in to development from the beginning through to delivery and beyond. Shames makes it clear that protecting our applications from adversaries seeking to monetize their attacks requires that each container has security baked-in and that each are without vulnerability. Otherwise, our entire application platform is at risk – putting our clients and organizations in harm’s way.
We recently sat down with Alyssa to talk about security across the SDLC and the new integration of Sonatype’s Nexus with NeuVector, which is seeking to ensure containers are continuously secure.
Here is what she had to say:
GovDevSecOpsHub (GDSOH): For the sake of our readers that may not know much about them, what are containers?
Alyssa Shames: Containers are pre-packaged code that make development faster and more reliable in terms of building, deploying, and running applications. A container can house an entire runtime environment – dependencies, applications, libraries, data files, config files, etc.
Containerizing this information helps ensure security, reliability, and speed when moving from one environment to the next – like when a container moves from staging to production.
GDSOH: Why are containers likely targets for cyber threat actors?
Alyssa Shames: Many organizations are moving to the cloud and containers work well in that environment. It’s like with anything we see that’s gaining popularity – the more people are using something, the more it’s taken advantage of.
In 2020, we expect to see almost 100 billion container downloads from public repositories and even more proprietary containers built and deployed by development and operations teams. When billions of containers are in use, there are bound to be security or configuration flaws in them that adversaries can exploit.
To date, one of the biggest malicious uses we’ve seen is cryptocurrency mining via container hijacking.
GDSOH: How vulnerable are the containers in the SDLC in comparison to other likely points of vulnerability?
Alyssa Shames: A container does not necessarily present any new or novel vulnerabilities, but it does act as an additional entry point for a cyber threat actor. A container is only as secure as the artifacts within it and its configuration. Just like individual artifacts, containerized parts can become vulnerable at any time within the SDLC.
Additionally, misconfigured containers are vulnerable from the get-go. That’s why you need to be constantly scanning containers from development to deployment.
Just because your container was secure when you put it together doesn’t mean it will remain that way as it makes its way to production. And if you are misconfiguring hundreds or thousands of containers at scale, you’re expanding the potential attack surface for adversaries.
GDSOH: How does encapsulating the NeuVector Sonatype integration in a container help with security?
Alyssa Shames: Containerization is one of the most popular means to develop, ship, and deploy packaged software. Providing a NeuVector + Sonatype integration in a container provides the ability to secure the SDLC easily and reliably.
Developers need rapid feedback on misconfigurations and code flaws that might impact the security-readiness of containers. The NeuVector integration aims to improve visibility to these flaws and risks for developers.
GDSOH: What was the impetus for the NeuVector and Sonatype’s Nexus Lifecycle platform pairing?
Alyssa Shames: While Nexus Lifecycle does have some native container scanning abilities, we really wanted to partner with a best-of-breed solution that would provide comprehensive support layer information that could match the quality of our application layer information.
We understand the importance of container security to our customers and see its growing use in the market, and we always want to make sure we’re providing the best integration options to our customers.
The quality and range of NeuVector’s data make them one of the best container security solutions currently in the market.
GDSOH: How has the open-source methodology informed and enhanced this integration?
Alyssa Shames: This integration was heavily enhanced and informed by open-source methodology because, at its core, the integration adopted and contributed to the open-source CycloneDX project – providing a common open-source framework to be used.
GDSOH: How does the user-interface in this integration help DevSecOps developers in their daily work?
Alyssa Shames: Most of the container solutions that we see from traditional software composition analysis (SCA) vendors are disconnected from a developer’s regular workflow. That results in developers needing to perform multiple scans in multiple solutions, which is not as seamless as what we’re providing with NeuVector.
Sonatype’s Nexus Lifecycle and NeuVector integrate so that you only need to run one scan, and then all results are displayed in Nexus Lifecycle for a singular view to see and manage vulnerability results.
To learn more about the NeuVector + Sonatype Integration click here.
