-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blog: Add blog post on Tekton Chains and IBM DevSecOps #1048
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
d1048b9
Add blog post on Tekton Chains and IBM DevSecOps
lehors 029eaa4
Fix formatting
lehors e409802
Fix links to slsa.dev
lehors c885477
Reword some of the text
lehors aef0c1a
Reword sentence about what Tekton chains provide
lehors 44f3e5c
Address comments
lehors File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
--- | ||
title: "Securing software artifacts with Tekton Chains and IBM's DevSecOps" | ||
author: "Arnaud J Le Hors" | ||
is_guest_post: true | ||
--- | ||
|
||
Tekton Chains, and the IBM DevSecOps offering that builds on it, can now be used to secure software artifacts with SLSA. | ||
|
||
## From DevOps to DevSecOps | ||
|
||
For years the industry has been advocating the modernization of development processes with the adoption of what is known as "DevOps" with the promise that, by combining and automating software development and IT operations, DevOps can speed delivery of higher-quality software. However, with the constant rise in security attacks against all software we've seen a quick shift towards "DevSecOps" which continuously integrates and automates security throughout the DevOps lifecycle. DevSecOps makes security a first class citizen by addressing security concerns throughout the development lifecycle rather than as an afterthought and often last check. | ||
|
||
## Tekton Chains | ||
|
||
[Tekton](https://tekton.dev) is a powerful and flexible open-source framework for creating continuous integration and delivery (CI/CD) systems which is used in the industry to manage the production and deployments of software artifacts in the cloud as part of a DevOps strategy. [Tekton Chains](https://tekton.dev/docs/chains/) adds to Tekton a resource controller which can be used to manage your supply chain security in Tekton pipelines and move you towards DevSecOps. | ||
|
||
As a sign of SLSA's growing adoption, Tekton Chains has been adding support for the production of SLSA Provenance attestations along with the ability to sign and verify artifacts with [sigstore](https://sigstore.dev). | ||
|
||
However, if you follow the [Getting Started Supply Chain Security Tekton tutorial](https://tekton.dev/docs/getting-started/supply-chain-security/) you will see that the attestation that you get is in the Provenance v0.1 or v0.2 format. While this is sufficient to achieve SLSA compliance you will probably want to get it in the Provenance v1 format rather since this is what is part of [SLSA v1.0 released last year](/blog/2023/04/slsa-v1-final). | ||
|
||
The good news is that thanks to a change introduced in [Tekton Chains v0.17.0](https://github.com/tektoncd/chains/releases/tag/v0.17.0), which was released last summer, Tekton Chains can now produce attestations in the SLSA Provenance v1 format. The challenge is that getting the right configuration to enable this capability involves option names that are not obvious. | ||
|
||
Indeed, one must set the Tekton Chains configuration output format option to `slsa/v2alpha3` to get the Provenance v1 format, while setting the format to `slsa/v1` (which is currently the default) produces an attestation in Provenance v0.2. These values are obviously unfortunate. There is actually evidence in the repo that they weren't meant to be exposed to the user but, as it sometimes happens, things that are meant to be temporary stick beyond the initial phase and, as specified in the [How to configure Tekton Chains](https://tekton.dev/docs/chains/slsa-provenance/#how-to-configure-tekton-chains) documentation, `slsa/v2alpha3` is what you must use for now. | ||
|
||
Obviously, it would make sense to have more straightforward values and for the v1 format to be the default. I will do what I can by engaging with the Tekton Chains community to help make this happen, but in the meantime you now have the right configuration to get the desired result. | ||
|
||
## IBM DevSecOps | ||
|
||
The [IBM DevSecOps offering](https://cloud.ibm.com/docs/devsecops) available to IBM Cloud users is based on Tekton and Tekton Chains and since January this year one can use it as a SLSA Level 3 build platform producing SLSA Provenance v1 attestations. | ||
|
||
This build platform is used internally by IBM to produce software artifacts such as the [IBM Cloud Paks](https://www.ibm.com/cloud-paks) generating along with them both SBOMs and SLSA Provenance attestations, and IBM Cloud users can equally benefit from it by using it to produce their own software artifacts. | ||
|
||
I'm happy to say that the configuration of IBM DevSecOps is a bit more straightforward than that of Tekton Chains and one can simply set the `slsa-attestation` parameter to `1` to get the build platform to produce SLSA attestations in the Provenance v1 format. | ||
|
||
You can then use [cosign](https://github.com/sigstore/cosign) to verify the signature on the produced attestation. | ||
|
||
More details can be found in the [Configuring collection of SLSA attestations for images](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-slsa) and the [Pipeline Private Workers - What is SLSA?](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-slsa-whatis) documentation. | ||
|
||
## Related information | ||
|
||
[SLSA 1.0](/spec/v1.0/) | ||
|
||
[SLSA Provenance v1](/spec/v1.0/provenance) | ||
|
||
[Secure Your Software Supply Chain with SLSA Level 3 Support on IBM Cloud](https://community.ibm.com/community/user/cloud/blogs/steve-weaver1/2024/01/11/secure-your-software-supply-chain-with-slsa-level) |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about verifying the artefacts themselves (through provenance)? Is that done with
cocao locker evidence check
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, this is currently "left as an exercise to the reader" so to speak. :-) But I agree with you that this should be addressed. I'll merge this now because it's been sitting there for a long time already and I'll post an update ASAP.
Thanks for your review!