Software Supply Chain Security

                                " In-toto is a supply chain security project incubated by CNCF".

Intro to supply chain:

In laymen terms supply chain is a network of people/organizations involved in creating a product, then delievering it to the consumer.

For example: Let’s talk about Cocoa Choclate. The supply chain would be

Growing Cocoa Trees
Harvesting
Drying the Cocoa
Sourcing(Sending the cocoa to Exporting companies)
Shipment
Grinding cocoa beans
Manufacturing(A company takes these cocoa beans and make choclate out of them)
Retail

Software Supply Chain:

let’s talk about software supply chain. Anything that goes into or affect the software, from development phase to the depolymenet phase is included in software supply chain.

In this software supply chain:

The source code is living in version-control system i.e GitHub.
And from that source code on github a builder(SDK) is building an object File.
There might be a continous integration service, such as: Travis, running tests continously on every single commit that you make, so that the quality of software increases.
And then the compiled object file is getting packaged . a package can be considered as an installer of the whole application,(For example an apk in case of mobile application). The package can be hosted on any package repositry like Docker. Then the package(software) is ready to be deoployed anywhere.

Security Problems in supply chain:

But we can have security compromises in this very simple supply chain too. For example:

Attackers can take control of version control system, For example GitHub. And can modify the program’s logic or can add some malicious part of code. Once the GNU repository was hacked by SQL injection, the case study is attached below. csoonline.com/article/2126377/free-software..
Surprisingly a builder(SDK) Can Also get Hacked. I want to point out to a very famous case of XcodeGhost, which happened recently, In which someone made a replica of Xcode(SDK for apple devices) that resulted in every single IOS application, being compiled from Xcode have a malicious code in it. For example Angry Bird was affected by this attack
Packaging infrastructure can also get hacked. Package infrastructre is a place where the packages are stored .It could be Docker, It could be Linux store where different distributions of Linux are stored. Once an attacker can get access to package infrastructure, they can introduce “Backdoors” or corrupted copies on the infrastructure for Example .An Attacker got access to Korean mirror server of “Php My_Admin” and introduced corrupted copies . You can read full details from the link attached.

sourceforge.net/blog/phpmyadmin-back-door

An attacker got accessed to Linux Package Repository ,and introduced a backdoor to create a Botnet. A Botnet is a network in which all the computers are hacked(under the control of hacker), so the hacker could do the DDOS attack on any system.

so if anyone downloads the “Linux Mint “ his/her computer was under the access of hacker. And the hacker was successful in getting access of almost 800 computers.

Hacker explains how he put "backdoor" in hundreds of Linux Mint downloads A lone hacker who duped hundreds of users into downloading a version of Linux with a backdoor installed has revealed…

zdnet.com/article/hacker-hundreds-were-tric..

One can also hack Testing Pipeline so that the testing Server starts telling lie. And pass the test cases even if they are Not passed.

In a nutshell the whole supply chain can get hacked.

Solution:

Incomplete solution:

One might think that we can take steps to secure each part in our supply chain, so overall our supply chain will be secured? For example:

The answer is NO!. Because how you will be sure that these point solutions are being followed? let's hypothetically assume these point solutions are getting followed, how u will ensure a product that's being into the build farm is from Autehntic Version Control System or is it from any other? So how are we gonna cover this gaps. even if we fix all the problems at each point? ## IN-TOTO: So the solution is IN-TOTO. Intoto provides two types of metadata files.

Layout
Links

Layout:

Layout is a piece of policy that defines what needs to happen and how it should happen?

Steps:

A policy writter tells the steps to be done in software supply chain For example Step(name="Version Control System")

Functionaries:

Functionaries are actors in supply chain who will perform certain steps in supply chain To define a functionary we will define the path and key of the Functionary

alice_path = 
generate_and_write_rsa_keypair(password="123", filepath="alice")
alice_key = 
import_rsa_privatekey_from_file(alice_path, password="123")

Now we have made the alice a Project Master.

bob_path = 
generate_and_write_rsa_keypair(password="123", filepath="bob")
bob_pubkey = 
layout.add_functionary_key_from_path(bob_path + ".pub")

Now the Bob is a functionary . To assign a task(let's say version-control) to bob we have to perform the following step

step_vcs = Step(name="vcs")
step_vcs.pubkeys = [bob_pubkey["keyid"]]

Material/Products:

Materials/Product are rules which defines that Who can create what, and who can consume what . Material is the input to a step and Product is the output a Step produces. For example we defined the step "VCS" for Bob. So Bob will create foo.py in the Step of VCS only and nothing else.

step_vcs.add_product_rule_from_string("ALLOW demo-project/foo.py")
step_vcs.add_product_rule_from_string("DISALLOW *")

Artifact rules:

Artifact rules are like defining Links between users, What a actor can supply to other actor.

For example Carol can produce a file(defined in material) and supply it to Bob. And Bob can supply a file to Dave . But if bob supply something to Carol. There's something fishy in the Supply Chain.

inspection = Inspection(name="untar")

inspection.set_run_from_string("tar xzf demo-project.tar.gz")
inspection.add_material_rule_from_string(
    "MATCH demo-project.tar.gz WITH PRODUCTS FROM package")
inspection.add_product_rule_from_string(
    "MATCH demo-project/foo.py WITH PRODUCTS FROM update-version")
In the above code we are defining the artifact named "Untar" . It says that when we run the command "tar xzf demo-project.tar.gz"

that the command will take its input from package step and will output foo.py to update-version

Signing:

In the end the whole supply chain gets signed by the Project Master . In our case the project master is alice

metablock = Metablock(signed=layout)
metablock.sign(alice_key)

now we are done with the Layout file . Let's jump to Link file :)

Link File:

Link is basically a signed Stamp for Each File. As if bob was working on code part of supply Chain . He will create a sign (stamp) on his operations for example he will have a sign on "GIT TAG" ensuring that I am the one who worked on it and no one else did it. Similarly every actor will sign his version of work and in the each file will be stamped by some actor. We don't have to build link file, it get's automatically built after commands of In-toto

Verification:

Link is like the evidence of supply chain. From link we can deduce who performed which action and then from that evidence we can match the policy defined in Layout File. For Example In the link File we got that Coding is done by Mr.A but our policy says the Code should be done by Mr.B so there's something wrong in the Software supply chain An Example Project: To demonstrate in-toto we do Go to start.spring.io and generate the project with these settings

Extract the downloaded zip folder and go to \demo\src\main\java\com\example\demo and open the Demo-Application and place this code in the file package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@RestController
public class MyController {
 @GetMapping(value = "/")
 public String getRootResponse() {
 return "hello world";
 }
}

Open Command Prompt and write pip install in-toto to install in-toto SDK and CLI. after some seconds in-toto will be installed in your system.

Created public/private key pairs to sign our in-toto data we can do this with in-toto-keygen

Open the file in notepad and copy the key because you have to paste in root.layout 5)Let's also keep our supply chain simple for now. Imagine we are: (i) Building an executable jar with mvn package (ii) Validating the jar's authenticity before allowing the workflow to continue

in-toto.engineering.nyu.edu/wrap-up Download the custom layout file from here

Open the File in VsCode or any IDE and paste the below code but don't forget to paste your own key here which was copied earlier.
```
{
"signatures": [],
"signed": {
"_type": "layout",
"expires": "2022-10-18T09:31:22Z",
"inspect": [],
"keys": {
{
"_type": "step",
"name": "package",
"expected_command": [
"mvnw", "package"
],
"expected_materials": [],
"expected_products": [
[ "CREATE",  "demo-0.0.1-SNAPSHOT.jar"],
[ "DISALLOW",  "*" ]
],
"pubkeys": [
""
],
"threshold": 1
}
},
"readme": "",
"steps": []
}
}
```
Don't forget to rename the file as root With expected_command, we're stating that mvnw package (exactly) must be used With expected_products, we're stating (using in-toto's rule lanaguage) that we're expecting the creation of demo-0.0.1-SNAPSHOT.jar and nothing else With pubkeys, we're defining the identity of the authorised actors (in-toto calls them "functionaries") that are allowed to perform this step

7.Sign your key with root file file in-toto-sign - key alice - file root.layout

8.Place your root.layout in the directory where your java main file is and run this command (make sure your command prompt is also on the same directory where your root file is) Just making the root file is not enough you have to tell the into about your steps by yourself. Where Public_keys is the file where my keys are stored in-toto-run --step-name package --products demo-0.0.1-SNAPSHOT.jar --key alice -- mvnw package It will create the Jar File and the link file

package.79d41488.link:

"signed": {
 "_type": "link",
 "command": [ "mvnw", "package" ],
 "environment": {},
 "materials": {},
 "name": "package",
 "products": {
 "demo-0.0.1-SNAPSHOT.jar": {
 "sha256": "e201e6c6eb05b54a0c9325a62114f93faa8158f9325331d1f80e126f8841d985"
 }
 }
 }

We now have cryptographically signed metadata that: Confirms the command we used to generate our products Gives us a crytographic hash of the products generated by the stage, aiding in preventing tampering

Verification of Supply Chain:

Imagine that an attacker has been able to compromise our build system and is able to mutate source code after it has been reviewed:

@RestController
public class MyController {    @GetMapping(value = "/")
    public String getRootResponse() {        return System.getenv("MYSQL_ROOT_PASSWORD");
    }
}

As part of the attack, they try to build the jar, hoping it will be picked up by the rest of our pipeline: mvnw package In our verification stage, when we run in-toto-verify, in-toto prevents us from proceeding:

$ in-toto-verify \
  --layout root.layout \
  --layout-key mykey.pub

(in-toto-verify) RuleVerificationError: 'DISALLOW *' matched the following artifacts: ['"demo-0.0.1-SNAPSHOT.jar"']

Wrap Up:

Now as a conclusion i want you to be convienced that, security of supply chain is a very big problem and I hope you understand the current loopholes in software supply chain, And how In-toto is a great tool to Secure the Software Supply Chain. In-toto is the first Step to secure the whole supply chain.

Cloud Native Islamabad