CLI-1015 Add security category enrichment

[kirill-knize-sonarsource]

---

Summary by Gitar

• Security Enrichment:
  • Added security category enrichment support in SecurityCategoryEnricher
  • Updated command line parser to include security metadata flags

_{This will update automatically on new commits.}

[netlify]

✅ Deploy Preview for sonarqube-cli canceled.

Name	Link
🔨 Latest commit	cdca4fe
🔍 Latest deploy log	https://app.netlify.com/projects/sonarqube-cli/deploys/6aa1757c731f7a0008609b2c

[hashicorp-vault-sonar-prod]

CLI-1015

[kirill-knize-sonarsource]

Gitar review

[gitar-bot]

Gitar review

Review is running and results will show up in the dashboard comment shortly.

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Adds security category enrichment support to the CLI quality-gate status command. The implementation is sound, but consider two refinements: security breakdowns currently emit category: 'issues' instead of category: 'security', which can confuse JSON consumers grouping by category—pass the category down through fetchSecurityBreakdown and add a case 'security' format handler. Additionally, hotspot metrics (security_hotspots_reviewed, security_review_rating, etc.) are excluded from CATEGORY_METRICS.security, so --category security may report no matching failures even when a Security-domain condition is failing in the gate.

✅ 2 resolved

✅ Quality: Security breakdown is emitted with category 'issues'

📄 src/commands/quality-gate/status/security-enrichment.ts:41-55 📄 src/commands/quality-gate/status/issues-enrichment.ts:75-82 📄 tests/integration/specs/quality-gate/status-breakdown-security.test.ts:82-95 📄 tests/integration/specs/quality-gate/status-breakdown-security.test.ts:349
fetchSecurityBreakdown delegates to searchIssuesBreakdown, which hardcodes category: 'issues' (issues-enrichment.ts:101), so a failing vulnerabilities/security_rating condition emits breakdown.category === 'issues' in JSON (asserted by the new test at status-breakdown-security.test.ts:349). Every other category emits its own name (coverage, duplications, dependency-risks), and --category security selects these metrics, so a JSON consumer grouping breakdowns by category silently merges vulnerabilities into the issues bucket and has no way to tell the two apart. Add a category: 'security' breakdown variant that reuses IssuesBreakdownEntry and pass the category down, plus a case 'security' in formatEntryLines.

✅ Edge Case: Hotspot metrics excluded from security category mislead --category

📄 src/commands/quality-gate/status/breakdown.ts:88 📄 src/commands/quality-gate/status/breakdown.ts:112-126 📄 src/commands/quality-gate/status/security-enrichment.ts:21
CATEGORY_METRICS.security only lists the vulnerability metrics, so Security-domain hotspot conditions (security_hotspots_reviewed, new_security_hotspots_reviewed, security_review_rating, new_security_review_rating — the first two are part of the default Sonar way gate) are in no category at all. Running quality-gate status --category security on a gate whose only failure is "Security Hotspots Reviewed" therefore prints No failing conditions match category 'security'. (index.ts:110-116) even though a Security condition is failing, which contradicts what the user sees in the SonarQube UI. Listing those metric keys under security keeps the filter and warning honest (fetchSecurityBreakdown would still return no breakdown for them until hotspot support lands), or the warning needs to distinguish "no breakdown available" from "no failing condition".

Implementation Status ✅ 6 of 6 objectives covered

✅ CLI-1015 - 6 of 6 objectives covered

This PR covers all the objectives related to registering the Security domain, mapping to --category security, enriching via GET /api/issues/search, showing the flat list of worst vulnerabilities with file, line, key, rule, and message, and mirroring the JSON breakdown entry.

✅ 6 covered here

• ✅ Register the Security domain in dispatch, mapped to --category security
• ✅ Exclude hotspots and SecurityReview domain from security category enrichment
• ✅ Show the worst --top vulnerabilities as a flat list for each failing condition in the Security domain
• ✅ Enrich security category via GET /api/issues/search with types=VULNERABILITY, s=SEVERITY&asc=false&ps=
• ✅ Ensure a failing vulnerability-count or security_rating condition shows file, line, key, rule, and message
• ✅ Mirror flat issues shape in JSON breakdown entry

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[kirill-knize-sonarsource]

Thanks for the review!

Finding #1 (breakdown emitted with category: 'issues' instead of 'security') — fixed in cdca4fe: threaded the category through searchIssuesBreakdown, added SecurityMetricBreakdown to the union in condition-summary.ts, and added the security case in format-table.ts. Verified manually that JSON output now shows "category": "security".

Finding #2 (hotspot metrics excluded from CATEGORY_METRICS.security) is intentional and out of scope for CLI-1015. The ticket's acceptance criteria explicitly state: "Hotspots (the SecurityReview domain) are out of scope... No hotspot-search call, no security_hotspots_reviewed/security_review_rating handling." This was agreed with the team beforehand, not an oversight — your own Implementation Status check above already confirms it as a covered objective ("Exclude hotspots and SecurityReview domain from security category enrichment").

To be clear on the actual risk: verified manually against a gate failing only on security_hotspots_reviewed/new_security_hotspots_reviewed — the top-level verdict and exit code stay correct ([✗ Failed], exit 51, taken directly from the server's project_status.status, not from our category mapping), and the condition itself is still shown in both table and JSON output. The only gap is no breakdown drill-down for those conditions, plus a slightly misleading "no matching failures" warning specifically when --category security is combined with a hotspot-only failure. That's a real UX nit, but it belongs to a future ticket covering SecurityReview/hotspot support, not this one.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Krosovok]

LGTM