GHSA advisories never use the OSV `FIX` reference type, though ~54% link a fix commit
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 38/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 领域
- security
调研方向
首先，针对已发布的按生态系统划分的 OSV 存档复现该测量，并检查示例 GHSA-35jh-r3h4-6jhm 的引用。阅读 repository 的 advisory curation workflow，以确定引用类型的分配方式；当维护者已决定修复提交是否以及如何获得 FIX labels，并且已定义 workflow 或数据变更时，即表示完成。
由索引模型根据 Issue 内容生成。
描述
Summary
Across every GHSA advisory published to the OSV feeds, the FIX reference type
is used zero times. Meanwhile about 54% of those advisories do link their fixing
commit, filed under WEB alongside vendor bulletins and NVD mirrors.
Consumers that want the fix commit therefore have to recognise it by URL shape
rather than by reading the reference type.
Measurement
Taken from the published OSV per-ecosystem archives at
https://storage.googleapis.com/osv-vulnerabilities/<ecosystem>/all.zip,
excluding withdrawn advisories. GHSA records only.
| Ecosystem feed | GHSA records | FIX refs |
Links a commit under another type |
|---|---|---|---|
| npm | 7,020 | 0 | 3,634 (52%) |
| Maven | 6,956 | 0 | 3,268 (47%) |
| Packagist | 6,347 | 0 | 3,464 (55%) |
| PyPI | 6,016 | 0 | 3,776 (63%) |
| Go | 4,607 | 0 | 2,646 (57%) |
| crates.io | 1,475 | 0 | 650 (44%) |
| RubyGems | 1,082 | 0 | 639 (59%) |
| NuGet | 1,075 | 0 | 511 (48%) |
| Total | 34,578 | 0 | 18,588 (53.8%) |
The field is in use elsewhere
This is not a dead part of the schema. Other databases in the same feeds
populate it:
| Source | Records | Using FIX |
|---|---|---|
GO-* (Go vulndb) |
4,362 | 2,300 (52.7%) |
PYSEC-* (PyPA) |
7,214 | 2,146 (29.7%) |
GHSA-* |
34,578 | 0 (0.0%) |
Example
GHSA-35jh-r3h4-6jhm (lodash, CVE-2021-23337) has 17 references. The fix commit
is present, typed WEB:
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2021-23337
WEB https://github.com/lodash/lodash/commit/3469357cff396a26c363f8c1b5a91dde28ba4b1c
WEB https://www.oracle.com/security-alerts/cpuoct2021.html
WEB https://snyk.io/vuln/SNYK-JS-LODASH-1040724
PACKAGE https://github.com/lodash/lodash
...
Why it matters
A consumer wanting the fix commit currently has to pattern-match commit URLs
across GitHub, GitLab and Bitbucket against every reference. That heuristic will
miss self-hosted forges and will occasionally match a link that is not the fix.
This came up while building tooling that uses fix-commit diffs to corroborate
advisory metadata. It is relevant to anything doing patch analysis, reachability
work, or backport detection.
The intent also seems to already be there. In an OpenJS discussion on affected
function naming, a maintainer noted:
For what it's worth we do tend to also provide fix commits when we can find
them which would allow someone to derive the file based location data.
That derivation would be considerably more reliable if the references were
labelled.
Question
Is there a reason FIX is not used, or is it simply not something the curation
workflow currently sets? I have no visibility into how references get typed, so
I may be missing context that makes this a non-issue.
Offer to help
If this is worth addressing and there is a useful way for me to contribute, I am
happy to. I recognise that a change spanning this many advisories is not
something to approach through the one-advisory-per-PR path, and that you likely
have better tooling for it than anything I would write.
So rather than guessing at an approach, I would rather ask: if you want this
fixed, what would actually help? I can share the measurement script, produce a
list of candidate advisories and the reference in each that looks like a fix
commit, or do something else entirely. Guidance welcome.
Reproducing the numbers
curl -O https://storage.googleapis.com/osv-vulnerabilities/npm/all.zip
mkdir feed && unzip -q all.zip -d feed
# count GHSA records, excluding withdrawn, whose references include type FIX
The same holds for every ecosystem archive. Happy to share the full script.
- 主要语言
- 没有语言数据
- 星标
- 2.5k
- 派生
- 789
- 平均合并
- 5 天 11 小时
- 30 天内合并 PR
- 70
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
github/advisory-database 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
github/advisory-database#9879 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
github/advisory-database#9255 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
github/advisory-database#9164 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
github/advisory-database#8994 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
github/advisory-database#8898 · 4 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
查看 github/advisory-database 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 72/100
-
Signup crashes with "policy.toJS is not a function" when password policy is unavailable (15.0.1)未关闭
难度 2/5 1-3 小时 新手友好度 90/100
维护者通常 5 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
monad-developers/ultrafuzz#1248 ·
维护者通常 1 天内回复