CVE-2023-5043 and CVE-2023-5044 missing from official list of vulnerabilities

[sftim]

Per kubernetes/website#45576, the official CVE feed at https://kubernetes.io/docs/reference/issues-security/official-cve-feed/ doesn't have entries for:

• CVE-2023-5043
• CVE-2023-5044

I am not sure if we want to narrow the scope of the feed, fix the missing issues, or change our processes to ensure all announced vulnerabilities show up in the feed.

However, this issue is about taking a step to add those entries into the upstream feed. Doing that should close issue kubernetes/website#45576.

/sig security
/committee security-response

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sftim]

/transfer kubernetes

[ritazh]

Seems the issues were created in their respective repos. But are missing from the official k8s CVE feed probably because there were no corresponding issues created in k/k with the official-cve-feed label.
kubernetes/ingress-nginx#10571
kubernetes/ingress-nginx#10572

We have had to create issues in both the sub project and k/k in the past. e.g. #118419

@cjcullen

[PushkarJ]

@ritazh would it be acceptable for @kubernetes/security-response-committee if SIG Security Tooling Maintainers add a duplicate issue in k/k with the right label for such instances? I am tracking this as part of beta -> GA graduation so want to acknowledge that this could happen again and we would like to establish a precedent for it.

[ritazh]

@ritazh would it be acceptable for @kubernetes/security-response-committee if SIG Security Tooling Maintainers add a duplicate issue in k/k with the right label for such instances? I am tracking this as part of beta -> GA graduation so want to acknowledge that this could happen again and we would like to establish a precedent for it.

Yes please do. And feel free to tag me for review.