TLCTC Blog - 2025/05/01
TLCTC in Practice: From a Messy SonarQube Report to Strategic Defense
Posted on 2025/05/01 by Dev Secure
Our journey with the Top Level Cyber Threat Clusters (TLCTC) framework began where many security initiatives do: with a problem. Our SonarQube 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. Today, I want to share how we used TLCTC to turn that noise into actionable threat intelligence, transforming our entire development process.
The "Aha!" Moment: It's Not Just 'What', It's 'How and Where'
Our first breakthrough came from understanding the core difference between CWE and TLCTC. (Inspired by `cwe-tlctc-blog-2025-04-07.md`)
- CWE told us 'what' was wrong: We had a CWE-120 (Buffer Copy without Checking Size).
- TLCTC forced us to ask 'how and where' it could be exploited: Was this buffer overflow in our server-side API processing a request? That's #2 Exploiting Server. Or was it in our custom client-side library parsing a response? That's #3 Exploiting Client.
This distinction was everything. The defense for each is different. This simple shift in perspective became the foundation for our entire integration strategy.
Our Solutions: A Step-by-Step Integration
1. Mapping Workshops with SonarQube Data
We ran interactive workshops using our actual SonarQube backlog. We took real findings and, as a team, mapped them to TLCTC clusters. This made the framework tangible. A CWE-89 (SQL Injection) was clearly a #2 Exploiting Server issue. A CWE-863 (Incorrect Authorization) was a classic #1 Abuse of Functions problem. This exercise built a shared language between developers and security.
2. Creating Checklists with the "Developer's View"
To make this actionable, we adopted the "Attacker's View" vs. "Developer's View" concept. (From `tlctc-sdlc-dev-blog-2025-06-13.md`). For each cluster, we created a checklist based on the defensive mindset.
For #4 Identity Theft:
- Attacker's View: "I abuse credentials."
- Developer's View (Our Checklist): "I must implement secure credential lifecycle management: proper hashing, secure transmission, robust session handling, and MFA."
This transformed abstract threats into concrete engineering principles.
3. Enhancing SonarQube with TLCTC Logic
We built a custom SonarQube post-processing script. (Inspired by `tlctc-sonarqube-blog-2025-04-12.md`). It consumes the SonarQube API output and adds TLCTC tags. The key feature is its context-aware logic: for a finding like CWE-120 (Buffer Overflow), the script checks the file path. If it contains `/api/` or `/server/`, it tags it `TLCTC-02.00`. If it contains `/client/` or `/ui/`, it tags it `TLCTC-03.00`. This automates the "how and where" analysis.
4. "Attack Path Thinking" in Code Reviews
This was the biggest win. With vulnerabilities tagged by TLCTC, we could see how they might chain together. A SonarQube finding for CWE-798 (Hard-coded Credentials) was a medium risk. A separate finding for CWE-89 (SQL Injection) was also medium. But when we saw them tagged as #4 Identity Theft and #2 Exploiting Server, we could model a high-severity attack path: #9 (Phishing) → #4 (Steal Hard-coded Dev Credentials) → #2 (Use Credentials to Access API and Exploit SQLi). This perspective completely changed our prioritization.
Impact on Our Development Process & Communicating Upwards
The impact was felt across the SDLC. But crucially, it also improved communication with management. We used the Bow-Tie model (From `white-paper-v1.6.3.pdf`) to explain our strategy. We could say: "On the left are the 'causes'—the 10 TLCTC threats. We're building controls to prevent the 'event'—a system compromise. This protects us from the 'consequences' on the right—like data loss or downtime." This clear, visual model made securing budget for our initiatives far easier.
| Area of Impact | Before TLCTC | After TLCTC Implementation |
|---|---|---|
| Security Requirements | Inconsistent, tool or compliance-driven. | Clear, framed in terms of TLCTC clusters (e.g., "Prevent #4 Identity Theft"). |
| Architectural Decisions | Often lacked security context. | Explicitly reference threat clusters they address (Programmer role). (From `tlctc-ssdcl-roles-blog`) |
| Code Implementation | Focused on fixing individual CWEs. | Focused on implementing secure patterns to block threat clusters (Coder role). |
| SAST Triage | Whack-a-mole with a flat list of CWEs. | Prioritized based on threat clusters and potential attack paths. |
| Management Reporting | "We have 150 open vulnerabilities." | "Our primary risk exposure is from the 'Exploiting Server' cluster, and here's our plan." |
Lessons for Other Teams
If you're considering implementing TLCTC, here are my key recommendations:
- Start with your SAST report: Don't treat TLCTC as a purely theoretical exercise. Use your existing vulnerability data as the starting point for mapping. It's the most effective way to learn.
- Distinguish Roles: Clarify the "Programmer" (architect, strategic) vs. "Coder" (implementer, tactical) responsibilities for each threat cluster. This creates ownership.
- Embrace the Dual Notation: Use the simple `#X` notation (`#1`, `#2`) in meetings, Jira tickets, and code review comments. Use the formal `TLCTC-XX.YY` notation in your tooling and scripts for machine readability. (From `dual-layer-notation-blog`)
- Focus on Attack Paths, Not Just Bugs: The real power of TLCTC is revealed when you stop looking at single vulnerabilities and start seeing how they connect.
- Build bridges, don't burn them: Show how TLCTC complements and adds strategic context to the frameworks your team already knows, like OWASP and NIST.
The Road Ahead
Our journey is ongoing. We're now working on integrating TLCTC with our threat intelligence feeds to see which clusters are being actively exploited against our industry, allowing for even more dynamic risk prioritization. The framework has given us a common mental model that connects a line of code to enterprise risk. It has empowered our developers to not just be coders, but to be the first line of a truly strategic defense.
Have you used a framework to bring order to your SAST findings? I'd love to hear about your experiences and approaches in the comments.