Secure Software Supply Chain – Docker Mon, 22 May 2023 20:17:06 +0000 en-US hourly 1 Secure Software Supply Chain – Docker 32 32 5 Developer Workstation Security Best Practices Wed, 15 Feb 2023 15:00:00 +0000 Supply chain attacks increased by 300% between 2020 and 2021, making clear that security breaches are happening earlier in the software development lifecycle. Research also shows that in 2021, 80% of cyber security breaches were due to human error, and 20% involved attacks on desktops and laptops. 

Developer workstations are being targeted for several reasons. Workstations have access to critical code and infrastructure, and the earlier a vulnerability is introduced, the more difficult it can be to identify the breach. Developers need to trust not only the dependencies they use directly but also the dependencies of those dependencies, called transitive dependencies. As we see more incidents stemming from developer workstations, developer workstation security should be a top priority for security-conscious organizations. 

Poor security practices in software development translate to trust-breaking breaches and expensive losses, with the average cost of a security breach reaching $9.44 million in the United States. Developers are increasingly responsible for not only the development of products but also for secure development. 

Organizations, regardless of industry, must be securing developer workstations in order to be prepared for the evolving and growing number of attacks. 

Docker’s white paper, Securing Developer Workstations with Docker, covers the top security risks when developing with containers — and how to best mitigate those risks with Docker. By understanding the potential attack vectors, your teams can mitigate evolving security threats.

Let’s take a look at five actions you can take to secure your developer workstations.

5 workstation security best practices featured

1. Prevent malware attacks

Malware refers to malicious software meant to attack software, hardware, or networks. In container development, malware can be particularly damaging not only because of the potentially harmful activities to be run within the container but also because of potential access to external systems like the host’s file system and network.

Containers should be secured by using only trusted images and dependencies, isolating and restricting permissions where possible, and running up-to-date software in up-to-date environments.

2. Build secure software supply chains

Supply chain attacks exploit direct and transitive dependencies. You may be familiar with Log4Shell, a vulnerability affecting an estimated hundreds of millions of devices. The vulnerability behind the infamous SolarWinds security incident was also a supply chain attack. Supply chain attacks increased by 300% in 2021, and security experts don’t expect them to slow down any time soon. 

Supply chain attacks can be mitigated through secure supply chain best practices. These include making sure every step of the supply chain is trustworthy, adding key automation, and making sure brand environments are clearly defined.

3. Account for local admin rights in policies

Individual developers may have different needs for their workstations. Many developers prefer to have local admin rights. Organizations are responsible for creating and enforcing policies that help developers work securely. How your team handles local admin rights is a team decision, and although the outcomes may differ per team, the conversation around local admin rights is a necessity to keep teams secure.

Finding the balance of security and autonomy is an active state. No balance can be achieved and then forgotten about. Instead, organizations must regularly review tools and configurations so developers can do their jobs without being unnecessarily blocked or accidentally jeopardizing their team, product, and customers.

4. Prevent hazardous misconfigurations

Configurations are necessary at almost every step of the software development lifecycle and connect development tools with production resources, such as environments and sensitive data. While more permissive configurations make anything seem possible, unfortunately, that flexibility can accidentally provide malicious actors access to sensitive resources. Configurations that are too strict frustrate developers and limit productivity.

Misconfiguration does not happen on purpose, but it can be mitigated. There’s no one-size-fits-all solution for configurations, given every team and organization has its own tooling, process, and network considerations. Regardless of your organization’s needs, make sure you’re considering the developer workstations and how your IT admins manage local configurations.

5. Protect against insider threats

Although most breaches come from outside of an organization, 20% of breaches in 2021 were caused by internal actors. For the same reasons that external attackers target the early stages of the software development lifecycle, internal bad actors have used similar strategies to bypass internal security safeguards.

Security measures that limit opportunities for external attackers also limit opportunities for internal bad actors. When considering settings, configurations, permissions, and scanning, remember that regardless of where the attack comes from, the trend of attacks is moving earlier in the development cycle, making securing developer workstations a critical step in your security strategy.

Hardened Docker Desktop: Stronger security for enterprises

With capabilities like Hardened Docker Desktop, we want every developer using Docker to be able to work securely and create secure products without being slowed down or needlessly distracted. In Securing Developer Workstations with Docker, we share container security best practices developed and tested by industry experts.

Read the white paper: Securing Developer Workstations with Docker.

Securing the Software Supply Chain: Atomist Joins Docker Tue, 21 Jun 2022 15:00:16 +0000 I’m excited to share some big news: Atomist is joining Docker. I know our team will thrive in its new home, and look forward to taking the great stuff we’ve built to a much larger audience.

I’ve devoted most of my career to trying to improve developer productivity and the development experience. Thus it’s particularly pleasing to me that Atomist is becoming part of a company that understands and values developers and has transformed developer experience for the better over the last 10 years. Docker’s impact on how we work has been profound and varied. Just a few of the ways I use it nearly every day: quickly spinning up and trying out a complex stack on my laptop without having to dread uninstallation; creating and destroying a database instance in seconds during CI to check the validity of a schema; confidently deploying my own code and third party products to production. Docker is both integral to development and a vital part of deployment. This is rare and makes it core to how we work.

Docker Atomist Logos

What does this acquisition mean for users and customers?

First, Atomist’s technology can help Docker provide additional value throughout the delivery lifecycle. Docker will integrate Atomist’s rich understanding of the secure software supply chain into its products. To start with, this will surface in sophisticated reporting and remediation of container vulnerabilities. But that is just the start. As deployed software becomes more and more complex, it’s vital to understand what’s in production deployments and how it evolves over time. Container images are core to this, and Atomist’s ability to make sense of the supply chain both at any point in time and as it changes becomes ever more important. Security is just one application for this insight–although arguably the single most critical.

Second, Docker will leverage Atomist’s sophisticated integration platform. Docker (the company) understands that the modern development and delivery environment is heterogeneous. No single vendor can supply best of breed solutions for every stage, and it’s not in customers’ interests for them to do so. Atomist will help Docker customers understand what’s happening through the delivery flow, while preserving their ability to choose the products that best meet their needs.

Finally, Atomist’s automation technology will help Docker improve development experience in a variety of ways, driven by user input.

We’re proud to have built powerful, unique capabilities at Atomist. And we’re ready to take them to a much larger audience as Docker. This is an important point in a longer voyage, with the best yet to come. Want to be the first to experience the new features resulting from this combination? You can sign up for the latest updates by visiting this page

Announcing Docker SBOM: A step towards more visibility into Docker images Thu, 07 Apr 2022 15:00:26 +0000 Today, Docker takes its first step in making what is inside your container images more visible so that you can better secure your software supply chain. Included in Docker Desktop 4.7.0 is a new, experimental docker sbom CLI command that displays the SBOM (Software Bill Of Materials) of any Docker image. It will also be included in our Linux packages in an upcoming release. The functionality was developed as an open source collaboration with Anchore using their Syft project.

As I wrote in my blog post last week, at Docker our priorities are performance, trust and great experiences. This work is focused on improving trust in the supply chain by making it easier to see what is in images and providing SBOMs to consumers of software, and improving the developer experience by making container images more transparent, so you can easily see what is inside of them. This command is just a first step that Docker is taking to make container images more self descriptive. We believe that the best time to determine and record what is in a container image is when you are putting the image together with docker build. To enable this, we are working on making it easy for partners and the community to add SBOM functionality to docker build using BuildKit’s extensibility.

As this information is generated at build time, we believe that it should be included as part of the image artifact. This means that if you move images between registries (or even into air gapped environments), you should still be able to read the SBOM and other image build metadata off of the image.

We’re looking to collaborate with partners and those in the community on our SBOM work in BuildKit. Take a look at our PoC and leave feedback here.

What is an SBOM?

A Software Bill Of Materials (SBOM) is analogous to a packing list for a shipment; it’s all the components that make up the software, or were used to build it. For container images, this includes the operating system packages that are installed (e.g.: ca-certificates) along with language specific packages that the software depends on (e.g.: log4j). The SBOM could include only some of this information or even more details, like the versions of components and where they came from.

SBOMs are sometimes required by governments or other software consumers who are trying to improve their supply chain security. This is because knowing what is inside your software gives you confidence that it is safe to use and can be useful in understanding impact when a vulnerability is made public.

Using the container image SBOM to check for a vulnerability

Let’s take a quick look at what the docker sbom command can do to help when a vulnerability like log4shell is made public. When a vulnerability like this appears, it’s crucial that you can quickly determine if your software is impacted. We’ll use the neo4j:4.4.5 Docker Official Image. Just running docker sbom neo4j:4.4.5 outputs a tabulated form of the SBOM:

$ docker sbom neo4j:4.4.5

Syft v0.42.2

 ✔ Loaded image            

 ✔ Parsed image            

 ✔ Cataloged packages      [385 packages]

NAME                      VERSION                        TYPE


bsdutils                  1:2.36.1-8+deb11u1             deb

ca-certificates           20210119                       deb


log4j-api                 2.17.1                         java-archive  

log4j-core                2.17.1                         java-archive  


Note that the output includes not only the Debian packages that have been installed inside the image but also the Java libraries used by the application. Getting this information reliably and with minimal effort allows you to promptly respond and reduce the chance that you will be breached. In the above example, we can see that Neo4j uses version 2.17.1 of the log4j-core library which means that it is not affected by log4shell.

Without docker sbom or another SBOM scanning tool, you would need to check your application’s source code to see which version of log4j-core you are using. When you have several applications or services deployed and multiple versions of them, this can be difficult.

In addition to outputting the SBOM in a table, the docker sbom command has options for outputting SBOM in the standard SPDX and CycloneDX formats along with the GitHub and native Syft formats.

We are sharing the docker sbom functionality early, as an experimental command, with the intention of getting feedback from the community on the direction that we’re going. We’d like to know about your use cases and any other feedback that you have. You can leave it on the command’s repo.

What’s next?

We’d love to collaborate with partners and the community on bringing SBOMs to all container images through BuildKit so please hack on our example and leave feedback on our RFC. Please also give the experimental docker sbom command a try and leave us any feedback that you have. You can also read more about the docker sbom collaboration with Anchore on their blog.


Join us for DockerCon2022 on Tuesday, May 10. DockerCon is a free, one day virtual event that is a unique experience for developers and development teams who are building the next generation of modern applications. If you want to learn about how to go from code to cloud fast and how to solve your development challenges, DockerCon 2022 offers engaging live content to help you build, share and run your applications. Register today at

The Impacts of an Insecure Software Supply Chain Wed, 09 Feb 2022 19:57:46 +0000

Today, software regularly integrates open-source code from third-party sources into applications. While this practice empowers developers to create more capable software in a shorter time frame, it brings with it the risk of introducing inadequately vetted code. How aware are we of the security of our open-source code?

Most of us use pip or npm to freely install software, making decisions based on functionality and support. Efficiency is the goal when we have delivery targets to meet. If we choose not to use open-source solutions, we miss out on their significant productivity benefits. But, if we decide to use open-source solutions, we take the chance of potentially introducing insecure components into our software supply chains and must mitigate any risk with the right tools and processes.

So what is the software supply chain? The software supply chain comprises the steps it takes to develop code before it makes its way into an organization’s application. The chain includes all open-source contributors who wrote the code, the dependencies the code relies on, the repositories where developers downloaded the code, and the organization’s internal review. Each link in the chain represents a potential weak point where unsafe or malicious code can make its way into a production application. 

What Can Go Wrong

Google’s security policy points out that “if an attacker successfully injects any code at all, it’s pretty much game over.” Unfortunately, with continuous deployment (CD) becoming more commonplace, the window to spot such attacks before releasing infected code to users has narrowed.

Attackers’ goals are varied. Hijacking resources for cryptocurrency mining, harvesting username and password combinations for credential stuffing, and data scraping are just a few examples. The consequences are often dire.

Let’s explore some of the potential risks of using open-source solutions.

Common Forms of Attack

Malicious software posing as genuine packages routinely shows up in package management software. Two types of supply chain attacks take advantage of modern software’s numerous dependencies: typosquatting and dependency confusion. In both, the assailant uses a variety of tactics to trick the developer or management software into downloading a dependency file that can execute malicious code. 


Typosquatting relies on the proximity of keys on a keyboard and common misspelling to gain entry. This method of attack transcends programming language bases. Since the early days of the web, domain name typosquatting has been a problem. Package and image deception has become increasingly prevalent, banking on developers’ quick fingers.

In typosquatting, a publisher has uploaded a package with a misspelled name. The misspelled name is so similar to the original package’s that the developer fails to notice they have misspelled the word, unknowingly downloading malicious code.

Dependency Confusion

Dependency confusion exploits the mix of private and public dependencies that software uses. Hackers typically inspect package.json files for Node.js applications to find internal unclaimed packages on npm. They create malicious packages with this same namespace, and automated developer tools install these external malicious packages instead of the intended internal package.

This tactic isn’t limited to npm. For example, Python’s pip displays insecurities ripe for exploitation. Here, a hacker can register a package on PyPi with the same name as an internal package, identified in a requirements.txt file. At registration, they select a higher version number than the genuine package. When this higher number is in builds that include –extra-index-url, it takes precedence, and this seemingly newer version replaces the older.

Like typosquatting, dependency confusion is a problem for all languages. Similar attacks could happen with a Maven pom.xml file or Gradle settings file in Java or a .csproj file referencing NuGet packages in .NET. Tools incorrectly substitute the code, leaving our application vulnerable.


It’s important to remember that these issues can be present deep in the chain, in transitive dependencies. In the diagram above, we can see that an attacker has targeted a dependency, of a dependency, of a dependency. This nesting makes our ecosystem unmanageable and challenging to audit. 

We may trust our developers not to make malicious codebase changes and perhaps feel content that a four-eye review policy will protect our software. When a dependency gets upgraded, we trust that someone else is carrying out reviews with our rigor. But this may not be the case for packages maintained in small teams or by individuals.

An Example Scenario

A malicious actor creates a seemingly innocent package, like some utility functions. Let’s call this Package X.

They then publish their code to a package distribution site. Remember, just because code is inspectable on GitHub doesn’t necessarily mean it’s the same code on the package management site.

They use Package X as part of a pull request into the code for Package Y, fixing minor bugs on open-source projects. Their genuinely-useful bug-fix has pulled in the malicious dependency (Package X), and presto! The malicious code is in the repository.

If our code uses Package Y, then our software inherits the vulnerability in Package X.

Organizations must update their open-source code constantly to mitigate the risk of hidden vulnerabilities. These organizations must also use detection methods such as automated vulnerability scanning to identify known vulnerabilities before they cause damage.

With global news coverage quick to publicize any data or security breach, these incidents can damage an organization’s reputation. Rebuilding that trust is highly challenging. 

Empowering Developers to Secure Your Supply Chain

All of the security risks that come with development means developers need access to tools that make security as easy as possible for them. Luckily, Docker seamlessly integrates security measures across our platform to help mitigate risks and secure the software supply chain. The first step is attestation and verification. To establish trust, we must verify code and not make any assumptions about its security. 

Docker’s Image Access Management feature, available to Docker Business users, enables organizations to control where they get their software. This approach shifts the control of access and permissions from developers to the site level, with toggle options to easily set options and role-based access control (RBAC) available to manage authorization at scale. This control helps ensure developers are only using approved and secure images.

Image Access Management is also a good way of guaranteeing the sources are legitimate. When your business has hundreds of developers, tracking what each software engineer is innocently installing becomes challenging. Docker Business users get an audit log that records the creation, deletion, and editing of teams and repositories to enhance visibility.

To help developers make better container image decisions, Docker provides a visual way of validating images via badging in Docker Hub. These badges are specific to Docker Verified Publisher Images and Docker Official Images and signal to developers that what they’re pulling is trusted, secure, and ready for use.

Docker also provides vulnerability scanning tools via our security partner, Snyk. Developers can use the Snyk scanner right in their CLI for the insight and visibility they need into the security posture of their local Dockerfiles and local images. This includes a list of Common Vulnerabilities and Exposures (CVEs), the sources, such as OS packages and libraries, versions in which they were introduced, and a recommended fixed version (if available) to remediate the CVEs discovered. When this step is automated, we no longer rely solely on our developers to manually scan for insecurities.

Gaining Peace of Mind

Returning to our Package X example, we now have multiple layers to prevent that worst-case scenario:

  • Image Access Management ensures that our developers can only pull base images from trusted, verified sources.
  • Role-Based Access Control enables developers to reduce the blast radius by controlling which developers can bring in new content and potentially isolating the breach to a single team’s work.
  • Vulnerability Scan automatically scans for CVEs when we build a new image. To quickly resolve our insecure dependency issues, Vulnerability Scanning vets and flags dependencies for our developers and offers remediation options.
  • Audit Log provides three months of history capturing all activities. This record helps organizations discover all affected internal supply chains quickly.

This layered approach to security offers increased opportunities for checks. While vigilance and manual checks are still ideal, it’s reassuring to have these tools available to help prevent and combat attacks.


In this article, we’ve explored the genuine supply chain security problem, one that President Biden has even addressed.

By targeting an app’s dependencies, cybercriminals can reach multiple organizations with the hope of evading scrutiny. It’s often the easiest way to break in when organizations are locked down. Everyone is a potential target, and attacks can have wide-reaching implications. Assailants seem happy to play the long game and use social engineering to gain access, perhaps offering their time as repository maintainers. As developers and automated tools integrate components into systems, there become multiple points where an adversary could inject malware.
Docker offers a robust suite of tools for vetting open-source code and dependencies before making their way into an application. Docker Business enables software development to continue to benefit from the productivity gains of containers without being hampered by security concerns.

Get started with Docker Business to discover how Docker helps keep your business safe and secure.


Join us for DockerCon2022 on Tuesday, May 10. DockerCon is a free, one day virtual event that is a unique experience for developers and development teams who are building the next generation of modern applications. If you want to learn about how to go from code to cloud fast and how to solve your development challenges, DockerCon 2022 offers engaging live content to help you build, share and run your applications. Register today at

Notary v2 Project Update Wed, 27 Oct 2021 14:00:00 +0000 Supply chain security is something that has been increasingly important to all of us in the last few years. Almost as important as the global supply chains that are having problems distributing goods around the world! There have been many attacks via the supply chain. This is where some piece of software that you use turns out to be compromised or to contain vulnerabilities that in turn compromises your production environment.

We have written about secure supply chain best practices . Docker is committed to helping you build security into your supply chain, and we are working on more tools to help you with this. We provide Docker Trusted Content, including Docker Official Images and Docker Verified Publisher images for you to use as a  trusted starting point for building your applications.

notary horizontal color

We have also been heavily involved with many community projects around supply chain security. In particular we are heavily involved in the Notary v2 project in the Cloud Native Computing Foundation (CNCF). We last wrote about this in January. This project is the next generation of the original Notary project that Docker started in 2015 and then donated to the CNCF. Notary (to simplify!) is a project for adding cryptographic signatures to container images so that you can make sure that the image someone produced is the same one that you are using, and that it has not been tampered with on the way.

Over the years we have learned a lot of things about how it is used, and the problems that have hindered wider adoption, and these are part of the community feedback into the design of Notary v2. We are looking to build a signing framework that can be used in every registry, and where signatures can be pushed and pulled with images so that you can identify that an image that you pull from your private on premise registry is the same as the Docker Official Image on Docker Hub, for example. This is one of the many use cases that are important to the community and which Notary v1 did not adequately address. We also want to make it much simpler to use, so we can have signature checks on by default for all users, rather than having opt-in signatures.

Today the project has released an early alpha prototype for further experimentation and for your feedback. Steve Lasker has written a blog post with the details. Check out the demos and please give feedback on whether these workflows fit your use cases, or how we can improve them.

Remember you can give us feedback about any aspect of our products on the Docker public roadmap. We are especially interested in your feedback around supply chain security and what you would like to see; we have had lots of really helpful feedback recently that is helping us work out where to take our products and tools.

Building a healthy and secure software supply chain Fri, 13 Aug 2021 17:07:54 +0000 Securing the software supply chain is now an everyday concern for developers. As attackers increasingly target open-source components as a way to compromise the software supply chain, developers hold the keys to making their projects as secure as they can be. That’s why Docker continues to invest heavily in our developer tools like Docker Desktop and secure supply chain offerings such as Docker Official Images and Docker Verified Publisher content.

In a recent webinar Docker CTO Justin Cormack and Head of Developer Relations Peter McKee cover what it takes to securely develop from code to cloud. The talk provides a comprehensive overview on software security including explaining what is a software supply chain attack, key principles to identifying the weakest link and the stages for effectively securing the software supply chain.

As Justin told Dark Reading last month:  

“Every time you use software that you didn’t write yourself, often open source software that you use in your applications, you are trusting both that the software you added is what you thought it is, and that it is trustworthy not hostile. Usually both these things are true, but when they go wrong, like when hundreds of people installed updates from SolarWinds that turned out to contain code to attack their infrastructure, the consequences are serious.”

Secure Software Supply Chain Best Practices Thu, 24 Jun 2021 15:01:00 +0000 Last month, the Cloud Native Computing Foundation (CNCF) Security Technical Advisory Group published a detailed document about Software Supply Chain Best Practices. You can get the full document from their GitHub repo. This was the result of months of work from a large team, with special thanks to Jonathan Meadows and Emily Fox. As one of the CNCF reviewers I had the pleasure of reading several iterations and seeing it take shape and improve over time.

supply chain shutterstock 1033377703

Supply chain security has gone from a niche concern to something that makes headlines, in particular after the SolarWinds “Sunburst” attack last year. Last week it was an important part of United States President Joe Biden’s Executive Order on Cybersecurity. So what is it? Every time you use software that you didn’t write yourself, often open source software that you use in your applications, you are trusting both that the software you added is what you thought it is, and that it is trustworthy not hostile. Usually both these things are true, but when they go wrong, like when hundreds of people installed updates from SolarWinds that turned out to contain code to attack their infrastructure, the consequences are serious. As people have hardened their production environments, attacking software as it is written, assembled, built or tested, before production, has become an easier route.

The CNCF Security paper started after discussions I had with Jonathan about what work needs to be done to make secure supply chains easier and more widely adopted. The paper does a really good job in explaining the four key principles:

  • First, every step in a supply chain should be “trustworthy” as a result of a combination of cryptographic attestation and verification
  • Second, automation is critical to supply chain security. Automating as much of the software supply chain as possible can significantly reduce the possibility of human error and configuration drift. 
  • Third, the build environments used in a supply chain should be clearly defined, with limited scope.  
  • Fourth, all entities operating in the supply chain environment must be required to mutually authenticate using hardened authentication mechanisms with regular key rotation.

In simpler language, this means that you need to be able to securely trace all the code you are using, which exact versions you are using,  where they came from, and in an automated way so that there are no errors. Your build environments should be minimal, secure and well defined, i.e. containerised. And you should be making sure everything is authenticated securely.

The majority of people do not meet all these criteria making exact traceability difficult. The report has strong recommendations for environments that are more sensitive, such as those dealing with payments and other sensitive areas. Over time these requirements will become much more widely used because the risks are serious for everyone.

At Docker we believe in the importance of a secure software supply chain and we are going to bring you simple tools that improve your security. We already set the standard with Docker Official Images. They are the most widely trusted images that  developers and development teams use as a secure basis for their application builds. Additionally, we have CVE scanning in conjunction with Snyk, which helps identify the many risks in the software supply chain. We are currently working with the CNCF, Amazon and Microsoft on the Notary v2 project to update container signing  which we will ship in a few months. This is a revamp of Notary v1 and Docker Content Trust that makes signatures portable between registries and will improve usability that has broad industry consensus. We have more plans to improve security for developers and would love your feedback and ideas in our roadmap repository.