Representing end-of-life (EOL) in OSV records

[dodys]

Hey folks,

This is to start a discussion around how to properly represent a ecosystem that is end-of-life (or even if we would want that at all) in OSV records.
Currently for Ubuntu we had two Ubuntu Releases (Ecosystems) that went to EOL and the way we did was:

• We stop loading information about that specific release, therefore the OSV records that had entries of it, will suddenly not have that entry anymore. The exception would be an OSV record that only affects the EOL ecosystem, in that case the OSV record wouldn't disappear but instead we would add the withdrawn field to it. This creates a bit of a "leftover" if anyone is looking for info for that release.

The other thing about end-of-life is usually when it happens, and for us that can be as soon as the next day that the release went EOL, meaning from one day to the other, scanners would completely not know anymore about such EOL release.

We've been getting more and more questions about having data in OSV for EOL releases, even though we wouldn't add new entries for it or anything else.

Therefore the question is really how should we treat EOL in OSV.

Talking to @another-rex, he mentioned that for debian (and alpine), it has been pretty similar that the entries go away when those ecosystems go EOL. Not sure if anyone has asked questions or saw issues with it.

@DmitriyLewen that might interest you as well and perhaps you have more comments from the users requests/POV.

[DmitriyLewen]

Hello everyone!
@dodys Thanks!

I'll add some context:
We in Trivy consider it important to show advisories even for EOL releases:

• Found vulnerabilities give users more motivation to update their OS.
• People don't remain in the dark, and some users will generally consider themselves "safe". I understand that new vulnerabilities won't be shown for an EOL release, but we should at least show known vulnerabilities.

Therefore, deleting entries leads to loss of information.

By the way @dodys , why do you need to delete records (why not keep records for outdated releases)?

[dodys]

By the way @dodys , why do you need to delete records (why not keep records for outdated releases)?

Not that we need to delete, it was just a design decision to try to stabilize the size of the repository. Also a natural thing to how we generate the records, since we generate them fully on every generation (we could change this easily), and if a release is EOL, then it is not loaded anymore during generation.

[jasnow]

FYI: Here are some EOL-related rubysec tickets:

• 2019: Include warnings for EOL ruby and gems  rubysec/ruby-advisory-db#416
• 2019: [RFC]: Support EOL rubysec/ruby-advisory-db#419
• 2019: Feature request: EoL version tracking rubysec/bundler-audit#227

[dodys]

Just to add to this discussion. There are today, at least to my knowledge, two proposals trying to standardize EOL for VEX/SBOMs:

1. https://owasp.org/www-project-common-lifecycle-enumeration/
2. https://openeox.org/

Maybe it would be interesting to support either or both?