Alyssa Shames – Docker

Docker Desktop 4.17: New Functionality for a Better Development Experience

Alyssa Shames — Mon, 27 Feb 2023 16:22:03 +0000

We’re excited to announce the Docker 4.17 release, which introduces new functionality into Docker Desktop to improve your developer experience. With Docker 4.17, you’ll have easier access to vulnerability data and recommendations on how to act on that information. Also, we’re making it easier than ever to bring the tools you already love into Docker Desktop with self-published Docker Extensions.

Read on to check out the highlights from this release.

Improved local image analysis

Container image security presents challenges such as dependency awareness, vulnerability awareness, and practical remediation in day-to-day reality. Since Docker Desktop 4.14, we’ve consistently added features to help you understand your images and their vulnerabilities. Improvements in 4.17 were designed with developers in mind to address software supply chain security.

We’re pleased to announce Early Access to the new Docker Scout service. Docker Scout provides visibility into vulnerabilities and recommendations for quick remediation. Now you can use Docker Scout to analyze and remediate vulnerabilities on local images in Docker Desktop and the Docker CLI.

Check out the Docker Scout documentation to learn more about how to get started.

What can you do with Docker Scout?

Image analysis results: Filter images based on vulnerability information, look for specific vulnerabilities, or confirm when vulnerabilities have been remediated. You’ll see results based on the layer in which a vulnerability is introduced, so you know exactly where the alert is coming from.

Remediation advice: Get guidance on available remediation options. Docker Scout shows you the recommended remediation path depending on the layer of the vulnerability. Docker Scout also shows a preview before you resolve anything, so you know how many vulnerabilities will be resolved by a specific update.

Remote registries: You can use Docker Desktop to view and pull images from Artifactory repositories to analyze them.

Command-line interface: As of Docker Desktop 4.17, the docker scan command is deprecated and replaced with a command for Docker Scout – docker scout. Read the release notes for more detail.

Update to Docker Desktop 4.17 to access these new features and take them for a test run. You can also provide feedback directly in Docker Desktop by navigating to the images tab and selecting Give feedback. We look forward to hearing from you!

A new way to publish Docker Extensions

We are excited to introduce a new way to publish a Docker Extension. When submitting an extension to the Marketplace, you now have two publishing options:

Docker Reviewed
Self-Published – New!

Self-Published extensions are automatically validated. If all validation checks pass, it is published on the Extensions Marketplace and accessible to all users within a few hours. Self-Published is the fastest way to get developers the tools they need and to get feedback from them as you work to evolve and polish your extension.

Developers can identify self-published extensions in the Extensions Marketplace by the not reviewed label. Extensions that are manually reviewed by the Docker Extensions team have a reviewed label, as shown in the following screenshot.

We are excited about the increased reach and accessibility the new self-publishing workflow brings to both Docker Extension publishers and users.

If you have an idea for an extension that isn’t already in the Extensions Marketplace, you can submit it to our ideas discussion board.

Let us know what you think

Thanks for using Docker Desktop! Learn more about what’s in store with our public roadmap on GitHub, and let us know what other features you’d like to see.

Check out the release notes for a full breakdown of what’s new in Docker Desktop 4.17.

New in Docker Desktop 4.15: Improving Usability and Performance for Easier Builds

Alyssa Shames — Thu, 01 Dec 2022 17:00:00 +0000

Docker Desktop 4.15 is here, packed with usability upgrades to make it simpler to find the images you want, manage your containers, discover vulnerabilities, and work with dev environments. Not enough for you? Well, it’s also easier to build and share extensions to add functionality to Docker Desktop. And Wasm+Docker has moved from technical preview to beta!

Let’s dig into what’s new and great in Docker Desktop 4.15.

Improvements for macOS

Move Faster with VirtioFS — now GA

Back in March, we introduced VirtioFS to improve sharing performance for macOS users. With Docker Desktop 4.15, it’s now generally available and you can enable it on the Preferences page.

Using VirtioFS and Apple’s Virtualization Framework can significantly reduce the time it takes to complete common tasks like package installs, database imports, and running unit tests. For developers, these gains in speed mean less time waiting for common operations to complete and more time focusing on innovation.

This option is available for macOS 12.5 and above. If you encounter any issues, you can turn this off in your settings tab.

Adminless install during first run on macOS

Now you don’t need to grant admin privileges to install and run Docker Desktop. Previously, Docker Desktop for Mac had to install the privileged helper process com.docker.vmnetd on install or on the first run.

There are some actions that may still require admin privileges (like binding to a privileged port), but when it’s needed, Docker Desktop will proactively inform you that you need to grant permission.

For more information see permission requirements for Mac.

Jump in faster with quick search

When you work with Docker Desktop, you probably know exactly which container you want to start with or image you want to run. But there might be times when you don’t remember if it’s already running — or if you pulled it locally at all.

So you might check a few of the current tabs in the Docker Dashboard, or maybe do a docker ps in the CLI. By the time you find what you need, you’ve checked a few different places, spent some time searching Docker Hub to find the right image, and probably got a little annoyed.

With quick search, you get to skip all of this (especially the annoyance!) and find exactly what you’re looking for in one simple search — along with relevant actions like the option to start/stop a container or run a new image. It even searches the Docker Hub API to help you run any public and private images you’ve hosted there!

To get started, click the search bar in the header (or use the shortcut: command+K on Mac / ctrl+K on Windows) and start typing.

The first tab shows results for any local containers or compose apps. You can perform quick actions like start, stop, delete, view logs, or start an interactive terminal session with a running container. You can also get a quick overview of the environment variables.

If you flip over to the Images tab, you’ll see results for Docker Hub images, local images, and images from remote repositories. (To see remote repository images, make sure you’re signed into your Docker Hub account.) Use the filter to easily narrow down the result types you want to see.

When you filter for local images, you’ll see some quick actions like run and an overview of which containers are using the image.

With Docker Hub images, you can pull the image by tag, run it (running will also pull the image as the first step), view documentation, or go to Docker Hub for more details.

Finally, with images in remote repositories, you can pull by tag or get quick info, like last updated date, size, or vulnerabilities.

Be sure to check out the tips in the footer of the search modal for more shortcuts and ways to use it. We’d love to hear your feedback on the experience and if there’s anything else you’d like to see added!

Flexible image management

Based on user feedback, Docker Desktop 4.15 includes user experience enhancements for the images tab. Cleaning up multiple images can now be done easier with multi-select checkboxes (this functionality used to be behind the “bulk clean up” button).

You can also manage your columns to only show exactly what you want. Want to view your complete container and image names? Drag the dividers in the table header to resize columns. You can also sort columns by header attributes or hide columns to create more space and reduce clutter.

And if you navigate away from your tab, don’t worry! State persistence will keep everything in place so your sorting and search results will be right where you left them.

Know your image vulnerabilities automatically

Docker Desktop now automatically analyzes images for vulnerabilities. When you explore an image, Docker Desktop will automatically provide you with vulnerability information at a base image and image layer level. The base image overview provides a high level view of any dependencies in packages that introduce Common Vulnerabilities and Exposures (CVEs). And it’ll let you know if there’s a newer base image version available.

If you’d prefer images were only analyzed on viewing them, you can turn off auto-analysis in Settings > Features in development > Experimental features > Enable background SBOM indexing.

Thanks to everyone who provided feedback in our 4.14 release. And let us know what you think of the new image overview!

Use Dev Environments with any IDE

When you create a new Dev Environment via Docker Desktop, you can now use any editor or IDE you’ve installed locally. Docker Desktop bind mounts your source code directory to the container. You can interact with the files locally as you normally do, and all your changes will be reflected in the Dev Environment.

Dev Environments help you manage and run your apps in Docker, while isolated from your local environment. For example, if you’re in the middle of a complicated refactor, Dev Environments makes it easier to review a PR without having to stash WIP. (Pro tip: you can install our extension for Chrome or Firefox to quickly open any PR as a Dev Environment!)

We’ve been making lots of little fixes to make Dev Environments better, including:

Custom names for projects
Better private repo support
Better port handling
CLI fixes (like interactive docker dev open)

Let us know what other improvements you’d like to see!

Building and sharing Docker Extensions just got easier

Did you know that you can build your own Docker Extension? Whether you’re just sharing it with your team or adding it to the Extensions Marketplace, Docker Desktop 4.15 makes the process easier and faster.

Meet the Build tab

In the Extensions Marketplace, you’ve got your Browse tab, your Manage tab, and, now, your Build tab. The Build tab brings all the resources you need to get started into one centralized view. You’ll find links to videos, documentation, community resources, and more! To start building, click “+ Add Extensions” in Docker Desktop and navigate to the new Build tab.

Share a link to your extension with others

So now you’ve made an extension to share with your teammates or the community. You could submit it to the Extensions Marketplace, but what if you aren’t quite ready to? (Or what if it’s just for your team?)

Prior to Docker Desktop 4.15, the extension developer had to share a CLI command that looked something like this: docker extension install IMAGE[:TAG]. Then anyone who wanted to install the extension had to paste that command into their CLI.

In Docker Desktop 4.15, we’ve simplified the process for both you and the developer you want to run your extension. When your extension’s ready to share, use the share button in the Manage tab to create a link. When the person you share it with opens on the link, they’ll be able to select the “Install” button from Docker Desktop.

Have an idea for a new Docker Extension?

If you have an idea for a new Docker Extension, we’ve got a new way that you can share them with Docker and the community. Inside the Extensions Marketplace, there’s a link to request an extension. This link will take you to our new GitHub repo that allows you to add your idea to our discussions and upvote existing ones. If you’re an extension developer, but aren’t sure what to build, be sure to check out the repo for some inspiration!

Docker+Wasm is now beta

We’ve integrated WasmEdge’s runwasi containerd shim into Docker Desktop (previously provided in a Technical Preview build).

This allows developers to run Wasm applications and compose Wasm applications with other containerized workloads, such as a database, in a single application stack. Learn more about it in the documentation and be on the lookout for more soon!

What else would make your life easier?

Take a test drive of the new usability upgrades and let us know what you think! Is there something you think we missed? Be sure to check out our public roadmap to see upcoming features — and to suggest any other ones you’d like to see.

And don’t forget to check out the release notes for a full breakdown of what’s new in Docker Desktop 4.15!

The Docker-Sponsored Open Source Program has a new look!

Alyssa Shames — Thu, 01 Sep 2022 17:00:00 +0000

It’s no secret that developers love open source software. About 70–90% of code is entirely made up of it! Plus, using open source has a ton of benefits like cost savings and scalability. But most importantly, it promotes faster innovation.

That’s why Docker announced our community program, the Docker-Sponsored Open Source (DSOS) Program, in 2020. While our mission and vision for the program haven’t changed (yes, we’re still committed to building a platform for collaboration and innovation!), some of the criteria and benefits have received a bit of a facelift.

We recently discussed these updates at our quarterly Community All-Hands, so check out that video if you haven’t yet. But since you’re already here, let’s give you a rundown of what’s new.

New criteria & benefits

Over the past two years, we’ve been working to incorporate all of the amazing community feedback we’ve received about the DSOS program. And we heard you! Not only have we updated the application process which will decrease the wait time for approval, but we’ve also added on some major benefits that will help improve the reach and visibility of your projects.

New application process — The new, streamlined application process lets you apply with a single click and provides status updates along the way
Updated funding criteria — You can now apply for the program even if your project is commercially funded! However, you must not currently have a pathway to commercialization (this is reevaluated yearly). Adjusting our qualification criteria opens the door for even more projects to join the 300+ we already have!
Insights & Analytics — Exclusive to DSOS members, you now have access to a plethora of data to help you better understand how your software is being used.
DSOS badge on Docker Hub — This makes it easier for your project to be discovered and build brand awareness.

What hasn’t changed

Despite all of these updates, we made sure to keep the popular program features you love. Docker knows the importance of open source as developers create new technologies and turn their innovations into a reality. That’s why there are no changes to the following program benefits:

Free autobuilds — Docker will automatically build images from source code in your external repository and automatically push the build image to your Docker Hub Repository.
Unlimited pulls and egress — This is for all users pulling public images from your project namespace.
Free 1-year Docker Team subscription — This feature is for core contributors of your project namespace. This includes Docker Desktop, 15 concurrent builds, unlimited Docker Hub image vulnerability scans, unlimited scoped tokens, role-based access control, and audit logs.

We’ve also kept the majority of our qualification criteria the same (aside from what was mentioned above). To qualify for the program, your project namespace must:

Be shared in public repos
Meet the Open Source Initiative’s definition of open source
Be in active development (meaning image updates are pushed regularly within the past 6 months or dependencies are updated regularly, even if the project source code is stable)
Not have a pathway to commercialization. Your organization must not seek to make a profit through services or by charging for higher tiers. Accepting donations to sustain your efforts is allowed.

Want to learn more about the program? Reach out to OpenSource@Docker.com with your questions! We look forward to hearing from you.

Automating Your Containers’ Security Scanning

Alyssa Shames — Fri, 03 Jun 2022 16:48:11 +0000

Application development is complex. Teams must juggle numerous processes, gather all dependencies, and package everything together into a performant application. On top of this, each containerized application must satisfy strict security requirements, to protect your users and systems against intrusion.

When it comes to maintaining container security, software bugs are inevitable. They’re often harmless glitches, but some can pose serious security risks — letting bad actors access your systems. Whenever someone discovers a vulnerability within commercial or open-source software, they must register it within the Common Vulnerability and Exposure (CVE) database. There are currently more than 170,000 recorded CVEs, and engineers discovered over 2,083 new ones in March 2022 alone.

In this article, we’ll explore how vulnerabilities impact containers and how using images from trusted sources helps. We’ll then discuss how to use Docker’s native Snyk integration to secure your software supply chain.

The State of Software Security

Developers have increasingly turned to third-party code and applications while building their services. Unfortunately, using third-party software may also expose your code to risk. It’s absolutely essential that you leverage trusted images and secure your containers through ongoing vigilance.

This is why image scanning is so critical — not just early on in development, but throughout an application’s life. Thankfully, Docker customers have access to continuous security scanning that’s integrated into their workflows via Snyk — so you can find and fix vulnerabilities more easily. Whether you’re running conventional containers or Kubernetes applications, our native Snyk integration is valuable throughout the software development lifecycle.

How Vulnerabilities Affect Containers

A Docker container starts with a base image, typically from an online source. Teams then add layers to incorporate the functionality they need. These layers might just be simple commands that perform actions like creating a folder, yet they often pull in additional packages.

Here’s a basic Dockerfile example called good-nodejs:

FROM node:lts-alpine3.15
WORKDIR /workdir
RUN npm i express-openid-connect

This file has three layers:

FROM: This instruction initializes a new build stage and prepares the base image for upcoming instructions. Any valid Dockerfile starts with a FROM expression. Our example above uses an official Node.js image built atop Alpine Linux. This image contains everything needed to get up and running with Node. It has multiple layers, which you can see from the size of its Dockerfile. Each layer — from the Alpine Linux OS layer and those that make up Alpine — is a potential vulnerability source.
WORKDIR: This layer sets a working directory. Risks here are minimal or non-existent, since WORKDIR doesn’t introduce any new, external software packages.
RUN: This instructional layer installs another third-party package. It may introduce additional vulnerabilities via the package code, its dependencies, and any other requisite packages.

These above layers have a knack for concealing vulnerabilities deep inside an image, where they’re inconspicuous. You may need to perform extensive penetration testing to find them.

Using Trusted Sources

Trusted images that follow image best practices are your most powerful allies when securing your supply chain. Docker Hub provides access to Docker Official Images and Verified Publisher images — denoted by the color-coded badges displayed prominently beside their names.

Docker’s internal teams curate Docker Official Images. We frequently update, scan, and patch these images to galvanize security. Every essential operating system, programming language, middleware, and database is represented.

Docker’s external partners supply Docker Verified Publisher images. When you use these images, you know that they’re sourced authentically and actively maintained. Our program helps ensure that these components are trustworthy. You’ll also find resources from Snyk, similar to those above:

Developers don’t need to have an advanced security background or read CVE reports to fix container issues. This partnership gives Docker developers access to the industry’s most comprehensive, timely, and accurate database of open source and container-vulnerability intelligence.

Our security coverage goes far beyond CVE vulnerabilities and other public databases. Snyk’s in-house research team maintains its database and combines public sources, community contributions, proprietary research, and machine learning to continuously adapt to dynamic security threats.

Identifying Vulnerabilities

Trusted images are great starting points for development, yet they may not be fully functional. You may choose to leverage community-sourced images or those from outside developers instead. Luckily, you can use Docker Hub’s Snyk integration to detect any threats hidden within any images and code. More importantly, our Snyk integration also arms developers with base image fix recommendations and identifies any Dockerfile lines that introduce vulnerabilities.

Automated vulnerability scanning can detect CVEs that find their way into your container images. It’s an essential tool for securing your software supply chain — acting as a front-line defense mechanism as you integrate third-party code into their projects.

This scan works by examining all packages and dependencies defined in your Dockerfile, and checks them against a list of recorded vulnerabilities.

You can enable a repository’s vulnerability scanning in its respective Settings tab.

With scanning enabled, Snyk will automatically analyze any new tags pushed to the repository (like a specific image version or variant).

Consider our basic Dockerfile from earlier. To demonstrate how image scanning works, you can pull an older version of your base image (with known vulnerabilities), and do the same for your npm package:

FROM node:15.9.0-alpine3.13
WORKDIR /workdir
RUN npm i express-openid-connect@2.7.1

We can test Snyk’s functionality from here. If you build and push this code to your Docker Hub repository — with the test tag bad-nodejs (alongside good-nodejs from earlier) — you’ll see that Snyk has automatically scanned it. This scan has found 22 high-severity and eight medium-severity vulnerabilities:

You can then dive into the bad-nodejs results to get a breakdown of all vulnerabilities discovered, showing:

Severity
Priority score
CVE number
Package introducing the issue
Package versions with the bug and the fix

When you drill further into a vulnerability, Snyk presents information within a tree-like structure. You can see which package is responsible for introducing the vulnerability. In the example below, apk-tools is importing zlib, which contains an out-of-bounds write vulnerability:

Enabling Continuous Monitoring

Using older image versions to replicate legacy systems is a common practice; it ensures that your applications are backwards compatible. Your workflows might also prioritize stability over new features. Finally, licensing new software versions can be cost-prohibitive for your company, therefore keeping you on an older version.

Building an image with bleeding-edge technologies — and deploying it into production — does introduce some risk. If product development stagnates for an extended period, there’s a high chance that someone will find vulnerabilities in public releases. You wouldn’t know about these vulnerabilities before deployment, since you chose the newest versions.

Using Snyk’s technology, Docker Hub mitigates these risks by periodically re-scanning all repository images. Your Docker Hub subscription grants you Docker Desktop as a local UI. This lets you view recent scan results for images across your organization.

Fixing the Container Image via a Web UI

When you push your Dockerfiles to publicly-accessible source control — like GitHub, GitLab, and Bitbucket — you can integrate the code with a free Snyk account and get detailed remediation recommendations. The web UI prompts you to automatically fix vulnerabilities with a pull request into the source code.

Fixing the Container Image via the Command Line

Docker Desktop also provides powerful CLI scanning locally. This alternative method lets Snyk examine your Dockerfile and provide detailed recommendations based on its findings. It’s also an essential tool if you’ve embraced a shift-left testing philosophy.

When you scan that aforementioned bad-nodejs image via the command line, you’ll uncover the same vulnerabilities found within Docker Hub:

✗ Critical severity vulnerability found in apk-tools/apk-tools
Description: Out-of-bounds Read
Info: https://snyk.io/vuln/SNYK-ALPINE313-APKTOOLS-1533754
Introduced through: apk-tools/apk-tools@2.12.1-r0
From: apk-tools/apk-tools@2.12.1-r0
Image layer: Introduced by your base image (node:15.9-alpine3.13)
Fixed in: 2.12.6-r0

This output shows how the vulnerability was introduced and links to Snyk, where more information is available.

By linking your Dockerfile on the CLI scan, you’ll receive the same upgrade recommendations for your base image as you had earlier.

You’ll find another vulnerability if you scroll further down. Your added npm package introduced the vulnerability after intentionally grabbing an older version. Crucially, Snyk tells you how to fix this.

Next Steps

Security discussions can be both headache inducing and complex in a traditional development environment. Process fragmentation impacts security from one team to the next, and the onus is often on leaders to form a cohesive strategy. However, you should never have to wonder if your teams are building, running, and sharing secure applications.

Accordingly, automated vulnerability scanning helps your organization secure its software supply chain. Docker’s native Snyk integration provides broad oversight of your organization’s image security — detecting vulnerabilities inside dependency layers. Our Docker Extension for Snyk helps you better follow development best practices, while also meeting your compliance requirements. Learn more about getting started with Snyk scanning, and our Docker Extension for Snyk, here.

The integration reduces the time and effort needed to boost security. Your development teams can instead spend their time improving your services. To learn more about Docker’s vulnerability scanning integrations — and how to start securing your images — browse our documentation.

Docker Business now available for purchase on the Amazon Web Services Marketplace

Alyssa Shames — Mon, 14 Mar 2022 20:18:14 +0000

Today, Docker and Amazon are happy to announce the availability of Docker Business on the Amazon Web Services (AWS) Marketplace. This is a huge step in providing more choice and flexibility to Docker and AWS customers, so you can procure the Docker Application Development Platform – including leading tools, services, integrations, and content – through your preferred channel.

Docker Business was launched in August 2021, as part of Docker’s new product subscription tiers. It addresses challenges faced by organizations that require developer management and software security at scale without impacting developer productivity and collaboration.

Now that Docker Business is on AWS Marketplace, customers will benefit from an accelerated purchase and procurement process, better visibility and control over your tech stack, and even the ability for AWS Enterprise Discount Plan (EDP) members to utilize incentives related to their committed yearly spend on a platform that millions of developers already know and love.

This announcement is just another step towards our growing ecosystem partnership with AWS, which already includes the ability to build and deploy applications with Docker Desktop and Amazon ECS on AWS Fargate, the availability of Docker Official Images on AWS ECR, and Docker’s Graviton ready designation.

What do I get with Docker Business?

Docker Business helps organizations build modern, secure, and reliable applications without compromising on development speed, flexibility, or trust. It includes the Docker Application Development Platform with added enterprise-grade features like:

Centralized user management and visibility controls
Registry and image access management
Single sign-on
Advanced security
Prioritized support

DockerCon Live 2022

Join us for DockerCon Live 2022 on Tuesday, May 10. DockerCon Live 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 Live 2022 offers engaging live content to help you build, share and run your applications. Register today at https://www.docker.com/dockercon/

The Impacts of an Insecure Software Supply Chain

Alyssa Shames — 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

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.

Conclusion

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.

DockerCon2022

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 https://www.docker.com/dockercon/

Join Us at SnykCon 2021!

Alyssa Shames — Tue, 05 Oct 2021 18:55:56 +0000

This week is Snyk’s annual SnykCon virtual conference that aims to connect with the global developer and security communities and Docker is excited to participate as a gold sponsor for the second year! At last year’s conference, we discussed our partnership with Snyk to incorporate their leading vulnerability scanning across the entire Docker application development lifecycle.

This partnership is just as important this year, as we’ve seen supply chain attacks happening at an alarming rate. In a cloud-native environment, everything you do is defined by code. We said it last year and we’ll say it again, security is vital to successful app development projects, and automating and integrating these security precautions with as little friction to development as possible, is key.

Together, Docker and Snyk bring security natively into the development workflow, so developers can automatically scan for image vulnerabilities while developing code versus after. The whole process is super simple too – you can automatically trigger scans after pushing an image into Docker Hub. Learn more about best practices for scanning and building secure images here. The best part? If you’re a Docker subscriber, you get access to Snyk scanning as part of your subscription!

Supply chain security is top-of-mind for all of us, and Docker CTO Justin Cormack breaks it all down in his session: “Understanding Supply Chain Security for Developers”, on October 7th, from 9:35am-9:55am ET.

Justin’s talk discusses what you can do during development to avoid security breaches and targeted attacks, specifically honing in on:

Vulnerabilities in dependencies
Credential management in build
Static analysis, code review, and ephemeral infrastructure

You can find more event and session details on the SnykCon agenda page, or visit Docker’s virtual booth!