OSV.dev downstream users have a clearly defined user journey to make corrections to OSV records served by OSV.dev with minimal overhead by all parties

[andrewpollock]

Problem statement

OSV.dev users often file issues in against OSV.dev about records that OSV.dev is merely redistributing, and is not the originator of (what I call the "Don't shoot the messenger problem") and this is discussed in https://google.github.io/osv.dev/faq/#ive-found-something-wrong-with-the-data

The user experience of an OSV.dev user should be such that they are nudged as much as possible to the authoritative source (i.e. the home database) of a record so that they can make a correction or provide feedback where it can be most efficiently handled.

It's neither a good user experience nor a good use of limited resources for OSV.dev team members to act as an intermediary.

Desired outcome

Make the UX around OSV.dev record correction as optimal as possible.

[andrewpollock]

The approach taken with #2821 currently falls down for the following existing OSV.dev sources, which lack a readily determinable human_link value:

• [ ] Android
• [ ] Bitnami
• [x] Chainguard
• [ ] Haskell
• [ ] Malicious Packages
• [ ] OSS Fuzz
• [ ] Python Software Foundation
• [ ] PyPI
• [ ] R

A large number of these are GitHub repositories, so I'm currently considering additional treatment of such cases to nudge the user towards making a pull request against the source data (but this assumes the user knows what needs to be fixed as opposed to just reporting feedback, and this may be an unreasonable assumption)

[andrewpollock]

Current status:

[hogo6002]

It would be great to direct users to the original source for any records that OSV doesn't maintain. This will help prevent unnecessary issues in the OSV.dev repository and make maintenance easier. Thanks to Andrew for the UX change!

[andrewpollock]

nudge the user towards making a pull request against the source data

• Malicious Packages
• OSS Fuzz
• PyPA
• R

all expressly invite pull requests, but deep linking to the specific record's file edit workflow in GitHub is complicated by the repo structures including additional things in the path, e.g.

• Malicious Packages
  • https://github.com/ossf/malicious-packages/edit/main/osv/malicious/crates-io/littest/MAL-2023-8429.json
• OSS Fuzz
  • https://github.com/google/oss-fuzz-vulns/edit/main/vulns/apache-commons-configuration/OSV-2022-871.yaml
• PyPA
  • https://github.com/pypa/advisory-database/edit/main/vulns/aim/PYSEC-2021-839.yaml
• R
  • https://github.com/RConsortium/r-advisory-database/edit/main/vulns/haven/RSEC-2023-5.yaml