mirror of https://github.com/docker/docs.git
124 lines
5.3 KiB
Markdown
124 lines
5.3 KiB
Markdown
---
|
|
title: Get started with Policy Evaluation in Docker Scout
|
|
keywords: scout, supply chain, vulnerabilities, packages, cves, policy
|
|
description: |
|
|
Policies in Docker Scout let you define supply chain rules and thresholds
|
|
for your artifacts, and track how your artifacts perform against those
|
|
requirements over time
|
|
---
|
|
|
|
> **Early Access**
|
|
>
|
|
> Policy Evaluation is an [Early Access](/release-lifecycle/#early-access-ea)
|
|
> feature of Docker Scout.
|
|
{ .restricted }
|
|
|
|
In software supply chain management, maintaining the security and reliability
|
|
of artifacts is a top priority. Policy Evaluation in Docker Scout introduces a
|
|
layer of control, on top of existing analysis capabilities. It lets you define
|
|
supply chain rules for your artifacts, and helps you track how your artifacts
|
|
perform, relative to your rules and thresholds, over time.
|
|
|
|
Learn how you can use Policy Evaluation to ensure that your artifacts align
|
|
with established best practices.
|
|
|
|
## How it works
|
|
|
|
When you activate Docker Scout for a repository, images that you push are
|
|
[automatically analyzed](../image-analysis.md). The analysis gives you insights
|
|
about the composition of your images, including what packages they contain and
|
|
what vulnerabilities they're exposed to. Policy Evaluation builds on top of the
|
|
image analysis feature, interpreting the analysis results against the rules
|
|
defined by policies.
|
|
|
|
A policy defines one or more criteria that your artifacts should fulfill. For
|
|
example, one of the default policies in Docker Scout is the **Critical
|
|
vulnerabilities** policy, which proclaims that your artifacts must not contain
|
|
any critical vulnerabilities. If an artifact contains one or more
|
|
vulnerabilities with a critical severity, that artifact fails the evaluation.
|
|
|
|
In Docker Scout, policies are designed to help you ratchet forward your
|
|
security and supply chain stature. Where other tools focus on providing a pass
|
|
or fail status, Docker Scout policies visualizes how small, incremental changes
|
|
affect policy status, even when your artifacts don't meet the policy
|
|
requirements (yet). By tracking how the fail gap changes over time, you more
|
|
easily see whether your artifact is improving or deteriorating relative to
|
|
policy.
|
|
|
|
Policies don't necessarily have to be related to application security and
|
|
vulnerabilities. You can use policies to measure and track other aspects of
|
|
supply chain management as well, such as base image dependencies and
|
|
open-source licenses.
|
|
|
|
## Default policies
|
|
|
|
Docker Scout ships the following three out-of-the-box policies:
|
|
|
|
- [Critical and high vulnerabilities with fixes](#critical-and-high-vulnerabilities-with-fixes)
|
|
- [Critical vulnerabilities](#critical-vulnerabilities)
|
|
- [Packages with AGPLv3, GPLv3 licenses](#packages-with-agplv3-gplv3-licenses)
|
|
- [Base images not up-to-date](#base-images-not-up-to-date)
|
|
|
|
These policies are turned on by default for Scout-enabled repositories. There's
|
|
currently no way to turn off or configure these policies.
|
|
|
|
### Critical and high vulnerabilities with fixes
|
|
|
|
This policy requires that your artifacts aren't exposed to known
|
|
vulnerabilities with a critical or high severity, and where there's a fix
|
|
version available. Essentially, this means that there's an easy fix that you
|
|
can deploy for images that fail this policy: upgrade the vulnerable package to
|
|
a version containing a fix for the vulnerability.
|
|
|
|
This policy only flags vulnerabilities that were published more than 30
|
|
days ago, with the rationale that newly discovered vulnerabilities
|
|
shouldn't cause your evaluations to fail until you've had a chance to
|
|
address them.
|
|
|
|
This policy is unfulfilled if an artifact is affected by one or more critical-
|
|
or high-severity vulnerability, where a fix version is available.
|
|
|
|
### Critical vulnerabilities
|
|
|
|
This policy requires that your artifacts contain no known critical
|
|
vulnerabilities. The policy is unfulfilled if your artifact contains one or
|
|
more critical vulnerabilities.
|
|
|
|
This policy flags all critical vulnerabilities, whether or not there's a fix
|
|
version available.
|
|
|
|
### Packages with AGPLv3, GPLv3 licenses
|
|
|
|
This policy requires that your artifacts don't contain packages distributed
|
|
under an AGPLv3 or GPLv3 license. These licenses are protective
|
|
[copyleft](https://en.wikipedia.org/wiki/Copyleft), and may be unsuitable for
|
|
use in your software because of the restrictions they enforce.
|
|
|
|
This policy is unfulfilled if your artifacts contain one or more packages with
|
|
a violating license.
|
|
|
|
### Base images not up-to-date
|
|
|
|
This policy requires that the base images you use are up-to-date.
|
|
|
|
It's unfulfilled when the tag you used to build your image points to a
|
|
different digest than what you're using. If there's a mismatch in digests, that
|
|
means the base image you're using is out of date.
|
|
|
|
#### No base image data
|
|
|
|
There are cases when it's not possible to determine whether or not the base
|
|
image is up-to-date. In such cases, the **Base images not up-to-date** policy
|
|
gets flagged as having **No data**.
|
|
|
|
This occurs when:
|
|
|
|
- Docker Scout doesn't know what base image tag you used
|
|
- The base image version you used has multiple tags, but not all tags are out
|
|
of date
|
|
|
|
To make sure that Docker Scout always knows about your base image, you can
|
|
attach [provenance attestations](../../build/attestations/slsa-provenance.md)
|
|
at build-time. Docker Scout uses provenance attestations to find out the base
|
|
image version.
|