Containers, like infrastructure as code (IaC), are a crucial part of cloud-native application development. Where IaC defines the infrastructure and orchestration configurations, containers host the microservices that make up an application.
Containers have reached peak adoption, with 92% of respondents from the 2020 CNCF survey using containers in production. However, according to Forrester’s recent survey Bridging The Developer and Security Divide, “the top two most challenging tasks are ensuring security in the cloud at 79% and securing workloads and containers at 71%.”
Containers also blur the line between application and infrastructure. Containers are created from a configuration file such as a Dockerfile and include packages that need to be configured to meet the need of the service. This is very similar to IaC templates with external modules and providers.
The problem with container technology is that while it enables microservices for independent, decoupled development, it adds significant complexity. And the blurred lines between infrastructure and application also show up in that an attack vector may be opened at multiple layers of a stack. An application may be secure, but if a firewall rule leaves the front door open, data can be exfiltrated. Similarly, if the infrastructure is fully locked down, but a vulnerability with a public rootkit exists in the frontend of a web service, attackers can easily inject malicious code.
That’s why it’s important to have a complete picture of your security posture, from the infrastructure to the containers running on top. The best time to secure a container is during the development and build phases. This is the stage when you have the most context for what is being built and is the easiest and fastest time to make changes, like updating a package that has breaking changes. So having a complete view of your containers’ posture with visibility into the posture of your IaC at build time gives you a better overall understanding of the threat blast radius.
With Checkov 2.0, we introduced the ability to find misconfigurations in Dockerfiles based on CIS benchmarks, but that doesn’t give you insights into the open source packages included in the container image. That’s why Bridgecrew is excited to announce our container image scanning is coming soon!
This new offering automatically scans repositories for container vulnerabilities leveraging Prisma Cloud’s twistcli, the CLI tool acquired from Twistlock, helping you identify and remediate vulnerabilities in container images with high accuracy and a low false-positive rate.
Automated container image scanning
With container image scanning, Bridgecrew will identify any Dockerfile in your repository and scan it for misconfigurations and vulnerabilities found in any dependencies.
With every vulnerability found, Bridgecrew will provide remediation feedback to get things done fast. For example, if you add a new Dockerfile with dependencies such as operating system packages and Python, NodeJS, Java, or Go libraries, Bridgecrew will identify any vulnerabilities and misconfigurations in those packages. All vulnerabilities identified will show up in the Bridgecrew platform along with feedback about the lowest possible version increase required to remediate the vulnerability. All this makes it easier to ensure only secure code is added to a repo.
Get started with git container image scanning
Scanning your containers is as easy as onboarding your version control system (VCS). Once you onboard your GitHub, GitLab, Bitbucket, or Azure Repos account, Bridgecrew will automatically check for any Dockerfiles in onboarded repositories periodically. When Bridgecrew identifies a new or modified Dockerfile, it builds the image and scans it for vulnerabilities and misconfigurations.
Bridgecrew will include any vulnerability identified in the Projects page along with any misconfigurations found in the IaC templates in the same repo. Each vulnerability will include:
- CVE ID
- Severity score
- CVSS score
- Package name
- Version number
- Repair status
- Publish date of the vulnerability
- Description of the vulnerability
The status includes the version number when the vulnerability was patched and the description provides the times since the discovery and patch were released. Updating the package to the recommended version number will resolve the vulnerability. Coupled with the Severity score, the timing details will help with prioritization to focus patching efforts.
Full-stack, build time cloud-native application scanning
With this latest innovation, Bridgecrew can now help you secure your entire cloud-native application, from the cloud infrastructure and orchestrators to the containers running on top—all from a single developer-friendly platform. Identifying and closing misconfigurations and vulnerabilities in your applications drastically reduces the attack surface area.
Expect this capability to show up automatically for any repo onboarded to the Bridgecrew platform in the coming weeks. Try this and other features out by signing up for our free 14-day trial and onboarding your VCS!
