This month has been huge in terms of features and exciting news for Chainloop. We cut more than 20 releases with numerous features and bug fixes. This post will highlight some of them, but to stay up to date, don´t forget to subscribe to our repository!

Extended signing options

Chainloop CLI is now able to sign attestations with more signing methods and key storages, including: 

• Cosign keys, 
• KMS services (AWS KMS, GCP Cloud KMS, Azure Key Vault, and Hashicorp Vault Key Management).  
• PKCS#11 HSMs
• Kubernetes secrets
• Gitlab secrets

And more methods are on the roadmap, like signing with custom x509 certificates. Be sure to keep up to date by checking our documentation.

Keyless signing and Sigstore bundle output

Don't have a private key for signing? Chainloop can generate ephemeral certificates for signing that can be discarded after pushing the attestation. This way, there is no risk of compromising your secret if you configure it improperly in your CI/CD system.

In keyless mode, the Chainloop CLI will generate a certificate request (CSR), which is then validated and signed by the Chainloop Certificate Authority (CA). This way, we are building a chain of trust. Verification material is then downloaded for further verification, if you need it, using the Sigstore Bundle format.

Do you want to try it? Just configure your CA in your deployment and omit the --key when pushing your attestation:

The Sigstore bundle will contain all the necessary materials for the proper verification. You can use the CLI's workflow run describe command to verify it:

As a bonus, you can also verify your bundle using cosign CLI itself! (if it was signed with a cosign key)

Contract-less attestations

This has been a top request from our users. Chainloop now allows adding pieces of evidence to an attestation without needing to add them previously to the workflow contract. This opens a new world of possibilities. For example, we could dynamically attest all artifacts and pieces of evidence generated during a Github go-release action.

Check our documentation for additional information. 

Auto-discovery of pieces of evidence

You might have noticed it in the previous example. Material types are now autodetected in the CLI, meaning you no longer need to specify the --kind flag. 

Just add your material, and Chainloop will do its best to determine its type. Of course, you can set the kind if you wish to override it.

Support of additional pieces of evidence

Chainloop now supports a new set of types of evidence, including Helm Charts, CycloneDX  1.6, and CSAF 2, including the CSAF VEX profile and three new profiles: Security Advisory, Informational Advisory, and Security Incident Response.

With these updates, Chainloop contracts can reference and validate the newly introduced material types. With the type autodetection feature, there is no need to specify the type when adding new materials to the attestation. Chainloop can dynamically determine the appropriate schema for the validation.

OpenShift support

Now, all our public containers and charts are 100% OpenShift compliant in terms of security and pod capabilities (or the lack of). All our containers can run seamlessly with the most restricted nonroot and nonroot-v2, restricted and restricted-v2 default Security Context Constraints (SCC) in OpenShift 4.x.

‍

Chainloop Platform Private Early Access

Our mission is to help developers and platform teams ship trusted software faster. We are building a Software Supply Chain Control Plane that provides visibility, evidence store, automated compliance, and security across the entire SDLC.

This month, we launched the Chainloop Platform as a private early access. You can learn more about the platform here, and request access in this form.

Do you want to know more? Check our latest releases, and visit our brand new Quickstart guide to have you onboarded in seconds!

If you like what we do, feel free to drop a contribution, join our community in Slack, or give Chainloop Open Source a star on GitHub chainloop-dev/chainloop :)