fix(checks): Improve the detection logic for AVD-KSV-0050

[simar7]

Discussed in #9744

^{Originally posted by james-mchugh November 3, 2025}

IDs

AVD-KSV-0050

Description

The description of AVD-KSV-0050 appears to indicate that the mere presence of roles or rolebinding permissions in a role is enough to escalate privileges. However, this is not the case. The Kubernetes API prevents roles from being created with more roles than the authorizer unless the authorizer already has escalate permissions. Similarly, a role can not be bound to a service account that unless the authorizer has the requested roles or has explicit bind permissions for the role.

Why does Trivy flag the presence of any role/rolebinding permisisons as critical instead of directly flagging uses of escalate, bind, or impersonate? What's even more interesting is that usage of escalate in verbs is not flagged any differently than other operations, even though that would be a true cause for concern security-wise.

I understand it may generally be a good practice to avoid dynamically provisioning roles or rolebindings, such as in an operator for example. However, it seems overkill to list it as a critical issue that can lead to privilege escalation.

Am I missing another concern here around CRUD access to roles/rolebindings?

Thank you!

Reproduction Steps

1. Create a Helm chart with a role that includes create, update, patch, or delete permissions for roles or rolebindings.
2. Scan the chart using `trivy config <path-to-chart>`
3. Observe critical AVD-KSV-0050 finding for role.

Target

Filesystem

Scanner

Misconfiguration

Target OS

No response

Debug Output

NA

Version

0.66.0

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct