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?

It was brought up that this repository can be confusing for new users wanting to get started with SLSA on GitHub actions. The feedback we got was that it was better to have a single repository for GitHub Actions and that it would be better to direct users to slsa-github-generator as it is better maintained.

After this PR is merged we can archive this repository.

/cc @diogoteles08

Signed-off-by: Ian Lewis [email protected]

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?

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.

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.

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

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

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

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:

🚸 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.

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/checkout@v3
    - 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]``

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:

• signing the provenance document (assuming 'the service generating the provenance' is allowed to be the builder?)
• perhaps identifying the source repo and tag/commit more specifically

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?

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.

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?