Conceptual on

Chainguard Shared Responsibility Model

Thu, 17 Oct 2024 11:07:52 +0200

Chainguard’s mission is to be the safe source for open source. As part of this mission, Chainguard builds all of our packages and images from upstream open source code and delivers the resulting artifacts to our customers. There are three distinct parties involved here: Upstream projects, Chainguard, and Customers; each of these parties share some measure of responsibility across a few dimensions.

This guide is an overview of Chainguard’s Shared Responsibility Model: a framework that outlines the security responsibilities of upstream open source software projects, Chainguard, and its customers. The dimensions of shared responsibility this guide covers are:

Strategies for Minimizing your CVE Risk

Thu, 16 Nov 2023 11:07:52 +0200

Common vulnerabilities and exposures (CVEs) are an increasing concern for developers and organizations, which is why Chainguard developed its minimal container images that reduce the attack surface. A new CVE in a widely-used application or a vulnerability scan with numerous positive results can significantly impact security posture, compliance requirements, and development timelines.

Chances are, your software has already been impacted by a CVE. It’s likely there are active CVEs in software you are using. After all, there are software vulnerabilities currently in existence that haven’t even been discovered (known as zero-day vulnerabilities). With that said, this conceptual article aims to highlight a few practices and strategies you and your team can use to reduce the risk of CVEs on your software. It also includes a section on tools recommended by Chainguard that can help to reduce your attack surface area and minimize your risk of CVEs.

What is an SBOM (software bill of materials)?

Thu, 04 Aug 2022 15:21:01 +0200

Modern software applications contain hundreds to thousands of open source and third-party components, creating significant security challenges that SBOMs help address - which is why Chainguard includes comprehensive SBOMs with every container image. Without structured visibility into these components, organizations struggle to identify and respond to vulnerabilities, even when patches are available. This lack of transparency leaves systems vulnerable to exploitation, making SBOMs essential for maintaining secure software supply chains.

Introduction to SLSA

Tue, 14 Feb 2023 08:49:15 +0000

SLSA (pronounced “salsa”), or Supply chain Levels for Software Artifacts, is a security framework consisting of standards and controls that prevent tampering, improve integrity, and secure packages and infrastructure. While cyberattacks like SolarWinds and Codecov have demonstrated the importance of protecting software from tampering and malicious compromise, the complexity of the software development lifecycle can leave many feeling unable to adequately understand or respond to these specific security issues.

Released by Google’s Open Source Security Team in 2021, SLSA was created as a framework to help software creators understand where and how they can harden their supply chain security practices, and help software consumers evaluate the integrity of a software product or component before they decide to use it. SLSA was also designed around the creation of verifiable metadata, so that software consumers can set automated policies to prevent the deployment of code that does not meet their preferred SLSA level.

What are Containers?

Tue, 17 Oct 2023 20:02:23 +0000

Maximizing the performance of computer hardware has been a critical undertaking for software engineers for decades. First developed in the 1960s, virtual machines (VMs) were an early answer to this challenge, allowing a single computer to host multiple, isolated operating systems. VMs enable different guest users or processes to share physical infrastructure while keeping their concurrent operations separated. However, as VMs are both slow to initialize and resource-intensive, a modern solution arrived in the early 2000s: containers.

Selecting a Base Container Image

Thu, 04 Aug 2022 15:21:01 +0200

Software teams building and deploying container-based software applications often use a “base image,” an initial set of software packages often associated with a Linux distribution. Software developers, security professionals, and infrastructure teams seeking to make an informed decision about what base image to use must consider a number of criteria when selecting a base image appropriate for their needs. Base images like those provided by Chainguard are designed to meet these security criteria while maintaining compatibility. To help these parties make a more informed decision when selecting a base image, this article describes a range of criteria:

What is software supply chain security

Thu, 04 Aug 2022 15:21:01 +0200

An earlier version of this material was published in the first chapter of the Linux Foundation Sigstore course.

Software producers have a supply chain just like manufacturing businesses have a supply chain. And just like manufacturers require physical inputs and then perform a manufacturing process to build a finished product, so do software producers, whether the producer is a company or individual. In other words, a software producer uses components, developed by third parties and themselves, and technologies to write, build, and distribute software. A compromise introduced anywhere in this chain is an example of a software supply chain security issue. Tools and practices like those implemented in Chainguard’s containers help organizations protect against these risks through built-in SBOMs, provenance attestations, and SLSA compliance.

What Makes a Good SBOM?

Thu, 04 Aug 2022 15:21:01 +0200

A software bill of materials, or an SBOM (pronounced s-bomb), is a formal record of the components contained in a piece of software. It is analogous to an ingredients list for a recipe. And it has become recognized as one of the key building blocks of software supply chain security. Proponents rightfully point out that organizations can’t secure their software if they don’t know what’s inside their software.

As awareness and adoption of SBOM has grown, there has been a gradual acknowledgement that not all SBOMs are created equal, some are more or less useful, depending on the goals of the SBOM user and the contents of the SBOM. This guide exists to provide some guidance on evaluating the quality of an SBOM, suggesting common use cases and the data fields that support these use cases and open source SBOM quality tools.

Chainguard Glossary

Mon, 01 Aug 2022 15:21:01 +0200

General terms

Software supply chain

Like in material good supply chains, a software supply chain is composed of activities that an organization undertakes to deliver an end product or service to a consumer. Software supply chain activities involve the transformation of dependencies, packages, components, binaries, build and packaging scripts, code and other software artifacts, and infrastructure into a finished software deliverable that is deployed into production. Participants in the supply chain include actors like developers, reviewers, testers, and maintainers who are working on the product at hand, but also includes those who maintain and contribute to packages and package managers, and other software that may be incorporated into a given product. Software supply chains also include information relevant to the software, such as versioning, signatures, and hashes.

Verified Organizations

Tue, 15 Aug 2023 14:22:23 -0700

Resources on the Chainguard platform are organized in a hierarchical structure called IAM Organizations. Single customers or organizations typically use a single root-level Organization to manage their Chainguard resources.

Organizations can optionally be verified. Verification modifies some aspects of the Chainguard platform user experience to help large organizations guide their user base to the correct resources.

Verifying your Organization

Verification is currently a manual process. To verify your organization, please contact your customer support contact. You can check if your organization is verified using chainctl.

What Is a Build Horizon?

Mon, 16 Mar 2026 00:00:00 +0000

A build horizon is the maximum amount of time a build artifact — such as a compiled binary or container image — is permitted to remain in use before it must be rebuilt. Once an artifact exceeds its build horizon, it is considered stale and must be regenerated from up-to-date sources.

The practice has been adopted broadly to maintain production hygiene, reduce technical debt, and limit exposure to vulnerabilities in aging dependencies.

What is OpenVex?

Tue, 31 Jan 2023 15:21:01 +0200

OpenVEX is an open source specification, library, and suite of tools designed to enable software users to eliminate vulnerability noise and focus their security efforts on vulnerabilities that pose an immediate risk. Released by Chainguard in January 2023, it’s the first set of open source tools to support the VEX specification championed by the United States National Telecommunications and Information Administration (NTIA) and the Cybersecurity and Infrastructure Security Agency (CISA).

With OpenVEX, stakeholders from across the software supply chain can collaborate on identifying and remediating exploitable vulnerabilities and use automation to enable more precise and efficient methods of security management. In this guide, you will learn more about the emerging supply chain security standards that OpenVEX supports, as well as how OpenVEX tooling can help you leverage them in your security management processes.

False Positives and False Negatives with Container Images Scanners

Thu, 14 Sep 2023 16:59:04 +0000

A vulnerability scanner is a tool that analyzes your software components and reports any CVEs it finds. Using a vulnerability scanner to find CVEs that impact your system is a critical step in software vulnerability remediation, but as you begin to triage scanner-reported vulnerabilities, you may find that your scanner’s results are not perfectly accurate.

The goal of a vulnerability scanner is to identify the vulnerabilities that impact your container images, which can be considered true positive vulnerabilities. Sometimes, a scanner surfaces CVEs which are not actually impacting your images, which are called false positive vulnerabilities. Your scanner may even miss some vulnerabilities that are impacting you, termed false negative vulnerabilities.

The Differences between SBOMs and Attestations

Sun, 19 Mar 2023 15:56:52 -0700

One of the first steps to improving your software supply chain security is to establish a process for creating quality Software Bills of Materials (SBOMs). An SBOM is a formal record that contains the details and supply chain relationships (such as dependencies) of the components used in building software.

Cosign — a part of the Sigstore project — supports software artifact signing, verification, and storage in an OCI (Open Container Initiative) registry. The cosign command line tool offers two subcommands that you can use to associate an SBOM with a container image and then upload them to a registry: cosign attach and cosign attest.

What is the future of the Chainguard Factory?

Sat, 02 Aug 2025 16:00:00 +0000

Transcript

Interviewer: So what do you see as the future for the Factory?

What is the Open Container Initiative?

Thu, 09 Jun 2022 15:22:20 +0100

The Open Container Initiative (OCI) is a Linux Foundation project dedicated to managing specifications and projects related to the storage, distribution, and execution of container images. The OCI was formed in 2015 when developers recognized that the quickly growing container industry needed standards to ensure the portability of containers across systems and platforms. As one of the most popular container developers, Docker was a key partner in the formation of the OCI and donated its specifications and associated code for OCI image formats and runtime specifications. Today, the OCI manages three specifications (the Image Specification, the Runtime Specification, and the Distribution Specification), which are evolving according to community participation and industry development.

Using Trivy to Scan Software Artifacts

Wed, 03 Jul 2024 20:00:00 +0200

Trivy is a vulnerability scanner for a wide variety of software artifacts and deployments. Trivy is written in the Go programming language and is maintained by Aqua Security. Trivy targets container images, VMs, filesystems, remote GitHub repositories, and Kubernetes and Amazon Web Services deployments. The tool can be used to detect known vulnerabilities (CVEs), generate SBOMs, analyze licenses, and scan for misconfigurations and exposed secrets. Trivy can be installed from package managers or as a binary, and can also be run as a container image.

What are OCI Artifacts?

Thu, 09 Jun 2022 15:22:20 +0100

OCI artifacts are a way of using OCI registries, or container registries that are compliant with specifications set by the Open Container Initiative, to store arbitrary files. They are useful to understand given their growing importance for software supply chain security and their general utility for container engineering. However, community usage of OCI artifacts is still actively evolving and differing opinions and understandings of their purpose can lead to confusion. In this guide, you will learn the difference between OCI “artifacts” and “Artifacts,” their utility for software supply chain security, and some important considerations when using them.

Why apk

Wed, 06 Jul 2022 08:49:31 +0000

apko uses the apk package manager to compose container images based on declarative pipelines. The apk format was introduced by Alpine Linux to address specific design requirements that could not be met by existing package managers such as apt and dnf. But what makes it different, and why does that matter in the context of apko?

Manipulating the Desired State

In traditional package managers like dnf and apt, requesting the installation or removal of packages causes those packages to be directly installed or removed, after a consistency check.