-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds SECURITY.md and scanning workflow #267
Conversation
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). I won't merge this until I get at least 2 approves. After that, I'll help apply this to the other java repos. Signed-off-by: Adrian Cole <adrian@tetrate.io>
ps all the main repos are clean, with the exception of zipkin-dependencies, which is a mess due to documented revlock on spark. When it gets to that repo, I'll make a special case note in the workflow. |
severity: HIGH,CRITICAL | ||
output: trivy-report.md | ||
cache-dir: .trivy | ||
- name: Set Summary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
intentionally just setting the summary vs opting into GitHub features. When we run trivy like this, it is basically the same as trivy fs .
so quite easy and has no licensing or other impact with GitHub, nor any new tabs to accidentally ignore.
SECURITY.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@anuraaga @reta @llinder @shakuzen trivya: The reason why this doesn't show up in red, despite testing with old spring deps, is that Trivy agreed that maven-invoker-test deps should be classified as dev dependencies, and they don't trigger by default anymore. That we could resolve that issue in OSS transparently, and also that trivy is OSS and we can run manually like all our other linters, is the reason I went with trivy here. This is in spite of us having access to snyk cloud and being able to manually work around the same (by deleting modules from the portal). Allowing anyone, not just the maintainers, to run the same checks as PRs require offline, is quite a good feature. If you think this decision should be in RATIONALE.md, I'm happy to add it! |
I think it is all good, not need for |
- name: Set Summary | ||
shell: bash | ||
if: ${{ failure() && steps.trivy.conclusion == 'failure' }} | ||
run: cat trivy-report.md >> $GITHUB_STEP_SUMMARY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth adding a link or comment about the 1MB limit on step summary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hopefully we don't end up with over 1MB of CVE descriptions, but sure ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put a note with a cheeky suggestion if this happens :D
PS I spent a good bit of time getting zipkin-dependencies clean, so this means all our prod images can use the same security settings. It is likely zipkin-dependencies will need more maintenance than others to stay clean. I think as volunteers we can choose how often we want to do that work. |
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
OK I raised PRs for all the most maintained and/or production repos. Folks who are interested can raise them for any of the others. |
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them). This is the same approach as approved and merged in openzipkin/zipkin-reporter-java#267 --------- Signed-off-by: Adrian Cole <adrian@tetrate.io>
This adds SECURITY.md and a scanning workflow, using Trivy. In particular, this clarifies what we use to scan for vulnerabilities (Trivy, not anything else), and the only channel likely to be responded to on a significant issue (zipkin-admin email, not advisories as people ignored them).
I won't merge this until I get at least 2 approves. After that, I'll help apply this to the docker and other java repos.