Feat/data enhancement spike #417
Conversation
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
| @@ -0,0 +1,8 @@ | |||
| # pretend the following PRs were merged | |||
| include-prs: | |||
| - https://github.com/github/advisory-database/pull/2630 | |||
There was a problem hiding this comment.
From Josh: This probably isn't needed; if we need to update GitHub's data, it's probably because they refused an update, not because they're being slow. And this really solves the "being slow" problem rather than the "we have a change they don't want" problem.
|
|
||
| # assuming the following GHSAs were reviewed, even if they | ||
| # are not returned by the API | ||
| assume-reviewed: |
There was a problem hiding this comment.
From Josh: This mechanism probably isn't needed. If we're going to include an unreviewed GHSA, we're going to have to change it anyway. So just have a mechanism for changing fetched GHSA data, and assume any changed GHSA should be included in our output, regardless of whether GHSA has reviewed it.
| @@ -0,0 +1,73 @@ | |||
| { | |||
There was a problem hiding this comment.
This could also be in GHSA's graphQL or rest API format.
There was a problem hiding this comment.
From Josh: But whatever we do, we should only record changes, not all the data. Otherwise it's too hard to read what we changed.
|
From Josh: For fixing the severity of CVE-2023-44487 in debian namespaces, we could solve the immediate problem by updating it to "high". |
draft for getting feedback