Security Documentation: Remove outdated Spring references and add scanner false positive guidance

Summary

During investigation of CVE-2022-22965 (Spring4Shell) false positive reports from customers, we discovered outdated documentation references to Spring Framework and identified an opportunity to help customers deal with common security scanner false positives.

Issues Found

1. Outdated Spring Reference in Documentation

File: docs/backend/SECURITY_BACKEND.md:255

The security documentation contains an example using Spring's HtmlUtils:

import org.springframework.web.util.HtmlUtils;

public class MyResponseBuilder {
    public Map<String, Object> buildResponse(MyEntity entity) {
        // Encode HTML content for safe display
        response.put("name", HtmlUtils.htmlEscape(entity.getName()));

Issue: Spring Framework was removed in dotCMS 22.06 (June 2022), but this documentation still references Spring utilities.

Impact:

• Confusing for developers who might try to use this import
• May contribute to false security scanner detections
• Inconsistent with actual codebase implementation

2. Customer Impact - Security Scanner False Positives

Context: BankIT (Ticket #35557) reported CVE-2022-22965 detections in dotCMS 26.01.22 preventing production deployment.

Root Cause: Security scanners use pattern-based detection that flags:

• JAX-RS URL patterns (/api/v1/*) that resemble Spring MVC
• Tomcat + JDK 9+ combinations (CVE mentions these)
• REST endpoint characteristics similar to Spring

Customer Impact:

• Blocked production deployments
• Increased support ticket volume
• Extended security review cycles
• Customer confusion about dotCMS security posture

Proposed Solutions

1. Fix Documentation (Immediate)

File to update: docs/backend/SECURITY_BACKEND.md

Replace Spring HtmlUtils example (line 255) with appropriate alternative:

import org.apache.commons.text.StringEscapeUtils;

public class MyResponseBuilder {
    public Map<String, Object> buildResponse(MyEntity entity) {
        // Encode HTML content for safe display
        response.put("name", StringEscapeUtils.escapeHtml4(entity.getName()));
        response.put("description", StringEscapeUtils.escapeHtml4(entity.getDescription()));

OR use Jersey/JAX-RS approach:

// Let Jersey handle encoding with proper Content-Type headers
@Produces(MediaType.APPLICATION_JSON)
public Response buildResponse(MyEntity entity) {
    // Jackson automatically handles safe JSON serialization
    return Response.ok(entity).build();
}

2. Add Security Scanner FAQ (High Priority)

New file: docs/security/SECURITY_SCANNER_FAQ.md

Content should cover:

• Common False Positives

  • CVE-2022-22965 (Spring4Shell) - Framework not present
  • JAX-RS vs Spring MVC pattern confusion
  • Tomcat-related false positives

• Framework Architecture

  • dotCMS uses JAX-RS (Jersey), not Spring MVC
  • CDI/Weld for DI, not Spring IoC
  • When Spring was removed (version 22.06)

• Verification Steps

  • How to verify no Spring JARs present
  • Dependency tree inspection commands
  • Scanner configuration recommendations

• For Security Teams

  • Evidence package for compliance
  • How to whitelist false positives
  • Alternative scanning tools recommendations

3. Enhance Security Advisory (Nice to Have)

File: Create or update SECURITY.md in repository root

Add section:

## Known Security Scanner False Positives

### CVE-2022-22965 (Spring4Shell)

**Status:** NOT VULNERABLE - False Positive

**Reason:** dotCMS does not use Spring Framework. Removed in version 22.06.

**Scanner Detection Cause:** 
- JAX-RS URL patterns resemble Spring MVC patterns
- Tomcat presence triggers heuristic matching
- Pattern-based scanners cannot distinguish frameworks

**Verification:**
- No `spring-*.jar` files in distribution
- No `org.springframework` imports in codebase
- Uses Jersey (JAX-RS) for REST APIs

**For Security Teams:** See [Security Scanner FAQ](docs/security/SECURITY_SCANNER_FAQ.md)

Benefits

1. Reduced Support Load

   • Self-service documentation for security teams
   • Faster resolution of false positive reports
   • Clear evidence for compliance reviews

2. Improved Customer Experience

   • Faster security approval cycles
   • Clear communication about architecture
   • Reduced deployment blockers

3. Documentation Accuracy

   • Remove confusing outdated references
   • Align docs with actual implementation
   • Prevent developer confusion

4. Proactive Security Communication

   • Anticipate common scanner issues
   • Provide clear architectural documentation
   • Build trust with security-conscious customers

Acceptance Criteria

• Remove Spring reference from docs/backend/SECURITY_BACKEND.md
• Replace with appropriate Apache Commons or JAX-RS example
• Create docs/security/SECURITY_SCANNER_FAQ.md
• Add CVE-2022-22965 false positive documentation
• Include verification steps for security teams
• Update SECURITY.md if it exists (or create if needed)
• Review with security team
• Add to release notes for next version

Related Issues

• Support Ticket #35557 (BankIT - CVE-2022-22965 false positive)
• Any other customer reports of Spring-related CVE detections

Priority

Medium-High - While not a functional bug, this documentation gap causes customer production blockers and increases support burden.

Labels

• documentation
• security
• enhancement
• good-first-issue (for the doc updates)

Start with docs/backend/SECURITY_BACKEND.md around line 255 and verify the proposed replacement against the documented JAX-RS and dependency approach. Then review the requested contents for docs/security/SECURITY_SCANNER_FAQ.md and the repository-root SECURITY.md, if present. Done means the outdated Spring example is removed, scanner false-positive and verification guidance is documented, and the listed acceptance criteria are reviewed with the security team.