TLCTC Blog - 2025/04/12
Enhancing SonarQube with the TLCTC Framework: Bridging CWE and TLCTC
Static Application Security Testing (SAST) tools like SonarQube excel at identifying code vulnerabilities through Common Weakness Enumeration (CWE) categorization. However, there's often a disconnect between these technical findings and strategic risk management. The Top Level Cyber Threat Clusters (TLCTC) framework bridges this gap by providing a structured approach to categorizing threats based on the fundamental vulnerability being exploited.
In this post, we'll explore how to integrate the TLCTC framework with SonarQube, enabling organizations to transform granular CWE findings into strategic threat intelligence that aligns with their overall cybersecurity risk management approach.
Understanding the Relationship Between CWE and TLCTC
Before diving into the technical integration, it's important to understand how CWE and TLCTC relate to each other:
CWE: Focusing on the 'What'
CWE provides a comprehensive dictionary of software weaknesses. It defines the type of error or condition – the specific "weakness" – present in software, hardware, design, or implementation. CWE describes "what" is wrong:
- Is it a buffer overflow (CWE-119)?
- Is it SQL injection (CWE-89)?
- Is it improper authentication (CWE-287)?
TLCTC: Focusing on the 'How/Where'
The TLCTC framework takes a different approach, categorizing threats based on the initial generic vulnerability exploited within the client-server interaction model. TLCTC focuses on "how" and "where" the exploitation occurs:
- Is the attacker exploiting a flaw in server-side code (TLCTC-02.00 Exploiting Server)?
- Is the attacker exploiting a flaw in client-side code (TLCTC-03.00 Exploiting Client)?
- Is the attacker abusing legitimate functionality (TLCTC-01.00 Abuse of Functions)?
- Is the attacker compromising the authentication process (TLCTC-04.00 Identity Theft)?
This distinction is crucial for several key reasons:
- Vulnerability Mapping: It determines how we map CWE findings to TLCTC categories in our SonarQube integration.
- Attack Path Analysis: It enables precise documentation of attack sequences using TLCTC notation (e.g., TLCTC-09.00→TLCTC-03.00→TLCTC-07.00), showing how threats chain together in real-world attacks.
- Incident Response: When analyzing security incidents, it helps identify the initial exploitation vector and subsequent propagation methods, providing clarity on how breaches actually occur.
- Strategic Defense Planning: It allows security teams to implement controls that specifically target how attackers are exploiting vulnerabilities, not just what the vulnerabilities are.
The TLCTC framework's emphasis on exploitation vectors rather than just weakness types creates a more actionable model for both preventive security and incident analysis.
The TLCTC Enumeration System
The TLCTC framework uses a structured enumeration system (TLCTC-XX.YY) designed for clarity and machine readability:
- TLCTC- prefix ensures proper attribution to the model
- XX represents the primary cluster number (01-10), zero-padded for consistent formatting
- .YY suffix designed for future refinement (.00 designates current high-level definitions)
For example, TLCTC-08.00 represents the Physical Attack threat cluster, while TLCTC-08.01 would represent a specific subcategory (Direct Physical Access Attacks).
This structured notation offers several advantages for SonarQube integration:
- Machine Readability: Enables automated processing in SonarQube plugins
- Consistent Sorting: Ensures logical ordering in reports and dashboards
- Extensibility: Provides a clear path for future refinement and sub-categorization
Mapping CWEs to TLCTC Categories
The integration's core challenge is mapping CWE findings to appropriate TLCTC categories. This isn't always straightforward, as some CWEs can map to different TLCTC categories depending on context.
For a comprehensive reference, check our detailed Top 25 CWE (2024) to TLCTC Mapping Guide that provides standardized mappings for the most critical weaknesses.
Key Mapping Considerations
- Context Matters: Some CWEs, particularly memory errors like buffer overflows (CWE-787), can map to either TLCTC-02.00 (Exploiting Server) or TLCTC-03.00 (Exploiting Client) depending on where the vulnerability exists.
- Focus on Generic Vulnerability: The mapping should reflect the fundamental vulnerability being exploited rather than the attack technique or outcome.
- Design vs. Implementation Flaws: Distinguish between design/logic issues (TLCTC-01.00 Abuse of Functions) and implementation bugs (TLCTC-02.00/03.00).
Example Mapping Table
Here's a partial mapping of common CWEs to TLCTC categories:
CWE Category | CWE IDs | TLCTC Category | Justification |
---|---|---|---|
Access Control | CWE-862, CWE-863, CWE-732 | TLCTC-01.00 | These represent design flaws in authorization logic that can be abused |
Injection | CWE-89, CWE-78, CWE-77 | TLCTC-02.00 | Server-side implementation flaws in input handling |
XSS/CSRF | CWE-79, CWE-352 | TLCTC-03.00 | Client-side implementation flaws in processing responses |
Authentication | CWE-287, CWE-306, CWE-798 | TLCTC-04.00 | Weaknesses in credential management or authentication process |
Memory Errors | CWE-119, CWE-787, CWE-125 | Context Dependent | Can be either TLCTC-02.00 or TLCTC-03.00 depending on where they occur |
Resource Management | CWE-400, CWE-770 | TLCTC-06.00 | Exploits lack of resource limits, enabling flooding attacks |
Implementation Approaches
Let's explore three approaches to integrating TLCTC with SonarQube:
1. Custom SonarQube Plugin
A custom plugin provides the most comprehensive integration. Our implementation includes:
- A structured mapping between CWE IDs and TLCTC categories using the TLCTC-XX.YY format
- Contextual analysis to determine whether certain vulnerabilities are server-side or client-side
- Reporting capabilities that show the distribution of vulnerabilities across TLCTC categories
- Integration with SonarQube's Quality Gate mechanism
The plugin processes analysis results, maps CWE findings to TLCTC categories, and generates a strategic report showing the threat landscape based on the TLCTC framework.
2. External Integration Script
If developing a plugin is not feasible, an external script can:
- Call the SonarQube API to retrieve vulnerability data
- Process the data to map CWEs to TLCTC categories
- Generate reports or dashboards outside the SonarQube interface
This approach is more accessible but lacks the tight integration of a custom plugin.
3. Custom Rules and Tags
You can also use SonarQube's existing capabilities:
- Create custom rules that include TLCTC metadata
- Use SonarQube's tagging system to add TLCTC categories to findings
- Configure custom dashboards to visualize TLCTC-based statistics
Example Plugin Implementation
Below is a sample implementation of a SonarQube plugin that maps CWE findings to TLCTC categories using the standardized TLCTC-XX.YY enumeration format:
TLCTCIntegrationPlugin.java
package org.sonarqube.plugins.tlctc; import org.sonar.api.batch.sensor.SensorContext; import org.sonar.api.batch.sensor.issue.NewIssue; import org.sonar.api.batch.sensor.issue.Issue; import org.sonar.api.rule.RuleKey; import org.sonar.api.batch.fs.InputFile; import org.sonar.api.ce.posttask.PostProjectAnalysisTask; import org.sonar.api.ce.posttask.QualityGate; import org.sonar.api.ce.posttask.Analysis; import java.util.HashMap; import java.util.Map; import java.util.List; import java.util.ArrayList; import java.util.Arrays; /** * SonarQube plugin for integrating the Top Level Cyber Threat Clusters (TLCTC) framework * with static application security testing (SAST) results. * * This plugin uses the standardized TLCTC-XX.YY enumeration format for machine readability * and categorizes CWE findings into the appropriate TLCTC categories * to provide a strategic view of vulnerabilities based on the TLCTC framework. */ public class TLCTCIntegrationPlugin implements PostProjectAnalysisTask { private static final MapCWE_TO_TLCTC_MAP = initializeMapping(); /** * Represents a TLCTC category with its standardized ID and metadata */ private static class TlctcCategory { private final String id; private final String name; private final String description; private final boolean contextDependent; public TlctcCategory(String id, String name, String description, boolean contextDependent) { this.id = id; this.name = name; this.description = description; this.contextDependent = contextDependent; } public String getId() { return id; } public String getName() { return name; } public String getDescription() { return description; } public boolean isContextDependent() { return contextDependent; } } /** * Initialize the mapping between CWE IDs and TLCTC categories. * This mapping is based on the TLCTC framework definitions, generic vulnerabilities, * and the relationship between CWE's "what" and TLCTC's "how/where" as described in the TLCTC blog. */ private static Map initializeMapping() { Map mapping = new HashMap<>(); // Define the TLCTC categories with standardized TLCTC-XX.YY format TlctcCategory abuse = new TlctcCategory( "TLCTC-01.00", "Abuse of Functions", "An attacker abuses the logic or scope of existing, legitimate software functions, features, or configurations for malicious purposes", false ); TlctcCategory serverExploit = new TlctcCategory( "TLCTC-02.00", "Exploiting Server", "An attacker targets and leverages flaws originating directly within the server-side application's source code implementation", false ); TlctcCategory clientExploit = new TlctcCategory( "TLCTC-03.00", "Exploiting Client", "An attacker targets and leverages flaws originating directly within the source code implementation of any software acting in a client role", false ); TlctcCategory identityTheft = new TlctcCategory( "TLCTC-04.00", "Identity Theft", "An attacker targets weaknesses in identity and access management processes or credential protection mechanisms", false ); TlctcCategory mitm = new TlctcCategory( "TLCTC-05.00", "Man in the Middle", "An attacker intercepts, eavesdrops on, modifies, or relays communication between two parties without their knowledge or consent", false ); TlctcCategory flooding = new TlctcCategory( "TLCTC-06.00", "Flooding Attack", "An attacker intentionally overwhelms system resources or exceeds capacity limits through a high volume of requests, data, or operations", false ); TlctcCategory malware = new TlctcCategory( "TLCTC-07.00", "Malware", "An attacker abuses the inherent ability of a software environment to execute foreign executable content", false ); TlctcCategory physical = new TlctcCategory( "TLCTC-08.00", "Physical Attack", "An attacker gains unauthorized physical interaction with or causes physical interference to hardware, devices, facilities, or data transmission media", false ); TlctcCategory socialEng = new TlctcCategory( "TLCTC-09.00", "Social Engineering", "An attacker psychologically manipulates individuals into performing actions counter to their or their organization's best interests", false ); TlctcCategory supplyChain = new TlctcCategory( "TLCTC-10.00", "Supply Chain Attack", "An attacker compromises systems by targeting vulnerabilities within an organization's supply chain", false ); // Memory Error CWEs - context dependent between server and client String[] memoryErrorCWEs = {"CWE-119", "CWE-125", "CWE-787", "CWE-416", "CWE-476", "CWE-190"}; for (String cwe : memoryErrorCWEs) { // Default to server-side, but mark as context-dependent TlctcCategory contextDepServerExploit = new TlctcCategory( serverExploit.getId(), serverExploit.getName(), serverExploit.getDescription(), true // Mark as context dependent ); mapping.put(cwe, contextDepServerExploit); } // TLCTC-01.00 Abuse of Functions for (String cwe : Arrays.asList("CWE-749", "CWE-289", "CWE-288", "CWE-732", "CWE-862", "CWE-269", "CWE-863")) { mapping.put(cwe, abuse); } // TLCTC-02.00 Exploiting Server (server-side specific) for (String cwe : Arrays.asList("CWE-89", "CWE-22", "CWE-78", "CWE-434", "CWE-918", "CWE-77")) { mapping.put(cwe, serverExploit); } // TLCTC-03.00 Exploiting Client (client-side specific) for (String cwe : Arrays.asList("CWE-79", "CWE-352", "CWE-601")) { mapping.put(cwe, clientExploit); } // TLCTC-04.00 Identity Theft for (String cwe : Arrays.asList("CWE-522", "CWE-798", "CWE-592", "CWE-384", "CWE-287", "CWE-306")) { mapping.put(cwe, identityTheft); } // TLCTC-05.00 Man in the Middle for (String cwe : Arrays.asList("CWE-300", "CWE-319", "CWE-295")) { mapping.put(cwe, mitm); } // TLCTC-06.00 Flooding Attack for (String cwe : Arrays.asList("CWE-400", "CWE-770")) { mapping.put(cwe, flooding); } // TLCTC-07.00 Malware for (String cwe : Arrays.asList("CWE-94", "CWE-96")) { mapping.put(cwe, malware); } // TLCTC-10.00 Supply Chain Attack for (String cwe : Arrays.asList("CWE-937", "CWE-829")) { mapping.put(cwe, supplyChain); } // Injection/Deserialization vulnerabilities that could be either TLCTC-02.00 (server) or TLCTC-07.00 (malware) // Default to TLCTC-02.00 in most contexts TlctcCategory contextDepDeserialization = new TlctcCategory( serverExploit.getId(), serverExploit.getName(), serverExploit.getDescription(), true // Mark as context dependent ); mapping.put("CWE-502", contextDepDeserialization); return mapping; } @Override public void finished(Context context) { Analysis analysis = context.getAnalysis(); QualityGate qualityGate = context.getQualityGate(); // Process issues and add TLCTC categorization List issues = getIssuesFromAnalysis(analysis); Map tlctcCounts = categorizeTLCTC(issues); // Generate TLCTC report generateTLCTCReport(tlctcCounts, context.getProject().getName(), analysis); } /** * Retrieves issues from the analysis. * This is a placeholder - actual implementation would use SonarQube's API. */ private List getIssuesFromAnalysis(Analysis analysis) { // In a real implementation, this would retrieve issues from SonarQube return new ArrayList<>(); } /** * Categorizes issues according to the TLCTC framework. * Takes into account the context-dependent nature of certain CWEs as highlighted in the TLCTC blog. */ private Map categorizeTLCTC(List issues) { Map tlctcCounts = new HashMap<>(); // Initialize counts for all TLCTC categories for (int i = 1; i <= 10; i++) { String categoryId = String.format("TLCTC-%02d.00", i); tlctcCounts.put(categoryId, 0); } for (Issue issue : issues) { String cweId = extractCWEId(issue); if (cweId != null && CWE_TO_TLCTC_MAP.containsKey(cweId)) { TlctcCategory category = CWE_TO_TLCTC_MAP.get(cweId); // For context-dependent CWEs, try to determine if it's server or client side if (category.isContextDependent()) { String context = determineContext(issue); if ("client".equalsIgnoreCase(context)) { // It's a client-side issue, switch to TLCTC-03.00 category = new TlctcCategory( "TLCTC-03.00", "Exploiting Client", "An attacker targets and leverages flaws originating directly within the source code implementation of any software acting in a client role", false ); } // Default remains server-side (TLCTC-02.00) } tlctcCounts.put(category.getId(), tlctcCounts.get(category.getId()) + 1); } } return tlctcCounts; } /** * Attempts to determine if a vulnerability is in server or client context. * This is a placeholder - actual implementation would analyze the issue details. */ private String determineContext(Issue issue) { // In a real implementation, examine issue details, file path, component name, etc. // to determine if it's likely server or client side // Example heuristic: if file path contains "client", "browser", "frontend", etc. // return "client" otherwise default to "server" return "server"; } /** * Extracts the CWE ID from an issue. * This is a placeholder - actual implementation would depend on how CWE IDs are stored in SonarQube. */ private String extractCWEId(Issue issue) { // In a real implementation, this would extract the CWE ID from the issue return null; } /** * Generates a report showing the distribution of issues across TLCTC categories. * Uses the standardized TLCTC-XX.YY enumeration format. */ private void generateTLCTCReport(Map tlctcCounts, String projectName, Analysis analysis) { // In a real implementation, this would generate and store/display a report System.out.println("TLCTC Report for " + projectName); System.out.println("Analysis date: " + analysis.getDate()); System.out.println("----------------------------------"); for (int i = 1; i <= 10; i++) { String categoryId = String.format("TLCTC-%02d.00", i); System.out.println(categoryId + ": " + getTLCTCName(categoryId) + " - " + tlctcCounts.get(categoryId)); } // Additional output for context-dependent CWEs System.out.println("\nNote: Some vulnerabilities like memory errors (CWE-119, CWE-787, etc.)"); System.out.println("can map to either TLCTC-02.00 or TLCTC-03.00 depending on context."); System.out.println("The report attempts to determine the correct context where possible."); } /** * Returns the full name of a TLCTC category. */ private String getTLCTCName(String categoryId) { switch (categoryId) { case "TLCTC-01.00": return "Abuse of Functions"; case "TLCTC-02.00": return "Exploiting Server"; case "TLCTC-03.00": return "Exploiting Client"; case "TLCTC-04.00": return "Identity Theft"; case "TLCTC-05.00": return "Man in the Middle"; case "TLCTC-06.00": return "Flooding Attack"; case "TLCTC-07.00": return "Malware"; case "TLCTC-08.00": return "Physical Attack"; case "TLCTC-09.00": return "Social Engineering"; case "TLCTC-10.00": return "Supply Chain Attack"; default: return "Unknown Category"; } } }
This enhanced plugin implementation demonstrates several key aspects of TLCTC integration:
- Proper use of the standardized TLCTC-XX.YY enumeration format for machine readability
- A more structured approach with the TlctcCategory class to represent TLCTC categories with metadata
- Context-aware handling of vulnerabilities that can map to different TLCTC categories depending on their environment
- Comprehensive CWE to TLCTC mapping with detailed descriptions
- Special handling for ambiguous cases such as memory errors that could be either server or client-side
This implementation also aligns more closely with the concepts discussed throughout this article, particularly the distinction between CWE's "what" approach and TLCTC's "how/where" categorization model.
Handling Context-Dependent Mappings
Some CWEs, particularly memory errors like buffer overflows, can map to different TLCTC categories depending on the context. Our implementation handles this by:
- Default Mapping: Assigning a default category (usually TLCTC-02.00 for server-side contexts)
- Context Analysis: Examining factors like file paths, component names, and code patterns to determine if the vulnerability is in client-side code
- Override Logic: Adjusting the mapping to TLCTC-03.00 when client-side context is detected
This context-aware mapping provides more accurate TLCTC categorization, reflecting the true nature of the vulnerability.
Benefits of the Integration
Integrating TLCTC with SonarQube provides several strategic advantages:
- Strategic Context: Transforms technical CWE findings into actionable threat intelligence aligned with risk management frameworks.
- Unified Communication: Provides a common language for discussing vulnerabilities across technical and management teams.
- Risk-Based Prioritization: Enables prioritization based on threat clusters rather than individual CWE findings.
- Attack Path Awareness: Helps identify potential attack sequences by understanding how different vulnerabilities relate to TLCTC categories.
- Control Alignment: Facilitates mapping between identified threats and appropriate controls within frameworks like NIST CSF.
Example: From CWE to TLCTC in Practice
Let's see this integration in action with two practical examples:
Example 1: Vulnerability Analysis
Imagine SonarQube identifies these vulnerabilities in your application:
- SQL Injection (CWE-89) in an API endpoint
- Cross-Site Scripting (CWE-79) in a frontend component
- Hard-coded credentials (CWE-798) in a configuration file
Our TLCTC integration would categorize these as:
- CWE-89 → TLCTC-02.00 (Exploiting Server)
- CWE-79 → TLCTC-03.00 (Exploiting Client)
- CWE-798 → TLCTC-04.00 (Identity Theft)
This clear categorization helps security teams understand that they need to:
- Address server-side code flaws in their data processing
- Fix client-side vulnerabilities in their frontend code
- Improve credential management practices
Example 2: Attack Path Analysis
The TLCTC framework truly shines when analyzing potential attack paths. Consider a real-world attack scenario:
- An attacker sends a phishing email with a malicious link (Social Engineering)
- The victim clicks the link, loading a page that exploits a browser vulnerability (Exploiting Client)
- The exploit drops malware that steals credentials (Malware → Identity Theft)
- Using the stolen credentials, the attacker accesses the server (Identity Theft)
- The attacker exploits a server vulnerability to escalate privileges (Exploiting Server)
In TLCTC notation, this attack path would be represented as:
TLCTC-09.00 → TLCTC-03.00 → TLCTC-07.00 → TLCTC-04.00 → TLCTC-02.00
This standardized notation provides several benefits:
- Clear communication about attack sequences
- Identification of common initial access vectors
- Understanding of how different threats chain together
- Insight into which controls might break the attack chain at each step
The TLCTC perspective transforms both static vulnerability analysis and dynamic attack path modeling, offering a more strategic view than a simple list of CWEs or isolated technical findings.
Implementation Challenges
While integrating TLCTC with SonarQube offers significant benefits, there are challenges to consider:
- Context Dependency: Accurately determining whether certain vulnerabilities are server-side or client-side can be difficult without detailed analysis.
- Mapping Ambiguities: Some CWEs don't map cleanly to a single TLCTC category and require judgment calls.
- Limited TLCTC Coverage: Not all CWEs map directly to TLCTC categories, as some represent control failures rather than exploitable vulnerabilities.
- Evolving Landscape: As new vulnerability types emerge, the mapping between CWEs and TLCTC may need to be updated.
To address some of these challenges, we maintain a standardized reference mapping of the Top 25 CWE (2024) to TLCTC categories. This resource serves as a baseline for organizations implementing the integration and ensures consistency across different security tools and frameworks.
Conclusion
Integrating the TLCTC framework with SonarQube bridges the gap between technical vulnerability findings and strategic risk management. By mapping CWE results to TLCTC categories, organizations gain a clearer understanding of their threat landscape and can better align their security controls with the actual threats they face.
This integration demonstrates the complementary nature of CWE and TLCTC: CWE provides the detailed "what" of specific weaknesses, while TLCTC provides the strategic "how/where" of exploitation vectors. Together, they create a more comprehensive approach to vulnerability management that spans from code-level details to enterprise risk strategy.
Remember that effective security requires understanding both the specific weakness (CWE) and the broader threat context (TLCTC) to develop truly resilient systems and applications.