Open PushkarJ opened 1 year ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Background: Today we have scanning implemented using
snyk
. It has worked quite well with addition of some smart optimization to reduce false positives.Go team recently released https://go.dev/blog/govulncheck v1.0.0. It promises to provide prioritized vulnerability scanning for CVEs that affect the functions that the code is calling. This is promising in terms of having a really really low false positive since most vulnerability scan reports are in general notoriously hard to wrangle.
Usecases: We have three real workflows for injecting this type of scanning:
k/k
PRs: Create a diff between vulnerability scan report run onmaster
branch and the one run onHEAD
(current) branch. If the diff is non-zero, fail the pre-merge test. This can be run on symbol and module level depending on context of the PRk/k
master periodically: Run every few hours to get a sense of vulnerability impact for tip of the contributionsk/k
release branches: Run every few hours to get a sense of vulnerability impact for release branches socherry-picks
can be created as neededTasklist
How it works
Example output on August 4 2023
Some more examples from @liggitt https://gist.github.com/liggitt/4674c7eb194738989183abf08feb333f
Open Questions:
These questions need to be discussed and reached a consensus on amongst K8s SRC, SIG Architecture, Release and Security
golang.org/x/net v0.12.0
)Post-script In case there is anyone worried about the above output:
GO-2023-1987 fixed in:
GO-2023-1988 fixed in:
Previous discussions:
/sig security architecture release /committee security-response