As we announced at DockerCon, we’re now providing a free Docker Scout Team subscription to all Docker-Sponsored Open Source (DSOS) program participants. 

If your open source project participates in the DSOS program, you can start using Docker Scout today. If your open source project is not in the Docker-Sponsored Open Source program, you can check the requirements and apply.

For other customers, Docker Scout is already generally available. Refer to the Docker Scout product page to learn more.

Why use Docker Scout?

Docker Scout is a software supply chain solution designed to make it easier for developers to identify and fix supply chain issues before they hit production. 

To do this, Docker Scout:

• Gives developers a centralized view of the tools they already use to see all the critical information they need across the software supply chain 
• Makes clear recommendations on how to address those issues, including for security issues and opportunities to improve reliability efforts
• Provides automation that highlights new defects, failures, or issues

Docker Scout allows you to prevent and address flaws where they start. By identifying issues earlier in the software development lifecycle and displaying information in Docker Desktop and the command line, Docker Scout reduces interruptions and rework.

Supply chain security is a big focus in software development, with attention from enterprises and governments. Software is complex, and when security, reliability, and stability issues arise, they’re often the result of an upstream library. So developers don’t just need to address issues in the software they write but also in the software their software uses.

These concerns apply just as much to open source projects as proprietary software. But the focus on improving the software supply chain results in an unfunded mandate for open source developers. A research study by the Linux Foundation found that almost 25% of respondents said the cost of security gaps was “high” or “very high.” Most open source projects don’t have the budget to address these gaps. With Docker Scout, we can reduce the burden on open source projects.

Conclusion

At Docker, we understand the importance of helping open source communities improve their software supply chain. We see this as a mutually beneficial relationship with the open source community. A well-managed supply chain doesn’t just help the projects that produce open source software; it helps downstream consumers through to the end user.

For more information, refer to the Docker Scout documentation.  

Learn more

• Join our “Improving Software Supply Chain Security for Open Source Projects” webinar on Wednesday, February 7, 2024 at 1 PM Eastern (1700 UTC). Watch on LinkedIn or on the Riverside streaming platform.
• Try Docker Scout.
• Looking to get up and running? Use our Quickstart guide.
• Vote on what’s next! Check out the Docker Scout public roadmap.
• Have questions? The Docker community is here to help.
• Not a part of DSOS? Apply now.

Cargo containers completely transformed the shipping industry and enabled the global commerce experience of today. Similarly, software containers simplify application development and deployment, which helps enable the cloud-native software architecture that powers the modern technology we all rely on. Although you can get benefits from containerizing your applications after the fact, you get the most value when you take a container-first approach. 

In this blog post, we discuss insights from Cracking the Code: Effectively Managing All of Those Applications, highlighting five benefits of embracing a container-first approach to software development.

1. Consistent and reliable software performance

Inconsistency can be a major roadblock to progress. The all too familiar frustration of “it works on my machine” can cause software delivery delays and hinders collaboration. But with containers comes standardization. This ensures that software will perform consistently across the entire development process, regardless of the underlying environment.

Developers and infrastructure engineers also save a lot of time and cognitive energy on configuring and maintaining their environments and workstations. Containers have a small resource footprint, which means your infrastructure can do more with less. And, because each container includes the exact versions of software it needs, you don’t have to worry about conflicting dependencies.

2. Fewer bugs

Bugs are the bane of every software developer’s existence. However, a container-first approach provides environmental parity. This means that the development, staging, and production environments remain consistent, reducing the likelihood of encountering bugs caused by disparities in underlying conditions. With containers, businesses can significantly reduce debugging time and enhance the overall quality of their software, leading to higher user satisfaction and a stronger competitive edge.

3. Faster developer onboarding

The learning curve for new developers can often be steep, especially when dealing with complex software environments. Containers revolutionize developer onboarding by providing a replica of the exact environment in which an application will be tested and executed. This is irrespective of the developer’s local operating system or installed libraries. With containers, developers can hit the ground running, accelerating their productivity and contributing to the project’s success from day one.

4. A more secure supply chain

The Consortium for Information & Software Quality estimates that poor software quality has cost the United States economy $2.41 trillion. Two of the top causes are criminals exploiting vulnerabilities and supply chain problems with third-party software. Containers can help.

Because the Dockerfile is a recipe for creating the container, you can use it to produce a software bill of materials (SBOM). This makes clear what dependencies — including the specific version — go into building the container. Cryptographically signed SBOMs let you verify the provenance of your dependencies, so you can be sure that the upstream library you’re using is the actual one produced by the project.

Using the SBOM, you can also monitor your fleet of containers for known vulnerabilities. When a new vulnerability is discovered, you can quickly tell which of your containers are affected, which makes the response quicker. Containers also provide isolation, micro-segmentation, and other zero-trust techniques, which reduce your attack surface and limit the impact of exploited vulnerabilities.

5. Improved productivity for faster time-to-market

The standardization, consistency, and security containers bring directly impact software delivery time. With fewer issues to deal with (bugs, compatibility issues, maintenance, etc.), developers can focus on more meaningful tasks and ultimately deliver solutions to customers faster. All of this helps development teams work more efficiently, collaborate effectively, and deliver higher-quality software.

Learn more

Dive deeper into the world of containers and the benefits of adopting a container-first model in your software development by downloading the full white paper, Cracking the Code: Effectively Managing All of Those Applications.

• Get the latest release of Docker Desktop.
•  Vote on what’s next! Check out our public roadmap.
•  Have questions? The Docker community is here to help.
•  New to Docker? Get started.

Modern software is interconnected. When you develop an application, it has to communicate with other services — on your infrastructure, cloud infrastructure services, or third-party applications. Of course, you don’t want just anyone to masquerade as you, so you use secrets like SSH keys or API tokens to make the communication secure. But having these secrets means you have to keep them secret.

Unfortunately, sometimes the secrets escape. When this happens, it can allow bad actors to maliciously use the secrets or post them on the “dark web” for others to use. They can insert vulnerabilities into your code. They can impersonate you or deny legitimate users access to resources. And, if the secret is for something billable (like public cloud infrastructure), they can cost you a lot of money. No matter what other costs you face, the public relations impact can cause your users to lose trust in you.

In this article, we’ll cover a few ways that Docker can help keep secrets from leaking.

Before you read on: If your secrets have been exposed, the first step is to immediately invalidate them and check for compromises.

Controlling access with Docker Hub

The principle of least privilege is a powerful part of your security posture. If someone doesn’t need access to your Docker Hub images, they shouldn’t have access. Docker Hub provides private repositories so that you can keep your images to yourself. Docker Personal subscribers can create one private repository, while Docker Pro, Docker Team, and Docker Business subscriptions offer unlimited private repositories.

Keep in mind that even with private repositories, Docker Hub is not for storing account secrets. Private repositories are a layer in your defense-in-depth model.

Of course, sometimes you want to selectively share your images. Docker Pro, Docker Team, and Docker Business subscribers can add collaborators — accounts that can push or pull images in a private repository. Docker Pro subscribers can add one collaborator to a repository. Docker Teams and Docker Business subscribers can add up to the organization size. This means you can share images with the people who need them — and no one else.

Keeping secrets out

What’s better than protecting the secrets on your Docker image? Not having them in the image in the first place! While there are cases where you need to store a secret in order to make the proper connections, many cases of secret leakage involve secrets that were added accidentally.

The best way to avoid accidentally adding secrets is to use a secret manager, such as AWS Secrets Manager, HashiCorp Vault, or 1Password, which has some CLI options. If you have to keep the secrets in a local environment, you can prevent files from accidentally winding up on your image by adding them to the .dockerignore file. For example, if you’re worried about accidentally adding SSH keys to your image, you can include: *id_rsa*

This approach works well for secrets in files with predictable names. If you’re always storing your cloud credentials in a file called cloud_key.txt, then you’re well-covered. But you won’t catch cloud_credentials.txt.

You can add another layer of security with secret scanners. Tools like Aqua Security Trivy, Anchore, and JFrog Xray search your files for things that look like secrets. If you run the scanner before pushing your image, then you can catch the secret before it escapes. Many secrets scanners can be tied into a Git commit hook as well to prevent secrets from being included in your code.

Conclusion

Keeping your secrets secret is an ongoing process but worth the effort. Like everything in cybersecurity, there’s no one magic solution, but Docker provides features that you can use to help prevent leaking secrets.

To get the most from private repositories and collaborators, check out our subscription offerings. We’re considering adding secret scanning to Docker Scout. If you’d like to see this capability, upvote the issue on our public roadmap.

Learn more

• Get the latest release of Docker Desktop.
•  Vote on what’s next! Check out our public roadmap.
•  Have questions? The Docker community is here to help.
•  New to Docker? Get started.