Merge pull request #21028 from dvdksn/scout-policy-no-custom-ootb

scout: ootb policy → policy types
This commit is contained in:
David Karlsson 2024-10-03 12:14:57 +02:00 committed by GitHub
commit f40b119000
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
10 changed files with 191 additions and 165 deletions

View File

@ -229,13 +229,12 @@ to look up and include the image digest for base image versions manually each
time you want to update it. And you're opting out of automated security fixes,
which is likely something you want to get.
Docker Scout has a built-in [**No outdated base images**
policy](../../scout/policy/_index.md#no-outdated-base-images) that checks for
whether the base image version you're using is in fact the latest version. This
policy also checks if pinned digests in your Dockerfile correspond to the
correct version. If a publisher updates an image that you've pinned, the policy
evaluation returns a non-compliant status, indicating that you should update
your image.
Docker Scout's default [**Up-to-Date Base Images**
policy](../../scout/policy/_index.md#up-to-date-base-images) checks whether the
base image version you're using is in fact the latest version. This policy also
checks if pinned digests in your Dockerfile correspond to the correct version.
If a publisher updates an image that you've pinned, the policy evaluation
returns a non-compliant status, indicating that you should update your image.
Docker Scout also supports an automated remediation workflow for keeping your
base images up-to-date. When a new image digest is available, Docker Scout can
@ -245,8 +244,7 @@ changes the version automatically, because you're in control and you have an
audit trail of when and how the change occurred.
For more information about automatically updating your base images with Docker
Scout, see
[Remediation](../../scout/policy/remediation.md#automatic-base-image-updates).
Scout, see [Remediation](/manuals/scout/policy/remediation.md).
## Build and test your images in CI

View File

@ -6,8 +6,8 @@ keywords: scout, supply chain, integration, code quality
---
The SonarQube integration enables Docker Scout to surface SonarQube quality
gate checks through Policy Evaluation, under a new [SonarQube quality gates passed
policy](/scout/policy/#sonarqube-quality-gates-passed).
gate checks through Policy Evaluation, under a new [SonarQube Quality Gates
Policy](/manuals/scout/policy/_index.md#sonarqube-quality-gates-policy).
## How it works
@ -68,8 +68,8 @@ To integrate Docker Scout with SonarQube, ensure that:
statuses.
From the integration overview page, you can go directly to the
**SonarQube quality gates passed** policy.
**SonarQube Quality Gates Policy**.
This policy will have no results initially. To start seeing evaluation results
for this policy, trigger a new SonarQube analysis of your project and push the
corresponding image to a repository. For more information, refer to the
[policy description](../../policy/_index.md#sonarqube-quality-gates-passed).
[policy description](../../policy/_index.md#sonarqube-quality-gates).

View File

@ -34,7 +34,7 @@ containing security fixes. The `alpine:3.18` tag you've been using becomes
out-of-date; the `alpine:3.18` you're using is no longer the latest.
When this happens, Docker Scout detects the discrepancy and surfaces it through
the [No outdated base images](/scout/policy/#no-outdated-base-images) policy.
the [Up-to-Date Base Images policy](/manuals/scout/policy/_index.md#up-to-date-base-images-policy).
When the GitHub integration's enabled, you'll also get automated suggestions on
how to update your base image. For more information about how Docker Scout can
help you automatically improve your supply chain conduct and security posture,

View File

@ -51,39 +51,47 @@ vulnerabilities. You can use policies to measure and track other aspects of
supply chain management as well, such as open-source license usage and base
image up-to-dateness.
## Out-of-the-box policies
## Policy types
Docker Scout ships the following out-of-the-box policies:
In Docker Scout, a *policy* is derived from a *policy type*. Policy types are
templates that define the core parameters of a policy. You can compare policy
types to classes in object-oriented programming, with each policy acting as an
instance created from its corresponding policy type.
- [No fixable critical or high vulnerabilities](#no-fixable-critical-or-high-vulnerabilities)
- [No AGPL v3 licenses](#no-agpl-v3-licenses)
- [No outdated base images](#no-outdated-base-images)
- [No high-profile vulnerabilities](#no-high-profile-vulnerabilities)
- [Supply chain attestations](#supply-chain-attestations)
- [Default non-root user](#default-non-root-user)
- [No unapproved base images](#no-unapproved-base-images)
Docker Scout supports the following policy types:
To give you a head start, Scout enables several policies by default for your
Scout-enabled repositories. You can customize the default configurations to
reflect internal requirements and standards. You can also disable a policy
altogether if it isn't relevant to you. For more information, see [Configure
policies](./configure.md).
- [Severity-Based Vulnerability](#severity-based-vulnerability)
- [Compliant Licenses](#compliant-licenses)
- [Up-to-Date Base Images](#up-to-date-base-images)
- [High-Profile Vulnerabilities](#high-profile-vulnerabilities)
- [Supply Chain Attestations](#supply-chain-attestations)
- [Default Non-Root User](#default-non-root-user)
- [Approved Base Images](#approved-base-images)
- [SonarQube Quality Gates](#sonarqube-quality-gates)
There's also a set of [additional policies](#additional-policies) that can be
optionally enabled for repositories.
Docker Scout automatically provides default policies for repositories where it
is enabled, except for the SonarQube Quality Gates policy, which requires
[integration with SonarQube](/manuals/scout/integrations/code-quality/sonarqube.md)
before use.
### No fixable critical or high vulnerabilities
You can create custom policies from any of the supported policy types, or
delete a default policy if it isn't applicable to your project. For more
information, refer to [Configure policies](./configure.md).
The **No fixable critical or high vulnerabilities** policy requires that your
artifacts aren't exposed to known vulnerabilities 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.
<!-- vale Docker.HeadingSentenceCase = NO -->
By default, this policy only flags critical and high severity vulnerabilities.
### Severity-Based Vulnerability
This policy is violated if an artifact is affected by one or more critical-
or high-severity vulnerability, where a fix version is available.
The **Severity-Based Vulnerability** policy type checks whether your
artifacts are exposed to known vulnerabilities.
By default, this policy only flags critical and high severity vulnerabilities
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.
Images are deemed non-compliant with this policy if they contain one or more
vulnerabilities that fall outside the specified policy criteria.
You can configure the parameters of this policy by creating a custom version of the policy.
The following policy parameters are configurable in a custom version:
@ -109,31 +117,32 @@ The following policy parameters are configurable in a custom version:
For more information about configuring policies, see [Configure policies](./configure.md).
### No AGPL v3 licenses
### Compliant Licenses
The **No AGPL v3 licenses** policy requires that your artifacts don't contain
packages distributed under an AGPLv3 license. This policy is violated if
your artifacts contain one or more packages with this license.
The **Compliant Licenses** policy type checks whether your images contain
packages distributed under an inappropriate license. Images are considered
non-compliant if they contain one or more packages with such a license.
You can configure the list of licenses that this policy should look out for,
and add exceptions by specifying an allow-list (in the form of PURLs).
See [Configure policies](./configure.md).
### No outdated base images
### Up-to-Date Base Images
The **No outdated base images** policy requires that the base images you use are
up-to-date.
The **Up-to-Date Base Images** policy type checks whether the base images you
use are up-to-date.
It's violated 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.
Images are considered non-compliant with this policy if 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.
Your images need provenance attestations for this policy to successfully
evaluate. For more information, see [No base image data](#no-base-image-data).
### No high-profile vulnerabilities
### High-Profile Vulnerabilities
The **No high-profile vulnerabilities** policy requires that your artifacts don't
The **High-Profile Vulnerabilities** policy type checks whether your images
contain vulnerabilities from Docker Scouts curated list. This list is kept
up-to-date with newly disclosed vulnerabilities that are widely recognized to
be risky.
@ -150,8 +159,8 @@ The list includes the following vulnerabilities:
- [CVE-2024-47175 (OpenPrinting - `libppd`)](https://scout.docker.com/v/CVE-2024-47175)
- [CVE-2024-47177 (OpenPrinting - `cups-filters`)](https://scout.docker.com/v/CVE-2024-47177)
You can configure the CVEs included in this list by creating a custom policy.
Custom configuration options include:
You can customize this policy to change which CVEs that are considered
high-profile by configuring the policy. Custom configuration options include:
- **Excluded CVEs**: Specify the CVEs that you want this policy to ignore.
@ -167,14 +176,14 @@ Custom configuration options include:
For more information on policy configuration, see [Configure policies](./configure.md).
### Supply chain attestations
### Supply Chain Attestations
The **Supply chain attestations** policy requires that your artifacts have
The **Supply Chain Attestations** policy type checks whether your images have
[SBOM](/manuals/build/metadata/attestations/sbom.md) and
[provenance](/manuals/build/metadata/attestations/slsa-provenance.md) attestations.
This policy is violated if an artifact lacks either an SBOM attestation or a
provenance attestation with max mode. To ensure compliance,
Images are considered non-compliant if they lack either an SBOM attestation or
a provenance attestation with *max mode* provenance. To ensure compliance,
update your build command to attach these attestations at build-time:
```console
@ -188,7 +197,7 @@ If you're using GitHub Actions to build and push your images,
learn how you can [configure the action](/manuals/build/ci/github-actions/attestations.md)
to apply SBOM and provenance attestations.
### Default non-root user
### Default Non-Root User
By default, containers run as the `root` superuser with full system
administration privileges inside the container, unless the Dockerfile specifies
@ -196,10 +205,10 @@ a different default user. Running containers as a privileged user weakens their
runtime security, as it means any code that runs in the container can perform
administrative actions.
The **Default non-root user** policy detects images that are set to run as the
default `root` user. To comply with this policy, images must specify a non-root
user in the image configuration. Images violate this policy if they don't
specify a non-root default user for the runtime stage.
The **Default Non-Root User** policy type detects images that are set to run as
the default `root` user. To comply with this policy, images must specify a
non-root user in the image configuration. Images are non-compliant with this
policy if they don't specify a non-root default user for the runtime stage.
For non-compliant images, evaluation results show whether or not the `root`
user was set explicitly for the image. This helps you distinguish between
@ -265,9 +274,9 @@ ENTRYPOINT ["/app/production"]
{{< /tab >}}
{{< /tabs >}}
### No unapproved base images
### Approved Base Images
The **No unapproved base images** policy ensures that the base images you use
The **Approved Base Images** policy type ensures that the base images you use
in your builds are maintained and secure.
This policy checks whether the base images used in your builds match any of the
@ -322,18 +331,9 @@ This policy is configurable with the following options:
Your images need provenance attestations for this policy to successfully
evaluate. For more information, see [No base image data](#no-base-image-data).
## Additional policies
### SonarQube Quality Gates
In addition to the [out-of-the-box policies](#out-of-the-box-policies) enabled
by default, Docker Scout supports the following optional policies. Before you
can enable these policies, you need to either configure the policies, or
configure the integration that the policy requires.
- [SonarQube quality gates passed](#sonarqube-quality-gates-passed)
### SonarQube quality gates passed
The **SonarQube quality gates passed** policy builds on the [SonarQube
The **SonarQube Quality Gates** policy type builds on the [SonarQube
integration](../integrations/code-quality/sonarqube.md) to assess the quality
of your source code. This policy works by ingesting the SonarQube code analysis
results into Docker Scout.
@ -366,8 +366,8 @@ in the CLI.
## No base image data
There are cases when it's not possible to determine information about the base
images used in your builds. In such cases, the **No outdated base images** and
**No unapproved base images** policies get flagged as having **No data**.
images used in your builds. In such cases, the **Up-to-Date Base Images** and
**Approved Base Images** policies get flagged as having **No data**.
This "no data" state occurs when:

View File

@ -1,36 +1,46 @@
---
title: Configure policies
description: Learn how to configure or disable the default policies in Docker Scout
keywords: scout, policy, configure, disable, enable, parametrize, thresholds
description: Learn how to configure, disable, or delete policies in Docker Scout
keywords: scout, policy, configure, delete, enable, parametrize, thresholds
---
Some of the existing policies are configurable. This means that you can clone
an existing policy and create new, custom policies with your own configuration.
You can also disable a policy altogether, if a policy doesn't quite match your
needs.
Some policy types are configurable. This means that you can create new,
customized version of that policy type with your own configuration parameters.
You can also disable a policy if you need to temporarily disregard it, or
delete a policy altogether if it doesn't match your needs.
## Configure a policy
> [!NOTE]
> Historic evaluation results for the default policy configuration are removed
> if you delete or customize a policy.
To change the configuration of a policy, you must clone one of the existing
default policies, and then save your configuration as a new policy. You can
edit the display name and description of the new policy to help distinguish
it from the default policy it's based on.
## Add a policy
The available configuration parameters for a policy depends on the default
policy you used as a base for your custom policy.
To add a new policy, select the policy type that you want to customize. All
custom policies use a policy type as a base.
To configure a policy:
You can edit the display name and description of the new policy to help
better communicate the compliant and non-compliant states of the policy.
You can not change the name of the policy type, only its display names.
The available configuration parameters for a policy depends on the
policy type that you're editing. For more information, refer to
[Policy types](/manuals/scout/policy/_index.md#policy-types).
To add a policy:
1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
2. Select the policy you want to configure.
3. Select **View policy details** to open the policy side panel.
2. Select the **Add policy** button to open the policy configuration screen.
3. On the policy configuration screen, locate the policy type that you want to
configure, and select **Configure** to open the policy configuration panel.
If this button is grayed out, then the selected policy doesn't have any
configuration parameters.
- If the **Configure** button is grayed out, it means the selected policy
has no configurable parameters.
- If the button reads **Integrate**, it indicates that setup is required
before the policy can be enabled. Selecting **Integrate** will direct you
to the integration's setup guide.
4. In the side panel, select **Copy to customize** to open the policy configuration page.
5. Update the policy parameters.
6. Save the changes:
4. Update the policy parameters.
5. Save the changes:
- Select **Save and enable** to commit the changes and enable the policy for
your current organization.
@ -50,3 +60,21 @@ To disable a policy:
1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
2. Select the policy you want to disable.
3. Select the **Disable** button.
## Delete a policy
When you delete a policy, evaluation results for that policy are deleted as
well, and no longer appear in the Docker Scout Dashboard or in the CLI.
To delete a policy:
1. Go to the [Policies page](https://scout.docker.com/reports/policy) in the Docker Scout Dashboard.
2. Select the policy you want to delete.
3. Select **View policy details**.
4. Select the **Delete** button.
## Recover a deleted policy
If you've deleted a policy, you can recreate it by following the steps in [Add
a policy](#add-a-policy). On the policy configuration screen, select
**Configure** on the deleted policy that you wish to recreate.

View File

@ -14,10 +14,15 @@ suggested actions you can take that improve policy compliance, or that add
metadata to images which enables Docker Scout to provide better evaluation
results and recommendations.
Docker Scout provides remediation advice for the following policies:
Docker Scout provides remediation advice for the default policies of the
following policy types:
- [No outdated base images](#no-outdated-base-image-remediation)
- [Supply chain attestations](#supply-chain-attestations-remediation)
- [Up-to-Date Base Images](#up-to-date-base-images-remediation)
- [Supply Chain Attestations](#supply-chain-attestations-remediation)
<!-- TODO(dvdksn): verify the following -->
> [!NOTE]
> Guided remediation is not supported for custom policies.
For images that violate policy, the recommendations focus on addressing
compliance issues and fixing violations. For images where Docker Scout is
@ -59,9 +64,9 @@ temporary solution.
The side panel may also contain one or more help sections related to the
available recommendations.
## No outdated base image remediation
## Up-to-Date Base Images remediation
The **No outdated base images** policy checks whether the base image you use is
The **Up-to-Date Base Images** policy checks whether the base image you use is
up-to-date. The recommended actions displayed in the remediation side panel
depend on how much information Docker Scout has about your image. The more
information that's available, the better the recommendations.
@ -133,10 +138,10 @@ versions](/manuals/build/building/best-practices.md#pin-base-image-versions).
https://github.com/docker/docs/pull/18961#discussion_r1447189475
-->
## Supply chain attestations remediation
## Supply Chain Attestations remediation
The **Supply chain attestations** policy requires full provenance and SBOM
attestations on images. If your image is missing an attestation, or if an
The default **Supply Chain Attestations** policy requires full provenance and
SBOM attestations on images. If your image is missing an attestation, or if an
attestation doesn't contain enough information, the policy is violated.
The recommendations available in the remediation side panel helps guide you to

View File

@ -52,13 +52,8 @@ along with each policy that contributed to the score.
## Scoring system
Health scores are determined by evaluating images against Docker Scout
[policies](./_index.md). These policies align with best practices for
the software supply chain and are recommended by Docker as foundational
standards for images. Some examples of these policies include:
- **Supply chain attestations**: Images should have supply chain attestations.
- **No outdated base images**: Images should not use outdated base images.
- **No AGPL v3 licenses**: Images should not contain AGPL v3-licensed packages.
[policies](./_index.md). These policies align with best practices for the
software supply chain.
If your image repositories are already enrolled with Docker Scout, the health
score is calculated automatically based on the policies that are enabled for
@ -66,19 +61,21 @@ your organization. This also includes any custom policies that you have
configured.
If you're not using Docker Scout, the health scores show the compliance of your
images with the default, [out-of-the-box policies](/manuals/scout/policy/_index.md#out-of-the-box-policies).
You can enable Docker Scout for your organization to get a more relevant health
score based on your specific policies.
images with the default policies, a set of supply chain rules recommended by
Docker as foundational standards for images. You can enable Docker Scout for
your organization and edit the policy configurations to get a more relevant
health score based on your specific policies.
### Scoring process
Each policy is assigned a points value. If the image is compliant with a
policy, it is awarded the points value for that policy. The health score of an
image is calculated based on the percentage of points achieved relative to the
total possible points.
Each policy is assigned a points value based on its
[type](/manuals/scout/policy/_index.md#policy-types). If the image is compliant
with a policy, it is awarded the points value for that policy type. The health
score of an image is calculated based on the percentage of points achieved
relative to the total possible points.
1. Policy compliance is evaluated for the image.
2. Points are awarded based on adherence to these policies.
2. Points are awarded based on compliance with policies.
3. The points achieved percentage is calculated:
```text
@ -114,18 +111,19 @@ If you see an `N/A` score, consider the following:
### Policy weights
The policies that influence the score, and their respective weights, are as follows:
Different policy types carry varying weights, which impact the score assigned
to an image during evaluation, as shown in the following table.
| Policy | Points |
| -------------------------------------------------------------------------------------------------------------------------- | ------ |
| [No fixable critical or high vulnerabilities](/manuals/scout/policy/_index.md#no-fixable-critical-or-high-vulnerabilities) | 20 |
| [No high-profile vulnerabilities](/manuals/scout/policy/_index.md#no-high-profile-vulnerabilities) | 20 |
| [Supply chain attestations](/manuals/scout/policy/_index.md#supply-chain-attestations) | 15 |
| [No unapproved base images](/manuals/scout/policy/_index.md#no-unapproved-base-images) | 15 |
| [No outdated base images](/manuals/scout/policy/_index.md#no-outdated-base-images) | 10 |
| [SonarQube quality gates passed](/manuals/scout/policy/_index.md#sonarqube-quality-gates-passed) \* | 10 |
| [Default non-root user](/manuals/scout/policy/_index.md#default-non-root-user) | 5 |
| [No AGPL v3 licenses](/manuals/scout/policy/_index.md#no-agpl-v3-licenses) | 5 |
| Policy type | Points |
| -------------------------------------------------------------------------------------------- | ------ |
| [Severity-Based Vulnerability](/manuals/scout/policy/_index.md#severity-based-vulnerability) | 20 |
| [High-Profile Vulnerabilities](/manuals/scout/policy/_index.md#high-profile-vulnerabilities) | 20 |
| [Supply Chain Attestations](/manuals/scout/policy/_index.md#supply-chain-attestations) | 15 |
| [Approved Base Images](/manuals/scout/policy/_index.md#approved-base-images) | 15 |
| [Up-to-Date Base Images](/manuals/scout/policy/_index.md#up-to-date-base-images) | 10 |
| [SonarQube Quality Gates](/manuals/scout/policy/_index.md#sonarqube-quality-gates) \* | 10 |
| [Default Non-Root User](/manuals/scout/policy/_index.md#default-non-root-user) | 5 |
| [Compliant Licenses](/manuals/scout/policy/_index.md#compliant-licenses) | 5 |
\* _This policy is not enabled by default and must be configured by the user._
@ -143,12 +141,13 @@ view of the repository's security status.
### Example
For an image with a total possible score of 90 points:
For an image with a total possible score of 100 points:
- If the image only deviates from one policy (for example, the Copyleft
Licenses policy), it might score 85 out of 90, resulting in a score of A.
- If the image has fixable CVEs and other issues, it might score 65 out of 90,
resulting in a score of B.
- If the image only deviates from one policy, worth 5 points, its score will be
95 out of 100. Since this score is above the 90th percentile, the image
receives an A health score.
- If the image is non-compliant with more policies and scores 65 out of 100, it
receives a C health score, reflecting its lower compliance.
## Improving your health score

View File

@ -155,7 +155,7 @@ $ docker scout config organization <ORG_NAME>
Now you can run the `quickview` command to get an overview
of the compliance status for the image you just built.
The image is evaluated against the default, out-of-the-box policies.
The image is evaluated against the default policy configurations.
```console
$ docker scout quickview
@ -240,7 +240,7 @@ The sidebar shows a compliance overview for the last pushed tag of a repository.
> It might take a few minutes before the results appear if this is your
> first time using the Docker Scout Dashboard.
Inspect the **No outdated base images** policy.
Inspect the **Up-to-Date Base Images** policy.
This policy checks whether base images you use are up-to-date.
It currently has a non-compliant status,
because the example image uses an old version `alpine` as a base image.

View File

@ -8,6 +8,8 @@ aliases:
tags: [Release notes]
---
<!-- vale Docker.We = NO -->
This page contains information about the new features, improvements, known
issues, and bug fixes in Docker Scout releases. These release notes cover the
Docker Scout platform, including the Dashboard. For CLI release notes, refer to
@ -20,6 +22,16 @@ for what's coming next.
New features and enhancements released in the third quarter of 2024.
### 2024-09-30
In this release, we've changed how custom policies work. Before, custom
policies were created by copying an out-of-the-box policy. Now, you can
customize policies either by editing the default policy from a **policy type**
which acts as a template. The default policies in Docker Scout are also
implemented based on these types.
For more information, refer to [policy types](/manuals/scout/policy/_index.md#policy-types).
### 2024-09-09
This release changes how [health scores](/manuals/scout/policy/scores.md) are
@ -42,10 +54,10 @@ The default out-of-the-box policies are now:
- **No high-profile vulnerabilities**
- **No fixable critical or high vulnerabilities**
- **No unapproved base images**
- **Approved Base Images**
- **Default non-root user**
- **Supply chain attestations**
- **No outdated base images**
- **Up-to-Date Base Images**
- **No AGPL v3 licenses**
The configurations for these policies are now the same as the configurations
@ -114,14 +126,11 @@ For more information and setup instructions, see
### 2024-01-23
New **No unapproved base images** policy, which lets you restrict which base
New **Approved Base Images** policy, which lets you restrict which base
images you allow in your builds. You define the allowed base images using a
pattern. Base images whose image reference don't match the specified patterns
cause the policy to fail.
For more information, see
[No unapproved base images](/scout/policy/#no-unapproved-base-images).
### 2024-01-12
New **Default non-root user** policy, which flags images that would run as the
@ -129,8 +138,6 @@ New **Default non-root user** policy, which flags images that would run as the
Specifying a non-root default user for your images can help strengthen your
runtime security.
For more information, see [Default non-root user](/scout/policy/#default-non-root-user).
### 2024-01-11
[Beta](../../release-lifecycle.md#beta) launch of a new GitHub app for integrating
@ -176,11 +183,6 @@ gates as a policy evaluation in Docker Scout. Enable the integration, push your
images, and see the SonarQube quality gate conditions surfaced in the new
**SonarQube quality gates passed** policy.
For more information, see:
- [Integration and setup instructions](../integrations/code-quality/sonarqube.md)
- [SonarQube quality gates passed policy](/scout/policy/#sonarqube-quality-gates-passed)
### 2023-12-01
[Beta](../../release-lifecycle.md#beta) release of a new **Azure Container
@ -210,17 +212,11 @@ images are built with SBOM and provenance attestations. Adding attestations to
images is a good first step in improving your supply chain conduct, and is
often a prerequisite for doing more.
See [Supply chain attestations policy](/scout/policy/#supply-chain-attestations)
for details.
### 2023-11-01
New **No high-profile vulnerabilities** policy, which ensures your artifacts are
free from a curated list of vulnerabilities widely recognized to be risky.
For more information, see
[No high-profile vulnerabilities policy](/scout/policy/#no-high-profile-vulnerabilities).
### 2023-10-04
This marks the General Availability (GA) release of Docker Scout.

View File

@ -126,21 +126,21 @@
- /go/scout-dashboard/
"/scout/policy/":
- /go/scout-policy/
"/scout/policy/#no-fixable-critical-or-high-vulnerabilities":
"/scout/policy/#severity-based-vulnerability":
- /go/scout-policy-dsp001/
"/scout/policy/#no-agpl-v3-licenses":
"/scout/policy/#compliant-licenses":
- /go/scout-policy-dsp002/
"/scout/policy/#no-outdated-base-images":
"/scout/policy/#up-to-date-base-images":
- /go/scout-policy-dsp003/
"/scout/policy/#no-high-profile-vulnerabilities":
"/scout/policy/#high-profile-vulnerabilities":
- /go/scout-policy-dsp004/
"/scout/policy/#supply-chain-attestations":
- /go/scout-policy-dsp005/
"/scout/policy/#default-non-root-user":
- /go/scout-policy-dsp006/
"/scout/policy/#no-unapproved-base-images":
"/scout/policy/#approved-base-images":
- /go/scout-policy-dsp007/
"/scout/policy/#sonarqube-quality-gates-passed":
"/scout/policy/#sonarqube-quality-gates":
- /go/scout-policy-dsp008/
"/scout/policy/configure/":
- /go/scout-configure-policy/
@ -287,4 +287,4 @@
"/admin/organization/insights/#docker-hub-images":
- /go/insights-images/
"/admin/organization/insights/#extensions":
- /go/insights-extensions/
- /go/insights-extensions/