Software supply chain compliance and security policies with SignServer, EJBCA, and Chainloop

Member post originally published on the EJBCA by Keyfactor and Chainloop blogs by Ben Dewberry, Product Manager, Signing and Key Management, Keyfactor and Miguel Martinez Trivino, Co-founder, Chainloop

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 the Chainloop 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: Remote signing with SignServer and 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. For more information, see 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, and more.

The guide: Use Keyfactor SignServer for attestation signing 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.pem \
  --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. For more information, see 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’ll need to add your EJBCA settings to your Chainloop Helm Chart configuration, as explained the guide: Configure Chainloop to use EJBCA as CA. 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:

1. Generated and signed attestations that protect the integrity of the metadata from manipulation.
2. 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.
3. 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.

In the next blog post, we’ll show you how to take security and compliance to the next level by running Rego Policies against metadata signed using EJBCA and SignServer ephemeral certificates in a segmented architecture with all keys HSM-protected and centrally stored. Stay tuned!

Glossary

Software Attestation: A software attestation is an authenticated statement (metadata) about a software artifact or collection of software artifacts. For more information, see slsa.dev. The primary intended use case is to feed into automated policy engines, such as in-toto and Binary Authorization.

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. For more information, see 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.

About the authors

Ben Dewberry

Product Manager, Signing and Key Management, Keyfactor

Miguel Martinez Trivino, Co-founder, Chainloop