mirror of https://github.com/docker/docs.git
scout: add docs for docker scout hub and cli
- add: new docker scout section - add: advanced image analysis - add: scout artifactory integration - add: image details view - add: docker scout cli reference - change: hub vulnerability scanning - change: security best practices (previously /develop/scan-images) - change: prune references to docker scan - deprecate: docker scan - remove: atomist section
This commit is contained in:
David Karlsson
parent
618b9c0933
commit
c0402932ca
|
|
@ -1,4 +1,5 @@
|
|||
APIs?
|
||||
CVEs?
|
||||
DHCP
|
||||
DNS
|
||||
Ethernet
|
||||
|
|
@ -11,6 +12,7 @@ IPv[46]
|
|||
IPvlan
|
||||
MAC
|
||||
RPM
|
||||
SARIF
|
||||
SDKs?
|
||||
SSO
|
||||
TCP
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
command: docker scout
|
||||
short: Command line tool for Docker Scout
|
||||
long: Command line tool for Docker Scout
|
||||
usage: docker scout [command]
|
||||
pname: docker
|
||||
plink: docker.yaml
|
||||
cname:
|
||||
- docker scout cves
|
||||
- docker scout version
|
||||
clink:
|
||||
- docker_scout_cves.yaml
|
||||
- docker_scout_version.yaml
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -0,0 +1,225 @@
|
|||
command: docker scout cves
|
||||
short: Display CVEs identified in a software artifact
|
||||
long: |-
|
||||
The `docker scout cves` command analyzes a software artifact for vulnerabilities.
|
||||
The following artifact types are supported:
|
||||
|
||||
- Images
|
||||
- OCI layout directories
|
||||
- Tarball archives, as created by `docker save`
|
||||
|
||||
The tool analyzes the provided software artifact, and generates a vulnerability report.
|
||||
|
||||
By default, the tool expects an image reference, such as:
|
||||
|
||||
- `redis`
|
||||
- `curlimages/curl:7.87.0`
|
||||
- `mcr.microsoft.com/dotnet/runtime:7.0`
|
||||
|
||||
If the artifact you want to analyze is an OCI directory or a tarball archive, you must use the `--type` flag.
|
||||
usage: docker scout cves [OPTIONS] IMAGE|DIRECTORY|ARCHIVE
|
||||
pname: docker scout
|
||||
plink: docker_scout.yaml
|
||||
options:
|
||||
- option: debug
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Debug messages
|
||||
deprecated: false
|
||||
hidden: true
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: details
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Print details on default text output
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: exit-code
|
||||
shorthand: e
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Return exit code '2' if vulnerabilities are detected
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: format
|
||||
value_type: string
|
||||
default_value: txt-by-packages
|
||||
description: |-
|
||||
Output format of the generated vulnerability report:
|
||||
- packages: default output, plain text with vulnerabilities grouped by packages
|
||||
- sarif: json Sarif output
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: ignore-base
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Filter out CVEs introduced from base image
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: only-cve-id
|
||||
value_type: stringSlice
|
||||
default_value: '[]'
|
||||
description: |
|
||||
Comma separated list of CVE ids (like CVE-2021-45105) to search for
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: only-fixed
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Filter to fixable CVEs
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: only-package-type
|
||||
value_type: stringSlice
|
||||
default_value: '[]'
|
||||
description: |
|
||||
Comma separated list of package types (like apk, deb, rpm, npm, pypi, golang, etc)
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: only-severity
|
||||
value_type: stringSlice
|
||||
default_value: '[]'
|
||||
description: |
|
||||
Comma separated list of severities (critical, high, medium, low) to filter CVEs by
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: only-unfixed
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Filter to unfixed CVEs
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: output
|
||||
shorthand: o
|
||||
value_type: string
|
||||
description: Write the report to a file.
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: platform
|
||||
value_type: string
|
||||
description: Platform of image for which to list CVEs for
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: ref
|
||||
value_type: string
|
||||
description: |-
|
||||
Reference to use if the provided tarball contains multiple references.
|
||||
Can only be used with --type archive.
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: type
|
||||
value_type: string
|
||||
default_value: image
|
||||
description: |-
|
||||
Type of the image to analyze. Can be one of:
|
||||
- image
|
||||
- oci-dir
|
||||
- archive (docker save tarball)
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
examples: |-
|
||||
### Display vulnerabilities grouped by package
|
||||
|
||||
```console
|
||||
$ docker scout cves alpine
|
||||
Analyzing image alpine
|
||||
✓ Image stored for indexing
|
||||
✓ Indexed 18 packages
|
||||
✓ No vulnerable package detected
|
||||
```
|
||||
|
||||
### Display vulnerabilities from a `docker save` tarball
|
||||
|
||||
```console
|
||||
$ docker save alpine > alpine.tar
|
||||
|
||||
$ docker scout cves --type archive alpine.tar
|
||||
Analyzing archive alpine.tar
|
||||
✓ Archive read
|
||||
✓ SBOM of image already cached, 18 packages indexed
|
||||
✓ No vulnerable package detected
|
||||
```
|
||||
|
||||
### Display vulnerabilities from an OCI directory
|
||||
|
||||
```console
|
||||
$ skopeo copy --override-os linux docker://alpine oci:alpine
|
||||
|
||||
$ docker scout cves --type oci-dir alpine
|
||||
Analyzing OCI directory alpine
|
||||
✓ OCI directory read
|
||||
✓ Image stored for indexing
|
||||
✓ Indexed 19 packages
|
||||
✓ No vulnerable package detected
|
||||
```
|
||||
|
||||
### Export vulnerabilities to a SARIF JSON file
|
||||
|
||||
```console
|
||||
$ docker scout cves --format sarif --output alpine.sarif.json alpine
|
||||
Analyzing image alpine
|
||||
✓ SBOM of image already cached, 18 packages indexed
|
||||
✓ No vulnerable package detected
|
||||
✓ Report written to alpine.sarif.json
|
||||
```
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
command: docker scout version
|
||||
short: Show Docker Scout version information
|
||||
long: Show Docker Scout version information
|
||||
usage: docker scout version
|
||||
pname: docker scout
|
||||
plink: docker_scout.yaml
|
||||
examples: |-
|
||||
```console
|
||||
$ docker scout version
|
||||
version: v0.2.2 (go1.19.5 - darwin/arm64)
|
||||
git commit: c15f374b9a39d993da2e8a1db7edc4be4f7c0c1e
|
||||
```
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
@ -136,13 +136,11 @@ guides:
|
|||
- path: /develop/
|
||||
title: Overview
|
||||
- path: /develop/dev-best-practices/
|
||||
title: Best practices
|
||||
- sectiontitle: Build images
|
||||
section:
|
||||
- path: /develop/develop-images/dockerfile_best-practices/
|
||||
title: Dockerfile best practices
|
||||
- path: /develop/scan-images/
|
||||
title: Scan images
|
||||
title: Development best practices
|
||||
- path: /develop/develop-images/dockerfile_best-practices/
|
||||
title: Dockerfile best practices
|
||||
- path: /develop/security-best-practices/
|
||||
title: Security best practices
|
||||
- sectiontitle: Deploy your app to the cloud
|
||||
section:
|
||||
- path: /cloud/aci-integration/
|
||||
|
|
@ -605,6 +603,14 @@ reference:
|
|||
title: docker run
|
||||
- path: /engine/reference/commandline/save/
|
||||
title: docker save
|
||||
- sectiontitle: docker scout
|
||||
section:
|
||||
- path: /engine/reference/commandline/scout/
|
||||
title: docker scout
|
||||
- path: /engine/reference/commandline/scout_cves/
|
||||
title: docker scout cves
|
||||
- path: /engine/reference/commandline/scout_version/
|
||||
title: docker scout version
|
||||
- path: /engine/reference/commandline/search/
|
||||
title: docker search
|
||||
- sectiontitle: docker secret
|
||||
|
|
@ -1796,6 +1802,17 @@ manuals:
|
|||
- path: /docker-hub/release-notes/
|
||||
title: Release notes
|
||||
|
||||
- sectiontitle: Docker Scout (Early Access)
|
||||
section:
|
||||
- path: /scout/
|
||||
title: Overview
|
||||
- path: /scout/image-details-view/
|
||||
title: Image details view
|
||||
- path: /scout/advanced-image-analysis/
|
||||
title: Advanced image analysis
|
||||
- path: /scout/artifactory/
|
||||
title: Artifactory integration
|
||||
|
||||
- sectiontitle: Docker subscription
|
||||
section:
|
||||
- path: /subscription/
|
||||
|
|
@ -1865,31 +1882,9 @@ manuals:
|
|||
- path: /docker-hub/image-access-management/
|
||||
title: Image Access Management
|
||||
|
||||
|
||||
- title: Security announcements
|
||||
path: /security/
|
||||
|
||||
- sectiontitle: Atomist
|
||||
section:
|
||||
- path: /atomist/
|
||||
title: Introduction
|
||||
- path: /atomist/try-atomist/
|
||||
title: Try Atomist
|
||||
- path: /atomist/get-started/
|
||||
title: Get started
|
||||
- sectiontitle: Configure
|
||||
section:
|
||||
- path: /atomist/configure/settings/
|
||||
title: Settings
|
||||
- path: /atomist/configure/advisories/
|
||||
title: Advisories
|
||||
- sectiontitle: Integrate
|
||||
section:
|
||||
- path: /atomist/integrate/github/
|
||||
title: GitHub
|
||||
- path: /atomist/integrate/deploys/
|
||||
title: Track deployments
|
||||
|
||||
- sectiontitle: Open-source projects
|
||||
section:
|
||||
- sectiontitle: Docker Registry
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
> **Note**
|
||||
>
|
||||
> Atomist is currently in [Early Access](/release-lifecycle#early-access-ea).
|
||||
> Features and APIs are subject to change.
|
||||
|
|
@ -553,3 +553,9 @@
|
|||
# feedback
|
||||
"https://docs.google.com/forms/d/e/1FAIpQLSenjK8KiBiOrwCpq06u_iVEZGv4tfTEpfmY_cQDmsqJrHL9Gw/viewform":
|
||||
- /feedback/extension/
|
||||
|
||||
# Docker Scout
|
||||
"/scout/":
|
||||
- /go/scout/
|
||||
"/scout/artifactory":
|
||||
- /go/scout-artifactory/
|
||||
|
|
|
|||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
title: Advisory sources
|
||||
description: Add and remove vulnerability advisories
|
||||
keywords: >
|
||||
advisories, vulnerabilities, databases, open source, configure, security,
|
||||
atomist
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
With no configuration required, Atomist already draws vulnerability data from
|
||||
several public advisories. You can extend this by adding your own, custom
|
||||
advisories if you wish.
|
||||
|
||||
## Adding and updating advisories
|
||||
|
||||
To add your own advisories:
|
||||
|
||||
1. Create a repository called `atomist-advisories` in the GitHub account where
|
||||
you've installed the Atomist GitHub app.
|
||||
|
||||
2. In the default branch of the repository, add a new JSON file called
|
||||
`<source>/<source id>.json`, where:
|
||||
|
||||
- `source` should be the name of your company
|
||||
- `source-id` has to be a unique id for the advisory within `source`.
|
||||
|
||||
3. The JSON file must follow the schema defined in
|
||||
[Open Source Vulnerability format](https://ossf.github.io/osv-schema/){:
|
||||
target="blank" rel="noopener" class=""}.
|
||||
|
||||
Refer to the
|
||||
[GitHub Advisory Database](https://github.com/github/advisory-database/tree/main/advisories/github-reviewed){:
|
||||
target="blank" rel="noopener" class=""} for examples of advisories.
|
||||
|
||||
## Deleting advisories
|
||||
|
||||
Delete an advisory from the database by removing the corresponding JSON advisory
|
||||
file from the `atomist-advisories` repository.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Atomist only considers additions, changes and removals of JSON advisory files
|
||||
> in the repository's **default branch**.
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
title: Settings
|
||||
description:
|
||||
keywords: settings, configure, vulnerabilities, base images, atomist
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
This page describes the configurable settings for Atomist. Enabling any of these
|
||||
settings instructs Atomist to carry out an action whenever a specific Git event
|
||||
occurs. These features require that you
|
||||
[install the Atomist GitHub app](/atomist/integrate/github/#connect-to-github){:
|
||||
target="blank" rel="noopener" class=""} in your GitHub organization.
|
||||
|
||||
To view and manage these settings, go to the
|
||||
[settings page](https://dso.docker.com/r/auth/policies){: target="blank"
|
||||
rel="noopener" class=""} on the Atomist website.
|
||||
|
||||
## New image vulnerabilities
|
||||
|
||||
Extract software bill of material from container images, and match packages with
|
||||
data from vulnerability advisories. Identify when new vulnerabilities get
|
||||
introduced, and display them as GitHub status check on the pull request that
|
||||
introduces them.
|
||||
|
||||
## Base image tags
|
||||
|
||||
Pin base image tags to digests in Dockerfiles, and check for supported tags on
|
||||
Docker official images. Automatically creates a pull request pinning the
|
||||
Dockerfile to the latest digest for the base image tag used.
|
||||
|
|
@ -1,439 +0,0 @@
|
|||
---
|
||||
title: Get started
|
||||
description: Getting started with Atomist
|
||||
keywords: atomist, software supply chain, vulnerability scanning, tutorial
|
||||
toc_max: 2
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
To get started with Atomist, you'll need to:
|
||||
|
||||
- Connect Atomist with your container registry
|
||||
- Link your container images with their Git source
|
||||
|
||||
Before you can begin the setup, you need a Docker ID. If you don't already have
|
||||
one, you can [register here](https://hub.docker.com/signup){: target="blank"
|
||||
rel="noopener" class=""}.
|
||||
|
||||
## Connect container registry
|
||||
|
||||
This section describes how to integrate Atomist with your container registry.
|
||||
Follow the applicable instructions depending on the type of container registry
|
||||
you use. After completing this setup, Atomist will have read-only access to your
|
||||
registry, and gets notified about pushed or deleted images.
|
||||
|
||||
> Using Docker Hub? 🐳
|
||||
>
|
||||
> If you are using Docker Hub as your container registry, you can skip this step
|
||||
> and go straight to
|
||||
> [linking images to Git source](#link-images-to-git-repository). Atomist
|
||||
> integrates seamlessly with your Docker Hub organizations.
|
||||
|
||||
<!-- vale off -->
|
||||
<ul class="nav nav-tabs">
|
||||
<li class="active"><a data-toggle="tab" data-target="#tab-ecr" aria-expanded="true">Amazon</a></li>
|
||||
<li><a data-toggle="tab" data-target="#tab-ghcr">GitHub</a></li>
|
||||
<li><a data-toggle="tab" data-target="#tab-google">Google</a></li>
|
||||
<li><a data-toggle="tab" data-target="#tab-jfrog">JFrog</a></li>
|
||||
</ul>
|
||||
<!-- vale on -->
|
||||
<div class="tab-content"><br>
|
||||
<div id="tab-ecr" class="tab-pane fade in active" markdown="1">
|
||||
<!-- ECR -->
|
||||
|
||||
When setting up an Amazon Elastic Container Registry (ECR) integration with
|
||||
Atomist, the following AWS resources are required:
|
||||
|
||||
- Read-only Identity Access Management (IAM) role, for Atomist to be able to
|
||||
access the container registry
|
||||
- Amazon EventBridge, to notify Atomist of pushed and deleted images
|
||||
|
||||
This procedure uses pre-defined CloudFormation templates to create the necessary
|
||||
IAM role and Amazon EventBridge. This template protects you from
|
||||
[confused deputy attacks](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html){:
|
||||
target="blank" rel="noopener" class=""} by ensuring a unique `ExternalId`, along
|
||||
with the appropriate condition on the IAM role statement.
|
||||
|
||||
1. Go to <https://dso.docker.com> and sign in using your Docker ID credentials.
|
||||
2. Navigate to the **Integrations** tab and select **Configure** next to the
|
||||
**Elastic Container Registry** integration.
|
||||
3. Fill out all the fields, except **Trusted Role ARN**. The trusted role
|
||||
identity is known only after applying the CloudFormation template.
|
||||
|
||||
Choose basic auth credentials to protect the endpoint that AWS uses to notify
|
||||
Atomist. The URL and the basic auth credentials are parameters to the
|
||||
CloudFormation template.
|
||||
|
||||
4. Now create the CloudFormation stack. Before creating the stack, AWS asks you
|
||||
to enter three parameters.
|
||||
|
||||
- `Url`: the API endpoint copied from Atomist
|
||||
- `Username`, `Password`: basic authentication credentials for the endpoint.
|
||||
Must match what you entered in the Atomist workspace.
|
||||
|
||||
Use the following **Launch Stack** buttons to start reviewing the details in
|
||||
your AWS account.
|
||||
|
||||
> Note
|
||||
>
|
||||
> Before creating the stack, AWS will ask for acknowledgement that creating
|
||||
> this stack requires a capability. This stack creates a role that will grant
|
||||
> Atomist read-only access to ECR resources.
|
||||
>
|
||||
> 
|
||||
|
||||
<div style="text-align: center">
|
||||
<table>
|
||||
<tr>
|
||||
<th>Region</th>
|
||||
<th>ecr-integration.template</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>us-east-1</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-us-east-1/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>us-east-2</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-us-east-2/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>us-west-1</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=us-west-1#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-us-west-1/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>us-west-2</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=us-west-2#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-us-west-2/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>eu-west-1</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=eu-west-1#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-eu-west-1/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>eu-west-2</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=eu-west-2#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-eu-west-2/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>eu-west-3</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=eu-west-3#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-eu-west-3/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>eu-central-1</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=eu-central-1#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-eu-central-1/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>ca-central-1</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=ca-central-1#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-ca-central-1/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>ap-southeast-2</th>
|
||||
<td>
|
||||
<a target="blank" rel="noopener" href="https://console.aws.amazon.com/cloudformation/home?region=ap-southeast-2#/stacks/new?stackName=atomist-public-templates-ecr-integration&templateURL=https://s3.amazonaws.com/atomist-ap-southeast-2/atomist-public-templates/latest/ecr-integration.template">
|
||||
<img alt="Launch Stack" src="https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
5. After creating the stack, copy the **Value** for the **AssumeRoleArn** key
|
||||
from the **Outputs** tab in AWS.
|
||||
|
||||
{: width="700px"}
|
||||
|
||||
6. Paste the copied **AssumeRoleArn** value into the **Trusted Role ARN** field
|
||||
on the Atomist configuration page.
|
||||
|
||||
7. Select **Save Configuration**.
|
||||
|
||||
Atomist tests the connection with your ECR registry. A green check mark
|
||||
displays beside the integration if a successful connection is made.
|
||||
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
</div>
|
||||
<div id="tab-ghcr" class="tab-pane fade" markdown="1">
|
||||
<!-- GitHub Container Registry -->
|
||||
|
||||
To integrate Atomist with GitHub Container Registry, connect your GitHub
|
||||
account, and enter a personal access token for Atomist to use when pulling
|
||||
container images.
|
||||
|
||||
1. Go to <https://dso.docker.com> and sign in using your Docker ID credentials.
|
||||
2. Connect your GitHub account as instructed in the
|
||||
[GitHub app page](./integrate/github.md#connect-to-github).
|
||||
3. Open the **Integrations** tab, and select **Configure** next to the **GitHub
|
||||
Container Registry** in the list.
|
||||
4. Fill out the fields and select **Save Configuration**.
|
||||
|
||||
Atomist requires the **Personal access token** for connecting images to
|
||||
private repositories. The token must have the
|
||||
[`read:packages` scope](https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages){:
|
||||
target="blank" rel="noopener" class=""}.
|
||||
|
||||
Leave the **Personal access token** field blank if you only want to index
|
||||
images in public repositories.
|
||||
|
||||
</div>
|
||||
<div id="tab-google" class="tab-pane fade" markdown="1">
|
||||
<!-- Google -->
|
||||
|
||||
Setting up an Atomist integration with Google Container Registry and Google
|
||||
Artifact Registry involves:
|
||||
|
||||
- Creating a service account and grant it a read-only access role.
|
||||
- Creating a PubSub subscription on the `gcr` topic to watch for activity in the
|
||||
registry.
|
||||
|
||||
To complete the following procedure requires administrator's permissions in the
|
||||
project.
|
||||
|
||||
1. Set the following environment variables. You will use them in the next steps
|
||||
when configuring the Google Cloud resources, using the `gcloud` CLI.
|
||||
|
||||
```bash
|
||||
export SERVICE_ACCOUNT_ID="atomist-integration" # can be anything you like
|
||||
export PROJECT_ID="YOUR_GCP_PROJECT_ID"
|
||||
```
|
||||
|
||||
2. Create the service account.
|
||||
|
||||
```bash
|
||||
gcloud iam service-accounts create ${SERVICE_ACCOUNT_ID} \
|
||||
--project ${PROJECT_ID} \
|
||||
--description="Atomist Integration Service Account" \
|
||||
--display-name="Atomist Integration"
|
||||
```
|
||||
|
||||
3. Grant the service account read-only access to the artifact registry.
|
||||
|
||||
The role name differs depending on whether you use Artifact Registry or
|
||||
Container Registry:
|
||||
|
||||
- `roles/artifactregistry.reader` for Google Artifact Registry
|
||||
- `roles/object.storageViewer` for Google Container Registry
|
||||
|
||||
```bash
|
||||
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
|
||||
--project ${PROJECT_ID} \
|
||||
--member="serviceAccount:${SERVICE_ACCOUNT_ID}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
--role="roles/artifactregistry.reader" # change this if you use GCR
|
||||
```
|
||||
|
||||
4. Grant service account access to Atomist.
|
||||
|
||||
```bash
|
||||
gcloud iam service-accounts add-iam-policy-binding "${SERVICE_ACCOUNT_ID}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
--project ${PROJECT_ID} \
|
||||
--member="serviceAccount:atomist-bot@atomist.iam.gserviceaccount.com" \
|
||||
--role="roles/iam.serviceAccountTokenCreator"
|
||||
```
|
||||
|
||||
5. Go to [dso.docker.com](https://dso.docker.com){: target="blank"
|
||||
rel="noopener" class=""} and sign in with your Docker ID credentials.
|
||||
6. Navigate to the **Integrations** tab and select **Configure** next to the
|
||||
**Google Artifact Registry** integration.
|
||||
7. Fill out the following fields:
|
||||
|
||||
- **Project ID** is the `PROJECT_ID` used in earlier steps.
|
||||
- **Service Account**: The email address of the service account created
|
||||
step 2.
|
||||
|
||||
8. Select **Save Configuration**. Atomist will test the connection. Green check
|
||||
marks indicate a successful connection.
|
||||
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
Next, create a new PubSub subscription on the `gcr` topic in registry. This
|
||||
subscription notifies Atomist about new or deleted images in the registry.
|
||||
|
||||
9. Copy the URL in the **Events Webhook** field to your clipboard. This will be
|
||||
the `PUSH_ENDPOINT_URI` for the PubSub subscription.
|
||||
|
||||
10. Define the following three variable values, in addition to the `PROJECT_ID`
|
||||
and `SERVICE_ACCOUNT_ID` from earlier:
|
||||
|
||||
- `PUSH_ENDPOINT_URL`: the webhook URL copied from the Atomist workspace.
|
||||
- `SERVICE_ACCOUNT_EMAIL`: the service account address; a combination of the
|
||||
service account ID and project ID.
|
||||
- `SUBSCRIPTION`: the name of the PubSub (can be anything).
|
||||
|
||||
```bash
|
||||
PUSH_ENDPOINT_URI={COPY_THIS_FROM_ATOMIST}
|
||||
SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_ID}@${PROJECT_ID}.iam.gserviceaccount.com"
|
||||
SUBSCRIPTION="atomist-integration-subscription"
|
||||
```
|
||||
|
||||
11. Create the PubSub for the `gcr` topic.
|
||||
|
||||
```bash
|
||||
gcloud pubsub subscriptions create ${SUBSCRIPTION} \
|
||||
--topic='gcr' \
|
||||
--push-auth-token-audience='atomist' \
|
||||
--push-auth-service-account="${SERVICE_ACCOUNT_EMAIL}" \
|
||||
--push-endpoint="${PUSH_ENDPOINT_URI}"
|
||||
```
|
||||
|
||||
When the first image push is successfully detected, a green check mark on the
|
||||
integration page will indicate that the integration works.
|
||||
|
||||
</div>
|
||||
<div id="tab-jfrog" class="tab-pane fade" markdown="1">
|
||||
<!-- JFrog Artifactory -->
|
||||
|
||||
Atomist can index images in a JFrog Artifactory repository by means of a
|
||||
monitoring agent.
|
||||
|
||||
The agent scans configured repositories at regular intervals, and send newly
|
||||
discovered images' metadata to the Atomist data plane.
|
||||
|
||||
In the following example, `https://hal9000.atomist.com` is a private registry
|
||||
only visible on an internal network.
|
||||
|
||||
```
|
||||
docker run -ti atomist/docker-registry-broker:latest\
|
||||
index-image remote \
|
||||
--workspace AQ1K5FIKA \
|
||||
--api-key team::6016307E4DF885EAE0579AACC71D3507BB38E1855903850CF5D0D91C5C8C6DC0 \
|
||||
--artifactory-url https://hal9000.docker.com \
|
||||
--artifactory-repository atomist-docker-local \
|
||||
--container-registry-host atomist-docker-local.hal9000.docker.com
|
||||
--username admin \
|
||||
--password password
|
||||
```
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------------- | --------------------------------------------------------------------------------------------------------------- |
|
||||
| `workspace` | ID of your Atomist workspace. |
|
||||
| `api-key` | Atomist API key. |
|
||||
| `artifactory-url` | Base URL of the Artifactory instance. Must not contain trailing slashes. |
|
||||
| `artifactory-repository` | The name of the container registry to watch. |
|
||||
| `container-registry-host` | The hostname associated with the Artifactory repository containing images, if different from `artifactory-url`. |
|
||||
| `username` | Username for HTTP basic authentication with Artifactory. |
|
||||
| `password` | Password for HTTP basic authentication with Artifactory. |
|
||||
|
||||
</div>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
## Link images to Git repository
|
||||
|
||||
Knowing the source repository of an image is a prerequisite for Atomist to
|
||||
interact with the Git repository. For Atomist to be able to link scanned images
|
||||
back to a Git repository repository, you must annotate the image at build time.
|
||||
|
||||
The image labels that Atomist requires are:
|
||||
|
||||
| Label | Value |
|
||||
| ------------------------------------ | ------------------------------------------------- |
|
||||
| `org.opencontainers.image.revision` | The commit revision that the image is built for. |
|
||||
| `com.docker.image.source.entrypoint` | Path to the Dockerfile, relative to project root. |
|
||||
|
||||
For more information about pre-defined OCI annotations, see the
|
||||
[specification document on GitHub](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys){:
|
||||
target="blank" rel="noopener" class=""}.
|
||||
|
||||
You can add these labels to images using the built-in Git provenance feature of
|
||||
Buildx, or set using the `--label` CLI argument.
|
||||
|
||||
### Add labels using Docker Buildx
|
||||
|
||||
> Beta
|
||||
>
|
||||
> Git provenance labels in Buildx is a [Beta](/release-lifecycle#beta) feature.
|
||||
|
||||
To add the image labels using Docker Buildx, set the environment variable
|
||||
`BUILDX_GIT_LABELS=1`. The Buildx will create the labels automatically when
|
||||
building the image.
|
||||
|
||||
```bash
|
||||
export BUILDX_GIT_LABELS=1
|
||||
docker buildx build . -f docker/Dockerfile
|
||||
```
|
||||
|
||||
### Add labels using the label CLI argument
|
||||
|
||||
Assign image labels using the `--label` argument for `docker build`.
|
||||
|
||||
```bash
|
||||
docker build . -f docker/Dockerfile -t $IMAGE_NAME \
|
||||
--label "org.opencontainers.image.revision=10ac8f8bdaa343677f2f394f9615e521188d736a" \
|
||||
--label "com.docker.image.source.entrypoint=docker/Dockerfile"
|
||||
```
|
||||
|
||||
Images built in a CI/CD environment can leverage the built-in environment
|
||||
variables when setting the Git revision label:
|
||||
|
||||
| Build tool | Environment variable |
|
||||
| ----------------------------- | ---------------------------------------------------------------- |
|
||||
| GitHub Actions | {% raw %}`${{ github.sha }}`{% endraw %} |
|
||||
| GitHub Actions, pull requests | {% raw %}`${{ github.event.pull_request.head.sha }}`{% endraw %} |
|
||||
| GitLab CI/CD | `$CI_COMMIT_SHA` |
|
||||
| Docker Hub automated builds | `$SOURCE_COMMIT` |
|
||||
| Google Cloud Build | `$COMMIT_SHA` |
|
||||
| AWS CodeBuild | `$CODEBUILD_RESOLVED_SOURCE_VERSION` |
|
||||
| Manually | `$(git rev-parse HEAD)` |
|
||||
|
||||
Consult the documentation for your CI/CD platform to learn which variables to
|
||||
use.
|
||||
|
||||
## Where to go next
|
||||
|
||||
Atomist is now tracking bill of materials, packages, and vulnerabilities for
|
||||
your images! You can view your image scan results on the
|
||||
[images overview page](https://dso.docker.com/r/auth/overview/images){:
|
||||
target="blank" rel="noopener" class=""}.
|
||||
|
||||
Teams use Atomist to protect downstream workloads from new vulnerabilities. It's
|
||||
also used to help teams track and remediate new vulnerabilities that impact
|
||||
existing workloads. The following sections describe integrate and configure
|
||||
Atomist further. For example, to gain visibility into container workload systems
|
||||
like Kubernetes.
|
||||
|
||||
- Connect Atomist with your GitHub repositories by
|
||||
[installing the Atomist app](integrate/github.md) for your GitHub
|
||||
organization.
|
||||
- Manage which Atomist features you use in [settings](configure/settings.md).
|
||||
- Learn about [deployment tracking](integrate/deploys.md) and how Atomist can
|
||||
help watch your deployed containers.
|
||||
- Atomist watches for new advisories from public sources, but you can also
|
||||
[add your own internal advisories](configure/advisories.md) for more
|
||||
information.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 387 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 370 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 871 KiB |
|
|
@ -1,43 +0,0 @@
|
|||
---
|
||||
title: Introduction to Atomist
|
||||
description: Introduction to Atomist
|
||||
keywords:
|
||||
atomist, software supply chain, indexing, sbom, vulnerabilities, automation
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
Atomist is a data and automation platform for managing the software supply
|
||||
chain. It extracts metadata from container images, evaluates the data, and helps
|
||||
you understand the state of the image.
|
||||
|
||||
Integrating Atomist into your systems and repositories grants you essential
|
||||
information about the images you build, and the containers running in
|
||||
production. Beyond collecting and visualizing information, Atomist can help you
|
||||
further by giving you recommendations, notifications, validation, and more.
|
||||
|
||||
Example capabilities made possible with Atomist are:
|
||||
|
||||
- Stay up to date with advisory databases without having to re-analyze your
|
||||
images.
|
||||
- Automatically open pull requests to update base images for improved product
|
||||
security.
|
||||
- Check that your applications don't contain secrets, such as a password or API
|
||||
token, before they get deployed.
|
||||
- Dissect Dockerfiles and see where vulnerabilities come from, line by line.
|
||||
|
||||
## How it works
|
||||
|
||||
Atomist monitors your container registry for new images. When it finds a new
|
||||
image, it analyzes and extracts metadata about the image contents and any base
|
||||
images used. The metadata is uploaded to an isolated partition in the Atomist
|
||||
data plane where it's securely stored.
|
||||
|
||||
The Atomist data plane is a combination of metadata and a large knowledge graph
|
||||
of public software and vulnerability data. Atomist determines the state of your
|
||||
container by overlaying the image metadata with the knowledge graph.
|
||||
|
||||
## What's next?
|
||||
|
||||
Head over to the [try atomist](./try-atomist.md) page for instructions on how to
|
||||
run Atomist, locally and with no strings attached.
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
---
|
||||
title: Track deployments
|
||||
description: >
|
||||
Deployment tracking lets Atomist compare your image builds with what's running
|
||||
in your environments.
|
||||
keywords: deployment, kubernetes, security
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
By integrating Atomist with a runtime environment, you can track vulnerabilities
|
||||
for deployed containers. This gives you contexts for whether security debt is
|
||||
increasing or decreasing.
|
||||
|
||||
There are several options for how you could implement deployment tracking:
|
||||
|
||||
- Invoking the API directly
|
||||
- Adding it as a step in your continuous deployment pipeline
|
||||
- Creating Kubernetes admission controllers
|
||||
|
||||
## API
|
||||
|
||||
Each Atomist workspace exposes an API endpoint. Submitting a POST request to the
|
||||
endpoint updates Atomist about what image you are running in your environments.
|
||||
This lets you compare data for images you build against images of containers
|
||||
running in staging or production.
|
||||
|
||||
You can find the API endpoint URL on the **Integrations** page. Using this API
|
||||
requires an API key.
|
||||
|
||||
The most straight-forward use is to post to this endpoint using a webhook. When
|
||||
deploying a new image, submit an automated POST request (using `curl`, for
|
||||
example) as part of your deployment pipeline.
|
||||
|
||||
```bash
|
||||
$ curl <api-endpoint-url> \\
|
||||
-X POST \\
|
||||
-H "Content-Type: application/json" \\
|
||||
-H "Authorization: Bearer <api-token>" \\
|
||||
-d '{"image": {"url": "<image-url>@<sha256-digest>"}}'
|
||||
```
|
||||
|
||||
### Parameters
|
||||
|
||||
The API supports the following parameters in the request body:
|
||||
|
||||
```json
|
||||
{
|
||||
"image": {
|
||||
"url": "string",
|
||||
"name": "string"
|
||||
},
|
||||
"environment": {
|
||||
"name": "string"
|
||||
},
|
||||
"platform": {
|
||||
"os": "string",
|
||||
"architecture": "string",
|
||||
"variant": "string"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| Parameter | Mandatory | Default | Description |
|
||||
| ----------------------- | :-------: | ---------- | ------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `image.url` | Yes | | Fully qualified reference name of the image, plus version (digest). You **must** specify the image version by digest. |
|
||||
| `image.name` | No | | Optional identifier. If you deploy many containers from the same image in any one environment, each instance must have a unique name. |
|
||||
| `environment.name` | No | `deployed` | Use custom environment names to track different image versions in environments, like `staging` and `production` |
|
||||
| `platform.os` | No | `linux` | Image operating system. |
|
||||
| `platform.architecture` | No | `amd64` | Instruction set architecture. |
|
||||
| `platform.variant` | No | | Optional variant label. |
|
||||
|
|
@ -1,104 +0,0 @@
|
|||
---
|
||||
title: Integrate with GitHub
|
||||
description: Link images with commits and pull requests on GitHub
|
||||
keywords: github, app, link, commits, source code, atomist
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
When installed for a GitHub organization, the Atomist GitHub app links
|
||||
repository activity to images. This enables Atomist to relate image tags and
|
||||
digests directly to specific commits in the source repository. It also opens up
|
||||
the possibility to incorporate image analysis in your Git workflow. For example,
|
||||
by adding analysis checks to pull request, or automatically raising pull
|
||||
requests for updating and pinning base image versions.
|
||||
|
||||
Install the GitHub app in the organization that contains the source code
|
||||
repositories for your Docker images.
|
||||
|
||||
## Connect to GitHub
|
||||
|
||||
1. Go to <https://dso.docker.com/> and sign in using your Docker ID.
|
||||
2. Open the **Repositories** tab.
|
||||
3. Select **Connect to GitHub** and follow the authorization flow. This installs
|
||||
the
|
||||
[Atomist GitHub App](https://github.com/apps/atomist "Atomist GitHub App"){: target="blank" rel="noopener" class=""}.
|
||||
|
||||
{: width="700px" }
|
||||
|
||||
4. Install the app.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If your GitHub account is a member of one or more organizations, GitHub
|
||||
> prompts you to choose which account to install the app into. Select the
|
||||
> account that contains the source repositories for your images.
|
||||
|
||||
After installing the app, GitHub redirects you back to Atomist.
|
||||
|
||||
5. In the repository selection menu, select what repositories you want Atomist
|
||||
to start watching.
|
||||
|
||||
{: width="500px" }
|
||||
|
||||
If you are just looking to evaluate Atomist, start by selecting a few
|
||||
repositories during evaluation. Once you are comfortable using Atomist, you
|
||||
can switch on the integration for all repositories. Selecting **All
|
||||
repositories** also includes any repository created in the future.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> If Atomist detects `FROM` commands in Dockerfiles in the selected
|
||||
> repositories, it begins raising automated pull requests. The pull requests
|
||||
> update the Dockerfile `FROM`-line to specify the image versions (as
|
||||
> digests).
|
||||
{: .important }
|
||||
|
||||
6. Select **Save selection**.
|
||||
|
||||
Atomist is now connected with your GitHub repositories and is be able to link
|
||||
image analyses with Git commits.
|
||||
|
||||
## Manage repository access
|
||||
|
||||
If you wish to add or remove repository access for Atomist, go to the
|
||||
**Repositories** page.
|
||||
|
||||
- Select **All repositories** if you want enable Atomist for all connected
|
||||
organizations and repositories.
|
||||
- Select **Only select repositories** if you want to provision access to only a
|
||||
subset of repositories.
|
||||
|
||||
## Disconnect from GitHub
|
||||
|
||||
You might want to disconnect from GitHub when:
|
||||
|
||||
- You want to change which GitHub organization or account connected to your
|
||||
Atomist workspace.
|
||||
|
||||
To do so, disconnect the old GitHub organization or account first. Then,
|
||||
follow the instructions for [connecting to GitHub](#connect-to-github) for the
|
||||
new GitHub organization or account.
|
||||
|
||||
- You want to remove Atomist access to a GitHub organization or account when you
|
||||
no longer use Atomist.
|
||||
|
||||
To disconnect a GitHub account:
|
||||
|
||||
1. Go to **Repositories** and select the **Disconnect** link. This removes the
|
||||
connection to your GitHub organization or account.
|
||||
2. Go to the
|
||||
[GitHub Applications settings page](https://github.com/settings/installations){:
|
||||
target="blank" rel="noopener" class=""}, then:
|
||||
|
||||
3. Find **atomist** on the Installed GitHub Apps tab.
|
||||
4. Select **Configure**
|
||||
|
||||
5. Select **Uninstall**. This removes the installation of the Atomist GitHub
|
||||
App from your GitHub organization or account.
|
||||
|
||||
6. Find **atomist** on the **Authorized GitHub Apps** tab.
|
||||
7. Select **Revoke**.
|
||||
|
||||
This removes the authorization of the Atomist GitHub App from your GitHub
|
||||
organization or account.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 227 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
|
|
@ -1,104 +0,0 @@
|
|||
---
|
||||
title: Try Atomist
|
||||
description:
|
||||
keywords: atomist, tutorial, introduction, local images
|
||||
---
|
||||
|
||||
{% include atomist/disclaimer.md %}
|
||||
|
||||
The quickest way to try Atomist is to run it on your local images, as a CLI
|
||||
tool. Trying it locally eliminates the need of having to integrate with and
|
||||
connect to a remote container registry. The CLI uses your local Docker daemon
|
||||
directly to upload the Software Bill of Materials (SBOM) to the Atomist control
|
||||
plane for analysis.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you can begin the setup, you need a Docker ID. If you don't already have
|
||||
one, you can [register here](https://hub.docker.com/signup){: target="blank"
|
||||
rel="noopener" class=""}.
|
||||
|
||||
## Steps
|
||||
|
||||
> Note
|
||||
>
|
||||
> Only use this CLI-based method of indexing images for testing or trial
|
||||
> purposes. For further evaluation or production use, integrate Atomist with
|
||||
> your container registry. See [get started](./get-started.md).
|
||||
|
||||
1. Go to the [Atomist website](https://dso.docker.com){: target="blank"
|
||||
rel="noopener" class=""} and sign in using your Docker ID.
|
||||
2. Open the **Integrations** tab.
|
||||
3. Under **API Keys**, create a new API key.
|
||||
4. In your terminal of choice, invoke the Atomist CLI tool using `docker run`.
|
||||
Update the following values:
|
||||
|
||||
- `--workspace`: the workspace ID found on the **Integrations** page on the
|
||||
Atomist website.
|
||||
- `--api-key`: the API key you just created.
|
||||
- `--image`: the Docker image that you want to index.
|
||||
|
||||
```bash
|
||||
docker run \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
-ti atomist/docker-registry-broker:latest \
|
||||
index-image local \
|
||||
--workspace AQ1K5FIKA \
|
||||
--api-key team::6016307E4DF885EAE0579AACC71D3507BB38E1855903850CF5D0D91C5C8C6DC0 \
|
||||
--image docker.io/david/myimage:latest
|
||||
```
|
||||
|
||||
> Note
|
||||
>
|
||||
> The image must have a tag (for example, `myimage:latest`) so that you are
|
||||
> able to identify the image later.
|
||||
|
||||
The output should be similar to the following:
|
||||
|
||||
```bash
|
||||
[info] Starting session with correlation-id c12e08d3-3bcc-4475-ab21-7114da599eaf
|
||||
[info] Starting atomist/docker-vulnerability-scanner-skill 'index_image' (1f99caa) atomist/skill:0.12.0-main.44 (fe90e3c) nodejs:16.15.0
|
||||
[info] Indexing image python:latest
|
||||
[info] Downloading image
|
||||
[info] Download completed
|
||||
[info] Indexing completed
|
||||
[info] Mapped packages to layers
|
||||
[info] Indexing completed successfully
|
||||
[info] Transacting image manifest for docker.io/david/myimage:latest with digest sha256:a8077d2b2ff4feb1588d941f00dd26560fe3a919c16a96305ce05f7b90f388f6
|
||||
[info] Successfully transacted entities in team AQ1K5FIKA
|
||||
[info] Image URL is https://dso.atomist.com/AQ1K5FIKA/overview/images/myimage/digests/sha256:a8077d2b2ff4feb1588d941f00dd26560fe3a919c16a96305ce05f7b90f388f6
|
||||
[info] Transacting SBOM...
|
||||
[info] Successfully transacted entities in team AQ1K5FIKA
|
||||
[info] Transacting SBOM...
|
||||
```
|
||||
|
||||
5. When the command exits, open the
|
||||
[Atomist web UI](https://dso.docker.com/r/auth/overview/images){:
|
||||
target="blank" rel="noopener" class=""}, where you should see the image in
|
||||
the list.
|
||||
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
6. Select the image name. This gets you to the list of image tags.
|
||||
|
||||
{: width="700px"}
|
||||
|
||||
Since this is your first time indexing this image, the list only has one tag
|
||||
for now. When you integrate Atomist with your container registry, images and
|
||||
tags show up in this list automatically.
|
||||
|
||||
7. Select the tag name. This shows you the insights for this tag.
|
||||
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
In this view, you can see how many vulnerabilities this image has, their
|
||||
severity levels, whether there is a fix version available, and more.
|
||||
|
||||
## Where to go next
|
||||
|
||||
The tutorial ends here. Take some time to explore the different data views that
|
||||
Atomist presents about your image. When you're ready, head to the
|
||||
[get started guide](./get-started.md) to learn how to start integrating Atomist
|
||||
in your software supply chain.
|
||||
|
|
@ -52,25 +52,8 @@ To inspect an image, simply select the image row. Inspecting an image displays d
|
|||
- Vulnerabilities found
|
||||
- Packages inside the image
|
||||
|
||||
### Image Hierarchy
|
||||
|
||||
The image you inspect may have one or more base images listed under **Image hierarchy**. This means the author of the image used another image as a starting point when building the image. Often these base images are either operating system images such as Debian, Ubuntu, and Alpine, or programming language images such as PHP, Python, and Java.
|
||||
|
||||
A base image may have its own parent base image so there is a chain of base images represented in **Image hierarchy**. Selecting each image in the chain lets you see which layers originate from each base image. Selecting the **ALL** row reselects all the layers and base images for the entire image.
|
||||
|
||||
One or more of the base images may have updates available, which may include updated security patches that remove vulnerabilities from your image. Any base images with available updates are noted to the right of **Image hierarchy**.
|
||||
|
||||
### Layers
|
||||
|
||||
A Docker image consists of layers. Image layers are listed from top to bottom, with the earliest layer at the top and the most recent layer at the bottom. Often, the layers at the top of the list originate from a base image, and the layers towards the bottom are layers added by the image author, often by adding commands to a Dockerfile. To see which layers originate from a base image, simply select a base image under **Image hierarchy** and the relevant layers are highlighted.
|
||||
|
||||
Selecting individual or multiple layers filters the packages and vulnerabilities on the right-hand side to see what has been added by the selected layers.
|
||||
|
||||
### Vulnerabilities
|
||||
|
||||
Images may be exposed to vulnerabilities and exploits. These are detected and listed on the right-hand side, grouped by package, and sorted in order of severity. Further information on whether the vulnerability has an available fix, for example, can be examined by expanding the sections. For even more details, you can visit dso.docker.com by selecting the link.
|
||||
|
||||
If you have any feedback about this feature you can use the **Give feedback** link to contact the development team.
|
||||
The image view is powered by [Docker Scout](../../scout/index.md).
|
||||
For more information about this view, see [Image details view](../../scout/image-details-view.md)
|
||||
|
||||
## Pull the latest image from Docker Hub
|
||||
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 136 KiB After Width: | Height: | Size: 136 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 343 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 99 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
|
|
@ -1,159 +0,0 @@
|
|||
---
|
||||
title: Best practices for scanning images
|
||||
description: Scan images best practices guide
|
||||
keywords: docker scan, scan, images, snyk, vulnerability
|
||||
---
|
||||
|
||||
{% include sign-up-cta.html
|
||||
body="Did you know that you can now get 10 free scans per month? Sign in to Docker to start scanning your images for vulnerabilities."
|
||||
header-text="Scan your images for free"
|
||||
target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_scan"
|
||||
%}
|
||||
|
||||
This page contains recommendations and best practices for scanning and building
|
||||
secure images.
|
||||
|
||||
Docker and Snyk have partnered together to bring security natively into the development workflow by providing a simple and streamlined approach for developers to build and deploy secure containers. Container security spans multiple teams - developers, security, and operations. Additionally, there are multiple layers of security that apply to containers:
|
||||
|
||||
- The container image and the software running inside
|
||||
- The interaction between a container, the host operating system, and other containers on the same host
|
||||
- The host operating system
|
||||
- Container networking and storage
|
||||
|
||||
Including the vulnerability scanning options into the Docker platform extends the existing, familiar process of vulnerability detection, and allows for remediation of vulnerabilities earlier in the development process. The process of simple and continuous checks, for example, by checking images in the background using [Snyk Advisor](https://snyk.io/advisor/docker){:target="_blank" rel="noopener" class="_"}, can lead to fewer vulnerabilities checked into Docker Hub. This can result in a shorter CI cycle and a more reliable deployment into production.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
## Scanning images
|
||||
|
||||
> **Log4j 2 CVE-2021-44228**
|
||||
>
|
||||
> Versions of `docker scan` earlier than `v0.11.0` are not able to detect [Log4j 2
|
||||
> CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228){:
|
||||
> target="_blank" rel="noopener" class="_"}. You must update your Docker Desktop
|
||||
> installation to version 4.3.1 or higher to fix this issue. For more information,
|
||||
> see [Scan images for Log4j 2 CVE](../../engine/scan#scan-images-for-log4j-2-cve).
|
||||
{: .important}
|
||||
|
||||
You can trigger scans automatically by pushing an image to Docker Hub. You can achieve this either through the `docker scan` command in the CLI, or through Docker Hub.
|
||||
|
||||
### Scan using the CLI
|
||||
|
||||
After you’ve built an image and before you push your image to Docker Hub, run the `docker scan` command. For detailed instructions on how to scan images using the CLI, see [docker scan](../../engine/scan/index.md).
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
### Scan using Docker Hub
|
||||
|
||||
You can trigger scans, view, and inspect vulnerabilities through Docker Hub. For detailed information, see [Hub Vulnerability Scanning](../../docker-hub/vulnerability-scanning.md).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Hub Vulnerability Scanning is available for developers subscribed to a Docker Pro, Team, or a Business tier. For more information about the pricing plans, see [Docker Pricing](https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade){:target="_blank" rel="noopener" class="_"}.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
### View the scan summary in Docker Desktop
|
||||
|
||||
Docker Desktop provides you a snapshot of your vulnerabilities status on the Docker Dashboard. Hover over the image and click **View in Hub** to view a detailed vulnerability report in Docker Hub.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
## Best practices
|
||||
|
||||
As a developer, you can take a few simple steps to improve the security of your container. This includes:
|
||||
|
||||
1. Choosing the right base image from a trusted source and keeping it small
|
||||
2. Using multi-stage builds
|
||||
3. Rebuilding images
|
||||
4. Scanning images during development
|
||||
5. Scanning images during production
|
||||
|
||||
Now, let’s take a detailed look at each of these best practices:
|
||||
|
||||
### Choose the right base image
|
||||
|
||||
The first step towards achieving a secure image is to choose the right base image. When choosing an image, ensure it is built from a trusted source and keep it small.
|
||||
|
||||
Docker Hub has more than 8.3 million repositories. Some of these images are [Official Images](../../docker-hub/official_images.md), which are published by Docker as a curated set of Docker open source and drop-in solution repositories. Docker also offers images that are published by [Verified Publishers](../../docker-hub/publish/index.md). These high-quality images are published and maintained by the organizations partnering with Docker, with Docker verifying the authenticity of the content in their repositories. When you pick your base image, look out for the **Official Image** and **Verified Publisher** badges.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
When building your own image from a Dockerfile, ensure you choose a minimal base image that matches your requirements. A smaller base image not just offers portability and fast downloads, but also shrinks the size of your image and minimizes the number of vulnerabilities introduced through the dependencies.
|
||||
|
||||
We also recommend that you use two types of base images: the first image for development and unit testing and the second one for testing during the latest stages of development and production. In the later stages of development, your image may not even require some build tools such as compilers, build systems, or any debugging tools. A small image with minimal dependencies can considerably lower the attack surface.
|
||||
|
||||
### Use multi-stage builds
|
||||
|
||||
Multi-stage builds are designed to create an optimized Dockerfile that is easy to read and maintain. With a multi-stage build, you can use multiple images and selectively copy only the artifacts needed from a particular image.
|
||||
|
||||
You can use multiple `FROM` statements in your Dockerfile, and you can use a different base image for each `FROM`. You can also selectively copy artifacts from one stage to another, leaving behind things you don’t need in the final image. This can result in a concise final image.
|
||||
|
||||
This method of creating a tiny image does not only significantly reduce complexity, but also the change of implementing vulnerable artifacts in your image. Therefore, instead of images that are built on images, that again are built on other images, multi-stage builds allow you to 'cherry pick' your artifacts without inheriting the vulnerabilities from the base images on which they rely on.
|
||||
|
||||
For detailed information on how to configure multi-stage builds, see [multi-stage builds](../../build/building/multi-stage.md).
|
||||
|
||||
### Rebuild images
|
||||
|
||||
A Docker image is built from a Dockerfile. A Dockerfile contains a set of instructions which allows you to automate the steps you would normally (manually) take to create an image. Additionally, it can include some imported libraries and install custom software. These appear as instructions in the Dockerfile.
|
||||
|
||||
Building your image is a snapshot of that image, at that moment in time. When you depend on a base image without a tag, you’ll get a different base image every time you rebuild. Also, when you install packages using a package installer, rebuilding can change the image drastically. For example, a Dockerfile containing the following entries can potentially have a different binary with every rebuild.
|
||||
|
||||
```dockerfile
|
||||
# syntax=docker/dockerfile:1
|
||||
FROM ubuntu:latest
|
||||
RUN apt-get -y update && apt-get install -y python
|
||||
```
|
||||
|
||||
We recommend that you rebuild your Docker image regularly to prevent known vulnerabilities that have been addressed. When rebuilding, use the option `--no-cache` to avoid cache hits and to ensure a fresh download.
|
||||
|
||||
For example:
|
||||
|
||||
```console
|
||||
$ docker build --no-cache -t myImage:myTag myPath/
|
||||
```
|
||||
|
||||
Consider the following best practices when rebuilding an image:
|
||||
|
||||
- Each container should have only one responsibility.
|
||||
- Containers should be immutable, lightweight, and fast.
|
||||
- Don’t store data in your container. Use a shared data store instead.
|
||||
- Containers should be easy to destroy and rebuild.
|
||||
- Use a small base image (such as Linux Alpine). Smaller images are easier to distribute.
|
||||
- Avoid installing unnecessary packages. This keeps the image clean and safe.
|
||||
- Avoid cache hits when building.
|
||||
- Auto-scan your image before deploying to avoid pushing vulnerable containers to production.
|
||||
- Scan your images daily both during development and production for vulnerabilities Based on that, automate the rebuild of images if necessary.
|
||||
|
||||
For detailed best practices and methods for building efficient images, see [Dockerfile best practices](../develop-images/dockerfile_best-practices.md).
|
||||
|
||||
### Scan images during development
|
||||
|
||||
Creating an image from a Dockerfile and even rebuilding an image can introduce new vulnerabilities in your system. Scanning your Docker images during development should be part of your workflow to catch vulnerabilities earlier in your development. You should scan images at all stages of the development cycle, and ideally consider automating scans. For example, consider configuring automated scans during the build process, before pushing the image to Docker Hub (or any other registry), and finally before pushing it to a production environment.
|
||||
|
||||
### Scan images during production
|
||||
|
||||
Actively checking your container can save you a lot of hassle when a new vulnerability is discovered, which otherwise can put your production system at risk.
|
||||
|
||||
Periodically scanning your Docker image is possible by using the Snyk monitor capabilities for containers. Snyk creates a snapshot of the image’s dependencies for continuous monitoring. Additionally, you should also activate runtime monitoring. Scanning for unused modules and packages inside your runtime gives insight into how to shrink images. Removing unused components prevents unnecessary vulnerabilities from entering both system and application libraries. This also makes an image more easily maintainable.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Building secure images is a continuous process. Consider the recommendations and best practices highlighted in this guide to plan and build efficient, scalable, and secure images.
|
||||
|
||||
Let’s recap what we’ve learnt in this guide:
|
||||
|
||||
- Start with a base image that you trust. Remember the Official image and Verified Publisher badges when you choose your base images.
|
||||
- Secure your code and its dependencies.
|
||||
- Select a minimal base image which contains only the required packages.
|
||||
- Use multi-stage builds to optimize your image.
|
||||
- Ensure you carefully monitor and manage the tools and dependencies you add to your image.
|
||||
- Ensure you scan images at multiple stages during your development lifecycle.
|
||||
- Check your images frequently for vulnerabilities.
|
||||
|
||||
## Further reading
|
||||
|
||||
You can also take a look at the following articles from Snyk:
|
||||
|
||||
- [Container Security Guide](https://snyk.io/learn/container-security/){:target="_blank" rel="noopener" class="_"}
|
||||
- [Docker Vulnerability Scanning Cheat Sheet](https://goto.docker.com/rs/929-FJL-178/images/cheat-sheet-docker-desktop-vulnerability-scanning-CLI.pdf){:target="_blank" rel="noopener" class="_"}
|
||||
|
|
@ -0,0 +1,163 @@
|
|||
---
|
||||
title: Security best practices
|
||||
description: Image security best practices guide
|
||||
keywords: docker, images, containers, vulnerability, cve
|
||||
redirect_from:
|
||||
- /develop/scan-images/
|
||||
---
|
||||
|
||||
As a developer, you can take a few simple steps to improve the security of your
|
||||
container. This includes:
|
||||
|
||||
1. Choosing the right base image from a trusted source and keeping it small
|
||||
2. Using multi-stage builds
|
||||
3. Rebuilding images
|
||||
4. Check your image for vulnerabilities
|
||||
|
||||
Now, let’s take a detailed look at each of these best practices:
|
||||
|
||||
### Choose the right base image
|
||||
|
||||
The first step towards achieving a secure image is to choose the right base
|
||||
image. When choosing an image, ensure it is built from a trusted source and keep
|
||||
it small.
|
||||
|
||||
Docker Hub has more than 8.3 million repositories. Some of these images are
|
||||
[Official Images](../docker-hub/official_images.md), which are published by
|
||||
Docker as a curated set of Docker open source and drop-in solution repositories.
|
||||
Docker also offers images that are published by
|
||||
[Verified Publishers](../docker-hub/publish/index.md). These high-quality images
|
||||
are published and maintained by the organizations partnering with Docker, with
|
||||
Docker verifying the authenticity of the content in their repositories. When you
|
||||
pick your base image, look out for the **Official Image** and **Verified
|
||||
Publisher** badges.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
When building your own image from a Dockerfile, ensure you choose a minimal base
|
||||
image that matches your requirements. A smaller base image not just offers
|
||||
portability and fast downloads, but also shrinks the size of your image and
|
||||
minimizes the number of vulnerabilities introduced through the dependencies.
|
||||
|
||||
We also recommend that you use two types of base images: the first image for
|
||||
development and unit testing and the second one for testing during the latest
|
||||
stages of development and production. In the later stages of development, your
|
||||
image may not even require some build tools such as compilers, build systems, or
|
||||
any debugging tools. A small image with minimal dependencies can considerably
|
||||
lower the attack surface.
|
||||
|
||||
### Use multi-stage builds
|
||||
|
||||
Multi-stage builds are designed to create an optimized Dockerfile that is easy
|
||||
to read and maintain. With a multi-stage build, you can use multiple images and
|
||||
selectively copy only the artifacts needed from a particular image.
|
||||
|
||||
You can use multiple `FROM` statements in your Dockerfile, and you can use a
|
||||
different base image for each `FROM`. You can also selectively copy artifacts
|
||||
from one stage to another, leaving behind things you don’t need in the final
|
||||
image. This can result in a concise final image.
|
||||
|
||||
This method of creating a tiny image does not only significantly reduce
|
||||
complexity, but also the change of implementing vulnerable artifacts in your
|
||||
image. Therefore, instead of images that are built on images, that again are
|
||||
built on other images, multi-stage builds allow you to 'cherry pick' your
|
||||
artifacts without inheriting the vulnerabilities from the base images on which
|
||||
they rely on.
|
||||
|
||||
For detailed information on how to configure multi-stage builds, see
|
||||
[multi-stage builds](../build/building/multi-stage.md).
|
||||
|
||||
### Rebuild images
|
||||
|
||||
A Docker image is built from a Dockerfile. A Dockerfile contains a set of
|
||||
instructions which allows you to automate the steps you would normally
|
||||
(manually) take to create an image. Additionally, it can include some imported
|
||||
libraries and install custom software. These appear as instructions in the
|
||||
Dockerfile.
|
||||
|
||||
Building your image is a snapshot of that image, at that moment in time. When
|
||||
you depend on a base image without a tag, you’ll get a different base image
|
||||
every time you rebuild. Also, when you install packages using a package
|
||||
installer, rebuilding can change the image drastically. For example, a
|
||||
Dockerfile containing the following entries can potentially have a different
|
||||
binary with every rebuild.
|
||||
|
||||
```dockerfile
|
||||
# syntax=docker/dockerfile:1
|
||||
FROM ubuntu:latest
|
||||
RUN apt-get -y update && apt-get install -y python
|
||||
```
|
||||
|
||||
We recommend that you rebuild your Docker image regularly to prevent known
|
||||
vulnerabilities that have been addressed. When rebuilding, use the option
|
||||
`--no-cache` to avoid cache hits and to ensure a fresh download.
|
||||
|
||||
For example:
|
||||
|
||||
```console
|
||||
$ docker build --no-cache -t myImage:myTag myPath/
|
||||
```
|
||||
|
||||
Consider the following best practices when rebuilding an image:
|
||||
|
||||
- Each container should have only one responsibility.
|
||||
- Containers should be immutable, lightweight, and fast.
|
||||
- Don’t store data in your container. Use a shared data store instead.
|
||||
- Containers should be easy to destroy and rebuild.
|
||||
- Use a small base image (such as Linux Alpine). Smaller images are easier to
|
||||
distribute.
|
||||
- Avoid installing unnecessary packages. This keeps the image clean and safe.
|
||||
- Avoid cache hits when building.
|
||||
- Auto-scan your image before deploying to avoid pushing vulnerable containers
|
||||
to production.
|
||||
- Scan your images daily both during development and production for
|
||||
vulnerabilities Based on that, automate the rebuild of images if necessary.
|
||||
|
||||
For detailed best practices and methods for building efficient images, see
|
||||
[Dockerfile best practices](develop-images/dockerfile_best-practices.md).
|
||||
|
||||
## Check your image for vulnerabilities
|
||||
|
||||
In addition to following the best practices outlined on this page when
|
||||
developing images, it's also important to continuously analyze and evaluate the
|
||||
security posture of your images using vulnerability detection tools.
|
||||
|
||||
Docker tools come with features helps you stay up to date about vulnerabilities
|
||||
that affect images that you build or use.
|
||||
|
||||
- Docker Hub supports automatic
|
||||
[vulnerability scanning](../docker-hub/vulnerability-scanning.md) feature,
|
||||
when enabled, automatically scans images you push them to a Docker Hub
|
||||
repository. Requires a Docker subscription.
|
||||
- Docker Hub also supports an early-access
|
||||
[advanced image analysis](../scout/advanced-image-analysis.md) feature, which extends
|
||||
the "core" vulnerability scanning solution with enhanced capabilities and more
|
||||
detailed and actionable insights.
|
||||
- For the CLI, there's a `docker scout` plugin which replaces the now-deprecated
|
||||
`docker scan` command. This CLI plugin lets you explore vulnerabilities for an
|
||||
image, directly in comfort of your terminal.
|
||||
- Docker Desktop sports a detailed image view for images in your local image
|
||||
store, that visualizes all of the known vulnerabilities affecting an image.
|
||||
|
||||
All of these security features are powered by the same technology:
|
||||
[Docker Scout](../scout/index.md). These features help you achieve a holistic
|
||||
view of your supply chain security, and to provide actionable suggestions for
|
||||
what you can do to remediate those vulnerabilities.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Building secure images is a continuous process. Consider the recommendations and
|
||||
best practices highlighted in this guide to plan and build efficient, scalable,
|
||||
and secure images.
|
||||
|
||||
Let’s recap what we’ve learnt in this guide:
|
||||
|
||||
- Start with a base image that you trust. Remember the Official image and
|
||||
Verified Publisher badges when you choose your base images.
|
||||
- Secure your code and its dependencies.
|
||||
- Select a minimal base image which contains only the required packages.
|
||||
- Use multi-stage builds to optimize your image.
|
||||
- Ensure you carefully monitor and manage the tools and dependencies you add to
|
||||
your image.
|
||||
- Ensure you scan images at multiple stages during your development lifecycle.
|
||||
- Check your images frequently for vulnerabilities.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 132 KiB After Width: | Height: | Size: 275 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 128 KiB |
|
|
@ -1,124 +1,174 @@
|
|||
---
|
||||
description: Hub Vulnerability Scanning
|
||||
keywords: scanning, vulnerabilities, Hub, Snyk
|
||||
title: Hub Vulnerability Scanning
|
||||
description: Hub Basic vulnerability scanning
|
||||
keywords: scanning, vulnerabilities, Hub, basic
|
||||
title: Basic vulnerability scanning
|
||||
---
|
||||
|
||||
{% include upgrade-cta.html
|
||||
body="Docker Hub Vulnerability Scanning is available for users subscribed to Docker Pro, Team, or a Business subscription. Upgrade now to get automatic vulnerability scans for your images."
|
||||
header-text="This feature requires a paid Docker subscription"
|
||||
target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_scan"
|
||||
%}
|
||||
|
||||
Docker Hub Vulnerability Scanning enables you to automatically scan Docker
|
||||
images for vulnerabilities using Snyk. This uses the same technology as the
|
||||
[docker scan](../engine/scan/index.md) command.
|
||||
|
||||
> When you enable Hub Vulnerability Scanning, you can also see whether your
|
||||
> images are affected by Log4Shell (CVE-2021-44228). For more information, see
|
||||
> [Scan images](#scan-images-on-docker-hub).
|
||||
|
||||
When you push an image to Docker Hub after enabling vulnerability scanning, Docker Hub automatically scans the image to identify vulnerabilities in your container images. Vulnerability Scanning allows developers and development teams to review the security state of the container images and take actions to fix issues identified during the scan, resulting in more secure deployments. The scan result includes the source of the vulnerability, such as OS packages and libraries, version in which it was introduced, and a recommended fixed version (if available) to remediate the vulnerabilities discovered.
|
||||
|
||||
## Scan images on Docker Hub
|
||||
|
||||
> **Log4j 2 CVE-2021-44228**
|
||||
>
|
||||
> Docker Hub security scans triggered after **1700 UTC 13 December 2021** are
|
||||
> now correctly identifying the Log4j2 CVE. Scans before this date **do not**
|
||||
> currently reflect the status of this vulnerability. Therefore, we recommend
|
||||
> that you trigger scans by pushing the image to Docker Hub to view the status
|
||||
> of Log4j2 CVE in the vulnerability report.
|
||||
{: .important}
|
||||
|
||||
Hub Vulnerability scanning allows repository owners and administrators of a
|
||||
Docker Pro, Team, or a Business tier to enable and disable scanning. When scanning is enabled on a specific repository, anyone with push access can trigger a scan by pushing an image to Docker Hub.
|
||||
|
||||
In addition, repository owners in a Docker Pro subscription and team members in a Team, or a Business subscription can view the detailed scan reports, including
|
||||
information about whether or not an image is affected by the **Log4j 2 CVE**.
|
||||
You must push the image to Docker Hub to trigger a scan that
|
||||
allows you to view the Log4j 2 CVE results.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Hub currently supports scanning images which are of AMD64 architecture, Linux OS, and are less than 10 GB in size.
|
||||
> Hub Vulnerability Scanning requires a Docker Pro, Team, or Business
|
||||
> subscription.
|
||||
|
||||
### Enable vulnerability scanning
|
||||
Docker Hub vulnerability scanning lets you automatically scan Docker images for
|
||||
vulnerabilities.
|
||||
|
||||
Repository owners and administrators can enable vulnerability scanning on a repository. If you are a member of a Team or a Business subscription, ensure the repository you would like to enable scanning on is part of the Team or a Business tier.
|
||||
When you push an image to a Docker Hub repository after turning on vulnerability
|
||||
scanning, Docker Hub automatically scans the image to identify vulnerabilities.
|
||||
Vulnerability Scanning lets you review the security state of your images and
|
||||
take actions to fix issues identified during the scan, resulting in more secure
|
||||
deployments.
|
||||
|
||||
To enable vulnerability scanning:
|
||||
Scan results include:
|
||||
|
||||
1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} account.
|
||||
2. Click **Repositories** from the main menu and select a repository from the list.
|
||||
3. By default, scanning is disabled for all repositories. You can enable scanning separately for each repository. Go to the **Settings** tab and click **Enable Image Scanning**.
|
||||
- The source of the vulnerability, such as OS packages and libraries
|
||||
- The version in which it was introduced
|
||||
- A recommended fixed version (if available) to remediate the vulnerabilities
|
||||
discovered.
|
||||
|
||||
### Scan an image for vulnerabilities
|
||||
## Changes to vulnerability scanning in Docker Hub
|
||||
|
||||
To scan an image for vulnerabilities, push the image to Docker Hub:
|
||||
From February 27th, 2023, Docker began rolling out changes to the technology
|
||||
that supports the Docker Hub Vulnerability Scanning feature. Docker Hub
|
||||
Vulnerability Scanning is now powered natively by Docker, instead of a
|
||||
third-party.
|
||||
|
||||
1. Ensure you have installed Docker locally. See [Get Docker](../get-docker.md) to download and install Docker on your local machine.
|
||||
2. Use the command line to log into your Docker account. See [docker login](../engine/reference/commandline/login.md) for more information.
|
||||
3. Tag the image that you’d like to scan. For example, to tag a Redis image, run:
|
||||
As a result of this change, scanning now detects vulnerabilities at a more
|
||||
granular level than before. This in turn means that vulnerability reports may
|
||||
show a higher number of vulnerabilities. If you used vulnerability scanning
|
||||
before February 27th, 2023, you may see that new vulnerability reports list a
|
||||
higher number of vulnerabilities, due to a more thorough analysis.
|
||||
|
||||
```console
|
||||
$ docker tag redis <your-Docker-ID>/<your-repo-name>:latest
|
||||
```
|
||||
There is no action required on your part. Scans will continue to run as usual
|
||||
with no interruption or changes to pricing. Historical data continues to be
|
||||
available.
|
||||
|
||||
4. Push the image to Docker Hub to trigger vulnerability scanning on the image:
|
||||
This page describes the Basic Hub vulnerability scanning feature. Docker Scout
|
||||
also supports an [Advanced image analysis](../scout/advanced-image-analysis.md)
|
||||
feature that provides more in-depth results and guided remediation steps for
|
||||
improving your security posture.
|
||||
|
||||
```console
|
||||
$ docker push <your-Docker-ID>/<your-repo-name>:latest
|
||||
```
|
||||
## Scan images with Basic vulnerability scanning
|
||||
|
||||
Repository owners and administrators of a Docker Pro, Team, or a Business tier
|
||||
enable and disable Basic vulnerability scanning. When scanning is active on a
|
||||
repository, anyone with push access can trigger a scan by pushing an image to
|
||||
Docker Hub.
|
||||
|
||||
Additionally, repository owners in a Docker Pro subscription and team members in
|
||||
a Team, or a Business subscription can view the detailed scan reports.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Basic vulnerability scanning supports scanning images which are of AMD64
|
||||
> architecture, Linux OS, and are less than 10 GB in size.
|
||||
|
||||
### Turn on Basic vulnerability scanning
|
||||
|
||||
Repository owners and administrators can enable Basic vulnerability scanning on
|
||||
a repository. If you are a member of a Team or a Business subscription, ensure
|
||||
the repository you would like to enable scanning on is part of the Team or a
|
||||
Business tier.
|
||||
|
||||
To enable Basic vulnerability scanning:
|
||||
|
||||
1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank"
|
||||
rel="noopener" class="_"} account.
|
||||
2. Click **Repositories** from the main menu and select a repository from the
|
||||
list.
|
||||
3. Go to the **Settings** tab.
|
||||
4. Under **Image insight settings**, select **Basic Hub vulnerability
|
||||
scanning**.
|
||||
5. Select **Save**.
|
||||
|
||||
### Scan an image
|
||||
|
||||
To scan an image for vulnerabilities, push the image to Docker Hub, to the
|
||||
repository for which you have turned on scanning:
|
||||
|
||||
1. Ensure you have installed Docker locally. See [Get Docker](../get-docker.md)
|
||||
to download and install Docker on your local machine.
|
||||
2. Use the command line to log into your Docker account. See
|
||||
[`docker login`](../engine/reference/commandline/login.md) for more
|
||||
information.
|
||||
3. Tag the image that you’d like to scan. For example, to tag a Redis image,
|
||||
run:
|
||||
|
||||
```console
|
||||
$ docker tag redis <your-Docker-ID>/<your-repo-name>:latest
|
||||
```
|
||||
|
||||
4. Push the image to Docker Hub to trigger Basic vulnerability scanning on the
|
||||
image:
|
||||
|
||||
```console
|
||||
$ docker push <your-Docker-ID>/<your-repo-name>:latest
|
||||
```
|
||||
|
||||
## View the vulnerability report
|
||||
|
||||
> **Scan report retention period**
|
||||
>
|
||||
> Docker retains the vulnerability scan report for one year. If you'd like a new, up-to-date vulnerability scan report after this period, you can rescan the image by pushing the image to Docker Hub.
|
||||
|
||||
To view the vulnerability report:
|
||||
|
||||
1. Go to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} and open the repository to view a summary of the vulnerability scanning report.
|
||||
1. Go to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener"
|
||||
class="_"} and open the repository page to view a summary of the Basic
|
||||
vulnerability scanning report.
|
||||
|
||||
It can take a couple of minutes for the vulnerability report to appear in your repository.
|
||||
It may take a couple of minutes for the vulnerability report to appear in
|
||||
your repository.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
2. Click on the **Tags** tab > **Digest** > **Vulnerabilities** to view the detailed scan report.
|
||||
2. Click on the **Tags** tab > **Digest** > **Vulnerabilities** to view the
|
||||
detailed scan report.
|
||||
|
||||
The scan report displays vulnerabilities identified by the scan, sorting them according to their severity, with highest severity listed at the top. It displays information about the package that contains the vulnerability, the version in which it was introduced, and whether the vulnerability is fixed in a later version.
|
||||
The scan report displays vulnerabilities identified by the scan, sorting them
|
||||
according to their severity, with highest severity listed at the top. It
|
||||
displays information about the package that contains the vulnerability, the
|
||||
version in which it was introduced, and whether the vulnerability is fixed in
|
||||
a later version.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You can also click the ‘open in browser’ icon on each row to view detailed information about the vulnerability on the Snyk website.
|
||||
For more information on this view, see
|
||||
[Image details view](../scout/image-details-view.md).
|
||||
|
||||
### Disable vulnerability scanning
|
||||
### Inspect vulnerabilities
|
||||
|
||||
Repository owners and administrators can disable vulnerability scanning on a repository. To disable scanning:
|
||||
The vulnerability report sorts vulnerabilities based on their severity. It
|
||||
displays information about the package that contains the vulnerability, the
|
||||
version in which it was introduced, and whether the vulnerability has been fixed
|
||||
in a later version.
|
||||
|
||||
1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} account.
|
||||
2. Click **Repositories** from the main menu and select a repository from the list.
|
||||
3. Go to the **Settings** tab and click **Disable Image Scanning**.
|
||||
The vulnerability scan report also allows development teams and security leads
|
||||
to compare the vulnerability counts across tags to see whether the
|
||||
vulnerabilities are decreasing or increasing over time.
|
||||
|
||||
### Inspect the vulnerabilities
|
||||
### Fix vulnerabilities
|
||||
|
||||
The vulnerability report sorts vulnerabilities based on their severity. It displays information about the package that contains the vulnerability, the version in which it was introduced, and whether the vulnerability has been fixed in a later version.
|
||||
Once a list of vulnerabilities have been identified, there are a couple of
|
||||
actions you can take to remediate the vulnerabilities. For example, you can:
|
||||
|
||||
The vulnerability scan report also allows development teams and security leads to compare the vulnerability counts across tags to see whether the vulnerabilities are decreasing or increasing over time.
|
||||
1. Specify an updated base image in the Dockerfile, check your application-level
|
||||
dependencies, rebuild the Docker image and then push the new image to Docker
|
||||
Hub.
|
||||
2. Rebuild the Docker image, run an update command on the OS packages, and push
|
||||
a newer version of image to Docker Hub.
|
||||
3. Edit the Dockerfile to manually remove or update specific libraries that
|
||||
contain vulnerabilities, rebuild the image, and push the new image to Docker
|
||||
Hub
|
||||
|
||||
### Fixing vulnerabilities
|
||||
Docker Scout can help provide you with concrete and contextual remediation steps
|
||||
for improving image security. For more information, see
|
||||
[Docker Scout](../scout/index.md).
|
||||
|
||||
Once a list of vulnerabilities have been identified, there are a couple of actions you can take to remediate the vulnerabilities. For example, you can:
|
||||
### Turn off Basic vulnerability scanning
|
||||
|
||||
1. Specify an updated base image in the Dockerfile, check your application-level dependencies, rebuild the Docker image and then push the new image to Docker Hub.
|
||||
2. Rebuild the Docker image, run an update command on the OS packages, and push a newer version of image to Docker Hub.
|
||||
3. Edit the dockerfile to manually remove or update specific libraries that contain vulnerabilities, rebuild the image, and push the new image to Docker Hub
|
||||
Repository owners and administrators can disable Basic vulnerability scanning on
|
||||
a repository. To disable scanning:
|
||||
|
||||
After you have followed the steps suggested above, browse the new vulnerability report to view the updated scan result.
|
||||
|
||||
## Feedback
|
||||
|
||||
Thank you for trying out the Hub Vulnerability Scanning feature. Your feedback is very important to us. Let us know your feedback by creating an issue in the [hub-feedback](https://github.com/docker/hub-feedback/issues){: target="_blank" rel="noopener" class="_"} GitHub repository.
|
||||
1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank"
|
||||
rel="noopener" class="_"} account.
|
||||
2. Go to **Repositories** from the main menu and select a repository from the
|
||||
list.
|
||||
3. Go to the **Settings** tab.
|
||||
4. Under **Image insight settings**, select **None**.
|
||||
5. Select **Save**.
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ instructions for enabling and configuring AppArmor or SELinux.
|
|||
The binaries for Mac also do not contain:
|
||||
|
||||
- A runtime environment. You must set up a functional engine either in a Virtual Machine, or on a remote Linux machine.
|
||||
- Docker components such as `buildx`, `docker scan`, and `docker compose`.
|
||||
- Docker components such as `buildx` and `docker compose`.
|
||||
|
||||
To install client binaries, perform the following steps:
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ To install client binaries, perform the following steps:
|
|||
>
|
||||
> The following section describes how to install the Docker daemon on Windows
|
||||
> Server which allows you to run Windows containers only. The binaries for
|
||||
> Windows do not contain Docker components such as `buildx`, `docker scan`, and
|
||||
> Windows do not contain Docker components such as `buildx` and
|
||||
> `docker compose`. If you are running Windows 10 or 11, we recommend that you
|
||||
> install [Docker Desktop](../../desktop/index.md) instead.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
datafolder: scout-cli
|
||||
datafile: docker_scout
|
||||
title: docker scout
|
||||
---
|
||||
<!--
|
||||
This page is automatically generated from Docker's source code. If you want to
|
||||
suggest a change to the text that appears here, open a ticket or pull request
|
||||
in the source repository on GitHub:
|
||||
|
||||
https://github.com/docker/scout-cli-plugin
|
||||
-->
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
datafolder: scout-cli
|
||||
datafile: docker_scout_cves
|
||||
title: docker scout cves
|
||||
---
|
||||
<!--
|
||||
This page is automatically generated from Docker's source code. If you want to
|
||||
suggest a change to the text that appears here, open a ticket or pull request
|
||||
in the source repository on GitHub:
|
||||
|
||||
https://github.com/docker/scout-cli-plugin
|
||||
-->
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
datafolder: scout-cli
|
||||
datafile: docker_scout_version
|
||||
title: docker scout version
|
||||
---
|
||||
<!--
|
||||
This page is automatically generated from Docker's source code. If you want to
|
||||
suggest a change to the text that appears here, open a ticket or pull request
|
||||
in the source repository on GitHub:
|
||||
|
||||
https://github.com/docker/scout-cli-plugin
|
||||
-->
|
||||
{% include cli.md datafolder=page.datafolder datafile=page.datafile %}
|
||||
|
|
@ -6,15 +6,27 @@ toc_min: 1
|
|||
toc_max: 2
|
||||
---
|
||||
|
||||
{% include sign-up-cta.html
|
||||
body="Did you know that you can now get 10 free scans per month? Sign in to Docker to start scanning your images for vulnerabilities."
|
||||
header-text="Scan your images for free"
|
||||
target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_scan"
|
||||
%}
|
||||
> **Deprecated**
|
||||
>
|
||||
> This page describes the `docker scan` CLI plugin. This plugin and associated
|
||||
> commands are deprecated, and replaced by `docker scout cves` command. See
|
||||
> [Docker Scout](../../scout/index.md) for more information.
|
||||
>
|
||||
> If you would like to continue using Snyk for image scanning and vulnerability
|
||||
> detection, refer to the
|
||||
> [Snyk CLI documentation](https://docs.snyk.io/snyk-cli){: target="\_blank"
|
||||
> rel="noopener" }
|
||||
{: .warning }
|
||||
|
||||
Looking to speed up your development cycles? Quickly detect and learn how to remediate CVEs in your images by running `docker scan IMAGE_NAME`. Check out [How to scan images](#how-to-scan-images) for details.
|
||||
Looking to speed up your development cycles? Quickly detect and learn how to
|
||||
remediate CVEs in your images by running `docker scan IMAGE_NAME`. Check out
|
||||
[How to scan images](#how-to-scan-images) for details.
|
||||
|
||||
Vulnerability scanning for Docker local images allows developers and development teams to review the security state of the container images and take actions to fix issues identified during the scan, resulting in more secure deployments. Docker Scan runs on Snyk engine, providing users with visibility into the security posture of their local Dockerfiles and local images.
|
||||
Vulnerability scanning for Docker local images allows developers and development
|
||||
teams to review the security state of the container images and take actions to
|
||||
fix issues identified during the scan, resulting in more secure deployments.
|
||||
Docker Scan runs on Snyk engine, providing users with visibility into the
|
||||
security posture of their local Dockerfiles and local images.
|
||||
|
||||
Users trigger vulnerability scans through the CLI, and use the CLI to view the
|
||||
scan results. The scan results contain a list of Common Vulnerabilities and
|
||||
|
|
@ -24,14 +36,14 @@ remediate the CVEs discovered.
|
|||
|
||||
> **Log4j 2 CVE-2021-44228**
|
||||
>
|
||||
> Versions of `docker Scan` earlier than `v0.11.0` are not able to detect [Log4j 2
|
||||
> CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228){:
|
||||
> target="_blank" rel="noopener" class="_"}. You must update your Docker
|
||||
> Desktop installation to 4.3.1 or higher to fix this issue. For more
|
||||
> information, see [Scan images for Log4j 2 CVE](#scan-images-for-log4j-2-cve).
|
||||
{: .important}
|
||||
> Versions of `docker Scan` earlier than `v0.11.0` are not able to detect
|
||||
> [Log4j 2 CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228){:
|
||||
> target="_blank" rel="noopener" class="_"}. You must update your Docker Desktop
|
||||
> installation to 4.3.1 or higher to fix this issue. For more information, see
|
||||
> [Scan images for Log4j 2 CVE](#scan-images-for-log4j-2-cve). {: .important}
|
||||
|
||||
For information about the system requirements to run vulnerability scanning, see [Prerequisites](#prerequisites).
|
||||
For information about the system requirements to run vulnerability scanning, see
|
||||
[Prerequisites](#prerequisites).
|
||||
|
||||
This page contains information about the `docker scan` CLI command. For
|
||||
information about automatically scanning Docker images through Docker Hub, see
|
||||
|
|
@ -39,15 +51,15 @@ information about automatically scanning Docker images through Docker Hub, see
|
|||
|
||||
## Scan images for Log4j 2 CVE
|
||||
|
||||
Docker Scan versions earlier than `v0.11.0` do not detect [Log4j 2
|
||||
CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228){:
|
||||
target="_blank" rel="noopener" class="_"} when you scan your
|
||||
images for vulnerabilities. You must update your Docker installation to the
|
||||
latest version to fix this issue.
|
||||
Docker Scan versions earlier than `v0.11.0` do not detect
|
||||
[Log4j 2 CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228){:
|
||||
target="_blank" rel="noopener" class="_"} when you scan your images for
|
||||
vulnerabilities. You must update your Docker installation to the latest version
|
||||
to fix this issue.
|
||||
|
||||
If you are using the `docker scan` plugin shipped
|
||||
with Docker Desktop, update Docker Desktop to version 4.3.1 or
|
||||
higher. See the release notes for [Mac](../../desktop/release-notes.md) and
|
||||
If you are using the `docker scan` plugin shipped with Docker Desktop, update
|
||||
Docker Desktop to version 4.3.1 or higher. See the release notes for
|
||||
[Mac](../../desktop/release-notes.md) and
|
||||
[Windows](../../desktop/release-notes.md) for download information.
|
||||
|
||||
If you are using Linux, run the following command to manually install the latest
|
||||
|
|
@ -65,10 +77,11 @@ On rpm-based distros, such as CentOS or Fedora:
|
|||
$ yum install docker-scan-plugin
|
||||
```
|
||||
|
||||
Alternatively, you can manually download the `docker scan` binaries from the [Docker Scan](https://github.com/docker/scan-cli-plugin/releases/tag/v0.11.0){:
|
||||
Alternatively, you can manually download the `docker scan` binaries from the
|
||||
[Docker Scan](https://github.com/docker/scan-cli-plugin/releases/tag/v0.11.0){:
|
||||
target="_blank" rel="noopener" class="_"} GitHub repository and
|
||||
[install](https://github.com/docker/scan-cli-plugin){:
|
||||
target="_blank" rel="noopener" class="_"} in the plugins directory.
|
||||
[install](https://github.com/docker/scan-cli-plugin){: target="_blank"
|
||||
rel="noopener" class="_"} in the plugins directory.
|
||||
|
||||
### Verify the `docker scan` version
|
||||
|
||||
|
|
@ -82,9 +95,10 @@ Git commit: 1074dd0
|
|||
Provider: Snyk (1.790.0 (standalone))
|
||||
```
|
||||
|
||||
If your code output contains `ORGAPACHELOGGINGLOG4J`, it is
|
||||
likely that your code is affected by the Log4j 2 CVE-2021-44228 vulnerability. When you run the updated version of `docker scan`, you should also see a message
|
||||
in the output log similar to:
|
||||
If your code output contains `ORGAPACHELOGGINGLOG4J`, it is likely that your
|
||||
code is affected by the Log4j 2 CVE-2021-44228 vulnerability. When you run the
|
||||
updated version of `docker scan`, you should also see a message in the output
|
||||
log similar to:
|
||||
|
||||
```console
|
||||
Upgrade org.apache.logging.log4j:log4j-core@2.14.0 to org.apache.logging.log4j:log4j-core@2.15.0 to fix
|
||||
|
|
@ -92,13 +106,15 @@ Upgrade org.apache.logging.log4j:log4j-core@2.14.0 to org.apache.logging.log4j:l
|
|||
introduced by org.apache.logging.log4j:log4j-core@2.14.0
|
||||
```
|
||||
|
||||
For more information, read our blog post [Apache Log4j 2
|
||||
CVE-2021-44228](https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/){:
|
||||
For more information, read our blog post
|
||||
[Apache Log4j 2 CVE-2021-44228](https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/){:
|
||||
target="_blank" rel="noopener" class="_"}.
|
||||
|
||||
## How to scan images
|
||||
|
||||
The `docker scan` command allows you to scan existing Docker images using the image name or ID. For example, run the following command to scan the hello-world image:
|
||||
The `docker scan` command allows you to scan existing Docker images using the
|
||||
image name or ID. For example, run the following command to scan the hello-world
|
||||
image:
|
||||
|
||||
```console
|
||||
$ docker scan hello-world
|
||||
|
|
@ -118,7 +134,8 @@ Note that we do not currently have vulnerability data for your image.
|
|||
|
||||
## Using an HTTP proxy
|
||||
|
||||
If your computer needs to use an HTTP proxy, then set the `HTTPS_PROXY` environment variable when using scan. For example:
|
||||
If your computer needs to use an HTTP proxy, then set the `HTTPS_PROXY`
|
||||
environment variable when using scan. For example:
|
||||
|
||||
```console
|
||||
$ export HTTPS_PROXY=http://username:password@proxyAddress:port
|
||||
|
|
@ -132,13 +149,18 @@ or for PowerShell:
|
|||
> docker scan hello-world
|
||||
```
|
||||
|
||||
Note that `docker scan` does not use the same proxy settings as Docker Desktop or the settings specified in `.docker/config.json` or the settings used by the Docker engine.
|
||||
Note that `docker scan` does not use the same proxy settings as Docker Desktop
|
||||
or the settings specified in `.docker/config.json` or the settings used by the
|
||||
Docker engine.
|
||||
|
||||
### Get a detailed scan report
|
||||
|
||||
You can get a detailed scan report about a Docker image by providing the Dockerfile used to create the image. The syntax is `docker scan --file PATH_TO_DOCKERFILE DOCKER_IMAGE`.
|
||||
You can get a detailed scan report about a Docker image by providing the
|
||||
Dockerfile used to create the image. The syntax is
|
||||
`docker scan --file PATH_TO_DOCKERFILE DOCKER_IMAGE`.
|
||||
|
||||
For example, if you apply the option to the `docker-scan` test image, it displays the following result:
|
||||
For example, if you apply the option to the `docker-scan` test image, it
|
||||
displays the following result:
|
||||
|
||||
```console
|
||||
$ docker scan --file Dockerfile docker-scan:e2e
|
||||
|
|
@ -169,7 +191,9 @@ According to our scan, you are currently using the most secure version of the se
|
|||
|
||||
### Excluding the base image
|
||||
|
||||
When using docker scan with the `--file` flag, you can also add the `--exclude-base` tag. This excludes the base image (specified in the Dockerfile using the `FROM` directive) vulnerabilities from your report. For example:
|
||||
When using docker scan with the `--file` flag, you can also add the
|
||||
`--exclude-base` tag. This excludes the base image (specified in the Dockerfile
|
||||
using the `FROM` directive) vulnerabilities from your report. For example:
|
||||
|
||||
```console
|
||||
$ docker scan --file Dockerfile --exclude-base docker-scan:e2e
|
||||
|
|
@ -200,7 +224,8 @@ Tested 200 dependencies for known issues, found 16 issues.
|
|||
|
||||
### Viewing the JSON output
|
||||
|
||||
You can also display the scan result as a JSON output by adding the `--json` flag to the command. For example:
|
||||
You can also display the scan result as a JSON output by adding the `--json`
|
||||
flag to the command. For example:
|
||||
|
||||
```console
|
||||
$ docker scan --json hello-world
|
||||
|
|
@ -253,7 +278,8 @@ $ docker scan --json hello-world
|
|||
}
|
||||
```
|
||||
|
||||
In addition to the `--json` flag, you can also use the `--group-issues` flag to display a vulnerability only once in the scan report:
|
||||
In addition to the `--json` flag, you can also use the `--group-issues` flag to
|
||||
display a vulnerability only once in the scan report:
|
||||
|
||||
```console
|
||||
$ docker scan --json --group-issues docker-scan:e2e
|
||||
|
|
@ -307,7 +333,8 @@ You can find all the sources of the vulnerability in the `from` section.
|
|||
|
||||
### Checking the dependency tree
|
||||
|
||||
To view the dependency tree of your image, use the --dependency-tree flag. This displays all the dependencies before the scan result. For example:
|
||||
To view the dependency tree of your image, use the --dependency-tree flag. This
|
||||
displays all the dependencies before the scan result. For example:
|
||||
|
||||
```console
|
||||
$ docker scan --dependency-tree debian:buster
|
||||
|
|
@ -372,39 +399,44 @@ Tested 200 dependencies for known issues, found 157 issues.
|
|||
For more free scans that keep your images secure, sign up to Snyk at https://dockr.ly/3ePqVcp.
|
||||
```
|
||||
|
||||
For more information about the vulnerability data, see [Docker Vulnerability Scanning CLI Cheat Sheet](https://goto.docker.com/rs/929-FJL-178/images/cheat-sheet-docker-desktop-vulnerability-scanning-CLI.pdf){: target="_blank" rel="noopener" class="_"}.
|
||||
For more information about the vulnerability data, see
|
||||
[Docker Vulnerability Scanning CLI Cheat Sheet](https://goto.docker.com/rs/929-FJL-178/images/cheat-sheet-docker-desktop-vulnerability-scanning-CLI.pdf){:
|
||||
target="_blank" rel="noopener" class="_"}.
|
||||
|
||||
### Limiting the level of vulnerabilities displayed
|
||||
|
||||
Docker scan allows you to choose the level of vulnerabilities displayed in your scan report using the `--severity` flag.
|
||||
You can set the severity flag to `low`, `medium`, or `high` depending on the level of vulnerabilities you’d like to see in your report.
|
||||
For example, if you set the severity level as `medium`, the scan report displays all vulnerabilities that are classified as medium and high.
|
||||
|
||||
```console
|
||||
$ docker scan --severity=medium docker-scan:e2e
|
||||
Docker scan allows you to choose the level of vulnerabilities displayed in your
|
||||
scan report using the `--severity` flag. You can set the severity flag to `low`,
|
||||
`medium`, or `high` depending on the level of vulnerabilities you’d like to see
|
||||
in your report.
|
||||
For example, if you set the severity level as `medium`, the scan report displays
|
||||
all vulnerabilities that are classified as medium and high.
|
||||
|
||||
```console
|
||||
$ docker scan --severity=medium docker-scan:e2e
|
||||
./bin/docker-scan_darwin_amd64 scan --severity=medium docker-scan:e2e
|
||||
|
||||
Testing docker-scan:e2e...
|
||||
|
||||
✗ Medium severity vulnerability found in sqlite3/libsqlite3-0
|
||||
Description: Divide By Zero
|
||||
Info: https://snyk.io/vuln/SNYK-DEBIAN10-SQLITE3-466337
|
||||
Introduced through: gnupg2/gnupg@2.2.12-1+deb10u1, subversion@1.10.4-1+deb10u1, mercurial@4.8.2-1+deb10u1
|
||||
From: gnupg2/gnupg@2.2.12-1+deb10u1 > gnupg2/gpg@2.2.12-1+deb10u1 > sqlite3/libsqlite3-0@3.27.2-3
|
||||
From: subversion@1.10.4-1+deb10u1 > subversion/libsvn1@1.10.4-1+deb10u1 > sqlite3/libsqlite3-0@3.27.2-3
|
||||
From: mercurial@4.8.2-1+deb10u1 > python-defaults/python@2.7.16-1 > python2.7@2.7.16-2+deb10u1 > python2.7/libpython2.7-stdlib@2.7.16-2+deb10u1 > sqlite3/libsqlite3-0@3.27.2-3
|
||||
Description: Divide By Zero
|
||||
Info: https://snyk.io/vuln/SNYK-DEBIAN10-SQLITE3-466337
|
||||
Introduced through: gnupg2/gnupg@2.2.12-1+deb10u1, subversion@1.10.4-1+deb10u1, mercurial@4.8.2-1+deb10u1
|
||||
From: gnupg2/gnupg@2.2.12-1+deb10u1 > gnupg2/gpg@2.2.12-1+deb10u1 > sqlite3/libsqlite3-0@3.27.2-3
|
||||
From: subversion@1.10.4-1+deb10u1 > subversion/libsvn1@1.10.4-1+deb10u1 > sqlite3/libsqlite3-0@3.27.2-3
|
||||
From: mercurial@4.8.2-1+deb10u1 > python-defaults/python@2.7.16-1 > python2.7@2.7.16-2+deb10u1 > python2.7/libpython2.7-stdlib@2.7.16-2+deb10u1 > sqlite3/libsqlite3-0@3.27.2-3
|
||||
|
||||
✗ Medium severity vulnerability found in sqlite3/libsqlite3-0
|
||||
Description: Uncontrolled Recursion
|
||||
Description: Uncontrolled Recursion
|
||||
...
|
||||
✗ High severity vulnerability found in binutils/binutils-common
|
||||
Description: Missing Release of Resource after Effective Lifetime
|
||||
Info: https://snyk.io/vuln/SNYK-DEBIAN10-BINUTILS-403318
|
||||
Introduced through: gcc-defaults/g++@4:8.3.0-1
|
||||
From: gcc-defaults/g++@4:8.3.0-1 > gcc-defaults/gcc@4:8.3.0-1 > gcc-8@8.3.0-6 > binutils@2.31.1-16 > binutils/binutils-common@2.31.1-16
|
||||
From: gcc-defaults/g++@4:8.3.0-1 > gcc-defaults/gcc@4:8.3.0-1 > gcc-8@8.3.0-6 > binutils@2.31.1-16 > binutils/libbinutils@2.31.1-16 > binutils/binutils-common@2.31.1-16
|
||||
From: gcc-defaults/g++@4:8.3.0-1 > gcc-defaults/gcc@4:8.3.0-1 > gcc-8@8.3.0-6 > binutils@2.31.1-16 > binutils/binutils-x86-64-linux-gnu@2.31.1-16 > binutils/binutils-common@2.31.1-16
|
||||
and 4 more...
|
||||
Description: Missing Release of Resource after Effective Lifetime
|
||||
Info: https://snyk.io/vuln/SNYK-DEBIAN10-BINUTILS-403318
|
||||
Introduced through: gcc-defaults/g++@4:8.3.0-1
|
||||
From: gcc-defaults/g++@4:8.3.0-1 > gcc-defaults/gcc@4:8.3.0-1 > gcc-8@8.3.0-6 > binutils@2.31.1-16 > binutils/binutils-common@2.31.1-16
|
||||
From: gcc-defaults/g++@4:8.3.0-1 > gcc-defaults/gcc@4:8.3.0-1 > gcc-8@8.3.0-6 > binutils@2.31.1-16 > binutils/libbinutils@2.31.1-16 > binutils/binutils-common@2.31.1-16
|
||||
From: gcc-defaults/g++@4:8.3.0-1 > gcc-defaults/gcc@4:8.3.0-1 > gcc-8@8.3.0-6 > binutils@2.31.1-16 > binutils/binutils-x86-64-linux-gnu@2.31.1-16 > binutils/binutils-common@2.31.1-16
|
||||
and 4 more...
|
||||
|
||||
Organization: docker-desktop-test
|
||||
Package manager: deb
|
||||
|
|
@ -418,7 +450,9 @@ Tested 200 dependencies for known issues, found 37 issues.
|
|||
|
||||
## Provider authentication
|
||||
|
||||
If you have an existing Snyk account, you can directly use your Snyk [API token](https://app.snyk.io/account){: target="_blank" rel="noopener" class="_"}:
|
||||
If you have an existing Snyk account, you can directly use your Snyk
|
||||
[API token](https://app.snyk.io/account){: target="_blank" rel="noopener"
|
||||
class="_"}:
|
||||
|
||||
```console
|
||||
$ docker scan --login --token SNYK_AUTH_TOKEN
|
||||
|
|
@ -426,25 +460,32 @@ $ docker scan --login --token SNYK_AUTH_TOKEN
|
|||
Your account has been authenticated. Snyk is now ready to be used.
|
||||
```
|
||||
|
||||
If you use the `--login` flag without any token, you will be redirected to the Snyk website to login.
|
||||
If you use the `--login` flag without any token, you will be redirected to the
|
||||
Snyk website to login.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To run vulnerability scanning on your Docker images, you must meet the following requirements:
|
||||
To run vulnerability scanning on your Docker images, you must meet the following
|
||||
requirements:
|
||||
|
||||
1. Download and install the latest version of Docker Desktop.
|
||||
|
||||
- [Download for Mac with Intel chip](https://desktop.docker.com/mac/main/amd64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-amd64)
|
||||
- [Download for Mac with Apple chip](https://desktop.docker.com/mac/main/arm64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-arm64)
|
||||
- [Download for Windows](https://desktop.docker.com/win/main/amd64/Docker%20Desktop%20Installer.exe)
|
||||
- [Download for Mac with Intel chip](https://desktop.docker.com/mac/main/amd64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-amd64)
|
||||
- [Download for Mac with Apple chip](https://desktop.docker.com/mac/main/arm64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-arm64)
|
||||
- [Download for Windows](https://desktop.docker.com/win/main/amd64/Docker%20Desktop%20Installer.exe)
|
||||
|
||||
2. Sign into [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"}.
|
||||
2. Sign into [Docker Hub](https://hub.docker.com){: target="_blank"
|
||||
rel="noopener" class="_"}.
|
||||
|
||||
3. From the Docker Desktop menu, select **Sign in/ Create Docker ID**. Alternatively, open a terminal and run the command `docker login`.
|
||||
3. From the Docker Desktop menu, select **Sign in/ Create Docker ID**.
|
||||
Alternatively, open a terminal and run the command `docker login`.
|
||||
|
||||
4. (Optional) You can create a [Snyk account](https://dockr.ly/3ePqVcp){: target="_blank" rel="noopener" class="_"} for scans, or use the additional monthly free scans provided by Snyk with your Docker Hub account.
|
||||
4. (Optional) You can create a [Snyk account](https://dockr.ly/3ePqVcp){:
|
||||
target="_blank" rel="noopener" class="_"} for scans, or use the additional
|
||||
monthly free scans provided by Snyk with your Docker Hub account.
|
||||
|
||||
Check your installation by running `docker scan --version`, it should print the current version of docker scan and the Snyk engine version. For example:
|
||||
Check your installation by running `docker scan --version`, it should print the
|
||||
current version of docker scan and the Snyk engine version. For example:
|
||||
|
||||
```console
|
||||
$ docker scan --version
|
||||
|
|
@ -455,34 +496,40 @@ Provider: Snyk (1.432.0)
|
|||
|
||||
> **Note:**
|
||||
>
|
||||
> Docker Scan uses the Snyk binary installed in your environment by default. If
|
||||
this is not available, it uses the Snyk binary embedded in Docker Desktop.
|
||||
> The minimum version required for Snyk is `1.385.0`.
|
||||
> Docker Scan uses the Snyk binary installed in your environment by default. If
|
||||
> this is not available, it uses the Snyk binary embedded in Docker Desktop. The
|
||||
> minimum version required for Snyk is `1.385.0`.
|
||||
|
||||
## Supported options
|
||||
|
||||
The high-level `docker scan` command scans local images using the image name or the image ID. It supports the following options:
|
||||
The high-level `docker scan` command scans local images using the image name or
|
||||
the image ID. It supports the following options:
|
||||
|
||||
| Option | Description |
|
||||
|:------------------------------------------------------------------ :------------------------------------------------|
|
||||
| `--accept-license` | Accept the license agreement of the third-party scanning provider |
|
||||
| `--dependency-tree` | Display the dependency tree of the image along with scan results |
|
||||
| `--exclude-base` | Exclude the base image during scanning. This option requires the --file option to be set |
|
||||
| Option | Description |
|
||||
| :-------------------: | ------------------------------------------------------------------------------------------------------------- |
|
||||
| `--accept-license` | Accept the license agreement of the third-party scanning provider |
|
||||
| `--dependency-tree` | Display the dependency tree of the image along with scan results |
|
||||
| `--exclude-base` | Exclude the base image during scanning. This option requires the --file option to be set |
|
||||
| `-f`, `--file string` | Specify the location of the Dockerfile associated with the image. This option displays a detailed scan result |
|
||||
| `--json` | Display the result of the scan in JSON format|
|
||||
| `--login` | Log into Snyk using an optional token (using the flag --token), or by using a web-based token |
|
||||
| `--reject-license` | Reject the license agreement of the third-party scanning provider |
|
||||
| `--severity string` | Only report vulnerabilities of provided level or higher (low, medium, high) |
|
||||
| `--token string` | Use the authentication token to log into the third-party scanning provider |
|
||||
| `--version` | Display the Docker Scan plugin version |
|
||||
| `--json` | Display the result of the scan in JSON format |
|
||||
| `--login` | Log into Snyk using an optional token (using the flag --token), or by using a web-based token |
|
||||
| `--reject-license` | Reject the license agreement of the third-party scanning provider |
|
||||
| `--severity string` | Only report vulnerabilities of provided level or higher (low, medium, high) |
|
||||
| `--token string` | Use the authentication token to log into the third-party scanning provider |
|
||||
| `--version` | Display the Docker Scan plugin version |
|
||||
|
||||
## Known issues
|
||||
|
||||
**WSL 2**
|
||||
|
||||
- The Vulnerability scanning feature doesn’t work with Alpine distributions.
|
||||
- If you are using Debian and OpenSUSE distributions, the login process only works with the `--token` flag, you won’t be redirected to the Snyk website for authentication.
|
||||
- If you are using Debian and OpenSUSE distributions, the login process only
|
||||
works with the `--token` flag, you won’t be redirected to the Snyk website for
|
||||
authentication.
|
||||
|
||||
## Feedback
|
||||
|
||||
Your feedback is very important to us. Let us know your feedback by creating an issue in the [scan-cli-plugin](https://github.com/docker/scan-cli-plugin/issues/new){: target="_blank" rel="noopener" class="_"} GitHub repository.
|
||||
Your feedback is very important to us. Let us know your feedback by creating an
|
||||
issue in the
|
||||
[scan-cli-plugin](https://github.com/docker/scan-cli-plugin/issues/new){:
|
||||
target="_blank" rel="noopener" class="_"} GitHub repository.
|
||||
|
|
|
|||
|
|
@ -4,55 +4,6 @@ keywords: get started, setup, orientation, quickstart, intro, concepts, containe
|
|||
description: Tips for building the images for our application
|
||||
---
|
||||
|
||||
## Security scanning
|
||||
|
||||
When you have built an image, it is a good practice to scan it for security vulnerabilities using the `docker scan` command.
|
||||
Docker has partnered with [Snyk](https://snyk.io){:target="_blank" rel="noopener" class="_"} to provide the vulnerability scanning service.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You must be logged in to Docker Hub to scan your images. Run the command `docker scan --login`, and then scan your images using
|
||||
> `docker scan <image-name>`.
|
||||
|
||||
For example, to scan the `getting-started` image you created earlier in the tutorial, you can just type
|
||||
|
||||
```console
|
||||
$ docker scan getting-started
|
||||
```
|
||||
|
||||
The scan uses a constantly updated database of vulnerabilities, so the output you see will vary as new
|
||||
vulnerabilities are discovered, but it might look something like this:
|
||||
|
||||
```plaintext
|
||||
✗ Low severity vulnerability found in freetype/freetype
|
||||
Description: CVE-2020-15999
|
||||
Info: https://snyk.io/vuln/SNYK-ALPINE310-FREETYPE-1019641
|
||||
Introduced through: freetype/freetype@2.10.0-r0, gd/libgd@2.2.5-r2
|
||||
From: freetype/freetype@2.10.0-r0
|
||||
From: gd/libgd@2.2.5-r2 > freetype/freetype@2.10.0-r0
|
||||
Fixed in: 2.10.0-r1
|
||||
|
||||
✗ Medium severity vulnerability found in libxml2/libxml2
|
||||
Description: Out-of-bounds Read
|
||||
Info: https://snyk.io/vuln/SNYK-ALPINE310-LIBXML2-674791
|
||||
Introduced through: libxml2/libxml2@2.9.9-r3, libxslt/libxslt@1.1.33-r3, nginx-module-xslt/nginx-module-xslt@1.17.9-r1
|
||||
From: libxml2/libxml2@2.9.9-r3
|
||||
From: libxslt/libxslt@1.1.33-r3 > libxml2/libxml2@2.9.9-r3
|
||||
From: nginx-module-xslt/nginx-module-xslt@1.17.9-r1 > libxml2/libxml2@2.9.9-r3
|
||||
Fixed in: 2.9.9-r4
|
||||
```
|
||||
|
||||
The output lists the type of vulnerability, a URL to learn more, and importantly which version of the relevant library
|
||||
fixes the vulnerability.
|
||||
|
||||
There are several other options, which you can read about in the [docker scan documentation](../engine/scan/index.md).
|
||||
|
||||
As well as scanning your newly built image on the command line, you can also [configure Docker Hub](../docker-hub/vulnerability-scanning.md)
|
||||
to scan all newly pushed images automatically, and you can then see the results in both Docker Hub and Docker Desktop.
|
||||
|
||||
{: style=width:75% }
|
||||
{: .text-center }
|
||||
|
||||
## Image layering
|
||||
|
||||
Did you know that you can look at what makes up an image? Using the `docker image history`
|
||||
|
|
@ -267,4 +218,4 @@ build-time dependencies from runtime dependencies.
|
|||
|
||||
In the next section, you'll learn about additional resources you can use to continue learning about containers.
|
||||
|
||||
[What next](11_what_next.md){: .button .primary-btn}
|
||||
[What next](11_what_next.md){: .button .primary-btn}
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 125 KiB |
|
|
@ -314,8 +314,6 @@ $ docker build --tag docker-gs-ping .
|
|||
=> => exporting layers 0.0s
|
||||
=> => writing image sha256:336a3f164d0f079f2e42cd1d38f24ab9110d47d481f1db7f2a0b0d2859ec 0.0s
|
||||
=> => naming to docker.io/library/docker-gs-ping 0.0s
|
||||
|
||||
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
|
||||
```
|
||||
|
||||
Your exact output will vary, but provided there aren't any errors, you should
|
||||
|
|
|
|||
|
|
@ -0,0 +1,115 @@
|
|||
---
|
||||
description: Image analysis with Docker Scout
|
||||
keywords: scanning, vulnerabilities, Hub, supply chain, security
|
||||
title: Advanced image analysis
|
||||
---
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Scout is an [early access](../release-lifecycle.md#early-access-ea)
|
||||
> product, and requires a Pro, Team, or Business subscription.
|
||||
|
||||
Advanced image analysis is a Docker Scout feature for Docker Hub.
|
||||
|
||||
When you activate Advanced image analysis for a repository, new tags are
|
||||
automatically analyzed when you push to that repository. Advanced image analysis
|
||||
is more than point-in-time scanning - your analysis gets reevaluated
|
||||
continuously, meaning you don't need to re-scan the image to see an updated
|
||||
vulnerability report. Information about packages and CVEs displays on the image
|
||||
tag page on Docker Hub, as well as in the image details view in Docker Desktop.
|
||||
|
||||
## Activate Advanced image analysis
|
||||
|
||||
Advanced image analysis is an early access feature. It can be activated on a
|
||||
per-repository basis for organizations with a Pro, Team, or Business
|
||||
subscription.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Only repository owners and administrators can activate Advanced image analysis
|
||||
> on a repository.
|
||||
|
||||
To activate Advanced image analysis:
|
||||
|
||||
1. Log into your Docker Hub account.
|
||||
2. Click **Repositories** from the main menu and select a repository from the
|
||||
list.
|
||||
3. Go to the **Settings** tab
|
||||
4. Under **Image insight settings**, select **Advanced image analysis provided
|
||||
by Docker Scout**.
|
||||
5. Select **Save**.
|
||||
|
||||
## Analyze an image
|
||||
|
||||
To trigger Advanced image analysis, push the image to a Docker Hub repository
|
||||
where Advanced image analysis is active:
|
||||
|
||||
1. Sign in to your Docker ID, either using the `docker login` command or the
|
||||
**Sign in** button in Docker Desktop.
|
||||
2. Tag the image that you’d like to analyze. For example, to tag a Redis image,
|
||||
run:
|
||||
|
||||
```console
|
||||
$ docker tag redis <org>/<imagename>:latest
|
||||
```
|
||||
|
||||
3. Push the image to Docker Hub to trigger analysis of the image:
|
||||
|
||||
```console
|
||||
$ docker push <org>/<imagename>:latest
|
||||
```
|
||||
|
||||
## View the vulnerability report
|
||||
|
||||
To view the vulnerability report on Docker Hub:
|
||||
|
||||
1. Go to Docker Hub and open the repository page. A vulnerability summary is
|
||||
available in the **Tags** section of the page.
|
||||
|
||||
It may take a few minutes for the vulnerability report to appear in your
|
||||
repository. If your vulnerability summary doesn't display yet, wait a moment
|
||||
and then refresh the page.
|
||||
|
||||
2. Click on the tag in the table. This opens the details page for the tag.
|
||||
|
||||
3. Select the **Vulnerabilities** tab on the right side of the page.
|
||||
|
||||
This tab displays a deep-dive view of your vulnerability exposure. If your
|
||||
image contains packages known to be affected by vulnerabilities, those
|
||||
packages show up here.
|
||||
|
||||
For more information about how to interpret the vulnerability report, see
|
||||
[Image details view](./image-details-view.md)
|
||||
|
||||
Expanding any of the packages in the list shows you more information about the
|
||||
vulnerabilities that affect a given package. Clicking on the hyperlink of a
|
||||
vulnerability opens it in Docker's image vulnerability database, which provides
|
||||
even more information on the vulnerability and what images it affects.
|
||||
|
||||
## Deactivate Advanced image analysis
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Only repository owners and administrators can deactivate Advanced image
|
||||
> analysis on a repository.
|
||||
|
||||
To deactivate Advanced image analysis:
|
||||
|
||||
1. Go to Docker Hub and sign in.
|
||||
2. Select **Repositories** from the main menu and select a repository from the
|
||||
list.
|
||||
3. Go to the **Settings** tab.
|
||||
4. Under **Image insight settings**, and select one of the following options:
|
||||
|
||||
- **None** if you want to completely turn off vulnerability detection
|
||||
- **Hub vulnerability scanning** if you want to use the basic scanning
|
||||
feature.
|
||||
|
||||
5. Select **Save**.
|
||||
|
||||
## Feedback
|
||||
|
||||
Thank you for trying out the Advanced image analysis feature. Give feedback or
|
||||
report any bugs you may find through the issues tracker on the
|
||||
[hub-feedback](https://github.com/docker/hub-feedback/issues){: target="_blank"
|
||||
rel="noopener" class="_"} GitHub repository.
|
||||
|
|
@ -0,0 +1,171 @@
|
|||
---
|
||||
description: >
|
||||
Integrate JFrog Artifactory and JFrog Container Registry with Docker Scout
|
||||
keywords: >
|
||||
docker scout, jfrog, artifactory, jcr, integration, image analysis, security,
|
||||
cves
|
||||
title: Artifactory integration
|
||||
---
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Scout is an [early access](../release-lifecycle.md#early-access-ea)
|
||||
> product.
|
||||
>
|
||||
> If you're interested in this integration for your organization and want to
|
||||
> learn more, get in touch by filling out the contact form on the
|
||||
> [Docker Scout product page](https://docker.com/products/scout){:
|
||||
> target="\_blank" rel="noopener" }.
|
||||
|
||||
Integrating Docker Scout with JFrog Artifactory lets you run image analysis
|
||||
automatically on images in your Artifactory registries.
|
||||
|
||||
This integration is made possible by a monitoring agent. The agent is a
|
||||
standalone service that analyzes images and uploads the result to Docker Scout.
|
||||
You can view the results using the
|
||||
[Docker Scout web UI](https://dso.docker.com/){: target="\_blank" rel="noopener"
|
||||
}.
|
||||
|
||||
## How it works
|
||||
|
||||
The Docker Scout Artifactory agent is available as an
|
||||
[image on Docker Hub](https://hub.docker.com/r/docker/artifactory-agent){:
|
||||
target="\_blank" rel="noopener" }. The agent works by continuously polling
|
||||
Artifactory for new images. When it finds a new image, it performs the following
|
||||
steps:
|
||||
|
||||
1. Pull the image from Artifactory
|
||||
2. Analyze the image
|
||||
3. Upload the analysis result to Docker Scout
|
||||
|
||||
The agent records the Software Bill of Material (SBOM) for the image, and the
|
||||
SBOMs for all of it's base images. The recorded SBOMs include both OS-level and
|
||||
application-level programs or dependencies that the image contains.
|
||||
|
||||
Additionally, metadata about the image itself is also recorded:
|
||||
|
||||
- The source repository for the image
|
||||
- Build instructions
|
||||
- Build date
|
||||
- Tags and digest
|
||||
- Target platforms
|
||||
- Layer sizes
|
||||
|
||||
The agent transacts this data to Docker Scout. The agent never transacts the
|
||||
image itself, nor any data inside the image, such as code, binaries, and layer
|
||||
blobs.
|
||||
|
||||
The agent doesn't detect and analyze pre-existing images. It only analyzes
|
||||
images that appear in the registry while the agent is running.
|
||||
|
||||
## Deploy the agent
|
||||
|
||||
This section describes the steps for deploying the Artifactory agent.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before you deploy the agent, ensure that the prerequisites are met:
|
||||
|
||||
- The server where you host the agent can access the following resources over
|
||||
the network:
|
||||
- Your JFrog Artifactory instance
|
||||
- `hub.docker.com`, port 443, for authenticating with Docker
|
||||
- `api.dso.docker.com`, port 443, for transacting data to Docker Scout
|
||||
- The server is not behind a proxy
|
||||
- The registries are Docker V2 registries. V1 registries are not supported.
|
||||
|
||||
The agent supports all versions of JFrog Artifactory and JFrog Container
|
||||
Registry.
|
||||
|
||||
### Create the configuration file
|
||||
|
||||
You configure the agent using a JSON file. The agent expects the configuration
|
||||
file to be in `/opt/artifactory-agent/data/config.json` on startup.
|
||||
|
||||
The configuration file includes the following properties:
|
||||
|
||||
| Property | Description |
|
||||
| --------------------------- | ------------------------------------------------------------------------------- |
|
||||
| `agent_id` | Unique identifier for the agent. |
|
||||
| `docker.organization_name` | Name of the Docker organization. |
|
||||
| `docker.username` | Username of the admin user in the Docker organization. |
|
||||
| `docker.pat` | Personal access token of the admin user with read and write permissions. |
|
||||
| `artifactory.base_url` | Base URL of the Artifactory instance. |
|
||||
| `artifactory.username` | Username of the Artifactory user with read permissions that the agent will use. |
|
||||
| `artifactory.password` | Password or API token for the Artifactory user. |
|
||||
| `artifactory.image_filters` | Optional: List of repositories and images to analyze. |
|
||||
|
||||
If you don't specify any repositories in `artifactory.image_filters`, the agent
|
||||
runs image analysis on all images in your Artifactory instance.
|
||||
|
||||
The following snippet shows a sample configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"agent_id": "acme-prod-agent",
|
||||
"docker": {
|
||||
"organization_name": "acme",
|
||||
"username": "mobythewhale",
|
||||
"pat": "dckr_pat__dsaCAs_xL3kNyupAa7dwO1alwg"
|
||||
},
|
||||
"artifactory": [
|
||||
{
|
||||
"base_url": "https://acme.jfrog.io",
|
||||
"username": "acmeagent",
|
||||
"password": "hayKMvFKkFp42RAwKz2K",
|
||||
"image_filters": [
|
||||
{
|
||||
"repository": "dev-local",
|
||||
"images": ["internal/repo1", "internal/repo2"]
|
||||
},
|
||||
{
|
||||
"repository": "prod-local",
|
||||
"images": ["staging/repo1", "prod/repo1"]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Create a configuration file and save it somewhere on the server where you plan
|
||||
to run the agent. For example, `/var/opt/artifactory-agent/config.json`.
|
||||
|
||||
### Run the agent
|
||||
|
||||
The following example shows how to run the Docker Scout Artifactory agent using
|
||||
`docker run`. This command creates a bind mount for the directory containing the
|
||||
JSON configuration file created earlier to `/opt/artifactory-agent/data` inside
|
||||
the container. Make sure the mount path you use is the directory containing the
|
||||
`config.json` file.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> **Important**
|
||||
>
|
||||
> Use the `v1` tag of the Artifactory agent image. Don't use the `latest` tag as
|
||||
> doing so may incur breaking changes.
|
||||
{: .important }
|
||||
|
||||
```console
|
||||
$ docker run \
|
||||
--mount type=bind,src=/var/opt/artifactory-agent,target=/opt/artifactory-agent/data \
|
||||
docker/artifactory-agent:v1
|
||||
```
|
||||
|
||||
## View analysis results
|
||||
|
||||
You can view the image analysis results in the Docker Scout web UI.
|
||||
|
||||
1. Go to [Docker Scout web UI](https://dso.docker.com).
|
||||
2. Sign in using your Docker ID.
|
||||
|
||||
Once signed in, you're taken to the **Images** page. This page displays the
|
||||
repositories in your organization connected to Docker Scout.
|
||||
|
||||
3. Select the image in the list.
|
||||
4. Select the tag.
|
||||
|
||||
When you have selected a tag, you're taken to the vulnerability report for that
|
||||
tag. Here, you can select if you want to view all vulnerabilities in the image,
|
||||
or vulnerabilities introduced in a specific layer. You can also filter
|
||||
vulnerabilities by severity, and whether or not there's a fix version available.
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
title: Image details view
|
||||
keywords: scout, supply chain, vulnerabilities, packages, cves, image, tag
|
||||
description: >
|
||||
Docker Scout helps you understand your images and their dependencies
|
||||
---
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Scout is an [early access](../release-lifecycle.md#early-access-ea)
|
||||
> product, and requires a Pro, Team, or Business subscription.
|
||||
|
||||
The image details view shows a breakdown of the Docker Scout analysis. You can
|
||||
access the image view both from within Docker Desktop, and from the image tag
|
||||
page on Docker Hub. This view provides a breakdown of the image hierarchy (base
|
||||
images), image layers, packages, and vulnerabilities.
|
||||
|
||||
The image view lets you inspect the composition of an image from different
|
||||
perspectives. The view displays vulnerabilities and packages that an image
|
||||
contains. You can choose whether you want to see data for the image as a whole,
|
||||
or for a specific base image or layer.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
## Image Hierarchy
|
||||
|
||||
The image you inspect may have one or more base images listed under **Image
|
||||
hierarchy**. This means the author of the image used another image as a starting
|
||||
point when building the image. Often these base images are either operating
|
||||
system images such as Debian, Ubuntu, and Alpine, or programming language images
|
||||
such as PHP, Python, and Java.
|
||||
|
||||
A base image may have its own parent base image so there is a chain of base
|
||||
images represented in **Image hierarchy**. Selecting each image in the chain
|
||||
lets you see which layers originate from each base image. Selecting the **ALL**
|
||||
row reselects all the layers and base images for the entire image.
|
||||
|
||||
One or more of the base images may have updates available, which may include
|
||||
updated security patches that remove vulnerabilities from your image. Any base
|
||||
images with available updates are noted to the right of **Image hierarchy**.
|
||||
|
||||
## Layers
|
||||
|
||||
A Docker image consists of layers. Image layers are listed from top to bottom,
|
||||
with the earliest layer at the top and the most recent layer at the bottom.
|
||||
Often, the layers at the top of the list originate from a base image, and the
|
||||
layers towards the bottom are layers added by the image author, often by adding
|
||||
commands to a Dockerfile. To see which layers originate from a base image,
|
||||
simply select a base image under **Image hierarchy** and the relevant layers are
|
||||
highlighted.
|
||||
|
||||
Selecting individual or multiple layers filters the packages and vulnerabilities
|
||||
on the right-hand side to see what has been added by the selected layers.
|
||||
|
||||
## Vulnerabilities
|
||||
|
||||
Images may be exposed to vulnerabilities and exploits. These are detected and
|
||||
listed on the right-hand side, grouped by package, and sorted in order of
|
||||
severity. Further information on whether the vulnerability has an available fix,
|
||||
for example, can be examined by expanding the sections.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 152 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 817 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
|
|
@ -0,0 +1,75 @@
|
|||
---
|
||||
title: Docker Scout
|
||||
keywords: scout, supply chain, vulnerabilities, packages, cves
|
||||
description: >
|
||||
Docker Scout helps you understand your images and their dependencies
|
||||
redirect_from:
|
||||
- /atomist/
|
||||
- /atomist/try-atomist/
|
||||
- /atomist/get-started/
|
||||
- /atomist/configure/settings/
|
||||
- /atomist/configure/advisories/
|
||||
- /atomist/integrate/github/
|
||||
- /atomist/integrate/deploys/
|
||||
---
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Scout is an [early access](../release-lifecycle.md#early-access-ea)
|
||||
> product, and requires a Pro, Team, or Business subscription.
|
||||
|
||||
Docker Scout is a collection of software supply chain features that appear
|
||||
throughout Docker user interfaces and the CLI. These features provide detailed
|
||||
insights into the composition and security of container images.
|
||||
|
||||
Docker Scout analyzes the image contents and generates a detailed report of
|
||||
packages and vulnerabilities that it detects. Docker Scout can also help provide
|
||||
you with suggestions for how you can remediate issues discovered by the image
|
||||
analysis.
|
||||
|
||||
The [image details view](./image-details-view.md) in Docker Desktop and the tag
|
||||
details pages on Docker Hub are both powered by Docker Scout.
|
||||
|
||||
You can view and interact with Docker Scout from your terminal through the
|
||||
`docker scout`
|
||||
[plugin for Docker CLI](../engine/reference/commandline/scout_cves.md).
|
||||
|
||||
There's also a [web UI](https://dso.docker.com/explore){: target="\_blank"
|
||||
rel="noopener" } that you can use to explore additional information about
|
||||
images, packages, and CVEs.
|
||||
|
||||
## Get started with Docker Scout
|
||||
|
||||
To start using Docker Scout, enable any of the following features:
|
||||
|
||||
- Advanced image analysis in Docker Hub
|
||||
- Artifactory integration
|
||||
|
||||
Enabling either feature requires a paid Docker subscription. Once enabled,
|
||||
Docker Scout is activated for your organization automatically.
|
||||
|
||||
### Advanced image analysis
|
||||
|
||||
Advanced image analysis is a feature in Docker Hub which, when enabled, triggers
|
||||
a Docker Scout analysis every time you push an image. The analysis updates
|
||||
continuously, meaning that the vulnerability report for an image is always up to
|
||||
date as new CVEs are discovered. No need to re-scan an image.
|
||||
|
||||
For more information, see
|
||||
[Advanced image analysis](./advanced-image-analysis.md).
|
||||
|
||||
### Artifactory integration
|
||||
|
||||
Users of JFrog Artifactory, or JFrog Container Registry, can integrate Docker
|
||||
Scout to enable automatic analysis of images. For more information, see
|
||||
[Artifactory integration](./artifactory.md).
|
||||
|
||||
## Docker Scout CLI
|
||||
|
||||
The `docker scout` CLI plugin provides a terminal interface for Docker Scout.
|
||||
|
||||
Using the CLI, you can analyze images and view the analysis report in a text
|
||||
format. You can print the results directly to stdout, or export them to a file
|
||||
using a structured format, such as Static Analysis Results Interchange Format
|
||||
(SARIF). For more information about how to use the `docker scout` CLI, see the
|
||||
[reference documentation](../engine/reference/commandline/scout_cves.md).
|
||||
|
|
@ -12,18 +12,6 @@ toc_max: 2
|
|||
|
||||
We strongly encourage you to update to the latest version of [Apache Commons Text](https://commons.apache.org/proper/commons-text/download_text.cgi){:target="_blank" rel="noopener" class="_"}.
|
||||
|
||||
### Scan images using the `docker scan` command
|
||||
|
||||
`docker scan` as shipped with latest versions of Docker Desktop detects the Text4Shell CVE-2022-42889 vulnerability.
|
||||
|
||||
If an image is vulnerable to CVE-2022-42889, the output of `docker scan` will contain the following text:
|
||||
|
||||
```
|
||||
Upgrade org.apache.commons:commons-text@1.9 to org.apache.commons:commons-text@1.10.0 to fix
|
||||
✗ Arbitrary Code Execution (new) [High Severity][https://snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-3043138] in org.apache.commons:commons-text@1.9
|
||||
introduced by org.apache.commons:commons-text@1.9
|
||||
```
|
||||
|
||||
### Scan images on Docker Hub
|
||||
|
||||
Docker Hub security scans triggered **after 1200 UTC 21 October 2021** are now
|
||||
|
|
@ -96,13 +84,6 @@ target="_blank" rel="noopener" class="_"}, the fix made in version 2.15.0 was
|
|||
> For a more complete fix to this vulnerability, we recommended that you update to 2.17.0 where possible.
|
||||
{: .important}
|
||||
|
||||
### Scan images using the `docker scan` command
|
||||
|
||||
The configurations for the `docker scan` command previously shipped in Docker
|
||||
Desktop versions 4.3.0 and earlier unfortunately do not detect this
|
||||
vulnerability on scans. You must update your Docker Desktop installation to
|
||||
4.3.1 or higher to fix this issue. For detailed instructions, see [Scan images for Log4j 2 CVE](../engine/scan/index.md#scan-images-for-log4j-2-cve).
|
||||
|
||||
### Scan images on Docker Hub
|
||||
|
||||
Docker Hub security scans triggered **after 1700 UTC 13 December 2021** are now
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ The following sections provide an overview of each tier. To compare features ava
|
|||
|
||||
## Docker Personal
|
||||
|
||||
Docker Personal is the new name for the Docker Free subscription. With its focus on the open-source communities, individual developers, education, and small businesses, Docker Personal will continue to allow free use of Docker components - including the Docker CLI, Docker Compose, Docker Engine, Docker Desktop, Docker Hub, Kubernetes, Docker Build and Docker BuildKit, Docker Official Images, Docker Scan, and more.
|
||||
Docker Personal is the new name for the Docker Free subscription. With its focus on the open-source communities, individual developers, education, and small businesses, Docker Personal will continue to allow free use of Docker components - including the Docker CLI, Docker Compose, Docker Engine, Docker Desktop, Docker Hub, Kubernetes, Docker Build and Docker BuildKit, Docker Official Images, and more.
|
||||
|
||||
Docker Personal includes unlimited public repositories, unlimited [Scoped Access Tokens](../docker-hub/access-tokens.md), and unlimited collaborators for public repositories at no cost per month.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue