Putting Strategy into Practice: How We Tamed SonarQube using TLCTC

Introduction: The Problem of Noise

Our journey began where many security initiatives stall: with a problem. Our SAST report was a sea of red — a long, flat list of Common Weakness Enumeration (CWE) findings. While technically accurate, it was overwhelming and lacked strategic context. A CWE-120 (Buffer Copy) meant nothing to our risk managers, and “fix everything” meant nothing to our developers.

The breakthrough came when we stopped looking at “what” was wrong (the CWE) and started looking at “how” it could be exploited (the TLCTC cluster).

The “Aha!” Moment

A single CWE could map to different threats depending on where it lived in the architecture.

• If a buffer overflow (CWE-120) is in the server-side API, it's #2 Exploiting Server.
• If the exact same flaw is in a client-side library, it's #3 Exploiting Client.

This distinction, derived from the axioms of the TLCTC framework, completely changed our prioritization strategy.

Methodology: From Manual to Automated

1. Mapping Workshops

We started by manually reviewing our backlog. We took real findings and mapped them to TLCTC clusters. This exercise built a shared language. CWE-863 (Incorrect Authorization) wasn't just a bug anymore; it was identified as a potential #1 Abuse of Functions vector.

2. Checklists via the “Attacker's View”

To make this actionable for developers, we adopted the “Attacker's View” vs. “Developer's View” concept. For #4 Identity Theft, instead of listing 20 different CWEs, we gave developers a single clear directive:

Attacker's View: “I abuse credentials to operate as a legitimate identity.”
Developer's View: “I must implement secure credential lifecycle management: proper hashing, secure transmission, and robust session handling.”

3. Automating with SonarQube

We built a custom post-processing script to automate the triage. The logic was simple but powerful: combining the specific vulnerability (CWE) with the architectural context (file path) to determine the threat cluster.

function mapToTLCTC(cwe, filePath) {
  // #4 Identity Theft (Credentials)
  if (['CWE-798', 'CWE-259', 'CWE-321'].includes(cwe)) {
    return 'TLCTC-04.00';
  }

  // #2 vs #3 based on architectural context
  if (['CWE-89', 'CWE-120', 'CWE-78'].includes(cwe)) {
    if (filePath.includes('/server/') || filePath.includes('/api/')) {
      return 'TLCTC-02.00'; // Server-side implementation flaw
    }
    if (filePath.includes('/client/') || filePath.includes('/ui/')) {
      return 'TLCTC-03.00'; // Client-side implementation flaw
    }
  }

  return 'TLCTC-Unknown';
}

Impact: Attack Path Thinking

The real win wasn't tagging; it was connecting the dots. Before TLCTC, we saw two medium-risk bugs: “hardcoded creds” and “SQL injection.” After TLCTC, we saw a high-severity attack path.

By recognising these as #4 Identity Theft and #2 Exploiting Server, we could model the sequence:

#9 (Phishing) → #4 (Steal Hardcoded Creds) → #2 (Auth & Exploit SQLi)

This perspective completely changed our prioritization. We weren't just fixing bugs; we were breaking attack chains.

Results & Recommendations

The shift in perspective improved communication across the board. We used the Bow-Tie model to explain the strategy to management: “We are fixing controls on the left side (causes) to prevent the centre event (compromise).”

Conclusion

If you want to replicate this, start small. Don't try to map every CWE immediately. Start with your existing SAST report, apply the Programmer-vs-Coder roles defined in Part 1, and use the simple dual-notation (#X for strategy, TLCTC-XX.YY for tooling). The framework gives you the mental model to turn noise into signal.