Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide vulnerability attestation based on cosign vuln spec #614

Open
developer-guy opened this issue Jan 31, 2022 · 7 comments
Open

Provide vulnerability attestation based on cosign vuln spec #614

developer-guy opened this issue Jan 31, 2022 · 7 comments
Labels
enhancement New feature or request good-first-issue Good for newcomers

Comments

@developer-guy
Copy link
Contributor

What would you like to be added:

Why is this needed:

In cosign, we (w/@Dentrax @dlorenc) worked on generating a spec for vulnerabilities1 and ended up having something like the following 👇
https://github.com/sigstore/cosign/blob/main/specs/COSIGN_VULN_ATTESTATION_SPEC.md

So, I thought that it'd be nice to adapt it to Grype, maybe we can enable this support with a flag --attestation <PATH>.

Additional context:

Footnotes

  1. https://github.com/sigstore/cosign/issues/442

@luhring
Copy link
Contributor

luhring commented Jan 31, 2022

Thanks @developer-guy! It'd be neat to produce vulnerability attestations in Grype. 🚀

Before we proceed, I'd like to better understand the spec and the thinking behind it. I've opened an issue in Cosign: sigstore/cosign#1381

@spiffcs spiffcs changed the title provide vulnerability attestation based on cosign vuln spec Provide vulnerability attestation based on cosign vuln spec Feb 24, 2022
@Dentrax
Copy link

Dentrax commented Mar 1, 2022

Kind ping here 🤞 We would like to help if any help is wanted.

@luhring
Copy link
Contributor

luhring commented Mar 6, 2022

Thanks @Dentrax — we're waiting for those questions around Cosign's attestation spec to be cleared up before we implement something here in Grype.

@spiffcs spiffcs added this to OSS Jun 1, 2022
@spiffcs
Copy link
Contributor

spiffcs commented Sep 1, 2022

Added the blocked label until questions from 1381 are resolved.

@spiffcs spiffcs moved this to Parking Lot (Comments or Progress) in OSS Sep 1, 2022
@tgerla tgerla removed the status in OSS Aug 3, 2023
@spiffcs spiffcs added needs-discussion and removed blocked Progress is being stopped by something labels Jul 29, 2024
@spiffcs
Copy link
Contributor

spiffcs commented Jul 29, 2024

This is now unblocked and there is a specification to follow
https://github.com/in-toto/attestation/blob/main/spec/predicates/vuln.md

I've added a label for this so we can discuss it on our livestream for the next Thursday meeting:
https://youtube.com/live/T9OkSGu23j4?feature=share

@popey
Copy link
Contributor

popey commented Aug 1, 2024

Hey! We discussed this during the latest live stream (from around 20-40 mins).

There was some feeling of resistance to adding cosign as a library in grype, given past experience doing the same in syft. We feel it's probably going to be too costly to integrate cosign into our project in terms of significantly increasing build time and binary size.

The preference would be for there to be better documentation of how calling cosign is done effectively after grype has run. A well-maintained recipe might be all that's needed from our perspective. Where that recipe lives is up for debate.

We also discussed the possibility of integrating cosign as a step in our GitHub actions to automate the attestation of the results of the scan-action / grype run.

@Dentrax
Copy link

Dentrax commented Aug 2, 2024

Thanks for the update. There was a tracking issue related to dependency tree: sigstore/cosign#1462

Also this project might helpful to provide basic operations without having lots of deps: https://github.com/sigstore/sigstore-go

@wagoodman wagoodman moved this to Ready in OSS Aug 7, 2024
@wagoodman wagoodman added the good-first-issue Good for newcomers label Aug 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good-first-issue Good for newcomers
Projects
Status: Ready
Development

No branches or pull requests

6 participants