Why?

Our objective is to help you defend yourself

An attacker only needs to discover one vulnerability

Many compromises result from known vulnerabilities in the software you build your software on

Every day a container or host runs without updates increases likelihood of compromise

Automation Required

In 2000 there were slightly more than 1,000 vulnerabilities with CVEs. In 2016, there were nearly 10,000. In 2017, we’re on track to see nearly 20,000 vulnerabilities with CVEs. By some estimates, CVE could represent considerably less than half of all vulnerabilities discovered.

Without automation, tracking and remediating them is a full-time job at even the smallest companies. Monitoring a mailing list is not enough.

Base Images Are a Cess Pool

Between 24% and 80% of Docker Hub images have severe vulnerabilities

24% of official, latest Docker Hub images have severe vulnerabilities
Federacy

80% of latest Docker Hub images have severe vulnerabilities
North Carolina State University

30% of Docker Hub images have severe vulnerabilities
Banyan Ops

Vulnerability Bleeding

Docker best practices suggest upgrading a whitelist of packages at build, which means that packages in all upstream layers not in the whitelist do not get updated. Any lag between package updates and the upstream release is a vulnerability window.

Because image maintainers take responsibility for only their layer(s), the result is synchronous release delays across numerous levels of layer dependencies increasing the time between a vulnerability patch being available and deployment of said patch to downstream containers.

North carolina state university vuln bleeding 246ecd75f543a1a9b4a590a1a112928d8941abf4c56ee66527c6f64e05b7d28f

credit: Rui Shu, Xiaohui Gu and William Enck
North Carolina State University

Your Software’s Software

While your software, or software you trust, may be the only things exposed on your containers or hosts, it is very likely that the software has dependencies. These dependencies’ vulnerabilities can bleed through similarly to layers mentioned above, which makes it essential to track vulnerabilities for everything you build on top of. Because you shouldn’t have packages installed that you don’t use, this effectively means tracking all packages and monitoring them for vulnerabilities.

Build, Deploy, and Registry Scanning

Build scanning is good.
Deploy scanning is better
but...

Constant layer scanning of registry and container host is ideal. We’re working on it.

We look at container build and host scanning as the first step in a good security posture. We can add deploy scanning at the orchestration layer for better coverage. Next, we can add active and passive scanning of running containers.

Network Security Is Not Enough

There is almost always a hole somewhere, and unprivileged access at an entry point can quickly become total ownership. As much as possible, we should presume that network security does not exist, and act accordingly. Likewise, vigilant Docker port exposure is always a good practice, but can be easily circumvented with access to a Docker daemon or host filesystem.

Vulnerabilities Stack

While a single vulnerability may require a local user account, or may not enable privilege escalation on it’s own, two vulnerabilities in combination can result in remote privilege escalation.

Subjectivity

There is an immense amount of subjectivity in the rating of vulnerabilities. Different vendors use different scales, and even the ones that use the same scale often disagree in their assessment of the vulnerabilities.

Weekly Roundup

Updates on major vulnerabilities, compromises, and security news.