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

Add capability to detect EOL packages and distros #2083

Open
tomersein opened this issue Aug 26, 2024 · 9 comments
Open

Add capability to detect EOL packages and distros #2083

tomersein opened this issue Aug 26, 2024 · 9 comments
Labels
blocked Progress is being stopped by something enhancement New feature or request needs-investigation

Comments

@tomersein
Copy link
Contributor

What would you like to be added:
I think grype can also cover EOL packages.
information is handled here - https://endoflife.date/
this website has an API which we can get the information, both to packages and OS distributions.
Why is this needed:
Grype covers CVEs, I think another scope which can be covered is EOL. Today xeol which is an open source based on grype is not maintained.
Additional context:

@tomersein tomersein added the enhancement New feature or request label Aug 26, 2024
@wagoodman
Copy link
Contributor

I think there is a path forward here to support this dataset, and it makes sense from the vulnerability perspective in terms of if something is EOL'd then we can't identify vulnerabilities for it, so that's worth noting to the user. The nice thing about the EOL dataset is that it appears to have the canonical product IDs and formats (CPE vs pURL) for each item they track. A good first cut would be to match against full distros, then a second pass would be to match against individual packages (such as the python interpreter or ruby interpreter).

I'll transfer this to grype since there is a lot more to work through over there and the change that adds the new EOL data source in vunnel would flow from that work.

@wagoodman wagoodman changed the title Sync EOL data from https://endoflife.date/ Add capability to detect EOL packages and distros Aug 26, 2024
@wagoodman wagoodman transferred this issue from anchore/vunnel Aug 26, 2024
@tomersein
Copy link
Contributor Author

Hi!
You have mentioned:
The nice thing about the EOL dataset is that it appears to have the canonical product IDs and formats (CPE vs pURL) for each item they track.
Can you show me an example? Since I didn't see it :)
Let me know if it will be discussed in the next OSS meeting

@TimBrown1611
Copy link

please checkout this endpoint - https://deploy-preview-2080--endoflife-date.netlify.app/docs/api/v1/
seems like endoflife is working on a new API which will support providing the identifiers of the packages \ distros.

@witchcraze
Copy link

As I wrote before, I use syft to detect EOL
My dataflow in the company checkes about 10000 images every day
endoflife-date/endoflife.date#3484 (reply in thread)

Cuurent rough flow is ...

  1. make json(s) by syft
  2. extract product by json (my scope is only major products)
  3. jusge EOL by several check
    a. Is OS package with OS EOL?
    b. Is OS package with specific EOL?
    c. Is non-OS package?
    d. paid suppoeted license?

To get much product, many detection approach, especially binary detection is very useful.

@TimBrown1611
Copy link

are you using it to distributions of images as well? @witchcraze

@witchcraze
Copy link

No
Our flow is combination of scripts and sql on BI tool in closed environment.

@willmurphyscode
Copy link
Contributor

This is an enhancement we'd love to see.

There are basically 2 steps to adding this: Add the data to the database Grype downloads, and change Grype to interpret the new data and present it to the user (the user presentation probably wants some more discussion.)

The way to do the first step is to design and add a Vunnel provider that captures the data that Grype would need. (One concern I have here is that the API doesn't seem to have PURLs in it, see https://endoflife.date/docs/api). Some design work is needed to figure out how to fetch complete enough data to match packages and distros. The release data repo also doesn't seem to have PURLs. The design challenge here is to make sure we can identify packages with their entries in the data.

It looks like there's an issue, endoflife-date/endoflife.date#3484, to include PURLs in their data. It might be possible to design around lack of PURLs, but if they had package identifiers of some kind in their release data or API it would certainly be easier to add this feature to Grype. It looks like the PURLs are in the raw markdown files, see https://raw.githubusercontent.com/endoflife-date/endoflife.date/master/products/angularjs.md for example, but it's not clear whether this data is stable or intended for consumption.

If anyone would like to help build this, please reply here or join us at a community meeting. If anyone is reading this from the endoflife.date project, we'd love to know how you intend us to programmatically access PURLs or other package identifiers.

Thanks all!

@TimBrown1611
Copy link

hi @willmurphyscode,
Please look in this issue - endoflife-date/endoflife.date#2530
and in this API - https://deploy-preview-2080--endoflife-date.netlify.app/api/v1/products/full.
here it seems the API calls returns the identifiers, and even the entire data in one call.

@willmurphyscode
Copy link
Contributor

Hi @TimBrown1611 thanks for those links. If endoflife-date/endoflife.date#2080 is merged and does include identifiers for packages, we might be able to build something here.

@willmurphyscode willmurphyscode added the blocked Progress is being stopped by something label Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Progress is being stopped by something enhancement New feature or request needs-investigation
Projects
Status: Backlog
Development

No branches or pull requests

6 participants