Changelog: AI-Driven Policy Authoring and Product Compliance at scale

Last month we continued in our quest of enabling our enterprise customers to bring their entire organization Software Delivery into Chainloop, and this meant implementing new features around Products compliance and release management.

Next, our goal is to make sure our customers can develop, and manage their custom policies in a scalable way, and for that, alongside our declarative capabilities, we can also see how useful Agentic workflows can be for developers when there are clear constraints, context and the tools are available, so we have extended our custom policy authoring with a more clear layout, instructions and more powerful tooling for developing, inspecting, or testing custom policies.

AI-Ready Policy Authoring

Writing custom policies and maintaining them declaratively at scale is one of our customers’ biggest challenges; that’s why, last month, we introduced our new set of policy development tools, which allow developers to easily write, lint, test, and manage custom Chainloop policies in their repositories.

This month, we are extending its capabilities with a “debug mode,” which further enhances the development experience by giving developers access to all the information about the used inputs, execution paths, logging messages, and outputs—no more trips to the rego playground!

The beauty of having this kind of tooling locally is that we are enabling developers to leverage agentic workflows (such as using Claude Code) to implement and test custom policies.

For example, using a combination of our CLI and this CLAUDE.md file, I can tell Claude to extend an existing SAST policy to support SonarQube SAST scan. This will give me the following implementation plan that leverages my current development workflow and tooling.

The result would be a fully compliant and end-to-end-tested Chainloop policy.

Policy Engine remote request support

In some cases, you might want to create a custom policy that makes an HTTP request to an external endpoint (see this example). Calling external hostnames is disabled by default as a security best practice, but now you can allow custom hostnames for your organization.

This feature enables you to build policies that act as dynamic control gates. For example, you could implement a policy that checks if we are within the release window, which is exposed as a JSON API in your organization.

Product Versioning and Compliance Applicability

In the previous changelog we introduced the concept of a product, a way to group different components or services (or, as we call it in Chainloop, “projects”)

Today, we are releasing two key features that advance our vision of allowing you to govern software at scale: compliance applicability matrix and product version tracking.

Product Version Tracking and Release Management

We understand that release management and versioning at the product level move at a different pace than the versioning of their underlying components. That’s why you can now create product versions and attach them to underlying projects either by tracking new versions or pinning them to specific ones.

In the example below, you can see a product called Chainloop Platform version 1.235 attached to five projects. Four of them (backend, controlplane, CLI, and CAS) have their version tracked (rolling), while the frontend one is pinned.

What this means in practice is that when a new version of the project comes out, product 1.235 will “be connected” to that new version.

Lastly, a release management feature has been added, which allows users to mark a product version as released. This will, in turn, pin all the underlying project versions and snapshot the compliance status.

Product Compliance Applicability Matrix

The Compliance Applicability matrix allows you to define compliance applicability at the product level and tweak it down to the project level.

This sounds complicated, but long story short, it allows compliance and product managers to mark frameworks as a whole or specific requirements as non-applicable (optionally providing a reasoning) for specific underlying projects, reducing the configuration burden.

Let’s see an example. Below, you can see a compliance applicability configuration for the compliance framework “Chainloop best practices.” On the left side, you can see the applicability for the whole product version (Chainloop Platform v1.235) and whether the underlying projects inherit or “override” the applicability.

At the product level, we are disabling “helm-chart-signed” requirement, indicating the rationale.

Further down, in the CLI, we indicate that the container-signed requirement does not apply to this project either.

Once configured, the requirements will be filtered out from both the project and the product compliance dashboards.

Audit Log Improvements

The audit log has received some love

• The UI has been revamped,
• You can now filter and download audit entries
• The number of recorded events has now grown and goes beyond authentication and compliance configuration changes. We now track project and product versioning rollovers, etc.

Looking Ahead: The Road to Dynamic Policy Enforcement

As we continue to evolve Chainloop, our focus for the coming months will be on further enhancing our compliance as code capabilities going beyond policies, by including declarative requirements, frameworks and controls. We want to make sure Chainloop is the best platform to encode all your organization policies, and controls, so authoring, testing or managing compliance should feel like a breeze.

This is enterprise-grade compliance that scales with you, not against you.

Want to see these features in action?

• Request demo: chainloop.dev/book-a-demo
• Documentation: docs.chainloop.dev
• Open source: github.com/chainloop-dev/chainloop

Stay updated: Follow us on LinkedIn