Skip to main content
So far we have performed attestations, attached pieces of evidence, evaluated policies and store the result in Chainloop. In this section, we’ll show you how you can see the compliance posture of your whole project and product with the use of products, project versions and compliance frameworks. If you remember, during the attestation process you have been providing the --project flag with the value myproject, so let’s inspect it in the project view. info The goal of this view is to show you a high-level, aggregated view of your project workflows, pieces of evidence, policy evaluations and compliance score. You can learn more about the project view in this guide.

​
Enabling compliance through products

In addition to the project concept that enables workflow, policy, and evidence aggregation, Chainloop also introduces the concept of product. Products can be seen as a collection of projects (components) to enable product management capabilities and become an entry point to manage compliance, alerting, and user access configuration at scale. To enable compliance, you need to create a product and then 1) attach the project to it 2) attach the compliance frameworks that we want to use, in our case we will use the SLSA and chainloop-best-practices frameworks Once done, you should be able to see the list of requirements automatically fulfilled by your workflows. info and you can drill down to see the details of each requirement in the frameworks tab. info

​
Manage Project Versions

Important: A “project” is different than a “product”, as well as a “project version” is different than a “product version”.Project versions represent the version of the component while product versions represent the version of the product. Products and project versions can evolve independently.
As you can see at the top left, there is a version selector with the none value for now. Chainloop allows you to create versions of your project, so all the compliance data can be aggregated by version. To learn more about versions, check this guide. Let’s try to perform the same attestation than before but this time providing the --version flag with the value 1.0.0. 
chainloop att init --workflow build-container-image --project myproject --version 1.0.0 --replace
# Provide materials
chainloop att add --name container --value ghcr.io/chainloop-dev/chainloop/control-plane
chainloop att add --name sbom --value https://raw.githubusercontent.com/chainloop-dev/chainloop/refs/heads/main/docs/examples/quickstart/sbom.json
chainloop att add --name vulnerabilities-report --value https://raw.githubusercontent.com/chainloop-dev/chainloop/refs/heads/main/docs/examples/quickstart/vulnerability-report.json

# Sign and push
chainloop att push
You now have the version 1.0.0 in the selector up top info

​
Aggregate data

As mentioned before the goal of this view is to show you a high-level, aggregated view of your project workflows, pieces of evidence, policy evaluations and compliance score for each version. So let’s try to perform another attestation but this time from another workflow 
chainloop att init --workflow build-another-service --project myproject --version 1.0.0 --replace

# We can push already since it has an empty contract
chainloop att push
Now you should be able to see the new workflow in the project view and any policy, and metadata evaluations aggregated by version. info
⌘I