search

argoproj / argo-workflows

Workflow Engine for Kubernetes
https://argo-workflows.readthedocs.io/
Apache License 2.0
15.13k stars 3.21k forks source link

Published Snyk report #7954

Open alexec opened 2 years ago

alexec commented 2 years ago

@crenshaw-dev

Message from the maintainers:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

alexec commented 2 years ago

As discussed in meeting.

crenshaw-dev commented 2 years ago

I think we could add a CI job to generate the relevant report(s) as JSON, convert that to HTML (there's a CLI for that), and upload the HTML as a release asset. Going to look into doing this for Argo CD and then will port it over.

alexec commented 2 years ago

@crenshaw-dev can I please bump

crenshaw-dev commented 2 years ago

I've made a bit of progress in the argo-cd repo (https://github.com/argoproj/argo-cd/issues/8657). Relevant Snyk scans can now block builds on high-severity issues. My next step is to add reports to release assets. I haven't scheduled time for that yet, but hoping soon.

Once the work is done, it should be trivial to replicate in Rollouts/Workflows/Events.

alexec commented 2 years ago

I noted yesterday, that snyk.io shows different issues to running snyk test.

I think we should probably just use snyk.io, not snyk test, as it is zero-config.

crenshaw-dev commented 2 years ago

There are a few problems with the web UI:

1) It doesn't automatically scan new tags. Every time we cut Argo CD releases, I have to delete the old Quay projects and add new ones. 2) It doesn't block builds. We have to proactively go to the UI to check for high-severity vulnerabilities. 3) It doesn't allow declarative "ignore" configuration. When we know a high-severity issue isn't actually an issue in the project, we either have to remember to ignore it when we look at the Snyk UI, or we have to manually add an "ignore" rule in the UI. 4) "Ignore" rules in the UI are not reviewed, version-controlled, or public. I think it's good that the community can look at .snyk in the project repo to see when an ignore rule was added, what justification was given, and view any discussion on the change's PR. 5) The UI doesn't generate a report which is publicly associated with a release. In the case of the Quay checks, the checks are against certain tags - but the report isn't publicly-available, and there's no historical record of past versions. In the case of the GitHub checks, only the latest commit on the master branch is scanned. So there's no (for example) npm report available for current versions or historical versions; even if there were, they wouldn't be publicly available.

tl;dr - the web UI isn't exactly zero-config - versioned scans and ignore rules must be maintained. I think the benefits of the CLI are worth the relatively light config work.

alexec commented 2 years ago

@crenshaw-dev can I bump?

crenshaw-dev commented 2 years ago

@alexec I'm gonna try to get this into next sprint.