Dependency Risk Triage

Use this skill to determine whether SonarQube SCA findings are reachable in the current codebase. A vulnerable package version alone is never a verdict.

Guardrails

• Triage only VULNERABILITY findings with status OPEN or CONFIRM. Preserve the order in which they were returned in the final report.
• Never classify a risk as NOT_VULNERABLE from a clean search unless the advisory identifies a narrow vulnerable API and the search covers all runtime-reachable code.
• Never classify a transitive dependency (release.directSummary is false) as NOT_VULNERABLE because the project's own code has no call sites. The parent library may call the vulnerable API, and semantic navigation does not index dependency code. Cap such verdicts at NEEDS_HUMAN unless the advisory is withdrawn or the dependency is non-runtime.
• Treat a search with timed-out files (timed_out_files) or code in a language that semantic navigation does not support as incomplete. An incomplete search ends in NEEDS_HUMAN, never NOT_VULNERABLE.
• Treat reflection, generated code, framework wiring, plugin loading, configuration-driven execution, and uncertain advisory details as NEEDS_HUMAN unless a focused subagent investigation produces decisive evidence.
• Never automatically mark a SonarQube finding SAFE. Prepare a paste-ready SAFE writeup for the user to apply in the UI.
• Never change the default branch. Never push or create a pull request without explicit user confirmation.
• Use semantic navigation for source code searches. Use shell commands only for repository, package-manager, and SonarQube operations.

1. Determine scope and mode

Determine whether the request targets one finding, a supplied ordered list, or the full backlog. Ask a question if the scope is ambiguous.