SONARRUBY-154 Update rule metadata

[hashicorp-vault-sonar-prod]

Rule Metadata Update Summary

Sonarpedia	Rules to update	Rules updated
./sonar-ruby-plugin/sonarpedia.json	42	16
Total	42	16

Rule API Version: 2.20.0.5857

This PR was automatically generated to update rule metadata across all supported languages.

[hashicorp-vault-sonar-prod]

SONARRUBY-154

[sonar-review-alpha]

Summary

Automated rule metadata update across 16 Ruby rules. Changes include:

Documentation formatting: Systematic whitespace cleanup across HTML rule files—removing spaces within <li> tags and reformatting text for consistency.

Content updates for 2 rules:

• S1313 (hardcoded IP addresses): Restructured documentation from security hotspot to code smell; moved from vulnerability-focused framing to operational/configuration coupling concerns
• S2068 (hardcoded credentials): Restructured from security hotspot to vulnerability; reorganized sections to match standard rule documentation template with "Why is this an issue?" and "How to fix it?" structure

Metadata changes:

• S1313: type SECURITY_HOTSPOT → CODE_SMELL, title updated, added former-hotspot tag
• S2068: type SECURITY_HOTSPOT → VULNERABILITY, severity Blocker → Major, security impact BLOCKER → MEDIUM, added former-hotspot tag

The update also bumps the latest-update timestamp in sonarpedia.json.

What reviewers should know

Scope: 16 of 42 rules updated; mostly formatting with two substantial rewrites. Safe to scan quickly unless S1313 or S2068 behavior concerns you.

Key files to review:

• S1313.html and S1313.json: IP address hardcoding rule classification shifted from security hotspot to code smell. Review if this change aligns with your security classification standards.
• S2068.html and S2068.json: Credentials rule type changed to VULNERABILITY with reduced severity. Check if impact downgrade (BLOCKER → MEDIUM) is intentional.
• sonarpedia.json: Timestamp-only change.

Content changes: Most HTML edits are trivial spacing (e.g., <li> text </li> → <li>text</li>). Only S1313 and S2068 have substantive rewrites—primarily restructuring examples and adding "Why is this an issue?" sections.

Non-obvious details: The two rule classification changes (S1313, S2068) may indicate a broader shift in how SonarSource categorizes these rules; they were marked former-hotspot to indicate the reclassification.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed for 'Ruby'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[sonar-review-alpha]

Mostly clean automated update. The formatting-only changes (whitespace inside <li> tags) across the 14 unchanged-content files are safe. The two substantial rewrites (S1313, S2068) are structurally sound and internally consistent with their JSON metadata changes.

One item worth confirming before merge: the S2068.html rewrite silently drops actionable user guidance (see inline comment). The two rule reclassifications below are clearly intentional policy decisions, but worth a quick sanity check:

• S1313: SECURITY_HOTSPOT → CODE_SMELL (security impact LOW). Hardcoded IP addresses are now a maintenance/operational issue rather than a security finding. The rule will no longer surface in the SonarQube Security Hotspots review workflow; the former-hotspot tag acknowledges this.
• S2068: SECURITY_HOTSPOT → VULNERABILITY (severity Blocker → Major, security impact BLOCKER → MEDIUM). Hard-coded credentials are now raised as real violations rather than hotspots, but at a notably lower severity than before. The quickfix change from unknown to infeasible is accurate.

🗣️ Give feedback

[sonar-review-alpha]

The previous version of this file included the following actionable guidance that was dropped in this rewrite:

It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", …

This is the only place where users learn the rule is configurable with additional pattern words. If this was intentionally removed from the RSPEC source, it's fine — but if it was accidentally dropped during the rewrite, it should be reinstated here.

• Mark as noise