| name | assess-vulnerability |
| description | This skill should be used when Claude discovers a potential security vulnerability in existing code, during a code review, or when asked to assess a security finding. Triggers on phrases like "is this a vulnerability", "security issue", "security finding", "could this be exploited", "is this safe", or when code patterns suggest injection, path traversal, XSS, auth bypass, privilege escalation, SSRF, or other OWASP-class issues. |
Vulnerability Assessment for Checkmk
Use this skill whenever you identify a potential security issue in code, whether proactively during review or in response to a user's query. Work through the steps below in order.
Step 1: Characterize the finding
Be precise about what you found:
- Class: vulnerability category (see description for typical classes).
- Location: file, function, line number.
- Root cause: the underlying flaw (missing validation, missing authz check, unsafe API use, etc.).
- Trigger: what input or action causes it, who can supply that input, and whether the code path is actually reachable in a default or documented Checkmk deployment.
- Scenario: concrete path by which this causes harm in a Checkmk environment, and the resulting harm.
State clearly whether this is a confirmed vulnerability, a suspected vulnerability (needs more investigation), or a potential false positive (looks dangerous but may be safe in context).
Step 2: Checkmk threat model
Security relevance depends entirely on whether a finding crosses a trust boundary. Work out which principals are involved and whether the attacker can reach a capability they were not granted.
Principals and when findings are interesting
For each principal, a finding is interesting only if the attacker gains a capability they were not granted and have no legitimate path to.
| Principal | Trust level | Notes |
|---|
| Unauthenticated network client | Untrusted | Anything they can trigger without credentials is interesting. |
| Authenticated non-admin user | Partially trusted | Interesting: escalation to admin permissions (code exec, MKP/backup/executable/automation/user management) however indirect; horizontal access to other users' data, folders, or config; cross-user information disclosure; stored XSS reaching other users. |
| Authenticated admin user | Fully trusted | Holds one or more dangerous permissions (wato.manage_mkps, wato.backups, wato.add_or_modify_executables, wato.automation, wato.users; see cmk/gui/wato/_ac_tests.py:DANGEROUS_PERMISSIONS) that by design already grant arbitrary code execution as the site OS user--via MKP install, backup restore, plugin upload, automation call, or self-promotion. There is no security boundary between a Checkmk admin and the site OS user. Findings whose impact stays within what an admin already controls are not vulnerabilities. |
| Monitored host / agent and relay | Trusted to report monitoring data | The agent is explicitly onboarded to send monitoring data. Sending bad or fake monitoring data is not interesting. A flaw that lets a monitored host or relay achieve code execution, auth bypass, DOS, or control over the site is interesting. Escalation of privileges on the monitored host itself is interesting as well. |
| Remote Checkmk site (distributed) | Trusted to report monitoring data | The site is explicitly onboarded to send monitoring data. Sending bad or fake monitoring data is not interesting. A flaw that lets a remote site achieve code execution, auth bypass, DOS, or control over the central site is interesting. |
Dismissal rules
Also dismiss findings that fall under any of these. Each is an independent filter — a finding must survive all of them.
- Attacker already owns it. The prerequisites the attacker needs already grant the capability the finding would provide — no escalation occurs. Instances: an admin achieving OS-level effects; local-only exploits requiring site-user access; a MITM attacker affecting a channel they already control.
- Not reachable in practice. Dead code, private APIs with provably safe callers, or paths unreachable in any default or documented Checkmk configuration. Confirm reachability before filing.
- Faithful to the spec. Checkmk correctly implements a permissive RFC, protocol, or standard (e.g. SNMP v1/v2c plaintext community strings). The flaw is in the standard, not the implementation.
- Documented behavior. Behavior the Checkmk docs or werks explicitly flag as risky or requiring operator care. A finding requires a breach of the documented contract, not use of it.
- Requires prior admin misconfiguration. Exploitation depends on the admin having misconfigured something first. Operational concern, not a vulnerability.
Key question
Has the attacker gained something they were not explicitly granted — and do they lack a legitimate path to that same capability?
Step 3: Check for existing Bandit exclusion
If the finding is Bandit-flagged (B-codes) or the code carries a # nosec BNS:xxxxx marker, consult tests/bandit-nosec-markers/bandit-exclusions.md and verify the recorded justification still holds for this call site.
Step 4: Classify severity and required action
Based on Steps 1–3, classify the finding:
| Classification | Criteria | Action |
|---|
| Critical / High | Network-reachable, little/no auth, significant impact | Security werk + CVE + immediate fix |
| Medium | Auth required, moderate impact | Security werk + CVE + fix in current cycle |
| Low | Auth + narrow non-default conditions, limited impact | Security werk + CVE; may defer to maintenance |
| Informational | Hardening / defense-in-depth, no direct exploit path | Regular fix/improvement werk (class: fix) |
| False positive | No realistic exploit path in Checkmk's context | None |
Step 5: Summarize and recommend next steps
Present a concise summary to the user:
Vulnerability: <class> in <component>
Severity: Critical/High/Medium/Low/Informational
Attacker profile: <minimum access required>
Exploitability: <one sentence>
Impact: <one sentence>
If the finding is informational or a false positive, say so clearly and explain why — this is equally important to avoid wasting triage time.
When to involve the security team: Recommend reaching out to team development security when the classification requires a security werk and CVE (Medium or above), or when you are genuinely unsure whether a finding is real. CVSS scoring and CVE assignment are the security team's responsibility — do not attempt either. Do not escalate clear false positives or informational findings.
