Security audit
Security checks for vulnerabilities and agentic risk
This Kubernetes skill needs review because its emergency runbooks can disrupt workloads without clearly requiring your approval or validating rollback targets.
Before using this skill on production systems, restrict access to the intended cluster and namespaces and require approval for each deletion or rollback. Review release history and choose a verified recovery revision instead of using revision 1 automatically. Limit Secret inspection to relevant resources and protect diagnostic logs. The empty static scan does not resolve the operational risks documented in the runbooks.
Pod deletion changes cluster state and can disrupt workloads. Although it can be an incident-remediation technique, the declared description does not disclose executing destructive remediation, and no corresponding permissions are declared. The supplied code therefore performs a materially broader action than the stated runbook-and-diagnostics capability.
Describing a Kubernetes resource fits the declared diagnostic purpose. The explicit Secrets query introduces sensitive-resource access not disclosed in the description, with no incident-specific justification shown. The snippet demonstrates listing Secrets, but does not establish retrieval or exfiltration of their secret values.
The emergency procedures provide directly actionable pod deletion and rollback calls without requiring target verification, impact assessment, or explicit authorization for disruptive changes. These operations can worsen availability, lose ephemeral state, or restore incompatible application versions; the hardcoded Helm revision of 1 is particularly unsafe because it is not necessarily a known-good release.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Args:
namespace: Focus namespace (empty for cluster-wide)
context: Optional kubeconfig context
include_logs: Include pod logs
since_minutes: Time window for logs/events
The activation instructions explicitly include generic terms such as 'down', 'not working', and 'fix' without requiring a Kubernetes-related request. Although the title and description supply Kubernetes context, these permissive triggers could route unrelated requests into cluster diagnostics or remediation when Kubernetes tools are available; activation alone does not establish authorization to act.
No suspicious patterns detected.