Publish content on Docker HubEstimated reading time: 13 minutes
Permitted content and support options
Content that runs on Docker Enterprise may be published on Docker Hub under a Verified Publisher profile. This content may also qualify to become a Docker Certified Container or Plugin image, and thus backed by collaborative Docker/Publisher support.
Content that runs on the Docker Community may be published in Docker Hub, but is not supported by Docker nor is it eligible to become Certified.
Content that requires a non Certified Infrastructure environment may not be published.
|If your content:||Can publish||Can be Certified||Supported by publisher|
|Works on Docker Enterprise||YES||YES||Required|
|Works on Docker Community||YES||NO||Optional|
|Does not work on Docker Certified Infrastructure||NO||N/A||N/A|
The Docker Hub publishing process begins from the landing page: sign in with your Docker ID and specify a product name and image source from a private or public repository.
After specifying a source, provide the content-manifest items to populate your product details page. These items include logos, descriptions, and licensing and support links so that customers can make informed decisions about your image. These items are submitted alongside the image itself for moderation.
The Docker Hub team then conducts a comprehensive review of your image and metadata. We use Docker Security Scanning to evaluate the security of your product images, and share results with you as the publisher. During the image-moderation phase, we iterate back and forth with publishers to address outstanding vulnerabilities and content-manifest issues until the image is ready for publication.
Commercial content and other supported images may qualify for the Docker Certified Container or Plugins quality mark. The testing for this program goes beyond the vulnerability scan and also evaluates container images for Docker best practices developed over years of experience. Collaborative support capability between Docker and the publisher is also established. Refer to the diagram below for a high-level summary:
Create great content
Create your content, and follow our best practices to Dockerize it. Keep your images small, your layers few, and your components secure. Refer to the links and guidelines listed below to build and deliver great content:
Here are some best practices when it comes to building vulnerability-free Docker images:
Choose a secure base image (See your Dockerfile’s
Many base images have a strong record of being secure, including:
Debian Linux: both small and tightly-controlled, Debian-linux is a good alternative if you’re currently using Ubuntu.
Alpine Linux: Alpine is a minimal linux distribution with an excellent security record.
Alpine-based application images: these include
golang:alpine. They are secure and minimal, while providing the convenience of their non-Alpine alternatives.
Docker strongly recommends Alpine Linux. The founder of this Linux distribution is leading an initiative at Docker to provide safe, compact base images for all container applications.
Remove unused components
Often, vulnerabilities exist in components that aren’t actually used in the containerized application. To avoid this, you can:
Follow best practices when using the
apt-get-removeto destroy any components required to build but not actually run your application. Usually, this involves creating multi-line Dockerfile directives, as seen below. The following example shows how to remove
python-pipafter they are used to install the Python
requestspackage, all in a single Dockerfile directive:
RUN apt-get update && \ apt-get install -y --no-install-recommends curl python-pip && \ pip install requests && \ apt-get remove -y python-pip curl && \ rm -rf /var/lib/apt/lists/
Files introduced in one directive of your Dockerfile can only be removed in the same directive (and not in subsequent directives in your Dockerfile).
Keep required components up-to-date
Your images are composed of open-source libraries and packages that amass vulnerabilities over time and are consequently patched. To ensure the integrity of your product, keep your images up-to-date:
Periodically update your base image’s version, especially if you’re using a version deemed to be vulnerable.
Re-build your image periodically. Directives including commands such as
apt-get install ...pull the latest versions of dependencies, which may include security fixes.
Create and maintain your Verified Publisher profile
Let the Docker community know who you are. Add your details, your company story, and what you do. At the very minimum, we require:
- Legal entity name
- Company website
- Phone number
- Valid company email
- Company icon/logo (square; at least 512x512px)
Prepare your image-manifest materials
You must provide the namespace (including repository and tags) of a private or public repository on Docker Hub that contains the source for your product. This repository path is not shown to users, but the repositories you choose determine the Product Tiers available for customers to download.
The following content information helps us make your product look great and discoverable:
- Product Name
- Product icon/logo
- Short description: a one-to-two-sentence summary; up to 140 characters
- Category: Database, Networking, Business Software, etc. and any search tags
- Long description: includes product details/pitch
- Support link
- Product tier name
- Product tier description
- Product tier price
- Installation instructions
- Link to, or text of, license agreements
How the manifest information is displayed in the UI
This is an approximate representation, and some elements might shift around as we make enhancements.
Support your users
Docker users who download your content might need help later, so be prepared for questions! The information you provide with your submission saves support time in the future.
If you provide support along with your content, include that information. Is there a support website? What email address can users contact for help? Are there self-help or troubleshooting resources available?
Include a Service Level Agreement (SLA) for each image you’re offering. An SLA is your commitment to your users about the nature and level of support you provide to them. Make sure your SLA includes support hours and response-time expectations, where applicable.
Security and audit policies
Docker Security Scanning
Docker Security Scanning automatically and continuously assesses the intergity of your products. The Docker Security Scanning tool deconstructs an image, conducts a binary scan of the bits to identify the open-source components present in each image layer, and associates those components with known vulnerabilities and exposures.
Docker then shares the scan results with you as the publisher, so that you can modify the content of your images as necessary. Your scan results are private, and are never shared with end customers or other publishers.
To interpret the results of a scanned image:
Log on to Docker Hub.
Navigate to the repository details page (for example, Nginx).
Click View Available Tags under the pull command in the upper right of the UI.
Displalyed is a list of each tag scan with its age. A solid green bar indicates a clean scan without known vulnerabilities. Yellow, orange, and red indicate minor, major, and critical vulnerabilities respectively.
Vulnerability scores are defined by the entity that issues the vulnerability, such as NVD, and are based on a Qualitative Severity Rating Scale defined as part of the Common Vulnerability Scoring System (CVSS) specification.
Click a scan summary to see a list of results for each layer of the image.
Each layer may have one or more scannable components represented by colored squares in a grid.
Base layers contain components that are included in the parent image, but that you did not build and may not be able to edit. If a base layer has a vulnerability, switch to a version of the parent image that does not have any vulnerabilities, or to a similar but more secure image.
Hover over a square in the grid, then click to see the vulnerability report for that specific component.
Only components that add software are scanned. If a layer has no scannable components, it shows a
No components in this layermessage.
Click the arrow icon (twice) to expand the list and show all vulnerable components and their CVE report codes.
Click one of the CVE codes to view the original vulnerability report.
Classification of issues
All Scan results include the CVE numbers and a CVSS (Common Vulnerability Scoring System) Score.
CVE Identifiers (also referred to by the community as “CVE names,” “CVE numbers,” “CVE entries,” “CVE-IDs,” and “CVEs”) are unique identifiers for publicly-known, cyber-security vulnerabilities.
The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities. Its quantitative model ensures repeatable, accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the scores. As a result, CVSS is well-suited as a standard measurement system for industries, organizations, and governments that need accurate and consistent vulnerability-impact scores. CVSS is commonly used to prioritize vulnerability-remediation activities, and calculate the severity of vulnerabilities discovered on systems. The National Vulnerability Database (NVD) provides CVSS scores for almost all known vulnerabilities.
In addition to CVSS, the Docker Security team can identify or classify vulnerabilities that need to be fixed, and categorize them in the minor-to-critical range.
The publisher is presented with initial scan results, including all components with their CVEs and their CVSS scores.
If you use Docker’s Scanning Service, you can subscribe to a notification service for new vulnerabilities.
Usage audit and reporting
Unless otherwise negotiated, an audit of activity on publisher content is retained for no less than 180 days.
A monthly report of said activity is provided to the publisher with the following data: (1) report of content download by free and paid customers by date and time; (2) report of purchase, cancellations, refunds, tax payments, where applicable, and subscription length for paid customers of the content; and (3) the consolidated amount to be received by the publisher.
There are three types of certification that appear in Docker Hub.
Certifies that a container image on Docker Hub has been tested; complies best practices guidelines; runs on Docker Certified Infrastructure; has proven provenance; been scanned for vulnerabilities; and is supported by Docker and the content publisher
This certification is designed for volume, network, and other plugins that access system level Docker APIs. Docker Certified Plugins provide the same level of assurance as a Docker Certified Container, but go further by having passed an additional suite of API compliance testing.
Docker Certified Publisher FAQ
What is the Docker Certified program?
Docker Certified Container images and plugins are meant to differentiate high quality content on Docker Hub. Customers can consume Certified Containers with confidence knowing that both Docker and the publisher stands behind the solution. Further details and an application can be found here..
What are the benefits of Docker Certified?
Docker Hub promotes Docker Certified Containers and Plugins running on Docker Certified Infrastructure trusted and high quality content. The Docker Certified badge can also be listed alongside external references to your product.
How is the Docker Certified Container image listed on Docker Hub?
These images are differentiated from other images through a certification badge. A user can search specifically for CI’s by limiting their search parameters to show only certified content.
Is certification optional or required?
Certification is recommended for all commercial and supported container images. Free, community, and other commercial (non-certified) content may also be listed on Docker Hub.
How is support handled?
All Docker Certified Container images and plugins running on Docker Enterprise come with support provided directly by the publisher, under your existing SLA. Normally, a customer contacts the publisher for container and application level issues. Likewise, a customer contacts Docker for Docker Enterprise support. In the case where a customer calls Docker (or vice versa) about an issue on the application, Docker advises the customer about the publisher support process and performs a handover directly to the publisher if required. TSAnet is required for exchange of support tickets between the publisher and Docker.
How does a publisher apply to the Docker Certified program?
Start by applying to be a Docker Technology Partner
What is the difference between Official Images and Docker Certified?
Official Images is a program sponsored by Docker for the curation and packaging of Open Source Software. While upstream vendors are sometimes involved, this is not always the case. Docker Certified content is explicitly provided, maintained, and supported directly by the ISV.
How is certification of plugins handled?
Docker Certification program recognizes the need to apply special scrutiny and testing to containers that access system level interfaces like storage volumes and networking. Docker identifies these special containers as “Plugins” which require additional testing by the publisher or Docker.Docker, docker, hub, purchase images