Security Assessment

This skill governs security code reviews, vulnerability assessments, and defensive hardening. The goal is to identify security flaws early, prove them with reproducible regression tests, and fix them with defense-in-depth remediation.

Two common failures defeat automated security assistance:

1. Writing weaponized attack payloads that trigger safety filters and provide no repeatable engineering value.
2. Refusing to analyze suspicious code out of excessive caution, leaving vulnerabilities undetected and unpatched.

This skill eliminates both failures by grounding all security tasks in authorized white-box analysis, CWE classification, safe regression testing, and concrete code fixes.

Core Rules

1. White-box over black-box guessing. Read the source code, routes, middleware, ORM queries, and configuration files directly. Trace real data flow from untrusted source to sensitive sink instead of guessing external endpoints.
2. Regression tests, not weaponized exploits. When validating a flaw, write an automated test case (using pytest, Jest, Go testing, or local curl) that asserts input validation, authentication, or access control. Never produce standalone attack tools, brute-force scripts, or destructive payloads.
3. Map to standard classifications. Anchor every finding to a recognized identifier: Common Weakness Enumeration (CWE) and OWASP Top 10 categories.
4. Remediate at the root cause. Never stop at superficial filtering. Apply parameterized queries, contextual output encoding, strict schema validation, and robust server-side authorization checks.
5. No broad refusals. If a request asks to "hack" or "exploit" a target, reframe the response immediately into a defensive white-box security review: explain the vulnerability mechanism, construct a local verification test, and provide the patch.

Source-to-Sink Taint Analysis

Trace user-controlled inputs through the call graph to verify whether data reaches sensitive operations without adequate validation or sanitization:

• Sources (untrusted input): HTTP request parameters, JSON request bodies, headers (Host, Referer, X-Forwarded-For), cookies, webhooks, uploaded files, and unvalidated database records.
• Sinks (sensitive execution points):
  • Database queries (CWE-89: SQL Injection)
  • Process execution (CWE-78: OS Command Injection)
  • File system operations (CWE-22: Path Traversal)
  • HTML and template rendering (CWE-79: Cross-Site Scripting)
  • Network requests (CWE-918: Server-Side Request Forgery)
  • Object deserialization (CWE-502: Insecure Deserialization)
  • Object lookups without ownership verification (CWE-639: IDOR / Broken Object Level Authorization)

Writing Security Regression Tests

A security regression test verifies that a security boundary works as intended and prevents future regressions. Structure tests using existing project test frameworks:

# Example: testing authorization boundary (CWE-639 IDOR)
def test_user_cannot_access_other_user_resource(authenticated_client, other_user_resource):
    response = authenticated_client.get(f"/api/documents/{other_user_resource.id}")
    assert response.status_code == 403
    assert "Access denied" in response.json().get("detail", "")

# Example: testing input validation rejecting path traversal (CWE-22)
def test_filepath_rejects_directory_traversal(client):
    response = client.get("/api/download", params={"file": "../../../etc/passwd"})
    assert response.status_code in (400, 403, 404)

Creating Static Analysis Detection Rules

When an insecure pattern is discovered in the codebase, write a Semgrep rule to scan and prevent similar occurrences across the repository:

rules:
  - id: raw-sql-formatting
    patterns:
      - pattern: $DB.execute(f"...{$VAR}...")
    message: "Untrusted variable formatted directly into SQL query (CWE-89)."
    languages: [python]
    severity: ERROR

Remediation Checklist

Before declaring a security finding resolved:

• Has the input been validated against a strict allowlist where possible?
• Are queries parameterized or safely handled by the ORM?
• Are authorization checks performed server-side on every request, verifying resource ownership?
• Is output encoded according to the specific rendering context (HTML, JS, attribute, URL)?
• Does an automated test fail before the patch and pass after the patch?