profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/slsa-framework/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
SLSA Framework slsa-framework https://github.com/slsa-framework/slsa Supply-chain Levels for Software Artifacts

slsa-framework/slsa 377

Supply-chain Levels for Software Artifacts

slsa-framework/github-actions-demo 25

Proof-of-concept SLSA provenance generator for GitHub Actions

slsa-framework/azure-devops-demo 2

SLSA Azure DevOps Pipelines Extension

startedslsa-framework/slsa

started time in 2 days

startedslsa-framework/slsa

started time in 2 days

issue commentslsa-framework/github-actions-demo

GitHub- vs Self-Hosted detection is inaccurate.

Another idea: Download all workflow run logs. The first line indicates whether it's github- or self-hosted. That would require the provenance generator to have access to the logs, which is not ideal, and when doing it mid-run, I'm not sure if there are race conditions where that wouldn't work well.

MarkLodato

comment created time in 2 days

issue openedslsa-framework/github-actions-demo

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?

created time in 2 days

issue commentslsa-framework/azure-devops-demo

Fix recipe and materials

There is a similar issue with self-hosted runners, which applies to both Azure Pipelines and GitHub Actions. Each individual job within a workflow can use its own runner, so there is no workflow-wide property that says "all steps were run on hosted runners."

MarkLodato

comment created time in 2 days

issue commentslsa-framework/slsa

Easy way to view versioned SLSA

That would work! To me the big challenge is all the styling - HTML, CSS, Jekyll. Not my area of expertise. :-)

joshuagl

comment created time in 2 days

issue commentslsa-framework/azure-devops-demo

Fix recipe and materials

Hi @gattjoe, sorry for the long delay. I was on leave.

We have the same issue with Google Cloud Build (GCB), where we can't tell whether the build steps come from YAML or from the GUI. (@msuozzo @TomHennen FYI.) For now, I think it's OK to say that we can't detect it, then add it later if we figure out a way (say by the API). I'll take a look. Thanks for the research!

I'll do a little more research then send you a pull request for the fields!

MarkLodato

comment created time in 2 days

issue commentslsa-framework/slsa

Easy way to view versioned SLSA

For The Update Framework (TUF) I wrote a GitHub Action that publishes each tagged release of the specification to a versioned folder in the GitHub-pages branch of the repo (see it here). We could do something similar just for the SLSA spec (levels + requirements) and generate some HTML to switch between versioned paths when viewing those pages?

joshuagl

comment created time in 2 days

issue commentslsa-framework/slsa

Indicating SLSA versions for policy evaluation

I think tooling should indicate (or allow users to choose?) which version of the SLSA framework is being used. Maybe down the road the levels will be stable enough that it won't be an issue, but for now I think that there's still enough in flux that versioning is useful.

joshuagl

comment created time in 2 days

issue openedslsa-framework/slsa

Indicating SLSA versions for policy evaluation

For the purpose of automatic artefact verification and policies to evaluate SLSA attestations, do we need to care about the version of SLSA which is implemented?

It has been suggested that we should not significantly alter SLSA levels once a release has been made, so perhaps SLSA level 1 is always equivalent enough that a policy engine does not need to distinguish between SLSA v0.1 level 1 and SLSA 1.2 level 1 – if that's the case, we should capture that decision and enforce it during PR reviews.

created time in 2 days

issue commentslsa-framework/slsa

Easy way to view versioned SLSA

Definitely! Suggestions / pull requests on how to do this would be we welcome.

Also, we currently have two different versions: the version of the spec (levels + requirements) and the version of the provenance schema. So we probably won't version the entire website.

joshuagl

comment created time in 2 days

issue openedslsa-framework/slsa

Tracking changes

Now that SLSA has its first release, we should figure out how to to communicate the differences introduced in subsequent versions. This might be as simple as a CHANGELOG which is rendered as part of slsa.dev. Or we might go more complex.

Why? Imagine someone adopts SLSA v0.1 (2021-09-16). They don't actively follow SLSA development and later come to find that SLSA 1.1 is released. How do they identify what changes they must make to be conformant with the newer SLSA version?

created time in 2 days

issue openedslsa-framework/slsa

Easy way to view versioned SLSA

Now that we have our first release, how do we make it easy for folks to refer to that version of SLSA. I'm imagining something like how documentation published on Read The Docs both shows the current version of the documentation (latest, stable, or a version number) and has a toggle to select a different version of the docs. Screenshot 2021-09-17 at 14 52 25

created time in 2 days

issue openedslsa-framework/azure-devops-demo

Publish extension under slsa-framework project

Currently it's under @gattjoe's account. We need to publish it under the SLSA Framework project.

Instructions: https://docs.microsoft.com/en-us/azure/devops/extend/overview?view=azure-devops

created time in 2 days

issue closedslsa-framework/azure-devops-demo

Set up Azure Pipeline

Set up an Azure Pipeline to run this demo. This will allow us to test it and verify that it works.

  • [x] Created a slsa-framework organization in Azure DevOps.
  • [x] Create an azure-devops-demo project.
  • [X] Configure a pipeline to run the demo.
  • [x] Configure GitHub to automatically run the pipeline on commit.
  • [X] Add other members to the organization. (@TomHennen and @joshuagl for now - we're limited to 5)

closed time in 2 days

MarkLodato

issue commentslsa-framework/azure-devops-demo

Set up Azure Pipeline

It worked: https://dev.azure.com/slsa-framework/azure-devops-demo/_build/results?buildId=3&view=artifacts&pathAsName=false&type=publishedArtifacts

I'll continue to refine it.

MarkLodato

comment created time in 2 days

startedslsa-framework/slsa

started time in 2 days

startedslsa-framework/slsa

started time in 3 days

startedslsa-framework/slsa

started time in 3 days

startedslsa-framework/slsa

started time in 3 days

push eventslsa-framework/slsa

Ilan Rabinovitch

commit sha 5c37c63dd18c5f6de5ba66f89ef0b0bb1431d896

fix caps on Datadog fix caps on Datadog

view details

Ilan Rabinovitch

commit sha 193aefdb55d7b89468775dd81ae3cb3d5f2c216e

fix caps on datadog fix caps on datadog

view details

Abhishek Arya

commit sha cac4021a965649ab860384dcfa20cac9e97b930f

Update README.md Co-authored-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Abhishek Arya

commit sha 6494a3ba9f150a92c29f6aafcf3e4e3517be86ab

Update getinvolved.md

view details

Abhishek Arya

commit sha 226e4e120d9b0217d885ca35d58996515e9fac5c

Merge pull request #165 from irabinovitch/patch-1 fix caps on Datadog

view details

push time in 3 days

PR merged slsa-framework/slsa

fix caps on Datadog

fix caps on Datadog

+2 -2

1 comment

2 changed files

irabinovitch

pr closed time in 3 days

PullRequestReviewEvent

pull request commentslsa-framework/slsa

fix caps on Datadog

all set

irabinovitch

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentslsa-framework/slsa

fix caps on Datadog

 SLSA is currently led by an initial cross-organization, vendor-neutral steering -   [Joshua Lock](https://github.com/joshuagl) - VMware -   [Bruno Domingues](https://github.com/brunodom) - Intel -   [David A. Wheeler](https://github.com/david-a-wheeler) - Linux Foundation--   [Trishank Kuppusamy](https://github.com/trishankatdatadog) - DataDog+-   [Trishank Kuppusamy](https://github.com/trishankatdatadog) - Datadog
-   [Trishank Karthik Kuppusamy](https://github.com/trishankatdatadog) - Datadog
irabinovitch

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

PR opened slsa-framework/slsa

fix caps on Datadog

fix caps on Datadog

+1 -1

0 comment

1 changed file

pr created time in 3 days

fork irabinovitch/slsa

Supply-chain Levels for Software Artifacts

https://slsa.dev

fork in 3 days