Thanks to Priya Wadhwa for giving me the clue about the title of the blog post. Credit: www.youtube.com/watch?v=LzWkURgzkx0
There’s no doubt that in today's world, software supply chain attacks are becoming an increasingly critical threat every day. I guess if they said you have three wishes for everyone in today's Cloud Native ecosystem world, they would all answer those three rights as protecting my software supply chain. Therefore, instead of believing in fairy tales and instead of waiting for someone to come out and touch the magic wand to our CI/CD system to secure it against supply chain attacks, we should start taking precautions against these attacks without wasting any time from today to be a victim of these attacks and not to be included in the compromises list of cncf/tag-security. Also, this isn’t a problem that we can only solve alone. Assuming that 99% of today's software uses open-source technologies, we can say that this problem is a problem for all of us. Therefore, to solve this problem, we all must come together and embrace the problem we face, then, to defend ourselves against that risk, we should provide some good practices, recommendations, requirements, and tools. Just as we said, everyone in the Cloud Native ecosystem and the open-source world took these attacks seriously and carried out important work on this issue. One of the results of these crucial works is the Tekton Chains project by the Tekton community, which we will talk about today.
If you don’t know where to start protecting your software supply chain against these attacks, Tekton Chains project is going to help you get off to a great start on this because it will make your software supply chain SLSA Level 2 compliant for free, please don’t worry if it doesn't make sense to you, we will be talking about SLSA in the upcoming sections.
Before diving into the details of the Tekton Chains project, it would be better to mention the Tekton project; thus, you need to be using Tekton to be using the Tekton Chains project.
Tekton, known as Tekton Pipelines. Tekton is part of the CD Foundation, a Linux Foundation project, and it is basically a CI/CD system built on top of Kubernetes; actually, it is more than a CI/CD system, it is more like a framework because it lets you create your own CI/CD system by leverages CRD (Custom Resource Definitions) to give you the building blocks of the CI/CD you would typically expect, such as steps, tasks, pipelines, etc. The power of these building blocks allows you to create custom pipelines with various tasks such as running tests and quality checks, compiling the source code, building and scanning container images, etc.
Next, to better understand the benefit that we will get when we use the Tekton Chains project and the vision it sets for itself as a goal, we need to talk about the SLSA (Supply Chain Levels for Software Artifacts) project first.
In the most basic terms, SLSA is a security framework designed to help organizations improve the integrity of their software supply chains. SLSA is organized by levels, where each level represents incremental progress from the previous. The higher the level, the more confidence that the software process hasn’t been tampered with.
As we said, once you use Tekton Chains, your software supply chain will become SLSA Level 2 compliant due to provenance generation and make this provenance authentic by signing it.
But, wait a minute, what does provenance mean, why is it so important? One of the golden rules in software supply chain security is that every artifact can be verifiably traced to Source Code and Hardware because this might be the only proof that the software that you want to run on your systems is the software that is built by your trusted company. Therefore, you can think that you must ask questions about your artifacts before allowing them to run on production systems. I liken deploying artifacts to production systems to a job interview. Just like in the interview, just as the employer asks questions about the person to be hired for his suitability for the company, we should ask questions to understand whether the artifact is suitable for deployment in the production environment or not. For example:
With provenance files, you can address these questions above. You can think of them as a proof document of your software, i.e. a record of prior ownership and a place of origin. Having this provenance offers several benefits. For one, it provides traceability for artifacts deployed in production, which significantly helps when debugging issues. Currently, provenance generation isn’t widely supported; again, thanks to Tekton Chains, as we mentioned above, Tekton Chains can create an attestation, a signed provenance, without any toil. But how?
TaskRuns are the main execution unit in Tekton Pipelines. Therefore, after the execution of a TaskRun, we can know: