Hello, I have identified vulnerabilities in the "oryd/keto:latest" image for the linux/amd64 architecture. I am aware that the standard procedure for reporting such vulnerabilities is to contact security@ory.sh, as outlined in the following link: https://github.com/ory/keto/security/policy. While I have no issues following this reporting process, I believe it may impose an additional burden on the team by requiring manual checks upon request, which is a typical flow for addressing security fixes. Instead, I am interested in adopting a more DevSecOps-oriented approach. This approach involves conducting automated vulnerability checks before pushing the image, thereby preventing its publication if it fails to meet the guidelines specified in this link: https://github.com/ory/keto/security/policy#supported-versions. Furthermore, I propose implementing a scheduled GitHub Action to examine the supported versions, to identify any vulnerabilities. If vulnerabilities are detected, corresponding GitHub Issues should be opened to address them. Given this context, I believe it would be prudent to open a feature request outlining the proposed DevSecOps approach. This will allow us to engage in a discussion before proceeding with its implementation. Please let me know if I can create this feature request, you have any questions or require further clarification.

Awesome! But I suggest, if you haven’t already, please report the actual vulnerability to that email independent of work on automated checks.

Certainly, considering the security policy, it appears that addressing those vulnerabilities may not be essential due to the age of the last image being over three months. I would prioritize the Ory team's efforts on upcoming releases instead of allocating time to the 4-month-old oryd/keto:v0.11.1 version, which, according to the sha256 image digest, is currently considered the latest. In any case, I will report those vulnerabilities so that they can be considered for inclusion in future releases.

If you are talking about vulnerable dependencies, we already have some automated checks in place: https://github.com/ory/keto/blob/7d150577abc44cfd0ccc4ebb3472b83cd481a8a2/.github/workflows/ci.yaml#L30-L34 https://github.com/ory/keto/blob/7d150577abc44cfd0ccc4ebb3472b83cd481a8a2/.github/workflows/cve-scan.yaml but let's first get the issue fixed before we look into any details

That is awesome Patrik, I didn't know there was already image scanning in place. The vulnerabilities have been detected by the Google GCP security scanning https://cloud.google.com/artifact-registry/docs/analysis. As you know is difficult to know which tools Google is using for scanning but Trivy Scanner should have cached those. Most probably the image was out of vulnerabilities when it was released. I will report the vulnerabilities so we can fix those, and count on me if you want me to pick some of the tasks.