New Check: Add Sigstore, other tools use check for signed tags, releases

[inferno-chromium]

Describe the bug
Currently signed tags and releases check don't detect use of signing tools like Sigstore.

Reproduction steps
Signed releases using sigstore are not detected.

Expected behavior
Signed releases using sigstore should be detected.

Additional context
Add any other context about the problem here.

[inferno-chromium]

Check code here -
https://github.com/ossf/scorecard/blob/main/checks/signed_releases.go
https://github.com/ossf/scorecard/blob/main/checks/signed_tags.go

Docs needs updating here -
https://github.com/ossf/scorecard/blob/main/checks/checks.yaml
and regeneration of json, etc.

[naveensrinivasan]

@dlorenc How can I identify if a packaged/container is signed by cosign?

[dlorenc]

See the spec here: https://github.com/sigstore/cosign/blob/main/SPEC.md

You'd have to check the registry itself. Since you don't really care about verifying for this check, it should be pretty simple.

[inferno-chromium]

@asraa - do you have cycles to give this a try, see comment from @dlorenc - #298 (comment) At this point, we just care on seeing if sigstore is used (verifying can come later).

[asraa]

Looking into this, my main problem is figuring out where the github project is uploading their containers/packages.
Searching for stuff like "gcr.io" or "docker.io" in the github repository might work, but there' would be lots of false positives if we did that and expected that to be the projects distribution.

[asraa]

I'm happy to keep this assigned, but given that there's no canonical place to look for artifact signing, I think we should hold off for about a quarter until there is one. Cosign itself doesn't have a good location to check for images.

[developer-guy]

hello @naveensrinivasan @inferno-chromium, this is not a perfect solution but we are working on a project called container-image-exporter which is basically a Prometheus exporter and aims to provide metrics about the images running on the Kubernetes cluster. Within this project, we are accepting public keys from the users via flag to check whether the image is signed or not. Maybe we can apply this similar approach here because we have to get this public key to verify the signature and make sure that this image is signed or not via cosign but I do not know about the keyless mode, maybe we can accept transparency log entry id from user too.

[naveensrinivasan]

Within this project, we are accepting public keys from the users via flag to check whether the image is signed or not.

For scorecard to check if a given GitHub release has been signed using cosign, how can getting public key help? Can you explain further?

Also, scorecard runs in a cron mode where it checks against s 200,000 repositories gets results. There isn't an interactive mode.

[naveensrinivasan]

I think it is possible to do it.

- Create SHA256 of your BLOB file (GitHub release item like binaries , tars)
- Get UUIDs: rekor search --rekor_server https://rekor.sigstore.dev --sha sha256:SHA256
- Get entry for UUID: rekor get --rekor_server https://rekor.sigstore.dev --uuid UUID
- Store Body.signature.content in a blob.sig file
- Decode Body.signature.publicKey.content from BASE64 and store in a blob.cert file.
- Finally run: cosign verify-blob -signature blob.sig -cert blob.cert BLOB

@asraa Thoughts on this?

[naveensrinivasan]

On a related note #1200

[naveensrinivasan]

I think it is possible to do it.

- Create SHA256 of your BLOB file (GitHub release item like binaries , tars)
- Get UUIDs: rekor search --rekor_server https://rekor.sigstore.dev --sha sha256:SHA256
- Get entry for UUID: rekor get --rekor_server https://rekor.sigstore.dev --uuid UUID
- Store Body.signature.content in a blob.sig file
- Decode Body.signature.publicKey.content from BASE64 and store in a blob.cert file.
- Finally run: cosign verify-blob -signature blob.sig -cert blob.cert BLOB

@asraa Thoughts on this?

@dlorenc Confirmed it is possible on slack https://sigstore.slack.com/archives/C01DGF0G8U9/p1635628124084900

@asraa I have cycles to take this and would like to implement this. Please let me know. Thanks

[azeemshaikh38]

Sounds good to me. We already look for the presence of .sig files in release artifacts, if we don't find anything there, we can look into Rekor for it. This will be a good first step for Scorecard to start integrating with Rekor. Thanks for looking into this @naveensrinivasan!

[afmarcum]

This feature does not align with the short term project focus and has not had movement in some time.

If there is no feedback in the next 7 days to the contrary, then this issue will be closed.

[inferno-chromium]

This issue is pretty critical as Sigstore is now the OSS's leading code signing solution. @spencerschrock @raghavkaul - this one should be easy to knock out, probably should check the sigstore transparency log for signature.

[spencerschrock]

I believe signed releases was implemented as part of #2144, but we don't check the tlog.

[raghavkaul]

I imagine we'd use something similar to what rekor-cli verify does, I'm just not clear on what kind of --artifact or --entry it's looking for. Our usage of slsa-github-generator emits intoto.jsonl. For this intoto.jsonl, checking the transaction log might be tricky, since the builder emits the UUID in logs, but not in the output file. Not sure if it's any different for .build.slsa.

What about other generators/file formats that scorecard should be looking for? Are there generators other than slsa-github-generator? Or is that the only canonical builder that Scorecard should evaluate?

[afmarcum]

This request needs more discussion to be fully scoped out and potentially broken into smaller issues.