Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to Software Supply Chain Security & Tooling

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.

Af49604c509b95ea8191c8d67e65fbf1?s=128

Bob Killen

August 05, 2022
Tweet

More Decks by Bob Killen

Other Decks in Technology

Transcript

  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

  19. None
  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?

  35. None
  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.

  59. None
  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

  103. None
  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