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
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
80% of latest Docker Hub images have severe vulnerabilities
North Carolina State University
30% of Docker Hub images have severe vulnerabilities
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.
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
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.
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.
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.