Introduction to Software Supply Chain Security & Tooling

You’re familiar with containers and Kubernetes, but suddenly people are talking about supply chains, and you’re pretty sure they don’t mean the Suez Canal. Join Jeffrey Sica and Bob Killen for an in-depth look at the nuts, bolts, and metaphorical shipping containers that make up modern container supply chain security. They’ll demo sigstore and show how container signing automation works with Kubernetes. You’ll leave prepared to make decisions that will keep your org unstuck.

1. Supply Chain Security Tooling
2. Welcome! Dependencies, Tutorials, Links to Slides: https://github.com/jeefy/sigstore-intro-tutorial
3. $ whoami - Bob Bob Killen bobkillen@linux.com OSS Program Manager @ Google Github: @mrbobbytables Twitter: @mrbobbytables Site: mrbobbytabl.es
4. $ whoami - Jeff Jeffrey Sica jeefy@linuxfoundation.org DevEx @ CNCF Github: @jeefy Twitter: @jeefy Site: jeefy.dev
5. Before We Begin https://docs.sigstore.dev/cosign/installation/
6. Before We Begin Pt. 2 Docker will be required to follow along with the demos. Docker is not required to use the tooling shown. https://docs.docker.com/engine/install/#desktop
7. Before We Begin Pt. 3 KinD (Kubernetes in Docker) and Helm will be used for later demos. https://kind.sigs.k8s.io/docs/user/quick-start/#installation https://helm.sh/docs/intro/install/
8. Disclaimer You should have some knowledge of containers and Kubernetes
9. Containers: Galaxy-scale overview • Package an application with all of its dependencies (container image) • Run instances of the packaged application (container) • Think “Virtual Machine” but sharing kernel space and OS libraries (cgroups)
10. Kubernetes: Galaxy-scale overview • “Container Orchestration” – It takes an entire orchestra to play a symphony • Manages containers and their dependencies (Storage, Networking, third-party resources) in a declarative way • 100% API Driven
11. So… What Is Supply Chain Security? Sourcing Inventory Production Planning Transportation
12. The “Software Supply Chain” Code Artifacts Distribution Dependencies Execution
13. Current State?
14. Current State https://www.bike-eu.com/market/nieuws/2022/01/imbalance-in-shipping-container-supply-chain-is-far-from-over-10142078
15. Current State https://www.bike-eu.com/market/nieuws/2022/01/imbalance-in-shipping-container-supply-chain-is-far-from-over-10142078
16. Current State https://www.cnbc.com/2021/03/26/satellite-images-of-ship-ever-given-in-suez-canal-shows-work-underway.html
17. Current State https://www.freightwaves.com/news/insurers-call-for-action-to-prevent-containership-fires
18. https://sonatype.com/resources/white-paper-2021-state-of-the-software-supply-chain-report-2021
20. Solarwinds Attack • SolarWinds Orion network management tool’s build servers compromised • Hack injected a malicious DLL at build time that was signed and distributed to clients automatically when they updated • 18,000 SolarWinds customers including many Fortune 500 Companies, Government Agencies and Tier 1 Network Providers were impacted Project Trebuchet: How SolarWinds is Using Open Source to Secure Their Supply Chain in the Wake of the Sunburst Hack
21. Solarwinds Attack • SolarWinds Orion network management tool’s build servers compromised • Hack injected a malicious DLL at build time that was signed and distributed to clients automatically when they updated • 18,000 SolarWinds customers including many Fortune 500 Companies, Government Agencies and Tier 1 Network Providers were impacted Project Trebuchet: How SolarWinds is Using Open Source to Secure Their Supply Chain in the Wake of the Sunburst Hack NO source code compromised
22. https://sonatype.com/resources/white-paper-2021-state-of-the-software-supply-chain-report-2021
23. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
24. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between the Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
25. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between the Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
26. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between the Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities Work on OSS? Want a security key? Find me after and get a free Titan key.
27. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between the Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
28. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
29. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
30. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
31. US Gov Policy Changes Executive Order 14028 - (Sec. 2) Remove barriers to threat information sharing between Government and the Private Sector - (Sec. 3) Modernize and implement stronger cybersecurity standards in the Federal Government - (Sec. 4) Improve Software Supply Chain Security - (Sec. 5) Establish a Cybersecurity Safety Review Board - (Sec. 6) Create a standard playbook for responding to cyber incidents - (Sec. 7) Improve Detection of Cybersecurity Incidents on Federal Government Networks - (Sec. 8) Improve Investigative and Remediation Capabilities
32. The Problem In A Nutshell
33. Supply Chain Attacks are on the rise and the Software Development Lifecycle has become a popular vector for attacks.
34. How can we trust the software we choose to run?
36. A Reasonable Solution
37. SLSA
38. Supply chain Levels for Software Artifacts 💃 slsa.dev
39. Source Integrity Build Integrity Source Build Package Dev Dependencies Users Software Supply Chain Artifact Process
40. Source Integrity Build Integrity Source Build Package Dev Inject bad code (A) Compromise source control (B) Build from modified sources (C) Dependencies Compromise build system (D) Bypass CI/CD, inject bad artifact (F) Compromise package repository (G) Use bad package (H) Users Software Supply Chain: Vulnerability Points Artifact Process Inject bad or vulnerable dependency (E)
41. Source Integrity Build Integrity Source Build Package Dev Inject bad code (A) Compromise source control (B) Build from modified sources (C) Dependencies Compromise build system (D) Bypass CI/CD, inject bad artifact (F) Compromise package repository (G) Use bad package (H) Users Software Supply Chain: Trust Boundaries Artifact Process Inject bad or vulnerable dependency (E)
42. SLSA Levels Automation & Provenance Build must be fully scripted/automated and generate provenance Version Control & Signed Provenance Requires using version control and hosted build service that generates authenticated provenance Non-falsifiable, Ephemeral Builds are fully trustworthy, with identity attestations of underlying build infrastructure/hardware. Ephemeral builds leave nothing behind. Hermetic Builds, Review All build inputs/dependencies are specified upfront with no internet egress during the build. Two-party reviews. https://slsa.dev/spec/v0.1/requirements
43. Build Provenance Set of metadata that describes a software artifact and how it was built. SLSA spec fields* - subject - artifact(s) information (name+digest) - builder - the entity that produced the artifact(s) - invocation - execution command / information - buildConfig - record of steps executed during build - materials - other artifacts/dependencies used during build
44. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }}
45. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }}
46. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }} builder - Entity that produced the artifact Examples: "builder": { "id": "mailto:person@example.com" } "builder": { "id": "https://github.com/Attestations/GitHubHostedActions@v1" } "builder": { "id": "https://gitlab.com/foo/bar/-/runners/12345678" }
47. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }} invocation - Execution command / information Example: "invocation": { "configSource": { "uri": "git+https://github.com/foo/bar.git, "digest": { "sha1": "1234..."}, //git commit hash "entryPoint": "build.yaml:build" }, "parameters": {"inputs": {}}, "environment": { “arch”: “amd64”, "env": { "GITHUB_RUN_ID": "1234", "GITHUB_RUN_NUMBER": "5678", "GITHUB_EVENT_NAME": "push" } } }
48. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }} materials - other artifacts/dependencies used during build Example: "materials": [{ "uri": "https://example.com/example-1.2.3.tar.gz", "digest": {"sha256": "1234..."} }] "materials": [{ "uri": "git+https://github.com/foo/bar.git", "digest": {"sha1": "abc..."} }]
49. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }} buildConfig - record of steps executed during build Example: "buildConfig": { "steps": [ { "image": "pkg:docker/make@sha256:244fd47e07d1004f0aed9c", "arguments": ["build"] } ] } "buildConfig": { "commands": [ "./configure --enable-some-feature", "make foo.zip" ], "shell": "bash" }
50. { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ ... }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "<URI>" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" }, "parameters": { /* object */ }, "environment": { /* object */ } }, … … "buildConfig": { /* object */ }, "metadata": { "buildInvocationId": "<STRING>", "buildStartedOn": "<TIMESTAMP>", "buildFinishedOn": "<TIMESTAMP>", "completeness": { "parameters": true/false, "environment": true/false, "materials": true/false }, "reproducible": true/false }, "materials": [ { "uri": "<URI>", "digest": { /* DigestSet */ } } ] }} subject - Artifact(s) information (name+digest) Examples: "subject": [{"name": "_", "digest": {"sha256": "5678..."}}] "subject": [ { "name": "herpderp.exe", "digest": {"sha256": "1234..."} }]
51. Software Attestation A software attestation is a signed set metadata (provenance) about one or more software artifacts. { "payload": "Gew9gICJzdWJqZWN0IjogWwogICAg...", "payloadType": "application/vnd.in-toto+json", "signatures": [{ "keyid": "my-awesome-builder-key", //optional "sig": "Re4ya66MyFyc9Y..." }] }
52. { "payload": "Gew9gICJzdWJqZWN0IjogWwogICAg...", "payloadType": "application/vnd.in-toto+json", "signatures": [{ "keyid": "my-awesome-builder", "sig": "Re4ya66MyFyc9Y..." }] } { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ "name": "_", "digest": {"sha256": "5678..."} }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "https://github.com/Attestations/GitHubHostedActions@v1" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" } …
53. { "payload": "Gew9gICJzdWJqZWN0IjogWwogICAg...", "payloadType": "application/vnd.in-toto+json", "signatures": [{ "keyid": "my-awesome-builder", "sig": "Re4ya66MyFyc9Y..." }] } { "_type": "https://in-toto.io/Statement/v0.1", "subject": [{ "name": "_", "digest": {"sha256": "5678..."} }], "predicateType": "https://slsa.dev/provenance/v0.2", "predicate": { "builder": { "id": "https://github.com/Attestations/GitHubHostedActions@v1" }, "buildType": "<URI>", "invocation": { "configSource": { "uri": "<URI>", "digest": { /* DigestSet */ }, "entryPoint": "<STRING>" } … Thanks SLSA!
54. Is There A Reasonable Technical Solution?
55. sigstore https://sigstore.dev
56. Community Driven
57. Community Driven
58. Let’s Encrypt? Let’s Sign.
60. An Overview Of sigstore • fulcio • rekor • cosign
61. An Overview Of sigstore • fulcio ◦ Identity • rekor ◦ Immutable log with artifact metadata • cosign ◦ Utility to automate combining fulcio, rekor, and OCI-compliant artifacts ◦ Utilizes underlying sigstore libraries
62. fulcio Free Root-CA for code signing certs - issuing certificates based on an OIDC email address fulcio only signs short-lived certificates that are valid for under 20 minutes https://docs.sigstore.dev/fulcio/overview https://github.com/sigstore/fulcio
63. fulcio Free Root-CA for code signing certs - issuing certificates based on an OIDC email address. fulcio only signs short-lived certificates that are valid for under 20 minutes. https://twitter.com/jacques_chester/status/1506332697387491335
64. rekor Greek for “Record” rekor is a transparency log where anyone can find and verify signatures, and check whether someone’s changed the source code, the build platform or the artifact repository. https://docs.sigstore.dev/rekor/overview https://github.com/sigstore/rekor
65. cosign cosign: Container Signing, verification and storage in an OCI registry “Make signatures invisible infrastructure” Pluggable components https://docs.sigstore.dev/cosign/overview https://github.com/sigstore/cosign
66. How it works! https://www.sigstore.dev/how-it-works
67. The. Demo.
68. Demo Recap • Built a container • Auth’d using cosign • Signed a container using cosign • Inspected the container’s signature using cosign
69. Cool I have a signed container. Now what?
70. Kubernetes Admission Webhooks Lightweight extensible way to “do something” with API Server requests Two kinds: - Validating Admission Webhook - Mutating Admission Webhook
71. Kubernetes Admission Webhooks Lightweight extensible way to “do something” with API Server requests Two kinds: - Validating Admission Webhook - Mutating Admission Webhook
72. Kubernetes Admission Webhooks … webhooks: - name: "pod-policy.example.com" rules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["pods"] scope: "Namespaced"
73. Kubernetes Admission Webhooks Lightweight extensible way to “do something” with API Server requests Two kinds: - Validating Admission Webhook - Mutating Admission Webhook
74. sigstore Policy Controller … apiVersion: policy.sigstore.dev/v1beta1 kind: ClusterImagePolicy metadata: name: image-policy spec: images: - glob: "**"
75. sigstore Policy Controller … apiVersion: policy.sigstore.dev/v1beta1 kind: ClusterImagePolicy metadata: name: image-policy spec: images: - glob: "**" Beta
76. Kubernetes native policy engine Entirely CRD-based https://kyverno.io
77. Demo: Part Deux
78. Demo Recap • Installed Kyverno • Attempted to create a Pod with an unsigned container image • Successfully created a Pod with a signed container image Task Failed Successfully!
79. Demo Recap • Installed the Kyverno • Attempted to create a Pod with an unsigned container image • Successfully created a Pod with a signed container image Task Failed Successfully!
80. kyverno is https://kyverno.io powerful configurable complicated
81. Let’s Talk Automation
82. https://github.blog/2021-12-06-safeguard-container-signing-capability-actions/
83. https://github.blog/2021-12-06-safeguard-container-signing-capability-actions/
84. GitHub Action jobs: test_cosign_action: runs-on: ubuntu-latest permissions: {} name: Install Cosign and test presence in path steps: - name: Install Cosign uses: sigstore/cosign-installer@main - name: Check install! run: cosign version https://github.com/sigstore/cosign-installer
85. GitHub Action … - name: Sign image with a key run: | cosign sign --key env://COSIGN_PRIVATE_KEY ${TAGS} env: TAGS: ${{ steps.docker_meta.outputs.tags }} COSIGN_PRIVATE_KEY: ${{secrets.COSIGN_PRIVATE_KEY}} COSIGN_PASSWORD: ${{secrets.COSIGN_PASSWORD}} https://github.com/sigstore/cosign-installer
86. Batteries included support for cosign Create a secret called signing-secrets with the following structure: • cosign.key • cosign.password cosign generate-key-pair k8s://tekton-chains/signing-secrets Tekton (Chains)
87. “Demo”: The Third
88. Demo Recap • Set up GitHub Action • Use cosign to sign the image • Use SLSA tooling to generate attestation • User cosign to attach attestation in rekor • Inspected and verified the image and SLSA payload
89. sigstore: Not Just Containers
90. Rust Crate Signing
91. PyPi Signing https://pypi.org/project/sigstore/
92. sigstore: Not Just Artifacts
93. gitsign Keyless Git signing with Sigstore! Homebrew: brew install sigstore/tap/gitsign Go: go install github.com/sigstore/gitsign@latest
94. gitsign # Sign all commits git config --global commit.gpgsign true # Sign all tags git config --global tag.gpgsign true # Use gitsign for signing git config --global gpg.x509.program gitsign # gitsign expects x509 args git config --global gpg.format x509 https://github.com/sigstore/gitsign
95. Demo #4
96. Demo Recap • Signed a git commit with gitsign • Inspected the rekor log of the commit
97. Tutorial Recap • Supply chain security is an increasing concern when building, shipping, and running code. • The SLSA framework can be used to enable or improve trust in the software that we build and run.
98. Tutorial Recap • sigstore looks to solve supply chain security with an end to end solution based on linking Identity and TLS certificates • Automating SLSA provenance generation and artifact signing lowers the mental load on developers shipping software
99. Tutorial Recap • Starts with Containers / OCI-compliant artifacts • Already moving further down the stack to packages
100. Secure Distribution By Default
101. Thanks + Q&A A @mrbobbytables + @jeefy Production
102. Graveyard
104. SLSA Framework Build Integrity • Modification of code after source control • Compromised build platforms • Bypassing CI/CD Source Integrity • Available change history • Code review • Compromised source control systems Dependencies • Applying SLSA checks recursively to dependencies • Dependency confusion