Skip to content

Return back snyk scanning - #4253

Merged
artem-shelkovnikov merged 30 commits into
mainfrom
artem/just-test
Jul 22, 2026
Merged

Return back snyk scanning#4253
artem-shelkovnikov merged 30 commits into
mainfrom
artem/just-test

Conversation

@artem-shelkovnikov

@artem-shelkovnikov artem-shelkovnikov commented Jul 21, 2026

Copy link
Copy Markdown
Member

Closes https://github.com/elastic/search-team/issues/15280

This PR returns Snyk scanning back to the table. How it's supposed to work:

  1. New make freeze action freezes the content of virtual environment for the package into a requirements.txt that can be scanned. We clean up entities that are not supported by general pip snyk scanner, such as git references or relative file references
  2. We enable snyk scanning on nightlies on main. ./snyk monitor should actually report scan issues in the Snyk UI
  3. We package a requirements.json file into docker images

We need to merge this PR and see what Snyk actually reports as some stuff is hard to confirm (namely Docker image scanning)

@artem-shelkovnikov artem-shelkovnikov changed the title Testing out snyk Return back snyk scanning Jul 22, 2026

@erikcurrin-elastic erikcurrin-elastic left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome.

Comment thread app/connectors_service/Makefile Outdated
Comment thread .buildkite/nightly_steps.yml Outdated
Comment thread libs/connectors_sdk/Makefile

@Jan-Kazlouski-elastic Jan-Kazlouski-elastic left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@artem-shelkovnikov

Copy link
Copy Markdown
Member Author

@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 trivy is used for docker images and is also a good source of CVEs. Snyk finds some, trivy finds some other.

@Jan-Kazlouski-elastic Jan-Kazlouski-elastic left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
My previous review-wide comment is more of a general direction, rather than comment that would keep us from merging. Good job!

@artem-shelkovnikov
artem-shelkovnikov merged commit a6978f5 into main Jul 22, 2026
4 checks passed
@artem-shelkovnikov
artem-shelkovnikov deleted the artem/just-test branch July 22, 2026 15:03
@github-actions

Copy link
Copy Markdown

💔 Failed to create backport PR(s)

The backport operation could not be completed due to the following error:
There are no branches to backport to. Aborting.

The backport PRs will be merged automatically after passing CI.

To backport manually run:
backport --pr 4253 --autoMerge --autoMergeMethod squash

@github-actions

Copy link
Copy Markdown

💔 Failed to create backport PR(s)

Status Branch Result
8.19 Commit could not be cherrypicked due to conflicts
9.3 Commit could not be cherrypicked due to conflicts
9.4 #4258
9.5 #4259

Successful backport PRs will be merged automatically after passing CI.

To backport manually run:
backport --pr 4253 --autoMerge --autoMergeMethod squash

@artem-shelkovnikov

Copy link
Copy Markdown
Member Author

Removed 8.19 as a target because project structure was different back then and requirements.txt were present

artem-shelkovnikov added a commit that referenced this pull request Jul 22, 2026
# 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)
artem-shelkovnikov added a commit that referenced this pull request Jul 22, 2026
Backports the following commits to 9.5:
 - Return back snyk scanning (#4253)

Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
artem-shelkovnikov added a commit that referenced this pull request Jul 22, 2026
Backports the following commits to 9.4:
 - Return back snyk scanning (#4253)

Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
artem-shelkovnikov added a commit that referenced this pull request Jul 22, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants