Return back snyk scanning - #4253
Conversation
Jan-Kazlouski-elastic
left a comment
There was a problem hiding this comment.
Left a few comments.
Also I might be confused, but perhaps we could do something similar to trivy image run? snyk container monitor seemingly does the same check for the whole image, if I understand correctly. Keep in mind I may be missing something
|
@Jan-Kazlouski-elastic the situation is that Snyk is our main source of issues in Github - there's automation that's tracking those CVEs, creating issues and such. Trivy doesn't do it. Also Snyk is responsible for RM release blocks when our SLOs are violated, not Trivy. My current understanding is |
Jan-Kazlouski-elastic
left a comment
There was a problem hiding this comment.
LGTM!
My previous review-wide comment is more of a general direction, rather than comment that would keep us from merging. Good job!
💔 Failed to create backport PR(s)The backport operation could not be completed due to the following error: The backport PRs will be merged automatically after passing CI. To backport manually run: |
💔 Failed to create backport PR(s)
Successful backport PRs will be merged automatically after passing CI. To backport manually run: |
|
Removed 8.19 as a target because project structure was different back then and requirements.txt were present |
# Backport This will backport the following commits from `main` to `9.3`: - [Return back snyk scanning (#4253)](#4253) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)
Manual backport of #4253 Since we don't do any scanning of deps on `main` we only needed a mainfest in our docker image. This change in essence just makes it so that docker images emit `requirements.txt` during build that are just a snapshot of all current dependencies. Then Snyk will be able to see it (it's pretty silly and requires `requirements.txt` or `requirements-*.txt` or `requirements_*.txt` to be present to scan). Fun side problem: our dependencies differ per architecture. The approach in this PR works in a way that _current_ docker image dependencies are frozen, so `requirements.txt` will be different per CPU architecture, but it's okay.
Closes https://github.com/elastic/search-team/issues/15280
This PR returns Snyk scanning back to the table. How it's supposed to work:
make freezeaction freezes the content of virtual environment for the package into arequirements.txtthat can be scanned. We clean up entities that are not supported by general pip snyk scanner, such as git references or relative file referencesmain../snyk monitorshould actually report scan issues in the Snyk UIWe need to merge this PR and see what Snyk actually reports as some stuff is hard to confirm (namely Docker image scanning)