Comments (15)
The only thing to confirm is which should be the prefix, Ubuntu-, UBUNTU-, UBTU-?
Thanks for confirming! We prefer UBUNTU-
to align with our current naming schema. Same as https://osv.dev/vulnerability/CURL-CVE-2024-7264
from osv.dev.
As someone that does not have a view of the whole osv.dev machinery, I think the main question is, why would you want to combine CVE entries?
from osv.dev.
why would you want to combine CVE entries?
The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.
from osv.dev.
why would you want to combine CVE entries?
The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.
From your first message, the thing that is not clear to me is, if you are not going to combine CVEs anymore, then why would you need to still add the prefixes (e.g. Debian-CVE-2024-0001
) ? Aren't those completely separate buckets?
from osv.dev.
why would you want to combine CVE entries?
The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.From your first message, the thing that is not clear to me is, if you are not going to combine CVEs anymore, then why would you need to still add the prefixes (e.g.
Debian-CVE-2024-0001
) ? Aren't those completely separate buckets?
For OSV, ID prefixes must be unique, and be associated with a home database. Debian security tracker, Alpine etc didn't have a unique ID before, so we were combining them into a single CVE record. If we don't combine them, then they would need their own prefix.
from osv.dev.
why would you want to combine CVE entries?
The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.From your first message, the thing that is not clear to me is, if you are not going to combine CVEs anymore, then why would you need to still add the prefixes (e.g.
Debian-CVE-2024-0001
) ? Aren't those completely separate buckets?For OSV, ID prefixes must be unique, and be associated with a home database. Debian security tracker, Alpine etc didn't have a unique ID before, so we were combining them into a single CVE record. If we don't combine them, then they would need their own prefix.
Thanks for clarifying it, and would the prefix also be necessary for the filename itself? or could we have a filename CVE-2024-0001.json and inside of it id = "UBTU-CVE-2024-0001
?
from osv.dev.
Thanks for clarifying it, and would the prefix also be necessary for the filename itself? or could we have a filename CVE-2024-0001.json and inside of it
id = "UBTU-CVE-2024-0001
?
We do prefer the filename to match the ID name to keep it consistent for other ecosystems. Are there any concerns for Ubuntu in changing the filename?
from osv.dev.
Thanks for clarifying it, and would the prefix also be necessary for the filename itself? or could we have a filename CVE-2024-0001.json and inside of it
id = "UBTU-CVE-2024-0001
?We do prefer the filename to match the ID name to keep it consistent for other ecosystems. Are there any concerns for Ubuntu in changing the filename?
No concerns, just confirming what needs to be done as it will be a mass operation.
The only thing to confirm is which should be the prefix, Ubuntu-
, UBUNTU-
, UBTU-
?
from osv.dev.
Hey @dodys, I have two questions about Ubuntu CVE OSV records (ubuntu-security-notices/osv).
First, I'm curious why some affected packages lack the ubuntu_priority
field. This field is from the vulnerability level and should be consistent across all affected packages. But I've noticed that some packages are missing this field while others within the same vulnerability have it. Example: https://osv.dev/vulnerability/CVE-2024-21131
Second question is about the status
field. I can't find it in the Ubuntu OSV records, not sure if it's an important one. But I'm wondering if there's a filtering mechanism that determines which records Ubuntu sends to OSV (like not sending all records with a status of DNE
or not-affected
?).
from osv.dev.
Hey @dodys, I have two questions about Ubuntu CVE OSV records (ubuntu-security-notices/osv). First, I'm curious why some affected packages lack the
ubuntu_priority
field. This field is from the vulnerability level and should be consistent across all affected packages. But I've noticed that some packages are missing this field while others within the same vulnerability have it. Example: https://osv.dev/vulnerability/CVE-2024-21131
Indeed, for now we only added the ecosystem_specific
part (including ubuntu_priority
) when the CVE was fixed. In the next batch of update to our scripts, we plan to add the ecosystem_specific
to all.
Second question is about the
status
field. I can't find it in the Ubuntu OSV records, not sure if it's an important one. But I'm wondering if there's a filtering mechanism that determines which records Ubuntu sends to OSV (like not sending all records with a status ofDNE
ornot-affected
?).
Since OSV has the affected
field, which is for only packages that are vulnerable to such "vulnerability" (CVE) or "set of vulnerabilities" (USN), for CVEs, we only list the ones that are affected or are still pending investigation. That means that the following status are always included:
needed
-> means vulnerable/affected
needs-triage
-> means that it needs investigation, therefore we consider it vulnerable until investigation is done
deferred
-> means that we tried to investigate but we still don't have enough information to do so, therefore it is vulnerable until confirmed
pending
-> means that the package is vulnerable and a fix is on its way
released
-> means that we patched it in such release
Some status are more complex and will depend on other factors:
not-affected (<version>)
-> if the <version>
exists in that specific Ubuntu release, we consider it similar to released
, if the <version>
is an old one, e.g. the first version to contain the fix and not vulnerable anymore, then we don't add it since that Ubuntu release is not vulnerable at all.
ignored
-> it will only be included for releases that are still "alive", as ignored can be used for different reasons.
And some status we just don't include:
DNE
-> package doesn't exist in such Ubuntu release
active
-> even though it is in the docs we still don't use that status.
Does that help clarify?
from osv.dev.
Does that help clarify?
Thanks Eduardo! It's very detailed and helpful!
Having all the ubuntu_priority
info should be sufficient for us, especially considering you've already helped us filter out DNE
and some not-affected
ones.
from osv.dev.
Related Issues (20)
- Support API queries for non-enumerated ecosystems
- Missing PURL converters HOT 1
- Git analysis: relax branch computation
- Crucial bug: osv-scanner does not detect known malicious package in lockfiles HOT 8
- Update Documentation Logos for Dark Theme Consistency
- Solution hashes for a vulnerability lies in an external fork HOT 3
- Missing `Packages` for some malicious packages HOT 1
- Export an `all.zip` containing every vulnerability.
- Invalidate `last_update_date` when source changes
- Sustainably ensure invalidly prefixed records are not imported HOT 3
- The importer does not honour ignore_patterns for REST sources HOT 1
- Automate submodule updates
- Strange behaviour in PyPI versions HOT 7
- Data quality issue with GHSA-4943-9vgg-gr5r HOT 2
- Affected methods by a vulnerability HOT 1
- DSA-5649-1 missing in OSV.dev HOT 6
- Query API for Ubuntu `linux` packages HOT 7
- Combine all `not yet assigned` Debian Security Tracker issues into OSV
- Missing CVSS_V4 Severity Type in osvSeverityType Enum in Swagger Definition
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osv.dev.