This blog post was co-authored with Ben Dewberry, Senior Product Manager at Keyfactor. Read more about our recent partnership with Keyfactor here.
A software supply chain is the series of steps performed when writing, testing, packaging, and distributing software. During this process, information about what and how the software is built is generated at each step. This is called metadata.
A Software Bill Of Materials (SBOM) is a canonical example of supply chain metadata, but more examples are scattered across your Software Delivery lifecycle, from QA tests/reports, CVE scans, VEX, legal/security/architecture reviews, etc.
Companies are starting to rely on this metadata to make critical decisions, such as whether to deploy an app to a bank system or whether it is vulnerable, compliant, etc. These decisions could be motivated by wanting to improve your security posture and reach a specific SLSA level or purely pushed by existing regulations such as EO 14028 in the US or upcoming ones like the European Cyber Resilience Act.
However, metadata that cannot be trusted is useless and even harmful.
That is why Chainloop and Keyfactor have partnered by integrating Chainloop’s modular evidence-based metadata storing platform with Keyfactor’s enterprise PKI solutions, EJBCA and SignServer. These integrations will allow organizations to collect, verify, trust, and protect the metadata generated by their Software Supply Chain.
Today, we are introducing two integrations: Remote signing with Keyfactor’s SignServer, and Local signing with Keyfactor’s EJBCA using ephemeral certificates.
After implementing this integration, you will have a solid foundation on which to begin making this metadata actionable for implementing automated policies controlling what is allowed to be run in your environments.
Setting up a metadata evidence store using Chainloop, SignServer, and EJBCA
Chainloop is an Open-Source evidence store for Software Supply Chain attestations, Software Bill of Materials (SBOMs), VEX, SARIF, CSAF files, QA reports, and more. Metadata sent to Chainloop will get attested, signed, evaluated, routed, and stored.
Chainloop offers an opinionated but pluggable end-to-end solution. In this blog post, we will give you an overview of configuring a Chainloop instance with SignServer and EJBCA. The result would be an end-to-end solution that will create in-toto attestations signed with SignServer and EJBCA, stored in an OCI registry.
Before you begin, you need SignServer, EJBCA, and Chainloop running.
- To learn how to get started with EJBCA Community as a Docker container, you can follow the Quick Start Guide - Start EJBCA Container with Client Certificate Authenticated Access.
- To learn how to get started with SignServer Community as a Docker container, you can follow the Quick Start Guide - Start SignServer Container with Client Certificate Authenticated Access.
- To deploy Chainloop, you can either run a local instance using this docker compose file or in a Kubernetes Cluster using our Helm Chart.
You should now have a SignServer, EJBCA, and a Chainloop instance running, but Chainloop is not configured to use them yet! By default, Chainloop will sign attestations using Sigstore’s Cosign key pairs.
Let’s change that! Keyfactor and Chainloop have partnered to offer two integrations to sign attestations and artifacts, allowing you to bring your own PKI: a) remote signing with SignServer and b) Local Signing with an EJBCA ephemeral certificate.
Remote Signing with SignServer
SignServer is a versatile and high-performing open-source code-signing software that enables secure cryptographic signing operations. It digitally signs different types of workloads including code, artifacts, attestations, and containers to ensure software integrity and authenticity - signserver.org
This integration allows users to send the attestation payload to a SignServer worker before sending it to Chainloop for storage. Think of this as a KMS-like approach, where the client environment can access the PKI infrastructure and send the data for remote signing.
Some of the benefits of this approach:
- The key can be stored on Hardware Security Modules (HSMs) where the signing takes place for additional security
- You can leverage this key for signing with additional SignServer workers to handle other artifacts from the pipeline, such as binaries, documents, etc…
This guide explains this integration in more detail, but the gist is that you should be able to run the attestation push command and have a remote SignServer worker sign the attestation like this.
$ chainloop attestation push --key signserver://mysignserver/my-signing-worker
Then, the integration will send the payload to sign to SignServer, retrieve the signature, and craft and store the attestation DSSE envelope.
To verify the payload, just instruct Chainloop to do it using the public key and CA Chain. The CA chain is provided by EJBCA which also issued the signing certificate to the SignServer worker.
$ chainloop workflow run describe --digest sha256:a1b2c3 --verify true --cert my-worker-key.pe--chain ManagementCA.pem
Local Signing with EJBCA Ephemeral Certificate
EJBCA is a flexible, scalable, open-source PKI (Public Key Infrastructure) system that manages certificates for a wide range of use cases, such as Kubernetes workloads and digital signing. - ejbca.org
With this integration, Chainloop can be configured to generate short-lived signing certs by using EJBCA as the certificate authority, enabling a user experience similar to Sigstore Fulcio’s “keyless” approach.
There are some key differences compared to the SignServer approach
- The client will not need access to the PKI infrastructure, and Chainloop will be in charge of exchanging the CLI identity for a short-lived certificate signed by EJBCA. Simplifying authentication.
- The signing process will happen locally, in the client.
The verification materials and the final attestation can optionally be downloaded as a Sigstore Bundle for further offline verification.
To enable this feature, you must add your EJBCA settings to your Chainloop Helm Chart configuration, as explained in this guide. Once you have done so, the attestation process will not require providing any signing material; the resulting attestation will be automatically signed.
$ chainloop attestation push
Summary and what’s next
Building a trusted, robust security framework for your software supply chain requires solutions that enforce security policies across your entire infrastructure, including PKI, signing, and the evidence store, and with the integrations presented today you get:
- Generated and signed an attestation that protects the integrity of the metadata from manipulation.
- With the signed metadata, you can verify that the certificate associated with the private key used for signing was issued by a Certificate Authority (EJBCA) that your organization trusts.
- By using Chainloop to manage and package the metadata, you have successfully organized and stored it, which can be audited and used to make actionable policy decisions.
So what’s next?
Combining Chainloop with EJBCA and SignServer for PKI gives you the foundation to enable automated compliance and security in your organization. This gives you a head start and future-proofs you for upcoming regulations or security practices.
If you like what we do, feel free to drop a contribution, join our community in Slack, or give Chainloop Open Source a star on GitHub chainloop-dev/chainloop :)
Glossary
Software Attestation
A software attestation is an authenticated statement (metadata) about a software artifact or collection of software artifacts. The primary intended use case is to feed into automated policy engines, such as in-toto and Binary Authorization. - slsa.dev
One of the most popular attestation implementations is in-toto, an Open-Source framework for modeling software supply chain metadata, steps, and interrelations.
Open Policy Agent and Rego
Rego is a language used to write rules for the Open Policy Agent (OPA), a tool that helps control what actions are allowed or denied in a system. Rego policies define conditions that decide if something is permitted, such as who can access certain data or perform specific actions. - openpolicyagent.org
Vulnerability Exploitability eXchange (VEX)
A VEX document (Vulnerability Exploitability eXchange) is a document that communicates the status of vulnerabilities in software products. Produced by vendors or maintainers, it clarifies whether specific vulnerabilities affect their products and provides guidance on mitigation or resolution.
