Add security audit report and blogpost #5775
Conversation
Signed-off-by: Adam Korczynski <[email protected]>
✅ Deploy Preview for knative ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
knative-prow
bot
added
the
size/S
|
PTAL: /assign @evankanderson |
There was a problem hiding this comment.
There are typos in the PDF.
eg. under thread modelling you have 'Knative Serving' but then the paragraphs under neath it talk about Knative Eventing
Then under the Knative Serving section there are phrases like Knative Eventing will autoscale - but it should be 'Knative Serving'
Thanks for catching that. Should now be fixed with the latest report. |
Signed-off-by: Adam Korczynski <[email protected]>
|
/lgtm |
|
|
||
| One CVE was assigned during the audit for a vulnerability that could allow an attacker with already escalated privileges to cause further damage in the cluster. The attacker needs to first establish a position in a Knative pod, and from there, they could exploit the vulnerability and cause denial of service of the Knative autoscaling, thereby denying any autoscaling of Knative. The issue was assigned CVE-2023-48713 of Moderate severity and has been fixed in v1.10.5, v1.12.0 and v1.11.3. | ||
|
|
||
| The auditors found that Knative does not include provenance with releases; Provenance is a critical component of complying with [SLSA](https://slsa.dev/) and ensuring tamper resistance of release artifacts. Recently, the SLSA community released v1.9.0 of the [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) which produces SLSA L3 compliant provenance. slsa-github-generator ensures tamper-resistance of artifacts by producing verifiable provenance, thereby mitigating a series of known supply-chain risks, many of which have been exploited in the wild in recent years. Ada Logics recommend that Knative switches its build to the slsa-github-generator to comply with SLSA L3. |
There was a problem hiding this comment.
Feel free to include this, but Knative is using Prow to build and test releases (our usage requires more resources than are available on GitHub Actions, including real Kubernetes clusters). As such, the GitHub Actions SLSA generator is probably not a good fit.
We're also using ko to build these releases, which doesn't currently have signing support (see ko-build/ko#357 and ko-build/ko#603).
There was a problem hiding this comment.
Actually, we have a provenance reporter here:
https://github.com/knative/hack/blob/7030d5bf584de17a82ec8742c1078ca50633d45e/release.sh#L415
Which is built into the image here: https://github.com/knative/infra/blob/b90750d6063cfcca6322d72d947f1670a83a9349/images/prow-tests/Dockerfile#L220
From the source code here: https://github.com/knative/toolbox/tree/main/provenance-generator
I'm currently trying to figure out the correct cosign download attestation invocation, but I'm pretty sure we have provenance implemented, even though it's not through GHA.
There was a problem hiding this comment.
Huh, it turns out that Knative Serving does not have attestations, but most of the other releases do. For example:
cosign download attestation $(curl -L https://github.com/knative/eventing/releases/download/knative-v1.12.1/eventing-core.yaml | grep image: | head -1 | cut -d: -f2-)
(Grab the first image from the Eventing release and run cosign download attestation on it...)
There was a problem hiding this comment.
(And append | jq -r '.payload' | base64 --decode | jq to read the actual in-toto attestation, rather than the base64-encoded envelope)
There was a problem hiding this comment.
knative/infra#287 for the attestations for serving.
There was a problem hiding this comment.
| The auditors found that Knative does not include provenance with releases; Provenance is a critical component of complying with [SLSA](https://slsa.dev/) and ensuring tamper resistance of release artifacts. Recently, the SLSA community released v1.9.0 of the [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) which produces SLSA L3 compliant provenance. slsa-github-generator ensures tamper-resistance of artifacts by producing verifiable provenance, thereby mitigating a series of known supply-chain risks, many of which have been exploited in the wild in recent years. Ada Logics recommend that Knative switches its build to the slsa-github-generator to comply with SLSA L3. |
There was a problem hiding this comment.
I would prefer to change that paragraph to mention Knatives good work on generating SLSA-compliant provenance than removing it. I have changed the paragraph in b93cf11
There was a problem hiding this comment.
I have also changed the executive summary and SLSA sections of the report to reflect this.
|
(Other than the comments on our builds not being done via GitHub Actions, this LGTM.) |
|
(If you're willing to accept the two strikeouts on provenance information, I'm willing to publish this.) |
Co-authored-by: Evan Anderson <[email protected]>
|
@evankanderson PTAL |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: AdamKorcz, evankanderson The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
knative-prow
bot
added
the
approved
Adds the Knative security audit report and blogpost.
cc @davidhadas @evankanderson