libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases Packages Activity Actions

Add documentation about how to handle CVEs on third-party libraries reported by Snyk

Browse source 
Closes #29707

Co-authored-by: Alexander Schwartz <alexander.schwartz@gmx.net>
Signed-off-by: Bruno Oliveira da Silva <bruno@abstractj.com>
This commit is contained in:
Bruno Oliveira da Silva 2024-05-20 13:21:52 -03:00
parent 82ae047231
commit 4a21b44b5f
1 changed files with 7 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/bug-triage.md
View file

@ -31,6 +31,12 @@ In cases where it is clear that no additional comment is needed you can just add
example if the description only states `It doesn't work` then there's not much point in explaining what information is example if the description only states `It doesn't work` then there's not much point in explaining what information is
missing. missing.
#### CVE reports on third-party libraries
Known CVEs on third-party libraries will be automatically created as GitHub issues, labeled with `kind/cve`, `kind/bug`, and `status/triage`. The triager identifies the responsible team for the dependency and assigned the appropriate `team/...` label. This process is similar to the bug triage process previously mentioned.
When evaluating the CVE report, assess the impact on the codebase by determining if we are vulnerable or affected. "Vulnerable" means that we use the code reported in the CVE, while "affected" means that we have the dependency with the CVE present but do not use the vulnerable code, making it impossible to exploit the CVE. If closing an issue as "not planned," include a proper explanation and the reason for closing it for future reference.
### Prioritize the issue ### Prioritize the issue
Second step is to prioritize the bug depending on how common the use-case is, if it's a regression, Second step is to prioritize the bug depending on how common the use-case is, if it's a regression,