When you integrate an existing CI/CD workflow with Chainloop, the generated artifacts are stored in your OCI registry and wrapped in a signed, SLSA 3 provenance-compliant in-toto attestation envelope.
At that point, in practice, you've managed to set up a single source of truth and a standardized process for attestation and artifact storage in your organization.
This is a good start but you told us loud and clear that it wasn't enough. You want to make more of that data, and specifically, you wanted a mechanism to leverage tooling that you already use. i.e Kibana for logging, Prometheus for metrics, or Dependency-Track for Software Bill Of Materials (SBOM).
We listened, we started working on the most demanded use-case and today we are happy to announce our first integration. Dependency-Track for SBOM analysis.
Chainloop can now be configured to automatically send any CycloneDX Software Bill Of Materials that has been received as part of an attestation to a Dependency-Track instance for continuous analysis.
Divide and Conquer
Traditionally, these kinds of integrations are encoded directly in the CI workflow. Chainloop, by contrast, enables a different approach by making sure that the responsibilities between the two main personas, Security/Operation (SecOps), and Development/Application teams are decoupled.
SecOps teams set up the integrations on the Control Plane while development teams just need to make sure their CI/CD workflow complies with the agreed contract. In other words, development teams will integrate with Chainloop once, while SecOps teams can mix and match later on with the different integrations.
There are technical benefits too! Let's go back to the Dependency-Track example. In a traditional approach, developers will need to write code on their CI workflows to talk to the Dep-Track API, store/rotate API tokens, and make sure that the instance is network-reachable from their CI runner.
With Chainloop, development teams don't need to know about Dep-Track existence, they just need to make sure they send a CycloneDX SBOM to the control plane as stated in the contract. No credentials sharing and more importantly, the Dep-Track instance can now be behind the firewall / VPN and accessible only by Chainloop Control Plane.
Enforcement and visibility
To glue the two responsibilities areas there is a crucial interface layer, the aforementioned Workflow Contract.
A contract states three things: a) who owns the workflow, b) what materials must be sent as part of the attestation and c) what environment (i.e GitHub Actions) the attestation must be crafted in.
For example, if you have a workflow associated with the following contract. Any incoming attestation will contain a CycloneDX SBOM. Which, in turn enables integration enforcement.
contract.yaml
schemaVersion: v1
materials:
# SBOMs will be uploaded to your OCI registry and referenced in the attestation
# Additionally they can be sent to any downstream integration for analysis
# i.e https://docs.chainloop.dev/guides/dependency-track/
- type: SBOM_CYCLONEDX_JSON
name: skynet-sbom
Expanding once again the Dep-Track example, before, the CI workflow is the one that sends the SBOM to Dep-Track, a bug or the removal of such code will break the integration. What's even worse is that you as an operator will likely not notice that the integration is broken.
With Chainloop, on the other hand, you'll get
a) Enforcement: if the contract states the inclusion of an SBOM. Then the attestation must contain it to be correctly recorded in the control plane.
b) Visibility: In the case of a bug on the CI/CD integration with Chainloop, Operators will detect anomalies in the number of received attestations and hence detect integration problems early.
This decoupled but enforced approach is what makes us believe that Chainloop is the best way of introducing third-party integrations into your Software Supply Chain.
What's next?
Dependency-Track integration is just the beginning. We are looking into helping you superpower your Software Supply Chain by for example sending in-toto, DSSE metadata and SPDX SBOM to guacsec/guac. CI/CD logs to your Kibana instance or feed your Grafana dashboard with custom Prometheus metrics.
If you have comments or suggestions on what integration we should support next let us know.
And if you are up for an adventure, take a look at the following end-to-end demo video or check out our reference how-to guide.
Thanks again and remember, send any thoughts or feedback our way!
Cheers, Miguel
