Comments (5)
Additionally, thank you for your feedback, and if you have any data quality observations on the records (at https://storage.googleapis.com/osv-vulnerabilities/index.html?prefix=GIT/ in particular) please file issues to capture them.
from osv.dev.
Hi @yashrsharma44 , thanks for the issue!
The versions
entry follows the standard of the ecosystem specified in package
. This is the same for versions specified in ranges
.
For example, https://osv.dev/vulnerability/GHSA-9wmf-xf3h-r8pr is for the Maven
ecosystem, and the OSV JSON looks like:
"affected": [
{
"package": {
"name": "org.jberet:jberet-core",
"ecosystem": "Maven",
"purl": "pkg:maven/org.jberet/jberet-core"
},
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.1.Final"
}
]
}
],
"versions": [
"1.0.0.Alpha1",
"1.0.0.Alpha2",
"1.0.0.Alpha3",
"1.0.0.Alpha4",
"1.0.0.Beta1",
"1.0.0.Beta2",
"1.0.0.CR1",
"1.0.0.CR2",
"1.0.0.Final",
"1.0.1.Beta",
...
Where every version listed is a version in the Maven
registry, following Maven's version numbering rules.
Where this is a bit more complicated is when there is no well-defined packaging ecosystem specified, like for general C/C++ libraries (i.e. there are only GIT
version ranges). In this case, the values formats are technically undefined according to the spec, but in OSV.dev's case, this typically means this is the upstream git version tags derived from the given GIT
commit ranges. In these cases, the GIT commit ranges should be used to match git commit hashes to vulnerabilities.
Does this answer your question?
from osv.dev.
Hi @yashrsharma44 , thanks for the issue!
The
versions
entry follows the standard of the ecosystem specified inpackage
. This is the same for versions specified inranges
.For example, https://osv.dev/vulnerability/GHSA-9wmf-xf3h-r8pr is for the
Maven
ecosystem, and the OSV JSON looks like:"affected": [ { "package": { "name": "org.jberet:jberet-core", "ecosystem": "Maven", "purl": "pkg:maven/org.jberet/jberet-core" }, "ranges": [ { "type": "ECOSYSTEM", "events": [ { "introduced": "0" }, { "fixed": "2.2.1.Final" } ] } ], "versions": [ "1.0.0.Alpha1", "1.0.0.Alpha2", "1.0.0.Alpha3", "1.0.0.Alpha4", "1.0.0.Beta1", "1.0.0.Beta2", "1.0.0.CR1", "1.0.0.CR2", "1.0.0.Final", "1.0.1.Beta", ...
Where every version listed is a version in the
Maven
registry, following Maven's version numbering rules.Where this is a bit more complicated is when there is no well-defined packaging ecosystem specified, like for general C/C++ libraries (i.e. there are only
GIT
version ranges). In this case, the values formats are technically undefined according to the spec, but in OSV.dev's case, this typically means this is the upstream git version tags derived from the givenGIT
commit ranges. In these cases, the GIT commit ranges should be used to match git commit hashes to vulnerabilities.Does this answer your question?
Thanks for the response. I agree with the versions returned; would be nice if we have this documented somewhere, ideally in the OSV Schema itself. The git
tags are indeed useful, as the tags can be used for matching the version(or if it doesn't exist).
Thanks for maintaining this awesome archive 😄
from osv.dev.
Additionally, thank you for your feedback, and if you have any data quality observations on the records (at https://storage.googleapis.com/osv-vulnerabilities/index.html?prefix=GIT/ in particular) please file issues to capture them.
My pleasure. I will add more GH issues, as I find any discrepancies in the data.
from osv.dev.
Thanks for the response. I agree with the versions returned; would be nice if we have this documented somewhere, ideally in the OSV Schema itself. The
git
tags are indeed useful, as the tags can be used for matching the version(or if it doesn't exist).
@yashrsharma44 Please take a look at ossf/osv-schema#238 and provide any feedback on how well you feel it addresses this deficiency in the schema documentation.
from osv.dev.
Related Issues (20)
- Handle very long fields on vulnerabilities pages HOT 1
- nvd-cve-osv: OpenSSL versions do not normalize correctly
- Bisection should not produce zero-length commit ranges HOT 1
- Improve the UX of failed vulnerability retrieval by the API
- Can't get Content-Length info with HEAD request HOT 4
- Show ecosystem case in osv.dev
- Data quality issue with GHSA-9wx4-h78v-vm56 HOT 3
- Advisories from GuardDog HOT 2
- Calculate and display the CVSS base score
- Make it possible to visually evaluate a list of vulnerabilities by severity
- Update material web components to 1.0
- Replace pipenv with a better dependency management tool HOT 5
- API: query vulnerabilities HOT 1
- Error importing osv in Python 3.9 HOT 2
- Include Alpine and Debian security tracker links to vulnerability `references` on OSV.dev HOT 1
- Data quality issue with CVE-2024-32760 (Alpine security tracker related) HOT 1
- Display the correct affected versions when filtering by ecosystem
- Few CWE root causes are mapped from the CVE database into OSV HOT 2
- Support commit enumeration on pathologically large repositories
- Advisories deleted from REST sources not being marked as withdrawn
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.