SLSA Generic generator

When I was pushing the code and checking my GitHub just for cross-verification, There was something in suggested workflow’s called SLSA Generic Generator. As being curious, I dug deeper and realised it was a kind of security plugin.

Lets understand with an example, I am a chef of an cloud kitchen platform. I cook a dish and then package it and give it to the delivery agent. He then proceeds to deliver to the person ordered. The person who ordered feels it tastes different from the time he ate there. This causes a distrust.

To mitigate this, we employ the Inspector (SLSA Generic Generator). As the chef, I go and prepare the dish with secret spices only known to me. The inspector stand in the end of the kitchen. Once, I have cooked the dish. he will take a photo (hash) of it and write a note “I saw Chef Tejha cook this dish in a clean and certified kitchen at 10:00pm”. Inspector puts the note in a sealed, tamper proof envelope. When the dish arrives to the person ordered has a note next to the dish. Which, he can make sure it was not swapped with a different dish during the journey.

Lets understand how it works actually,

• Before the generator starts, it relies on OpenID Connect (OIDC — an identity layer built on the OAuth 2.0 authorization protocol basically it enables the application to verify a user’s identity for Single Sign-On(SSO)). When you run a build job, Github issues a temporary JWT token. This is done to make sure the job is running in a specific repo, on a specific commit SHA and by a specific workflow.
• Once the build runs, It produces a binary file (app.exe). we will run it thorugh a hashing algorithm. The hash string alone is sent to the generator.
• Generator in Github actions is like a security boundary. It cannot be modified by build script because it exists in a separate process space. Generator looks back at your build job and then used the OIDC toke to verify where the hash came from.
• Generator creates a JSON in-toto statement and then does Keyless Signing.
• Generator sends its OIDC token to fulcio (a certificate authority), it verifies the token and issues a short-lived certificate tired to that github workflow.
• Generator signs the JSON statement using the private key
• The signed statement and the certificate is published in rekor(a public, immutable log). This allows anyone to verify later.

When a user wants to verify the software, they use the slsa-verifier tool to perfom the checks

I tried it out, it was fun to learn this week something new.

Here is my github link : https://github.com/ntejha/slsa-test