May: Chainloop OSS 1.0, CRA, SLSA and compliance automation

TL;DR

As in previous changelog editions, this month comes packed with new features for Chainloop Platform and Community Edition:

• Chainloop Open Source Community Edition 1.x milestone reached: Our open source project has reached its first major version 1.x.
• New revamped and united documentation site for OSS and Platform available at https://docs.chainloop.dev/, including OpenAPI 3 docs.
• Compliance frameworks:
  • New compliance frameworks: SLSA 1.1 framework is now bultin in Chainloop Platform. CRA is offered in preview.
  • Time-bound compliance requirements: framework requirements can enforce periodicity and SLA for resolution.
  • Full framework self assessment through Platform UI to provide manual evidence for requirements.
• New policy features: authenticated runners for Github and Gitlab, tool metadata extraction for multipurpose formats like SARIF, CSAF, SPDX and CycloneDX.

Introduction

Last month saw a massive Chainloop Community Edition 1.0 release, an expansion of Chainloop’s capabilities with the implementation of new compliance features, support for new frameworks and requirement scenarios, and enhancements to the policy engine. These updates ensure Chainloop users can concentrate on core business operations while Chainloop automates compliance status tracking by gathering and validating evidence from CI/CD systems and self-assessments.

Documentation

The documentation for both Chainloop OSS and Chainloop Platform has been consolidated into a new website: https://docs.chainloop.dev. The site features a redesigned navigation and content architecture to improve content discoverability.

The new site includes autogenerated content for the Chainloop CLI and OpenAPI REST reference. Check it out!

Chainloop 1.0

Chainloop OSS has reached a stable major version 1.0.0, marking a significant milestone after 189 pre-release versions and release candidates. During this extensive development, every feature has been rigorously implemented, tested, refined and validated in real-world production settings.

Read the full story in our previous post Reaching a Milestone: Chainloop 1.0 Release Candidate

Chainloop 1.0 is just the needed milestone to what’s coming next during the next few months, and to celebrate it, we have completely redesigned our web site. Welcome to the new chainloop.dev!

Compliance frameworks:

Cyber Resilience Act (CRA)

We are happy to announce the European Cyber Resilience Act (CRA) has been added to the family of built-in frameworks in Chainloop. Organizations can start attesting their compliance status, before this regulatory framework is fully obliged.

This framework is under preview and not available by default, but you can enable it in your Organization settings to start testing it:

Check https://docs.chainloop.dev/reference/cyber-resilience-act for more information on how CRA is implemented in Chainloop.

SLSA 1.1

SLSA 1.1 framework is now fully available for all organizations. You can already integrate it into your projects with a combination of automatic policies and manual checks to provide proof of your SLSA compliance status:

• SLSA Level 1: Build Process Documentation: It ensures that the entire build process is documented and recorded. This gives basic visibility into how the software is made, but doesn’t protect against tampering. Chainloop ensures that the build is run on a dedicated infrastructure, but at this level it doesn’t verify its authenticity.
• SLSA Level 2: Protection Against Tampering: It ensures that the build is run on an authenticated, hosted runner with access to the build script. Chainloop checks this using an OIDC token from the build platform and also requires the provenance information to be signed using keyless signing. This helps prevent attackers from tampering with the code or build process, since all changes are tracked and the provenance is securely signed.
• SLSA Level 3: Advanced Threat Protection: Currently the most advanced level of SLSA. It strengthens the build system with security controls and auditing. Provenance is non-falsifiable, so even insiders or compromised systems have a much harder time sneaking in malicious changes. Chainloop uses a mixture of automatic and manual evidence to ensure this SLSA level.

To simplify validation, a new policy group, slsa-checks has been implemented. This group includes preconfigured policies designed to automate the validation of common SLSA requirements for projects hosted and built on platforms like Github or Gitlab pipelines.

Check https://docs.chainloop.dev/reference/slsa-provenance for full documentation on Chainloop’s SLSA implementation.

Self-assessment improvements

Chainloop’s Compliance platform integrates automated policy checks with manual evidence submission to ensure comprehensive compliance. While policies and attestations handle automated aspects, users can upload manual evidence for requirements that cannot be fully automated. The platform then evaluates compliance based on both automated and manually submitted evidence.

Users with enough access rights will be able to provide evidence through simple checklists or even uploading files to the platform that will be stored in their Content Addressable Storage (CAS) and kept for auditing purposes.

Policy improvements

Some new policies and updates:

• runner-authenticated: Ensures the authenticity of the CI/CD runner that generated the attestation. This is done through enforcing the generation of an ID Token in the host (in Github or Gitlab), that gets verified by the CLI using standard JWT verification process.
• vulnerability-scan-present: checks that there is at least one vulnerability scan in the attestation (regardless of its result).

Additionally, attestation materials for generic formats like SARIF, CSAF, CycloneDX and SPDX include the tool and version that generated the report as part of the attestation annotations: