.png)
TLDR;
On the road to 1.0—manage policies with confidence and at scale, with expanded support for custom policies, policy groups, and enhanced versioning.
Workflow names are now project-scoped, and workflows are automatically created upon first attestation—streamlining onboarding and enhancing scalability to support enterprise readiness.
More policies, more tools. We added support for additional material types, security scans, and vulnerability formats to enhance your compliance toolkit.
Introduction
As we progress towards version 1.0, we continue to collaborate closely with our partners to help own their fragmented software supply chain. Our goal is not only to provide a single source of truth for all SDLC metadata and artifacts but also to automate governance and centralize policy management, policy evaluations, compliance, and security dashboards.
This month, we've expanded our policy library, transforming Chainloop into your central DevSecOps platform—not just for SBOMs and CVEs anymore. New policies address compliance requirements and support secrets detection through GitLab secret scan reports. We've also added policies compatible with the 2023 CWE Top 25, working seamlessly with tools like SpotBugs, Zap, KICS, Blackduck, and GitLab, as well as policies for Infrastructure as Code (IaC) misconfigurations.
To make policy management easier, we've improved the user experience by allowing you to create policy groups, add custom policies, and manage versioned policies. This gives you control over change management for your compliance and governance processes, ensuring you can update policies confidently without worrying about system disruptions.
Finally, we're excited to announce that Chainloop will be at KubeCon North America and BackstageCon in Salt Lake City in just under two weeks!
Chainloop HQ
Let’s start with a few announcements.
KubeCon - We’ll Be There!
Chainloop is headed to KubeCon North America and BackstageCon in Salt Lake City in just under two weeks! We’ll bring an array of demos, from showcasing our PKI integrations in collaboration with our friends at Keyfactor, to demonstrating how policies can streamline Software Delivery compliance at scale. Plus, we’ll reveal some exciting new integrations with developer portals. Stop by to see it all in action—we look forward to connecting with you there!
CNCF Blog Post
At Chainloop, one of our core principles is to meet users where they are, and Keyfactor’s solutions—across both open-source and enterprise versions—are a common theme in conversations with our community. This shared focus makes our partnership and integration with Keyfactor especially exciting.
Read more about how we enable automated software supply chain compliance and governance using trusted metadata, supported by technologies like SignServer, EJBCA, in-toto, and more in our joint blog post on the Cloud Native Computing Foundation (CNCF) website.
We were named the "Startup of the Year"!
Chainloop is proud to announce that we have been named the "Startup of the Year" at the 5th #Cyber24Day conference. Read more in our LinkedIn post.
Chainloop Platform
Now, let's move into the features added to the Chainloop Platform, which builds on the open-source Chainloop Evidence Store. Currently, the platform is available for private early access both as a SaaS offering and for on-prem deployment.
New policies
We have introduced some new policies to the built-in library:
- CWE in top 25 and Cusp list: Regularly analyze vulnerability scan reports for CWEs listed in the 2023 CWE Top 25 and Cusp list to stay ahead of critical and emerging security threats. Compatible with tools like SpotBugs, Zap, KICS, Blackduck, and GitLab.
- SBOM NTIA compliance: Ensure Software Bill of Materials (SBOM) reports meet National Telecommunications and Information Administration (NTIA) compliance standards, verifying they contain all necessary fields as per NTIA guidelines
- Artifact Signed: Validate the authenticity of artifacts, specifically CONTAINER_IMAGE types, by enforcing valid signatures. This helps secure the software supply chain against unauthorized or tampered deployments.
- Secrets detection: Identify exposed secrets in SAST (Static Application Security Testing) reports to prevent leaks. Supports GitLab secret scan reports secret scan reports to catch critical data like API keys and passwords before they reach production.
- IAC misconfiguration: Detect misconfigurations in Infrastructure as Code (IaC) scans to ensure best practices. It supports the SARIF format, tested with Checkov, for identifying infrastructure vulnerabilities.
- Binary scans: Detect misconfigurations in Infrastructure as Code (IaC) scans to ensure best practices. It supports the SARIF format, tested with Checkov, for identifying infrastructure vulnerabilities
Manage Custom Policies
If you can’t find the right policy in our official library of policies, we now support managing your own list of policies that can be used across your organization. Using the Policy form, you can craft your policy from scratch or import an existing one.
Once your custom policy is created, it will appear alongside the built-in Chainloop policies in the policy list. You can easily toggle a checkbox to filter and view only your custom policies for a more streamlined experience.
If you’d like to attach your custom policy, you can do so in a manner similar to the built-in Chainloop policies; simply add <your org name>/ as a prefix to your policy name. This makes it easy to manage and apply your custom policies alongside the default ones.
.gif)
To simplify the process of assigning policies, we’ve introduced a Policies Helper List on the side of the form. This feature will assist you in quickly locating the relevant policies you need. The Policies Helper List will automatically appear when you enter policies: or "policies": in the contract, making it easier to find and assign the appropriate policies for your use case.
Policy groups
We’re introducing Policy Groups to help you streamline compliance efforts more effectively. Policy Groups allow you to organize related policies into a single collection, simplifying compliance management and application across workflows. Groups are also versioned, so you can select specific versions as your compliance requirements evolve. Currently, the UI supports browsing policy groups, with additional functionality in future updates.
Policy Groups Management allows you to organize policy groups in a way that best fits your compliance and workflow needs. This added flexibility will make it easier to manage and apply policies across different areas of your organization.
Enhanced Policy Navigation
As our library of policies continues to grow rapidly, the Chainloop UI has evolved to make finding the right policy easier than ever. New features improve searchability and organization, and now, full support is available for creating and managing custom policies, allowing you to tailor compliance to your specific needs.
Policies can now be searched by name, category, and applicable material type, and the list can be sorted by name or creation date. This makes it faster to locate exactly what you need.
Versioned Policies
Policies now support versioning. You can preview all available versions and choose the one best suited to your requirements, with the latest version applied by default. If you are interested in how to choose a specific version, see the "Policy pinning" section in the open-source section above.
Skipped Policy Status
During evaluations, policies may now have a “skipped” status in the attestation, allowing you to track which policies have been properly evaluated and avoid unnecessary compliance issues. To make it easier to identify relevant messages, we’ve also moved validation and skipped reason messages to the “Evaluated Subjects” section, helping you quickly locate and understand policy outcomes.
Skipped policies are now excluded from our security and compliance scoring, ensuring that only fully evaluated and relevant policies impact your compliance status. This means you can focus on the policies that matter most to your security posture, without unnecessary noise from intentionally skipped items.
Chainloop Open Source - Evidence Store
Let’s start with the work done in our open-source project, Chainloop Evidence Store.
New material types
We want to ensure that you can use Chainloop with any SAST, DAST, or Secret Scanning tool you might already have without changing a single line of code. So the following list of supported material types have been added in this iteration.
- BlackDuck SCA
- GitHub Advanced Security Secret scan
- GitHub Advanced Security Code scan
- GitHub Advanced Security Dependency scan
- PrismaCloud Twistcli Scan
- ZAP Dast
You can read about the full list of material types here.
Container Image Signature Attestation
During the attestation of a container image, Chainloop will automatically retrieve the image signature created by Cosign or Notary and store it in the attestation alongside the digest of the artifact, useful in combination with policies.
Multi-kind policies
Multi-kind policies allow you to create a single policy that understands different input material types.
For example, we want to create a policy that checks if the CVE reported by a BlackDuck, Trivy, our GitHub Advance Security outputs are in the CISA’s KEV database.
Before Multi-kind, you needed to create one policy for each piece of evidence; now, you can just write a single policy and provide different execution paths and rego scripts.
The policy engine will then ensure that the right path(s) is chosen, aggregate the output, and report the aggregated evaluation result, an orchestrator, if you will.
However, using multi-kind policies for different material types is just one example. You can also use it to handle the same output type generated by different tools. In the next example, you have a policy that handles SARIF files generated by different tools (Zap, Spotbugs, KICS, and Stackhack).
Multi-kind policies give you a maintainable way of handling all these edge cases from a single entry point for the user.
But you might have spotted a challenge here: If, as a policy author, I can handle multiple inputs in the same policy, how can I handle exceptions and properly communicate whether the policy has been evaluated, skipped, or errored? Glad you asked :)
More Robust Policy Evaluation Output; removal of false positives
We want to ensure our policies have mechanisms to prevent false positives and communicate when the policy has been successfully evaluated, failed, or skipped.
To do so, we have updated our policy engine to have a set of expectations on what the underlying policies should return and crafted an example template that can be easily used to write your policies in Rego.
With that template, you just need to implement two functions, valid_input and violations. These two simple methods provide a standardized way of indicating when a policy was skipped why or was evaluated and its result.
Policy authoring resources
We’ve put together a set of resources to help you in the journey of writing your own Chainloop policies.
Hardened Policy Evaluation Engine
Running arbitrary code like rego policies must happen in a sandboxed environment with limited and explicit capabilities. We've significantly enhanced our sandbox environment to better protect our system from unauthorized access and potential risks.You can read more about the policy engine constraints here.
Policy pinning
To use a policy in Chainloop, you’ll need to attach it to the workflow contract. In this example, we instruct Chainloop to run two policies, one from a local file and another downloaded remotely.
A best practice in declarative configuration is to rely on version pinning when referencing an external dependency. In our case, we want to make sure we run a specific version of the policy or reject it otherwise.
To do so, just append the content digest of the policy, and Chainloop will take care of the integrity check for you.
Workflow Names in Project Scope
Before this feature, to represent two build pipelines, you needed to prefix them with, for example, their project name, e.g., frontend-build. This is because workflow names were unique within an organization. This is not the case anymore. Workflow names are now scoped within a project!
Automatic Workflow Creation
To simplify pipeline onboarding, workflows will now be automatically created the first time they are referenced during an attestation process. For example, by performing the following attestation, you’ll automatically register a workflow called build for the project frontend in the control plane.
Project Versions
When you talk about workflows, you usually want to do so in the context of the project they belong to. But segmenting by project is not enough; tracking project versions is also important.
Now, during the attestation process, you can specify an optional version number.
And will be shown through the CLI.
Wrapping Up
That’s it for October! We’re thrilled to bring you these updates, and we hope they enhance your experience with Chainloop. Book a demo to see the latest features in action, and if you’re enjoying the progress, consider joining our community on Slack and starring Chainloop Open Source on GitHub.
