Ensure that images meet your requirements for security, compliance and operational best practices.
Ensure that images meet your requirements for security, compliance and operational best pract
Basic Security Checks: CVEs
Traditional approaches to image scanning have focused on scanning the operating system for vulnerabilities known as CVEs , presenting the user with a list of CVEs found within the image. In some cases the image would be scored based on the level of severity of the CVEs – for example “Fail if any High vulnerabilities are found,” in other cases the user is presented with a list of CVEs and is responsible for making the go / no-go decision based on the data displayed which represents a daunting challenge for most developers or operators.
Just because a CVE is marked as High does not necessarily mean that this issue should block a container’s deployment. In many cases a CVE may not have a fix available from the Linux distributor because it is not exploitable as configured or it may only represent a less serious issue in this distributors configuration. This level of uncertainty often leads to confusion and in many cases CVEs are ignored altogether.
CVE Scans Are InsufficientWhile checking an image for CVEs is critical, it is just the first step. An image may contain no operating system CVEs but may still be insecure, mis-configured or in some other way out of compliance. Container images typically contain hundreds, often thousands of files – some coming from operating system packages, some from configuration files, some from 3rd party software libraries such as Node.JS NPMs, Ruby GEMs, Python modules, Java Archives, and some may be supplied by the user. Each one of these artifacts should undergo the same level scrutiny as the operating system packages.
Using Anchore tools policies can be defined that specify rules to govern security vulnerabilities, package whitelists and blacklists, configuration file contents, presence of credentials in image, manifest changes, exposed ports or any user defined checks. These policies can be deployed site wide or customized for specific images or categories of applications.
Anchore supports the creation of whitelists that can be used to override a specific policy check. For example a CVE may be listed as high but has been assessed by the end-user as harmless and so can be specifically excluded from policy evaluations. Whitelists can be applied globally to all images or can be applied on a per-image or per-application basis.
The Anchore engine subscribes to data feeds published by Anchore’s SaaS service. These feeds include data used within the evaluation of policies. CVE Feeds from key Linux Distributors, vulnerability feed from the National Vulnerability Database (NVD), operating system package feeds Node.JS Package data, Ruby GEM Package data, and other security feeds.
Policies covering operating system packages, including: required packages, minimum versions, blacklisted packages, non-official packages, available updates.
Anchore ships with a default set of Policy Modules, also known as gates to perform specific checks i.e. analyzing a Dockerfile, checking file contents, or comparing package data. Custom policy modules can be added to extend the policy evaluation to run user defined checks.
File Contents Checks
Artifacts that should not be present in the image including source code, sensitive configuration information and secrets such as API keys and passwords
Node.JS NPM Checks
Policies covering Node.JS modules including blacklist NPM modules, blacklist Specific versions of modules, block outdated modules, block unofficial modules
Security checks on the image contents including CVE vulnerability scans, changes to sensitive files such as binaries with SUID bit, changes in file owners or attributes.
Policies that are evaluated against the image’s Dockerfile to ensure best operational and security practices
Policies that restrict specified software licences for operating system and 3rd party libraries such as NPMs and Ruby GEMs.
Ruby GEM Checks
Policies covering Ruby GEMs including, blacklist GEM modules, blacklist Specific versions of modules, block outdated modules, block unofficial modules
Schedule a Time to Speak with Us
Request a demo to learn more about how Anchore policies can work in your workflow.