Proof-of-concept SLSA provenance generator for GitHub Actions

Overview

SLSA GitHub Actions Demo

A proof-of-concept SLSA provenance generator for GitHub Actions.

Background

SLSA is a framework intended to codify and promote secure software supply-chain practices. SLSA helps trace software artifacts (e.g. binaries) back to the build and source control systems that produced them using in-toto's Attestation metadata format.

Description

This proof-of-concept GitHub Action demonstrates an initial SLSA integration conformant with SLSA Level 1. This provenance can be uploaded to the native artifact store or to any other artifact repository.

While there are no integrity guarantees on the produced provenance at L1, publishing artifact provenance in a common format opens up opportunities for automated analysis and auditing. Additionally, moving build definitions into source control and onto well-supported, secure build systems represents a marked improvement from the ecosystem's current state.

Security and Support

This is demo repo and is not intended to be used in production contexts. As such, we cannot make any commitments of future support.

Example

To see an example of the action... in action, see the example action and example provenance in this repository.

Usage

The GitHub action has the following user configuration

Input Default Description
artifact_path none Path to build artifact or directory of build artifacts
output_path build.provenance Path to write build provenance file

To try out this provenance generator, add the following snippet to your GitHub Actions workflow:

      - name: Generate provenance
        uses: slsa-framework/[email protected]
        with:
          artifact_path: <path-to-artifact>

In this example we use the default output path build.provenance, you can upload the build provenance to the workflow run result with the actions/upload-artifact github action

      - name: Upload provenance
        uses: actions/[email protected]
        with:
          name: my-artifact
          path: build.provenance
Issues
  • Bugs in provenance

    Bugs in provenance

    1. _type: wrong capitalization: "Statement", not "statement"
    2. name (not Name)
    3. digest (not Digest)
    4. predicateType: wrong capitalization: "Provenance", not "provenance"
    5. builder.id: should identify the specific workflow that invoked the action, not github hosted actions. This represents the entity that needs to be trusted.
    6. recipe.entryPoint: Should be "<workflow.yaml>:<job_name>", e.g. "example-publish.yaml:build"
    7. recipe.arguments: Should be an object with an input field? Could you test by doing an invocation with an input? (It's OK for this to be null, but if it's not null, I think it should have an input field, but looking at the code I'm guessing that's not the case.)
    8. materials.uri: protocol should be git+https?
    9. buildInvocationId: Can we use a URI instead of just the number, i.e. the /runs/ URI?
    10. recipe.environment: Maybe we should just omit it since it's so huge? In reality I think GitHub would minimize the fields that are present. It's only really needed for reproducibility which is SLSA 4.

    Q: Should the output be an Envelope (with no signatures), rather than the Statement?

    opened by MarkLodato 12
  • Confirm that `recipe.arguments` has an `input` subfield.

    Confirm that `recipe.arguments` has an `input` subfield.

    Looking at the code, it appears that the GitHub input object is assigned directly to recipe.arguments rather than recipe.arguments.input. @msuozzo Could you confirm with an example and fix if needed?

    opened by MarkLodato 1
  • Revert

    Revert "Properly name each artifact in GH Actions."

    This reverts commit f293d1cd68f0b3457dbf3f4f793e9f9cadd5efa1.

    An "artifact" in GitHub Actions is a collection of files, not a single file, so the original version was working fine (with all files under the collection named "artifact") whereas the new version broke because it tried to download the non-existent artifact named "artifact".

    Let's just revert to the old version because it was fine.

    opened by MarkLodato 0
  • Properly name each artifact in GH Actions.

    Properly name each artifact in GH Actions.

    Previously both the artifact (salsa.txt) and the provenance (build.provenance) were uploaded with the default name of "artifact", meaning that the provenance overwrote the original artifact.

    opened by MarkLodato 0
  • Prepare for publishing

    Prepare for publishing

    Signed-off-by: Appu Goundan [email protected]

    Adds more metadata to action.yml

    Also contains two examples using the action in this repo

    • example-local.yml (uses the action directly from the repo, since it's private)
    • example-publish.yml (uses this action potentially when it is published)
      • requires that we make this repo public, create a release and publish this release onto github marketplace
    opened by loosebazooka 0
  • Improve Scorecard score

    Improve Scorecard score

    Describe the bug I know this is a demo repository, but if we are expecting people to install on their own systems, we should try to follow security best practices as well. If the demo is no longer valid, we could either repurpose for future demos or deprecate the repo.

    Improve repository's OpenSSF Scorecard score (currently at 4.2)

    To Reproduce docker run -e GITHUB_AUTH_TOKEN gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/slsa-framework/github-actions-demo --format=json > scorecard_slsa-framework_github-actions-demo.json

    Expected behavior

    • Branch Protections could be improved
    • CII-Best-Practices Badge could be obtained
    • Project should always have reviews/CI-Tests when possible
    • Project should be Fuzzed
    • Dependencies should be updated regularly with automated tooling
    • Repo is not maintained --> may be as a result of it being a deprecated repo
    • All dependencies should be pinned via hash
    • SAST Tool should be used to scan upon code commits
    • Security Policy should be created
    • Token Permissions should follow principle of least privilege

    Screenshots image image image image image image

    Additional context Attempted to upload the JSON file, but github does not allow me to. Related to recommendation of securing our repos: https://github.com/slsa-framework/slsa/issues/424

    opened by melba-lopez 0
  • Configure Renovate

    Configure Renovate

    Mend Renovate

    Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

    🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.


    Detected Package Files

    • Dockerfile (dockerfile)
    • .github/workflows/example-local.yml (github-actions)
    • .github/workflows/example-publish.yml (github-actions)
    • go.mod (gomod)

    Configuration Summary

    Based on the default config's presets, Renovate will:

    • Start dependency updates only once this onboarding PR is merged
    • Enable Renovate Dependency Dashboard creation.
    • If Renovate detects semantic commits, it will use semantic commit type fix for dependencies and chore for all others.
    • Ignore node_modules, bower_components, vendor and various test/tests directories.
    • Autodetect whether to pin dependencies or maintain ranges.
    • Rate limit PR creation to a maximum of two per hour.
    • Limit to maximum 10 open PRs at any time.
    • Group known monorepo packages together.
    • Use curated list of recommended non-monorepo package groupings.
    • A collection of workarounds for known problems with packages.

    🔡 Would you like to change the way Renovate is upgrading your dependencies? Simply edit the renovate.json in this branch with your custom config and the list of Pull Requests in the "What to Expect" section below will be updated the next time Renovate runs.


    What to Expect

    With your current configuration, Renovate will create 5 Pull Requests:

    Update dependency golang to v1.19
    • Schedule: ["at any time"]
    • Branch name: renovate/golang-1.x
    • Merge into: main
    • Upgrade golang to 1.19-buster
    Update module go to 1.19
    • Schedule: ["at any time"]
    • Branch name: renovate/go-1.x
    • Merge into: main
    • Upgrade go to 1.19
    Update actions/checkout action to v3
    • Schedule: ["at any time"]
    • Branch name: renovate/actions-checkout-3.x
    • Merge into: main
    • Upgrade actions/checkout to v3
    Update actions/download-artifact action to v3
    • Schedule: ["at any time"]
    • Branch name: renovate/actions-download-artifact-3.x
    • Merge into: main
    • Upgrade actions/download-artifact to v3
    Update actions/upload-artifact action to v3
    • Schedule: ["at any time"]
    • Branch name: renovate/actions-upload-artifact-3.x
    • Merge into: main
    • Upgrade actions/upload-artifact to v3

    🚸 Branch creation will be limited to maximum 2 per hour, so it doesn't swamp any CI resources or spam the project. See docs for prhourlylimit for details.


    ❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.


    This PR has been generated by Mend Renovate. View repository job log here.

    opened by renovate-bot 0
  • Generating provenance file,  path not found error

    Generating provenance file, path not found error

    More guidance on how to integrate the action is required. We have an action to build a docker container:

    name: Docker Image CI
    on:
      push:
        branches: [ main ]
      pull_request:
        branches: [ main ]
    jobs:
      build:
        runs-on: ubuntu-latest
        steps:
        - uses: actions/[email protected]
        - name: Build the Docker image
          run: docker build . --file a10rest/Dockerfile.local --tag a10rest:$(date +%s)
        - uses: slsa-framework/[email protected]
          with:
            artifact_path: /a10rest
            output_path: a10rest.provenance
          continue-on-error: true
    

    The integration of the sla-framework action above is an educated guess from the instructions, but it runs. The artifact path however is a mystery: we've tried paths, relative paths and the name of the generated container (tag), but are unsure exactly how to refer to the artifact.

    The above action run with the slsa action producing the error in this case `Resource path not found: [provided=/a10rest]``

    opened by iolivergithub 4
  • Document for which SLSA Levels this approach can (and can not) be used

    Document for which SLSA Levels this approach can (and can not) be used

    The README mentions this action is applicable for SLSA level 1. This might be a good place to document what would be necessary for further SLSA levels.

    Looking at the Requirements it looks like this approach could also be used for L2, and that the main things missing would be:

    For L3, it might be the approach no longer suffices, because of the non-falsifiability requirement that specifies the user-defined build steps have no access to the provenance signing key. Of course in GitHub Actions you can make a secret available to only specific steps, but I'm not sure that is sufficient isolation?

    opened by raboof 1
  • Add feature to specify extra materials

    Add feature to specify extra materials

    This can e.g. be used when the build entrypoint generates files with extra materials, like installed operating system packages or downloaded zip-files.

    I can type up some more documentation if you like this feature.

    opened by pieterlexis 0
  • GitHub- vs Self-Hosted detection is inaccurate.

    GitHub- vs Self-Hosted detection is inaccurate.

    The detection of GitHub-hosted runner vs Self-hosted runner is inaccurate. What we want to know is "did all jobs use GitHub-hosted runners?" Instead, the current code says "does the current job (creating the provenance) use a GitHub-hosted runner." Is it possible to actually check what we need?

    An ugly idea is to parse the yaml to check all the runs-on fields, but that both (a) requires fetching and parsing the yaml, which is terrible, and (b) properly identifying which are github-hosted and which are self-hosted.

    Any better ideas?

    opened by MarkLodato 1
Releases(v0.1)
Owner
SLSA Framework
Supply-chain Levels for Software Artifacts
SLSA Framework
A code generator that turns plain old Go services into RPC-enabled (micro)services with robust HTTP APIs.

Frodo is a code generator and runtime library that helps you write RPC-enabled (micro) services and APIs.

Monadic 19 Jul 22, 2022
gRPC to JSON proxy generator following the gRPC HTTP spec

The gRPC-Gateway is a plugin of the Google protocol buffers compiler protoc. It reads protobuf service definitions and generates a reverse-proxy server which translates a RESTful HTTP API into gRPC. This server is generated according to the google.api.http annotations in your service definitions.

gRPC Ecosystem 13.8k Aug 8, 2022
Social previews generator as a microservice.

ogimgd Social previews generator as a microservice. Can be used to generate images for og:image meta-tag. It runs as an HTTP server with a single endp

Dmitry Nikitenko 10 Apr 9, 2022
OpenAPI Client and Server Code Generator

This package contains a set of utilities for generating Go boilerplate code for services based on OpenAPI 3.0 API definitions

Discord Gophers 45 Jul 28, 2022
This example showcases an event-sourced CQRS system based on github.com/romshark/eventlog

Eventlog Example This example is showcasing an eventually consistent, fault-tolerant, event sourced system following the CQRS (Command-Query-Responsib

Roman Sharkov 3 Mar 13, 2022
Go-github-actions - `go-github-actions` is a package for developing GitHub Actions

go-github-actions go-github-actions is a package for developing GitHub Actions.

Ken’ichiro Oyama 1 Feb 6, 2022
github-actions-merger is github actions that merges pull request with commit message including pull request labels.

github-actions-merger github-actions-merger is github actions that merges pull request with commit message including pull request labels. Usage Write

ABEMA 6 Jun 14, 2022
Temporal Activity Protobuf Generator Proof of Concept

Temporal Activity Protobuf Generator Proof of Concept This is a protoc plugin for generating easy to use code for calling and implementing activities.

Chad Retz 6 Jul 8, 2022
Toy gRPC Tunnel over CloudFlare (Proof of Concept)

gun You know what it means. Guide Server Go to your domain in CloudFlare. In "Network" tab, turn on gRPC.

Qv2ray Workgroup 142 Aug 2, 2022
This is a proof of concept (PoC) for creating a QR code system for proving that one has had a valid vaccination record

TestVac QR Core This is a proof of concept (PoC) for creating a QR code system for proving that one has had a valid vaccination record (FHIR, see http

Ministerie van Volksgezondheid, Welzijn en Sport 38 Feb 2, 2022
squirrelbyte is a "proof of concept" document / search server backed by sqlite.

??️ squirrelbyte is a "proof of concept" document / search server backed by sqlite.

null 135 May 20, 2022
Proof of concept project with MQTT and PLC4X imported as Go modules

portal-connect PoC for a edge MQTT client written in Go Basic project setup with PLC4X and Eclipse Paho How to run Install latest Go version https://g

pragmatic industries GmbH 8 Jan 19, 2022
ZipExec is a Proof-of-Concept (POC) tool to wrap binary-based tools into a password-protected zip file.

ZipExec ZipExec is a Proof-of-Concept (POC) tool to wrap binary-based tools into a password-protected zip file. This zip file is then base64 encoded i

Tylous 914 Aug 1, 2022
Small proof of concept project to try temporal.io with Dispatch Incident Management from Netflix.

temporal-dispatch-poc Small POC project to try out the Temporal workflow engine together with Netflix's Dispatch Incident Management System. Supported

Jørgen 1 Nov 12, 2021
Proof-of-Concept tool for CVE-2021-29156, an LDAP injection vulnerability in ForgeRock OpenAM v13.0.0.

CVE-2021-29156 Proof-of-Concept (c) 2021 GuidePoint Security Charlton Trezevant [email protected] Background Today GuidePoint

GuidePoint Security, LLC 2 Apr 13, 2022
Proof on concept with metamask

Local Run go run ./app.go # generate swagger go get github.com/swaggo/swag/cmd/swag Swag init -g app.go Local Docker Compose Run # rebuild docker ima

James Yang 4 Jun 24, 2022
Goket (Golang Keyboard Event Tree) is a proof-of-concept code for using keyboard events trees for performing operations.

Goket Goket (Golang Keyboard Event Tree) is a proof-of-concept code for using keyboard events trees for performing operations. Its main goal is to all

Wojciech Kocjan 0 Jan 3, 2022
A proof-of-concept Bitcoin client that treats Bitcoin with the contempt it deserves

Democracy A proof-of-concept Bitcoin client that treats Bitcoin with the contempt it deserves. Bitcoin offers no inbuilt democracy. One can either vot

Josh Deprez 2 Jul 19, 2022
Proof of concept microservices webportal and GRPC clients w/ multiDB support

Proof of concept microservices Webportal using Hero templates and websockets GRP

null 1 Dec 17, 2021
proof-of-concept minimal GraphQL service for LTV

LTV GraphQL Proof-of-Concept This is a barebones proof-of-concept of a possible GraphQL implementation that interacts with Core. It includes a few ver

Nick Kelley 1 Jan 4, 2022
Local-audio - Web walking audio tour platform proof-of-concept

Goal: Proof of concept for a Web Audio walk platform Data retention dynamdo db "time to live" expires in 1 day from creation of record set in add.go s

Kai Hendry 3 Jan 9, 2022
Go poc - Golang proof of concept

quickstart tar -zxvf go1.17.6.linux-amd64.tar.gz -C ~/tools/ echo "export PATH=

ileson 0 Jan 8, 2022
Freebase - Proof of concept microservice for A2S INFO message caching

Freebase A sensible albeit primitive A2S_INFO cache service written in Go. Proof

Gerard Russell 1 Feb 23, 2022
A proof-of-concept project that makes accessible buildkitd daemon from macOS

buildkit-machine buildkit-machine allows you to make buildkitd daemon accessible in your macOS environment. To do so, it uses lima, which is a Linux s

Batuhan Apaydın 51 Jul 11, 2022
Ssh-lxd - A proof of concept for an ssh server that spawns a bash session inside a LXD container

SSH LXD A proof of concept for an ssh server that spawns a bash session inside a

Henning Dahlheim 2 Jan 14, 2022
Eventproc - A proof-of-concept for exploring event based architecture utilizing bi-directional gRPC streams

eventproc A proof-of-concept for exploring event based architecture utilizing bi

null 0 Jan 25, 2022
Proof of concept/experimental detection of Discord Nitro phishing links via image analyzation

discord-scam-detection Experimental detection, and proof-of-concept, of Discord Nitro phishing/scam links via analyzing images. This repository is not

Levi 7 Jun 28, 2022
Proof-of-concept Windows-like clipboard manager for Linux in Go

Goclip Simple Windows-like clipboard manager for linux. This application is just a proof-of-concept and might be highly unstable. Features Clipboard t

null 2 Jan 28, 2022
Experimental detection, and proof-of-concept, of Discord Nitro phishing/scam links via analyzing images.

Experimental detection, and proof-of-concept, of Discord Nitro phishing/scam links via analyzing images.

Levi 7 Jun 28, 2022