Since the inception of Chainguard, we have been committed to the principles that underpin CISA’s Secure by Design pledge and furthering these goals is core to the mission of Chainguard. I’m honored to sign the pledge on behalf of Chainguard and applaud CISA’s efforts to promote best practices to build secure software from the start, not after the fact. At Chainguard, we embrace this with the motto start left, don’t shift left. As a result, we already exceed many of the goals outlined in the pledge, and we believe that we meet the rest; however, in the spirit of the pledge we seek to do better.
In this blog, we will highlight our approach to meeting/exceeding these goals and areas where we are striving to improve beyond the baseline recommendations.
Multi-factor authentication (MFA)
Goal: “Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.”
Multi-factor authentication is the greatest defense against password-based attacks, the 2024 Verizon Data Breach Investigations Report found that credentials remain the number one way that attackers gain access to systems, “use of stolen credentials” is the number one initial action during breaches, and stolen credentials also account for a whopping 77% of Basic Web Application Attacks.
Chainguard's products do not accept passwords and rely exclusively on Single Sign-On (SSO) for human login, with support for built-in providers and custom identity providers. Chainguard requires SSO and MFA for all key business systems and provides employees with phishing-resistant MFA in the form of FIDO-compliant security keys. However, some of the critical SSO providers used in Chainguard's Auth0 flow do not support the amr claim, which is an area for potential improvement.
This is an area where the industry as a whole could improve. OIDC flows have a standard amr claim to convey whether an SSO flow checked MFA, and these can even be required using acr_values, however, the lack of adoption of these claims by key SSO providers creates a significant hurdle to widespread adoption.
Default passwords
Goal: “Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.”
As highlighted above, Chainguard’s products do not accept passwords, let alone a “default password”. Also highlighted above, we leverage SSO and MFA across all of the key business systems supporting our business.
Our hope is that this pledge further expedites the “kill the password” movement.
Reducing entire classes of vulnerability
Goal: “Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.”
This is an area that is near and dear to Chainguard and formulates the heart of our Chainguard Images value proposition. We eliminate the class of vulnerability that stems from running software with unpatched CVEs. Let’s look at a few of the classes touched on in the pledge itself.
- On Memory Safety, we are big fans. BIG fans. All of Chainguard’s first party authored product code is written in Go. In Wolfi, our linux undistro, and Chainguard Images, where we ship a significant amount of upstream software, we are embracing memory-safe alternatives for common packages like rustls and sudo-rs. We are also helping support the development of new memory-safe projects, such as River, by contributing financial and technical resources to the Internet Security Research Group (ISRG).
- On SQL injection, Chainguard has since the beginning of our product development made use of SQL frameworks that enforce the use of parameterized queries eliminating the possibility of SQL injection.
- On Cross-site scripting (XSS), Chainguard leverages Content Security Policy (CSP) to detect and mitigate several classes of browser-based attacks, including XSS. We’ve configured our CSP to tell browsers what JavaScript should be allowed to run on our page and which endpoints requests are allowed to be sent to.
- On Credential Leaks, our product exclusively uses short-lived credentials. We have also developed and open sourced projects like Octo STS which have enabled us to broadly eliminate our use of several classes of long-lived credentials across GitHub.
Finally, we avidly “eat our own dogfood;” which is to say that we extensively use our own Chainguard Images product. This means that our workloads and services typically have no unpatched CVEs. This also means that our workloads and services are significantly less susceptible to the rising pattern of “living off the land” attacks.
Security patches
Goal: “Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.”
This is the core foundation of Chainguard Images. The number of vulnerabilities being reported across the board is only increasing and the best defense is getting rid of all of them as fast as possible. Last month, Chainguard remediated 125 vulnerabilities in open source software at a pace of around 31 CVEs per week. This strategy makes software more secure by default and improves the developer experience. Chainguard Images are the result of a meticulously designed toolchain built from the ground up with software supply chain security at the center of it. We offer our customers an SLA for the availability of security patches.
To further this goal is to further our product adoption by new and existing customers, and you can bet we are working on that.
Vulnerability disclosure policy
Goal: “Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP) that authorizes testing by members of the public on products offered by the manufacturer, commits to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP, provides a clear channel to report vulnerabilities, and allows for public disclosure of vulnerabilities in line with coordinated vulnerability disclosure best practices and international standards.”
Chainguard currently has a documented way to responsibly disclose vulnerabilities on our contact page, which directs folks to email us at security@chainguard.dev. We have had several security researchers responsibly disclose issues to us this way, such as this disclosure from Boost Security about a potential vulnerable Github Actions workflow. Right now, in lieu of an official vulnerability rewards program, we donate funds to a charity/non profit of the researchers choosing.
However, this is an area where we can and will do better. We are actively working on a more official disclosure policy that spells out a commitment to not pursue legal action against folks that engage in good faith efforts to disclose vulnerabilities to us, but our current verbiage is not explicit about this:
We don’t have a bug bounty yet. If you find an issue in our products or sites, report it to our team. In lieu of a financial reward, we can send swag and donate $200 to a charity of your choice.
CVEs
Goal: “Within one year of signing the pledge, demonstrate transparency in vulnerability reporting by including accurate Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) fields in every Common Vulnerabilities and Exposures (CVE) record for the manufacturer’s products. Additionally, issue CVEs in a timely manner for, at minimum, all critical or high impact vulnerabilities (whether discovered internally or by a third party) that either require actions by a customer to patch or have evidence of active exploitation.”
Effective CVE management is one of the core value propositions of Chainguard Images. Accurate CWE and CPE fields are critical to being able to effectively associate CVEs with pieces of software. For the software that we distribute as part of Chainguard Images, we complement the CWE and CPE data that manifests in the National Vulnerability Database (NVD) with our advisory feed, which reflects our classification of the relevance of CVEs to software present in our images. Our CVE SLA is our commitment to customers that this information is curated in a timely manner.
We are actively engaged in the CVE community and have recently spearheaded an effort to shed light on the current challenges plaguing the NVD.
Evidence of intrusions
Goal: “Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.”
Today Chainguard surfaces all of our API mutations via CloudEvents, which provides users with data on all modifications, by which actor, and includes the OICD claims from the original identity that were checked in order to federate as the Chainguard identity.
However, this is an area where we can do better. We do not retain these logs beyond making them available to end-users as CloudEvents. Chainguard will start to retain these events for a period of time appropriate for retaining user data, and make them available to users upon request.
Pledges aren’t progress
While this pledge is an important step, there are more actions organizations large and small need to take to ensure they are taking responsibility and accountability for providing secure products and outcomes. Today marks an important milestone, but now collectively we all need to go beyond commitments and focus on the right outcomes. It is only when we start to build secure by design products in practice that we will all reap the benefits of this promise.
If you are at RSA and are interested in talking about Secure by Design or Defense in Depth reach out.
