Cline rules

1---
2description: "Guides Cline to perform structured security audits — covering OWASP Top 10, threat modeling, dependency scanning, secrets detection, and compliance-aware reporting."
3author: "Cline Team"
4version: "1.0"
5category: "Development"
6tags: ["security", "audit", "owasp", "threat-modeling", "vulnerability", "compliance"]
7globs: ["*.*"]
8---
9 
10# Security Audit & Threat Modeling Protocol
11 
12## Objective
13 
14Guide Cline to perform thorough, structured security assessments of codebases. This goes beyond the surface-level checks in code review — it provides a repeatable methodology for identifying vulnerabilities, assessing risk, and producing actionable remediation plans.
15 
16---
17 
18## When to Activate
19 
20This protocol activates when the user requests:
21- A security audit or review
22- Threat modeling for a feature or system
23- Dependency vulnerability analysis
24- Pre-deployment security checks
25- Compliance-related code assessment
26 
27---
28 
29## 1. Security Audit Process
30 
31### Phase 1: Reconnaissance
32 
33Before analyzing code, gather context:
34 
351. **Identify the attack surface** — What is exposed? (APIs, user inputs, file uploads, auth endpoints, admin panels)
362. **Identify trust boundaries** — Where does data cross from untrusted to trusted zones?
373. **Identify sensitive data** — PII, credentials, tokens, financial data, health records
384. **Identify dependencies** — Third-party libraries, external services, infrastructure
39 
40### Phase 2: Systematic Analysis
41 
42Analyze the codebase against these categories, ordered by typical severity:
43 
44#### A. Injection Flaws (OWASP A03)
45- SQL injection via string concatenation or unsanitized ORM inputs
46- Command injection via `exec`, `system`, `child_process`, or `subprocess`
47- LDAP, XPath, NoSQL injection vectors
48- Template injection in server-side rendering
49 
50**What to check:**
51```
52- [ ] All database queries use parameterized statements or prepared queries
53- [ ] No user input is passed directly to shell commands
54- [ ] Template engines have auto-escaping enabled
55- [ ] ORM queries do not interpolate raw user input
56```
57 
58#### B. Authentication & Session Management (OWASP A07)
59- Password storage (must use bcrypt, scrypt, or argon2 — never MD5/SHA1 alone)
60- Session token generation (must be cryptographically random)
61- Token expiration and rotation policies
62- Multi-factor authentication implementation
63- Account lockout and brute-force protection
64 
65**What to check:**
66```
67- [ ] Passwords hashed with a modern, salted algorithm
68- [ ] Session tokens are not predictable
69- [ ] JWT secrets are not hardcoded and tokens have expiration
70- [ ] Failed login attempts are rate-limited
71- [ ] Password reset flows do not leak user existence
72```
73 
74#### C. Authorization & Access Control (OWASP A01)
75- Broken access control (IDOR — insecure direct object references)
76- Missing function-level access checks
77- Privilege escalation paths
78- CORS misconfiguration
79 
80**What to check:**
81```
82- [ ] Every endpoint enforces authorization, not just authentication
83- [ ] Object-level access checks prevent users from accessing other users' data
84- [ ] Admin functions are not accessible by manipulating client-side state
85- [ ] CORS allows only expected origins
86```
87 
88#### D. Sensitive Data Exposure (OWASP A02)
89- Secrets in source code (API keys, passwords, tokens)
90- Sensitive data in logs
91- Missing encryption for data at rest or in transit
92- Overly verbose error messages leaking internals
93 
94**What to check:**
95```
96- [ ] No secrets or credentials in source files or config committed to git
97- [ ] Sensitive fields are excluded from logs and error responses
98- [ ] HTTPS is enforced; no mixed content
99- [ ] Database connections use TLS
100- [ ] Error responses do not expose stack traces or internal paths
101```
102 
103#### E. Cross-Site Scripting — XSS (OWASP A03)
104- Reflected XSS via URL parameters rendered without escaping
105- Stored XSS via database content rendered in HTML
106- DOM-based XSS via client-side JavaScript
107 
108**What to check:**
109```
110- [ ] All user-generated content is escaped before rendering
111- [ ] Content-Security-Policy headers are configured
112- [ ] innerHTML is not used with untrusted data
113- [ ] Rich text inputs use a sanitization library (e.g., DOMPurify)
114```
115 
116#### F. Dependency Vulnerabilities (OWASP A06)
117- Known CVEs in direct and transitive dependencies
118- Outdated packages with security patches available
119- Typosquatting or supply chain risks
120 
121**What to check:**
122```
123- [ ] `npm audit` / `pip audit` / `dotnet list package --vulnerable` has been run
124- [ ] No dependencies with known critical/high CVEs
125- [ ] Lock files are committed and reviewed
126- [ ] Dependency update process exists
127```
128 
129### Phase 3: Secrets Detection
130 
131Scan for accidentally committed secrets:
132 
133**Patterns to search for:**
134- API keys: `(api[_-]?key|apikey)\s*[:=]\s*['"][A-Za-z0-9]`
135- AWS keys: `AKIA[0-9A-Z]{16}`
136- Generic secrets: `(password|secret|token)\s*[:=]\s*['"][^'"]+`
137- Private keys: `-----BEGIN (RSA |EC |)PRIVATE KEY-----`
138- Connection strings: `(mongodb|postgres|mysql|redis):\/\/[^\s]+`
139 
140**MUST** use `search_files` to scan the codebase for these patterns when performing a security audit.
141 
142---
143 
144## 2. Threat Modeling (STRIDE)
145 
146When asked to threat-model a feature or system, apply the STRIDE framework:
147 
148| Threat | Question | Example |
149|--------|----------|---------|
150| **S**poofing | Can someone pretend to be another user or system? | Forged JWT, session hijacking |
151| **T**ampering | Can someone modify data they should not? | URL parameter manipulation, unsigned API payloads |
152| **R**epudiation | Can someone deny an action they took? | Missing audit logs for admin actions |
153| **I**nformation Disclosure | Can someone access data they should not see? | IDOR, verbose errors, exposed .env files |
154| **D**enial of Service | Can someone make the system unavailable? | Unbounded queries, missing rate limits, regex DoS |
155| **E**levation of Privilege | Can someone gain higher access than intended? | Missing role checks, JWT claim manipulation |
156 
157**Output format:** Present findings as a table mapping each threat to specific code locations and recommended mitigations.
158 
159---
160 
161## 3. Output Format
162 
163Present audit findings grouped by severity:
164 
165**CRITICAL** — Exploitable now, data loss or breach risk
166- Must be fixed before deployment
167 
168**HIGH** — Likely exploitable with moderate effort
169- Should be fixed in the current sprint
170 
171**MEDIUM** — Exploitable under specific conditions
172- Should be tracked and scheduled
173 
174**LOW** — Defense-in-depth improvements
175- Nice to have, fix opportunistically
176 
177For each finding:
1781. **Location** — File and line/section
1792. **Vulnerability** — What the issue is
1803. **Risk** — What could happen if exploited
1814. **Remediation** — Specific fix with code example when possible
1825. **Reference** — OWASP or CWE identifier if applicable
183 
184End with an executive summary: total findings by severity, top 3 priorities, and overall security posture assessment.
185 
186---
187 
188## 4. Pre-Completion Security Checklist
189 
190Before `attempt_completion` on any security-related task:
191 
192- [ ] All OWASP Top 10 categories have been evaluated
193- [ ] Secrets scan has been performed
194- [ ] Findings are categorized by severity
195- [ ] Each finding has a concrete remediation
196- [ ] Executive summary is included
197 
198<!--
199Enterprise Considerations:
200- Organizational security policy templates aligned to SOC2, HIPAA, PCI-DSS
201- Centralized vulnerability tracking and trend analysis across repositories
202- Automated audit trail generation for compliance evidence packages
203- Admin-configurable severity thresholds that block deployments
204- Integration with enterprise SIEM and vulnerability management platforms
205-->
206