From 890ccc1734837b3aea4e500847ea271a6c6dbc29 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Mon, 20 Mar 2023 11:45:37 +0100 Subject: [PATCH 1/4] DVP draft --- .github/vale/Vocab/Docker/accept.txt | 2 + docker-hub/publish/index.md | 25 ++++++----- docker-hub/publish/insights-analytics.md | 56 +++++++++++------------- docker-hub/vulnerability-scanning.md | 37 ++++++++-------- 4 files changed, 59 insertions(+), 61 deletions(-) diff --git a/.github/vale/Vocab/Docker/accept.txt b/.github/vale/Vocab/Docker/accept.txt index d1b0f6466b..30b809ff0b 100644 --- a/.github/vale/Vocab/Docker/accept.txt +++ b/.github/vale/Vocab/Docker/accept.txt @@ -24,3 +24,5 @@ Swarm Mode [Mm]oby dockerd dockerignore +Docker Hub Vulnerability Scanning +Basic vulnerability scanning \ No newline at end of file diff --git a/docker-hub/publish/index.md b/docker-hub/publish/index.md index 2cb0f5df72..b3a445f32d 100644 --- a/docker-hub/publish/index.md +++ b/docker-hub/publish/index.md @@ -20,7 +20,7 @@ redirect_from: --- The Verified Publisher Program provides several features and benefits to Docker -Hub publishers. The following perks are granted based on participation tier: +Hub publishers. The program grants the following perks based on participation tier: - Verified publisher badge - Insights and analytics @@ -32,8 +32,8 @@ Hub publishers. The following perks are granted based on participation tier: ## Verified publisher badge The verified publisher badge signals high quality, and trust, to developers. -Images with this badge are verified as high quality, and the content can be -trusted. + +Images from publishers with this badge are verified as high quality, and that users can trust the content. ![Docker, Inc. org with a verified publisher badge](./images/verified-publisher-badge.png) @@ -46,17 +46,18 @@ behavior. ![The insights and analytics tab on the Docker Hub website](./images/insights-and-analytics-tab.png) -Select the time span you want to view analytics data, and export the data in -either a summary or raw format. The summary format shows you image pulls per -tag, and the raw format lists information about every image pull for the -selected time span. Data points include tag, type of pull, user geolocation, -client tool (user agent), and more. +You can use the view to select the time span you want to view analytics data and export the data in +either a summary or raw format. + +The summary format shows image pulls per tag, and the raw format lists information about every image pull for the +selected time span. Data points include tag, type of pull, user geolocation, client tool (user agent), and more. ## Vulnerability scanning - -Automatic vulnerability scanning using Snyk for images published to Docker Hub. -Scanning images ensures that the published content is secure, and underlines to -developers that it can be trusted. Scanning can be enabled on a per-repository + +[Docker Scout](/scout/){: +target="blank" rel="noopener" class=""} provides automatic vulnerability scanning for images published to Docker Hub. +Scanning images ensures that the published content is secure, and preoves to +developers that they can trust the image. You can enable scanning on a per-repository basis, refer to [vulnerability scanning](/docker-hub/vulnerability-scanning/){: target="blank" rel="noopener" class=""} for more information about how to use it. diff --git a/docker-hub/publish/insights-analytics.md b/docker-hub/publish/insights-analytics.md index 081bb3d690..20286cc2b3 100644 --- a/docker-hub/publish/insights-analytics.md +++ b/docker-hub/publish/insights-analytics.md @@ -14,19 +14,17 @@ to learn more about the benefits of becoming a verified publisher. ## View the analytics data -Analytics data for your repositories is available on the **Insights and +You can find analytics data for your repositories on the **Insights and analytics** dashboard at the following URL: `https://hub.docker.com/orgs/{namespace}/insights`. The dashboard contains a -chart visualization of the usage data, as well as a table where you can download +visualization of the usage data and a table where you can download the data as CSV files. To view data in the chart: - Select the data granularity: weekly or monthly - Select the time interval: 3, 6, or 12 months -- Select one or more repositories in the list. - - You can filter the list by repository name. +- Select one or more repositories in the list ![Insights and analytics chart visualization](./images/chart.png) @@ -37,18 +35,17 @@ To view data in the chart: > for points in time. {: .tip } -### Share +### Share analytics data -You can share the visualization chart with others using the share icon located -just above the chart: +You can share the visualization with others using the share icon above the chart. +This is a convenient way to share statistics with others in your organization. ![Chart share icon](./images/chart-share-icon.png) Selecting the icon generates a link that gets copied to your clipboard. The link -preserves the display selections you've made. When someone uses the link, the +preserves the display selections you made. When someone uses the link, the **Insights and analytics** page opens and displays the chart with the same -configuration as you had set up when creating the link. This is a convenient way -to quickly share statistics with others in your organization. +configuration as you had set up when creating the link. ## Exporting analytics data @@ -63,8 +60,7 @@ can analyze it manually as a spreadsheet. ### Export data using the website -Here's how to export usage data for your organization's images using the Docker -Hub website. +Export usage data for your organization's images using the Docker Hub website by following these steps: 1. Sign in to [Docker Hub](https://hub.docker.com/){: target="_blank" rel="noopener" class="_"} and select **Organizations**. @@ -103,7 +99,7 @@ represents an image pull. | Data point | Description | Date added | | ----------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------- | | Action | Request type, see [Action classification rules][1]. One of `pull_by_tag`, `pull_by_digest`, `version_check`. | January 1, 2022 | -| Action day | The date part of the timestamp: `YYYY-MM-DD` | January 1, 2022 | +| Action day | The date part of the timestamp: `YYYY-MM-DD`. | January 1, 2022 | | Country | Request origin country. | January 1, 2022 | | Digest | Image digest. | January 1, 2022 | | HTTP method | HTTP method used in the request, see [registry API documentation][2] for details. | January 1, 2022 | @@ -112,8 +108,8 @@ represents an image pull. | Reference | Image digest or tag used in the request. | January 1, 2022 | | Repository | Docker [repository][4] (image name). | January 1, 2022 | | Tag (included when available) | Tag name that's only available if the request referred to a tag. | January 1, 2022 | -| Timestamp | Date and time of the request: `YYYY-MM-DD 00:00:00` | January 1, 2022 | -| Type | The industry from which the event originates. One of `business`, `isp`, `hosting`, `education`, `null` | January 1, 2022 | +| Timestamp | Date and time of the request: `YYYY-MM-DD 00:00:00`. | January 1, 2022 | +| Type | The industry from which the event originates. One of `business`, `isp`, `hosting`, `education`, `null`. | January 1, 2022 | | User agent tool | The application a user used to pull an image (for example, `docker` or `containerd`). | January 1, 2022 | | User agent version | The version of the application used to pull an image. | January 1, 2022 | | Domain | Request origin domain, see [Privacy](#privacy). | October 11, 2022 | @@ -161,20 +157,20 @@ The following table describes the rules applied for determining intent behind pulls. To provide feedback or ask questions about these rules, [fill out the Google Form](https://forms.gle/nb7beTUQz9wzXy1b6){: target="_blank" rel="noopener" class="_"}. - + | Starting event | Reference | Followed by | Resulting action | Use case(s) | Notes | | :------------- | :-------- | :-------------------------------------------------------------- | :--------------- | :------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| HEAD | tag | N/A | Version check | User already has all layers existing on local machine | This is similar to the use case of a pull by tag when the user already has all the image layers existing locally, however, we are able to differentiate the user intent and classify accordingly. | -| GET | tag | N/A | Pull by tag | User already has all layers existing on local machine and/or the image is single-arch | -| GET | tag | Get by different digest | Pull by tag | Image is multi-arch | Second GET by digests must be different from the first | -| HEAD | tag | GET by same digest | Pull by tag | Image is multi-arch but some or all image layers already exist on the local machine. | The HEAD by tag will send the most current digest, the following GET must be by that same digest. There may occur an additional GET, if the image is multi-arch (see the next row in this table). If the user doesn't want the most recent digest, then the user would perform HEAD by digest. | -| HEAD | tag | GET by the same digest, then a second GET by a different digest | Pull by tag | Image is multi-arch | The HEAD by tag will send the most recent digest, the following GET must be by that same digest. Since the image is multi-arch, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user would perform HEAD by digest. | -| HEAD | tag | GET by same digest, then a second GET by different digest | Pull by tag | Image is multi-arch | The HEAD by tag will send the most current digest, the following GET must be by that same digest. Since the image is multi-arch, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user would perform HEAD by digest. | -| GET | digest | N/A | Pull by digest | User already has all layers existing on local machine and/or the image is single-arch | -| HEAD | digest | N/A | Pull by digest | User already has all layers existing on their local machine. | -| GET | digest | GET by different digest | Pull by digest | Image is multi-arch | The second GET by digest must be different from the first | -| HEAD | digest | GET by same digest | Pull by digest | Image is single arch and/or image is multi-arch but some part of the image already exists on the local machine | -| HEAD | digest | GET by same digest, then a second GET by different digest | Pull by Digest | Image is multi-arch | +| HEAD | tag | N/A | Version check | User already has all layers existing on local machine | This is similar to the use case of a pull by tag when the user already has all the image layers existing locally, however, it differentiates the user intent and classifies accordingly. | +| GET | tag | N/A | Pull by tag | User already has all layers existing on local machine and/or the image is single-architecture | +| GET | tag | Get by different digest | Pull by tag | Image is multi-architecture | Second GET by digest must be different from the first. | +| HEAD | tag | GET by same digest | Pull by tag | Image is multi-architecture but some or all image layers already exist on the local machine | The HEAD by tag sends the most current digest, the following GET must be by that same digest. There may occur an additional GET, if the image is multi-architecture (see the next row in this table). If the user doesn't want the most recent digest, then the user performs HEAD by digest. | +| HEAD | tag | GET by the same digest, then a second GET by a different digest | Pull by tag | Image is multi-architecture | The HEAD by tag sends the most recent digest, the following GET must be by that same digest. Since the image is multi-architecture, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. | +| HEAD | tag | GET by same digest, then a second GET by different digest | Pull by tag | Image is multi-architecture | The HEAD by tag sends the most current digest, the following GET must be by that same digest. Since the image is multi-architecture, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. | +| GET | digest | N/A | Pull by digest | User already has all layers existing on local machine and/or the image is single-architecture | +| HEAD | digest | N/A | Pull by digest | User already has all layers existing on their local machine | +| GET | digest | GET by different digest | Pull by digest | Image is multi-architecture | The second GET by digest must be different from the first. | +| HEAD | digest | GET by same digest | Pull by digest | Image is single-architecture and/or image is multi-architecture but some part of the image already exists on the local machine | +| HEAD | digest | GET by same digest, then a second GET by different digest | Pull by Digest | Image is multi-architecture | ## Changes in data over time @@ -200,11 +196,11 @@ consumers of content on Docker Hub remain completely anonymous. > analytics data. {: .important } -The summary dataset includes Unique IP address count. This data point only +The summary dataset includes unique IP address count. This data point only includes the number of distinct unique IP addresses that request an image. Individual IP addresses are never shared. -The raw dataset includes user IP domains as a data point. That's the domain name +The raw dataset includes user IP domains as a data point. This is the domain name associated with the IP address used to pull an image. If the IP type is `business`, the domain represents the company or organization associated with that IP address (for example, `docker.com`). For any other IP type that's not diff --git a/docker-hub/vulnerability-scanning.md b/docker-hub/vulnerability-scanning.md index 21e2a919f7..d37fbc3712 100644 --- a/docker-hub/vulnerability-scanning.md +++ b/docker-hub/vulnerability-scanning.md @@ -22,7 +22,7 @@ Scan results include: - The source of the vulnerability, such as Operating System (OS) packages and libraries -- The version in which it was introduced +- The version which introduced the vulnerability - A recommended fixed version (if available) to remediate the vulnerabilities discovered. @@ -51,14 +51,14 @@ improving your security posture. ## 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 +can toggle 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** +> **Image types supported** > > Basic vulnerability scanning supports scanning images which are of AMD64 > architecture, Linux OS, and are less than 10 GB in size. @@ -67,24 +67,24 @@ a Team, or a Business subscription can view the detailed scan reports. 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 +the repository you want 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 +2. Select **Repositories** from the main menu and select a repository from the list. -3. Go to the **Settings** tab. +3. Select 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: +To scan an image for vulnerabilities, push to the +repository for the image to Docker Hub 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. @@ -117,14 +117,13 @@ To view the vulnerability report: ![Vulnerability scan report](images/vuln-scan-report.png){:width="700px"} -2. Click on the **Tags** tab > **Digest** > **Vulnerabilities** to view the +2. Select the **Tags** tab > **Digest** > **Vulnerabilities** to view the detailed scan report. - The scan report displays vulnerabilities identified by the scan, sorting them + The scan report displays the vulnerabilities identified, 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. + version that introduced it, and whether a later version fixes the vulnerability. ![Vulnerability scan details](images/vuln-scan-details.png){:width="700px"} @@ -133,18 +132,18 @@ For more information on this view, see ### Inspect vulnerabilities -The vulnerability report sorts vulnerabilities based on their severity. It +The scan report displays the vulnerabilities identified, 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 has been fixed -in a later version. +version that introduced it, and whether a later version fixes the vulnerability. -The vulnerability scan report also allows development teams and security leads +The vulnerability scan report helps development teams and security leads to compare the vulnerability counts across tags to see whether the vulnerabilities are decreasing or increasing over time. ### Fix vulnerabilities -Once a list of vulnerabilities have been identified, there are a couple of +Once you have identified a list of vulnerabilities, there are a couple of actions you can take to remediate the vulnerabilities. For example, you can: 1. Specify an updated base image in the Dockerfile, check your application-level @@ -167,8 +166,8 @@ a repository. To disable scanning: 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 +2. Select **Repositories** from the main menu and select a repository from the list. -3. Go to the **Settings** tab. +3. Select the **Settings** tab. 4. Under **Image insight settings**, select **None**. 5. Select **Save**. From d75c07c194e9e8e0887ce8607ebe2f33021faf0e Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 6 Apr 2023 09:46:42 +0200 Subject: [PATCH 2/4] Draft --- docker-hub/publish/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docker-hub/publish/index.md b/docker-hub/publish/index.md index b3a445f32d..0df2d83853 100644 --- a/docker-hub/publish/index.md +++ b/docker-hub/publish/index.md @@ -53,10 +53,10 @@ The summary format shows image pulls per tag, and the raw format lists informati selected time span. Data points include tag, type of pull, user geolocation, client tool (user agent), and more. ## Vulnerability scanning - + [Docker Scout](/scout/){: target="blank" rel="noopener" class=""} provides automatic vulnerability scanning for images published to Docker Hub. -Scanning images ensures that the published content is secure, and preoves to +Scanning images ensures that the published content is secure, and proves to developers that they can trust the image. You can enable scanning on a per-repository basis, refer to [vulnerability scanning](/docker-hub/vulnerability-scanning/){: target="blank" rel="noopener" class=""} for more information about how to use From 7dde6e40c6da56de651e017bb9f586bb69e14da0 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 6 Apr 2023 10:14:04 +0200 Subject: [PATCH 3/4] Draft --- .github/vale/Vocab/Docker/accept.txt | 1 + docker-hub/publish/index.md | 2 +- docker-hub/publish/insights-analytics.md | 32 ++++++++++---------- docker-hub/vulnerability-scanning.md | 37 ++++++++++++------------ 4 files changed, 38 insertions(+), 34 deletions(-) diff --git a/.github/vale/Vocab/Docker/accept.txt b/.github/vale/Vocab/Docker/accept.txt index 30b809ff0b..55de96b6d7 100644 --- a/.github/vale/Vocab/Docker/accept.txt +++ b/.github/vale/Vocab/Docker/accept.txt @@ -25,4 +25,5 @@ Swarm Mode dockerd dockerignore Docker Hub Vulnerability Scanning +Docker Vulnerability Scanning Basic vulnerability scanning \ No newline at end of file diff --git a/docker-hub/publish/index.md b/docker-hub/publish/index.md index 0df2d83853..446585c5c0 100644 --- a/docker-hub/publish/index.md +++ b/docker-hub/publish/index.md @@ -55,7 +55,7 @@ selected time span. Data points include tag, type of pull, user geolocation, cli ## Vulnerability scanning [Docker Scout](/scout/){: -target="blank" rel="noopener" class=""} provides automatic vulnerability scanning for images published to Docker Hub. +target="blank" rel="noopener" class=""} provides automatic vulnerability scanning for DVP images published to Docker Hub. Scanning images ensures that the published content is secure, and proves to developers that they can trust the image. You can enable scanning on a per-repository basis, refer to [vulnerability scanning](/docker-hub/vulnerability-scanning/){: diff --git a/docker-hub/publish/insights-analytics.md b/docker-hub/publish/insights-analytics.md index 20286cc2b3..38cdc5b6c5 100644 --- a/docker-hub/publish/insights-analytics.md +++ b/docker-hub/publish/insights-analytics.md @@ -4,11 +4,13 @@ description: Provides usage statistics of your images on Docker Hub. keywords: docker hub, hub, insights, analytics, api, verified publisher --- -Insights and analytics provides usage analytics for your Docker Verified -Publisher (DVP) images on Docker Hub. With this tool, you have self-serve access +Insights and analytics provides usage analytics for Docker Verified +Publisher (DVP) images on Docker Hub, providing self-serve access to metrics as both raw data and summary data for a desired time span. You can view number of image pulls by tag or by digest, and get breakdowns by -geolocation, cloud provider, client, and more. Head to the +geolocation, cloud provider, client, and more. + +Head to the [Docker Verified Publisher Program page](https://www.docker.com/partners/programs/){: target="blank" rel="noopener" class="_" } to learn more about the benefits of becoming a verified publisher. @@ -42,8 +44,8 @@ This is a convenient way to share statistics with others in your organization. ![Chart share icon](./images/chart-share-icon.png) -Selecting the icon generates a link that gets copied to your clipboard. The link -preserves the display selections you made. When someone uses the link, the +Selecting the icon generates a link that's copied to your clipboard. The link +preserves the display selections you made. When someone follows the link, the **Insights and analytics** page opens and displays the chart with the same configuration as you had set up when creating the link. @@ -58,7 +60,7 @@ Sunday) or monthly format. Monthly data is available from the first day of the following calendar month. You can import this data into your own systems, or you can analyze it manually as a spreadsheet. -### Export data using the website +### Export data Export usage data for your organization's images using the Docker Hub website by following these steps: @@ -161,16 +163,16 @@ target="_blank" rel="noopener" class="_"}. | Starting event | Reference | Followed by | Resulting action | Use case(s) | Notes | | :------------- | :-------- | :-------------------------------------------------------------- | :--------------- | :------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | HEAD | tag | N/A | Version check | User already has all layers existing on local machine | This is similar to the use case of a pull by tag when the user already has all the image layers existing locally, however, it differentiates the user intent and classifies accordingly. | -| GET | tag | N/A | Pull by tag | User already has all layers existing on local machine and/or the image is single-architecture | -| GET | tag | Get by different digest | Pull by tag | Image is multi-architecture | Second GET by digest must be different from the first. | -| HEAD | tag | GET by same digest | Pull by tag | Image is multi-architecture but some or all image layers already exist on the local machine | The HEAD by tag sends the most current digest, the following GET must be by that same digest. There may occur an additional GET, if the image is multi-architecture (see the next row in this table). If the user doesn't want the most recent digest, then the user performs HEAD by digest. | -| HEAD | tag | GET by the same digest, then a second GET by a different digest | Pull by tag | Image is multi-architecture | The HEAD by tag sends the most recent digest, the following GET must be by that same digest. Since the image is multi-architecture, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. | -| HEAD | tag | GET by same digest, then a second GET by different digest | Pull by tag | Image is multi-architecture | The HEAD by tag sends the most current digest, the following GET must be by that same digest. Since the image is multi-architecture, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. | -| GET | digest | N/A | Pull by digest | User already has all layers existing on local machine and/or the image is single-architecture | +| GET | tag | N/A | Pull by tag | User already has all layers existing on local machine and/or the image is single-arch | +| GET | tag | Get by different digest | Pull by tag | Image is multi-arch | Second GET by digest must be different from the first. | +| HEAD | tag | GET by same digest | Pull by tag | Image is multi-arch but some or all image layers already exist on the local machine | The HEAD by tag sends the most current digest, the following GET must be by that same digest. There may occur an additional GET, if the image is multi-arch (see the next row in this table). If the user doesn't want the most recent digest, then the user performs HEAD by digest. | +| HEAD | tag | GET by the same digest, then a second GET by a different digest | Pull by tag | Image is multi-arch | The HEAD by tag sends the most recent digest, the following GET must be by that same digest. Since the image is multi-arch, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. | +| HEAD | tag | GET by same digest, then a second GET by different digest | Pull by tag | Image is multi-arch | The HEAD by tag sends the most current digest, the following GET must be by that same digest. Since the image is multi-arch, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. | +| GET | digest | N/A | Pull by digest | User already has all layers existing on local machine and/or the image is single-arch | | HEAD | digest | N/A | Pull by digest | User already has all layers existing on their local machine | -| GET | digest | GET by different digest | Pull by digest | Image is multi-architecture | The second GET by digest must be different from the first. | -| HEAD | digest | GET by same digest | Pull by digest | Image is single-architecture and/or image is multi-architecture but some part of the image already exists on the local machine | -| HEAD | digest | GET by same digest, then a second GET by different digest | Pull by Digest | Image is multi-architecture | +| GET | digest | GET by different digest | Pull by digest | Image is multi-arch | The second GET by digest must be different from the first. | +| HEAD | digest | GET by same digest | Pull by digest | Image is single-arch and/or image is multi-arch but some part of the image already exists on the local machine | +| HEAD | digest | GET by same digest, then a second GET by different digest | Pull by Digest | Image is multi-arch | ## Changes in data over time diff --git a/docker-hub/vulnerability-scanning.md b/docker-hub/vulnerability-scanning.md index d37fbc3712..21e2a919f7 100644 --- a/docker-hub/vulnerability-scanning.md +++ b/docker-hub/vulnerability-scanning.md @@ -22,7 +22,7 @@ Scan results include: - The source of the vulnerability, such as Operating System (OS) packages and libraries -- The version which introduced the vulnerability +- The version in which it was introduced - A recommended fixed version (if available) to remediate the vulnerabilities discovered. @@ -51,14 +51,14 @@ improving your security posture. ## Scan images with Basic vulnerability scanning Repository owners and administrators of a Docker Pro, Team, or a Business tier -can toggle Basic vulnerability scanning. When scanning is active on a +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. -> **Image types supported** +> **Note** > > Basic vulnerability scanning supports scanning images which are of AMD64 > architecture, Linux OS, and are less than 10 GB in size. @@ -67,24 +67,24 @@ a Team, or a Business subscription can view the detailed scan reports. 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 want to enable scanning on is part of the Team or a +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. Select **Repositories** from the main menu and select a repository from the +2. Click **Repositories** from the main menu and select a repository from the list. -3. Select the **Settings** tab. +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 to the -repository for the image to Docker Hub which you have turned on scanning: +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. @@ -117,13 +117,14 @@ To view the vulnerability report: ![Vulnerability scan report](images/vuln-scan-report.png){:width="700px"} -2. Select the **Tags** tab > **Digest** > **Vulnerabilities** to view the +2. Click on the **Tags** tab > **Digest** > **Vulnerabilities** to view the detailed scan report. - The scan report displays the vulnerabilities identified, sorting them + 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 that introduced it, and whether a later version fixes the vulnerability. + version in which it was introduced, and whether the vulnerability is fixed in + a later version. ![Vulnerability scan details](images/vuln-scan-details.png){:width="700px"} @@ -132,18 +133,18 @@ For more information on this view, see ### Inspect vulnerabilities -The scan report displays the vulnerabilities identified, sorting them -according to their severity, with highest severity listed at the top. It +The vulnerability report sorts vulnerabilities based on their severity. It displays information about the package that contains the vulnerability, the -version that introduced it, and whether a later version fixes the vulnerability. +version in which it was introduced, and whether the vulnerability has been fixed +in a later version. -The vulnerability scan report helps development teams and security leads +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. ### Fix vulnerabilities -Once you have identified a list of vulnerabilities, there are a couple of +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: 1. Specify an updated base image in the Dockerfile, check your application-level @@ -166,8 +167,8 @@ a repository. To disable scanning: 1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} account. -2. Select **Repositories** from the main menu and select a repository from the +2. Go to **Repositories** from the main menu and select a repository from the list. -3. Select the **Settings** tab. +3. Go to the **Settings** tab. 4. Under **Image insight settings**, select **None**. 5. Select **Save**. From 5573db454000c45f86c7327eb08fbfe71ac375e9 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Wed, 12 Apr 2023 14:44:08 +0200 Subject: [PATCH 4/4] Remove comment that got left behind --- docker-hub/publish/insights-analytics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docker-hub/publish/insights-analytics.md b/docker-hub/publish/insights-analytics.md index 38cdc5b6c5..1fa6d3d642 100644 --- a/docker-hub/publish/insights-analytics.md +++ b/docker-hub/publish/insights-analytics.md @@ -159,7 +159,7 @@ The following table describes the rules applied for determining intent behind pulls. To provide feedback or ask questions about these rules, [fill out the Google Form](https://forms.gle/nb7beTUQz9wzXy1b6){: target="_blank" rel="noopener" class="_"}. - + | Starting event | Reference | Followed by | Resulting action | Use case(s) | Notes | | :------------- | :-------- | :-------------------------------------------------------------- | :--------------- | :------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | HEAD | tag | N/A | Version check | User already has all layers existing on local machine | This is similar to the use case of a pull by tag when the user already has all the image layers existing locally, however, it differentiates the user intent and classifies accordingly. |