TL;DR: November and December have been special months for Chainloop, with tons of exciting news, features, and announcements. The focus on Compliance with the new Frameworks and Requirements feature was followed by many improvements in other areas, like policies, materials, and performance in both Enterprise and Community editions. Keep reading for the details.

Custom Frameworks and Requirements

In previous releases, we focused on introducing policies and groups to set the foundations for compliance modeling. Now, we have taken yet another step forward by releasing the ability to model custom frameworks and requirements into Chainloop.

Organizations can now describe their security and compliance expectations by creating requirements and grouping them into frameworks. Requirements describe a control-like activity that is directly connected to policies.

To close the loop, frameworks can be associated with projects, enabling project-level risk management all through automated evaluation of policies derived from the SDLC activities!  

Projects and Release Management UI

We understand that information about the different CI/CD steps in isolation is not useful for a release manager, or a compliance operator. That’s why we have done some work on exposing such information in the context of software projects and their versions.

Projects and versions can now be managed directly from the Chainloop Platform. A new dashboard gives aggregated insights into a particular project version, including workflow runs, compliance status, policy evaluations, pieces of evidence, etc.

A release management workflow has also been introduced. Compliance operators can now assess project risk at a glance, add any compliance exception (more on that in the next changelog :) and promote the version from pre-release to final. 

Audit Logs

One request we’ve gotten from our enterprise customers is the need to keep track of and store all events, changes, and user actions that could affect the configuration of their Chainloop instance. This includes changes in policies, requirements, frameworks, contracts, logins, projects, you name it.

Chainloop Platform now has an event-sourced system that tracks all events, changes, and user actions. The system exposes those entries in the Chainloop Platform UI and optionally forwards them to a SIEM tool through our webhook integration.

This is an example of a Chainloop event received in a lambda function. In the future, in addition to webhook forwarders, you should expect native integrations with log and event processors.

New Policies

We have introduced some new policies to the built-in library:

• Code Coverage: This policy checks a code coverage report against a given percentage threshold. It currently supports JaCoCo XML report format.
• Latest Tag: Make sure a pushed container image doesn’t include the rolling latest tag. 
• Helm Chart signature check: Check that the Helm Chart stored in OCI registry was signed.
• Source Commit signature check: Besides checking that the attestation includes a head Git Commit, you can now check that the commit was signed.
• Material Present: You can now encode into policies what kind of pieces of evidence you are expecting in your attestations.

Policy Arguments

Policy definitions can now include a section with expected inputs, specify mandatory or optional policy arguments, and set default values where needed. When adding a policy to a contract, Chainloop CLI will validate that the values provided match the expected policy inputs.

In this example, a required “licenses” argument is needed for the policy to be used:

1spec:
2  inputs:
3    - name: licenses
4      description: Comma separated list of licenses to ban
5      required: true
6  policies:
7    - kind: SBOM_CYCLONEDX_JSON
8      path: banned-licenses-cyclonedx.rego
9

As usual, you can find more information in Chainloop documentation.

Policy Groups Encapsulation

With policy groups, users could create reusable policy configurations that could be added to multiple contracts. In this new release, we improved groups also to include expected materials. This way, a group will behave as a kind of subcontract. Better than that, policy groups also admit input parameters that can be mapped to parameters in the underlying policies.

In this example, we create a policy group that forces attestations to include a named SBOM and some policies applied to it:

1apiVersion: workflowcontract.chainloop.dev/v1
2kind: PolicyGroup
3metadata:
4  name: sbom-quality
5  description: This policy group applies a number of SBOM-related policies
6  annotations:
7    category: SBOM
8spec:
9  inputs:
10    - name: bannedLicenses
11      description: comma separated list of licenses to ban
12      required: true
13    - name: bannedComponents
14      description: comma separated list of components to ban
15      required: true
16  policies:
17    materials:
18      - name: sbom
19        type: SBOM_CYCLONEDX_JSON
20        policies:
21        - ref: sbom-banned-licenses
22          with:
23            licenses: {{ inputs.bannedLicenses }}
24        - ref: sbom-banned-components
25          with:
26            components: {{ inputs.bannedComponents }}
27

‍

Check policy groups documentation for more information.

New Material Types

In this release, we introduced two new material types and some improvements:

• OCI charts: In addition to gzipped charts, Chainloop CLI will now accept OCI references to chart artifacts. As with container images, it will automatically detect and attest all relevant metadata, like its repository digest and tags.
• JaCoCo XML coverage reports: this new material type enables the creation of new policies that check for coverage threshold in your codebase. 
• Enhanced JUnit reports: The CLI now supports adding multiple JUnit files in a compressed file (zip or gzip).

Automatic Signature Retrieval 

• Signed OCI Helm Charts: With the addition of OCI-based Helm Charts, Chainloop CLI is now able to detect and retrieve anyOCI signatures attached to them, as it used to do with container images, supporting Cosgin and Notary signatures. Signature information will be automatically added to the attestation as annotations on the chart piece of evidence.
• Signed commits: With this improvement, Chainloop will detect Git commit PGP signatures. Now, users can easily create policies that check for its presence in their attestations.

Automatic SBOM Contextualization 

When an SBOM material is added to an attestation, is not always easy to relate the SBOM to the artifact (container image, JAR file …) used to generate such content. With this improvement, the “main component” information is extracted. Then, a policy can be created to match this information with other materials present in the attestation.

1  "materials": [
2     {
3        "annotations": {
4           "chainloop.material.cas.inline": true,
5           "chainloop.material.name": "material-1734016181713664000",
6           "chainloop.material.sbom.main_component.name": "index.docker.io/bitnami/wordpress",
7           "chainloop.material.sbom.main_component.type": "container",
8           "chainloop.material.sbom.main_component.version": "6.7.1-debian-12-r5",
9           "chainloop.material.type": "SBOM_CYCLONEDX_JSON"
10        },
11        "digest": {
12           "sha256": "25025ad29584ea25ccdedb4fbed2e2eabfb2398f4e1773819451c5a39d0f8cb1"
13        },
14        "name": "o.json"
15     }
16  ],
17

‍

Performance Improvements and Tooling

One of our focuses in this iteration has been production readiness, specifically resilience and performance. We have addressed this topic in different ways:

• Database connection settings: You can now configure different database connection settings such as pool size, max idle, …
• Generic database improvements: we looked for expensive queries, refactored them, and created indexes where appropriate.
• Retry mechanisms: networking issues are unavoidable. We have mitigated possible side effects by introducing idempotent retries in all our API calls. 
• New tooling to measure performance: we have introduced an option to enable pprof profiling in Chainloop’s control plane, which can help finding existing bottlenecks and expensive operations.

To enable it yourself:

• set “controlplane.enableProfiler=true” in the helm chart values.yaml file.
• Once you've done this, the profiler will be exposed through port 6060, so you can proceed with port forwarding and retrieve the profiling information.

// port forward profiler server to localhost:6060
kubectl port-forward deployment/chainloop-controlplane 6060:6060 -n chainloop-prod
// measure a 30 seconds sample of the app call-trace and open a web-ui
go tool pprof -http=:1234 http://localhost:6060/debug/pprof/profile

Client Side Organization Management

Chainloop’s multi-tenancy is partitioned into organizations (a.k.a namespaces). However, there has been a common pitfall in its implementation that prevented the coexistence of multiple organizations with the same CLI instance without annoying context-switching calls. 

This is now fixed since the current context is stored on the client side, and we added and additional CLI flag to set the context for a single CLI call.

Chainloop HQ

Kubecon + CloudNativeCon Salt Lake City

We went to this edition of the Kubecon, and had the opportunity to connect with many friends and colleagues, especially our friends from Keyfactor, who were showcasing our enterprise-grade integration. 

Securing the Software Supply Chain CNCF Workshop 

Also with Keyfactor, we recorded a webinar that is now posted on the Cloud Native Computing Foundation YouTube channel. You can check it out here.

All-hands Sevilla 

This month we had our All-hands in our Sevilla office. These events are very important to us: as a remote-friendly company, we also love getting in touch, discussing features the old way, with stickers and whiteboards, and mostly, having time to share good wines and tapas in our loved city.

Wrapping up

2024 has been a great year for laying solid foundations for our product and team. We have rolled out numerous features in the pursuit of securing the software supply chain for our customers.

It's been a busy year, but we're just getting started. We look forward to GA in 2025, as we keep delivering faster, better, and with stronger and higher standards.

Thank you for being with us on this journey. Our team wants to wish you happy holidays and a great 2025 year!