diff --git a/skills/appsec/dependency-scanning/SKILL.md b/skills/appsec/dependency-scanning/SKILL.md
index 298fdd86..0ab8d12d 100644
--- a/skills/appsec/dependency-scanning/SKILL.md
+++ b/skills/appsec/dependency-scanning/SKILL.md
@@ -12,7 +12,7 @@ phase: [build, deploy]
 frameworks: [SLSA-v1.0, CycloneDX, SPDX, CISA-KEV]
 difficulty: intermediate
 time_estimate: "15-30min"
-version: "1.0.0"
+version: "1.0.1"
 author: unitoneai
 license: MIT
 allowed-tools: Read, Grep, Glob
@@ -218,16 +218,86 @@ When performing a dependency scan, produce findings in the following structure:
 1. [Prioritized list of remediation actions]
 ```
 
+## Vendored Native Library Analysis
+
+### Why Vendored Libraries Create Blind Spots
+
+Many Python, Node.js, and Ruby packages vendor (bundle) native C/C++ libraries -- OpenSSL, libxml2, zlib, SQLite, etc. -- compiled directly into wheel or binary distributions. Standard SCA scanners only examine the package manifest and miss these embedded native components entirely, creating two systematic failure modes (per ArXiv 2603.18693):
+
+- **False negatives (missed vulnerabilities)**: A Python wheel bundles an outdated `libexpat` with a known CVE. `pip-audit` sees only the Python package version, which appears clean. The vendored native library vulnerability is invisible.
+- **False positives (phantom vulnerabilities)**: OS-level scanners flag `libssl 1.1.1` as vulnerable, but the distribution backported the fix (common in RHEL, Debian, Ubuntu LTS). The CVE applies to upstream OpenSSL but not to the patched OS package.
+
+### Required Scan Dimensions
+
+Dependency scanning must cover three layers to eliminate these blind spots:
+
+1. **Package-level**: Standard manifest/lockfile scanning (npm audit, pip-audit, cargo audit).
+2. **Vendored native libraries**: Inspect binary distributions for bundled C/C++ libraries. Tools: `syft` (detects vendored libs in Python wheels and container layers), `trivy` (filesystem mode with `--scanners vuln`), or manual inspection of `.so`/`.dll` files in site-packages.
+3. **OS package cross-reference**: For containerized or server deployments, cross-reference OS package versions against upstream CVEs, accounting for distribution backports. Use `trivy image` or `grype` which understand distro-specific version schemes.
+
+### Cross-Ecosystem False Positive/Negative Patterns
+
+| Pattern | Cause | Scanner Behavior | Fix |
+|---|---|---|---|
+| Vendored vuln (FN) | Native lib bundled in wheel/gem | Package scanner reports clean | Scan with syft/trivy at binary level |
+| Backport phantom (FP) | Distro backported fix, version number unchanged | OS scanner flags CVE | Cross-reference distro security tracker |
+| Dual-source conflict | pip package and OS package provide same lib | Contradictory findings | Determine which copy is actually loaded at runtime |
+
+## Shift-Left: IDE and Install-Time Scanning
+
+### Detection at Install Time
+
+Traditional dependency scanning runs in CI -- after code is committed and pushed. This misses the **pre-CI attack surface**: developers installing malicious or vulnerable packages locally during development. The GlassWorm campaign (2025-2026) demonstrated attackers specifically targeting this phase, publishing malicious npm/PyPI packages designed to execute during `npm install` or `pip install` before any CI gate runs.
+
+### Recommended IDE and Install-Time Tools
+
+| Ecosystem | Tool | Mode | Behavior |
+|---|---|---|---|
+| npm/Node.js | socket.dev | IDE extension + CLI | Flags malicious install scripts, typosquats, and known vulns at `npm install` time |
+| npm/Node.js | `npm audit signatures` | CLI | Verifies registry signatures on packages at install |
+| Python/pip | pip-audit | CLI (pre-commit hook) | Scans resolved dependencies before code runs |
+| Java/Maven | OWASP Dependency-Check Maven plugin | Build plugin | Flags CVEs during `mvn compile` |
+| Multi-ecosystem | Snyk for VS Code | IDE extension | Real-time vulnerability warnings in editor, soft-alert mode |
+| Rust/Cargo | cargo-audit | CLI (pre-commit hook) | Checks Cargo.lock against RustSec advisory DB |
+
+### Gate Strategy
+
+- **IDE (soft alert)**: Show warnings inline but do not block installation. Developers need fast iteration; hard blocks at the IDE level cause alert fatigue and workarounds.
+- **Pre-commit hook (soft gate)**: Run `pip-audit` / `cargo audit` / `npm audit` as a pre-commit check. Warn on new vulnerabilities but allow override with documented justification.
+- **CI pipeline (hard gate)**: Block merge on Critical/High CVEs with EPSS > 0.1 or KEV listing. This is the enforcement point -- IDE and install-time layers are early warning only.
+
+## AI Confirmation Bias in CI Supply Chain Gates
+
+### The Risk
+
+LLM-based vulnerability detection is increasingly used as a CI gate -- automated code review bots that approve or flag PRs. Research (ArXiv 2603.18740) demonstrates that LLMs used in this role exhibit confirmation bias: they favor interpretations consistent with surrounding context (comments, commit messages, PR descriptions).
+
+### Exploitation Vector
+
+Attackers targeting CI pipelines with LLM-based review can:
+
+1. **Craft adversarial context**: Write PR descriptions, code comments, and variable names that prime the LLM to interpret a malicious dependency change as benign.
+2. **Exploit framing effects**: Introduce a vulnerable dependency alongside a legitimate security fix, relying on the LLM to generalize the "security improvement" framing to the entire changeset.
+3. **Target auto-merge flows**: In pipelines where LLM approval triggers automatic merge, a single bypassed review can introduce a compromised dependency into production.
+
+### Mitigation
+
+- **Never use LLM review as the sole CI security gate** for dependency changes. Pair with deterministic SCA tools (npm audit, pip-audit, trivy) that are not susceptible to contextual manipulation.
+- **Separate dependency PRs from code PRs** to prevent framing contamination. A dependency bump should be reviewed in isolation, not bundled with feature work.
+- **Require human approval for new dependencies** and major version bumps, regardless of automated review outcome.
+- **Audit LLM reviewer decisions**: Log the full LLM reasoning chain for dependency-related approvals. Periodically review for patterns of missed findings that correlate with adversarial context.
+
 ## Procedure
 
 1. **Identify manifests**: Use Glob to locate all package manifest and lockfiles in the project.
 2. **Inventory dependencies**: Read manifest files to enumerate direct dependencies and their declared version ranges.
 3. **Analyze lockfiles**: Read lockfiles to map the full transitive dependency tree with pinned versions.
 4. **Vulnerability scan**: Cross-reference packages and versions against known CVE databases. Apply the EPSS+CVSS+KEV triage model.
-5. **License audit**: Extract license declarations from lockfiles or registry metadata. Flag copyleft and unlicensed packages.
-6. **Typosquatting check**: Review dependency names for patterns described in the detection section.
-7. **Supply chain assessment**: Evaluate SLSA posture -- lockfile presence, pinned versions, provenance availability.
-8. **Report**: Produce the assessment using the output template above, with prioritized remediation recommendations.
+5. **Vendored library scan**: Check for vendored native libraries in binary distributions. Cross-reference OS package versions against upstream CVEs, accounting for distro backports.
+6. **License audit**: Extract license declarations from lockfiles or registry metadata. Flag copyleft and unlicensed packages.
+7. **Typosquatting check**: Review dependency names for patterns described in the detection section.
+8. **Supply chain assessment**: Evaluate SLSA posture -- lockfile presence, pinned versions, provenance availability. Note any CI gates relying solely on LLM-based review.
+9. **Report**: Produce the assessment using the output template above, with prioritized remediation recommendations.
 
 ## Prompt Injection Safety Notice
 
@@ -251,3 +321,5 @@ This skill processes user-supplied content including package manifests, lockfile
 - [NIST NVD](https://nvd.nist.gov/)
 - [OpenSSF Scorecard](https://securityscorecards.dev/)
 - [Executive Order 14028 - Improving the Nation's Cybersecurity](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)
+- ArXiv 2603.18693: Cross-Ecosystem Vulnerability Analysis for Python Applications -- vendored native library analysis and cross-ecosystem FP/FN patterns
+- ArXiv 2603.18740: Measuring and Exploiting Confirmation Bias in LLM-Assisted Security Code Review -- AI confirmation bias in CI supply chain gates
diff --git a/skills/appsec/secure-code-review/SKILL.md b/skills/appsec/secure-code-review/SKILL.md
index be7101ab..aedd4251 100644
--- a/skills/appsec/secure-code-review/SKILL.md
+++ b/skills/appsec/secure-code-review/SKILL.md
@@ -12,7 +12,7 @@ phase: [build, review]
 frameworks: [OWASP-ASVS, CWE-Top-25, OWASP-Top-10]
 difficulty: intermediate
 time_estimate: "15-45min per module"
-version: "1.0.0"
+version: "1.0.1"
 author: unitoneai
 license: MIT
 allowed-tools: Read, Grep, Glob
@@ -22,7 +22,7 @@ argument-hint: "[target-file-or-directory]"
 
 # Secure Code Review
 
-A structured, repeatable process for performing security-focused code review grounded in OWASP Application Security Verification Standard (ASVS) 4.0.3 and the CWE Top 25 Most Dangerous Software Weaknesses (2024 edition). This skill produces findings with traceable control IDs, severity ratings, and actionable remediation guidance.
+A structured, repeatable process for performing security-focused code review grounded in OWASP ASVS 4.0.3 and CWE Top 25 (2024). Produces findings with traceable control IDs, severity ratings, and actionable remediation guidance.
 
 ---
 
@@ -32,168 +32,132 @@ If a target is provided via arguments, focus the review on: $ARGUMENTS
 
 Before examining any code, establish the review boundary.
 
-1. **Identify the languages and frameworks** present in the changeset (Python, JavaScript/TypeScript, Go, Java, etc.).
-2. **Catalog the modules under review** -- list every file path and its primary responsibility (route handler, data model, utility, middleware, configuration).
-3. **Determine trust boundaries** -- mark where user-controlled data enters the system (HTTP parameters, headers, file uploads, message queues, environment variables).
-4. **Note dependencies** -- third-party libraries that handle security-sensitive operations (auth libraries, ORM layers, crypto packages, templating engines).
-5. **Map ASVS sections to scope** -- based on what the code does, select which ASVS chapters (V1 through V14) are applicable to this review.
+1. **Identify the languages and frameworks** present in the changeset.
+2. **Catalog the modules under review** -- list every file path and its primary responsibility.
+3. **Determine trust boundaries** -- mark where user-controlled data enters the system.
+4. **Note dependencies** -- third-party libraries that handle security-sensitive operations.
+5. **Map ASVS sections to scope** -- select which ASVS chapters (V1-V14) are applicable.
 
-> **Gate:** Do not proceed until the language, trust boundaries, and applicable ASVS sections are documented. This prevents scope creep and ensures coverage.
+> **Gate:** Do not proceed until the language, trust boundaries, and applicable ASVS sections are documented.
 
 ---
 
 ## Step 2: Input Validation and Injection Review
 
 **ASVS Reference:** V5 -- Validation, Sanitization and Encoding
-**CWE Coverage:** CWE-79 (XSS), CWE-89 (SQL Injection), CWE-78 (OS Command Injection), CWE-22 (Path Traversal), CWE-77 (Command Injection), CWE-20 (Improper Input Validation)
+**CWE Coverage:** CWE-79, CWE-89, CWE-78, CWE-22, CWE-77, CWE-20
 
 ### 2.1 Controls to Verify
 
 | ASVS Control | Description |
 |---|---|
-| V5.1.1 | Input validation is applied on a trusted service layer, not solely client-side |
-| V5.1.3 | All input is validated against an allowlist of permitted characters or patterns |
-| V5.2.1 | All HTML form output is properly encoded to prevent reflected XSS |
-| V5.2.2 | Unstructured data is sanitized to enforce safety and allowed characters |
-| V5.3.1 | Output encoding is relevant for the interpreter context (HTML, JS, URL, CSS, SQL) |
-| V5.3.4 | Data selection or database queries use parameterized queries or ORM |
-| V5.3.7 | The application protects against LDAP injection |
-| V5.3.8 | The application protects against OS command injection |
-| V5.5.1 | Serialized objects use integrity checks or encryption to prevent hostile object creation |
-
-### 2.2 Vulnerable Patterns by Language
-
-**Python -- SQL Injection (CWE-89)**
+| V5.1.1 | Input validation on trusted service layer, not solely client-side |
+| V5.1.3 | All input validated against allowlist of permitted characters/patterns |
+| V5.2.1 | HTML form output properly encoded to prevent reflected XSS |
+| V5.3.1 | Output encoding relevant for interpreter context (HTML, JS, URL, CSS, SQL) |
+| V5.3.4 | Database queries use parameterized queries or ORM |
+| V5.3.8 | Application protects against OS command injection |
+| V5.5.1 | Serialized objects use integrity checks or encryption |
+
+### 2.2 Vulnerable Patterns
+
+**SQL Injection (CWE-89)**
 ```python
 # VULNERABLE: string formatting in SQL query
-def get_user(username):
-    query = f"SELECT * FROM users WHERE name = '{username}'"
-    cursor.execute(query)
+query = f"SELECT * FROM users WHERE name = '{username}'"
+cursor.execute(query)
 ```
 Remediation: Use parameterized queries -- `cursor.execute("SELECT * FROM users WHERE name = %s", (username,))`.
 
-**JavaScript -- Cross-site Scripting (CWE-79)**
+**Cross-site Scripting (CWE-79)**
 ```javascript
 // VULNERABLE: inserting unsanitized user input into DOM
-app.get('/search', (req, res) => {
-  res.send(`<h1>Results for: ${req.query.q}</h1>`);
-});
+res.send(`<h1>Results for: ${req.query.q}</h1>`);
 ```
-Remediation: Use a templating engine with auto-escaping enabled, or explicitly escape with a library such as `he` or `DOMPurify`.
+Remediation: Use a templating engine with auto-escaping, or escape with `DOMPurify`.
 
-**Go -- OS Command Injection (CWE-78)**
+**OS Command Injection (CWE-78)**
 ```go
-// VULNERABLE: user input passed directly to shell execution
-func handler(w http.ResponseWriter, r *http.Request) {
-    filename := r.URL.Query().Get("file")
-    cmd := exec.Command("sh", "-c", "cat "+filename)
-    output, _ := cmd.Output()
-    w.Write(output)
-}
-```
-Remediation: Avoid shell invocations. Use `exec.Command("cat", filename)` with an allowlist of permitted filenames.
-
-**Java -- Path Traversal (CWE-22)**
-```java
-// VULNERABLE: user-controlled path with no canonicalization
-String filename = request.getParameter("file");
-File f = new File("/uploads/" + filename);
-FileInputStream fis = new FileInputStream(f);
+// VULNERABLE: user input passed directly to shell
+cmd := exec.Command("sh", "-c", "cat "+filename)
 ```
-Remediation: Canonicalize the resolved path and verify it remains within the expected base directory.
+Remediation: Avoid shell invocations. Use `exec.Command("cat", filename)` with an allowlist.
 
 ### 2.3 Review Checklist
 
-- [ ] Every point where user input enters the system is identified.
-- [ ] All SQL queries use parameterized statements or a query builder -- no string concatenation.
-- [ ] HTML output is encoded contextually (HTML body, attribute, JavaScript, URL).
-- [ ] OS commands, if unavoidable, use allowlisted arguments and avoid shell interpretation.
+- [ ] Every user input entry point is identified.
+- [ ] All SQL queries use parameterized statements -- no string concatenation.
+- [ ] HTML output is encoded contextually (HTML body, attribute, JS, URL).
+- [ ] OS commands use allowlisted arguments and avoid shell interpretation.
 - [ ] File path operations validate and canonicalize against a base directory.
-- [ ] Regular expressions used for validation are anchored (`^...$`) and tested for ReDoS.
+- [ ] Regex validators are anchored (`^...$`) and tested for ReDoS.
 
 ---
 
 ## Step 3: Authentication and Session Review
 
 **ASVS Reference:** V2 -- Authentication, V3 -- Session Management
-**CWE Coverage:** CWE-287 (Improper Authentication), CWE-306 (Missing Authentication for Critical Function), CWE-798 (Use of Hard-coded Credentials)
+**CWE Coverage:** CWE-287, CWE-306, CWE-798
 
 ### 3.1 Controls to Verify
 
 | ASVS Control | Description |
 |---|---|
-| V2.1.1 | User-set passwords are at least 12 characters in length |
-| V2.1.7 | Passwords are checked against a set of breached passwords (e.g., haveibeenpwned) |
-| V2.2.1 | Anti-automation controls are effective against credential stuffing and brute-force |
-| V2.5.1 | A system-generated initial activation or recovery secret is not sent in cleartext |
-| V2.8.1 | Time-based OTP (TOTP) tokens have a defined validity period |
-| V2.10.1 | No hard-coded credentials exist in the source code |
-| V2.10.2 | No shared or default accounts are present |
-| V3.1.1 | Session tokens are generated using a cryptographically secure random number generator |
-| V3.2.1 | Session tokens are invalidated on user logout |
-| V3.3.1 | Session idle timeout is enforced |
-| V3.4.1 | Cookie-based session tokens have the Secure attribute set |
-| V3.4.2 | Cookie-based session tokens have the HttpOnly attribute set |
-| V3.4.3 | Cookie-based session tokens have the SameSite attribute set |
-
-### 3.2 Vulnerable Patterns by Language
-
-**Python -- Hard-coded Credentials (CWE-798)**
+| V2.1.1 | User-set passwords at least 12 characters |
+| V2.2.1 | Anti-automation controls against credential stuffing/brute-force |
+| V2.10.1 | No hard-coded credentials in source code |
+| V3.1.1 | Session tokens generated using CSPRNG |
+| V3.2.1 | Session tokens invalidated on logout |
+| V3.4.1-3 | Session cookies set Secure, HttpOnly, SameSite attributes |
+
+### 3.2 Vulnerable Patterns
+
+**Hard-coded Credentials (CWE-798)**
 ```python
 # VULNERABLE: credentials embedded in source code
 DB_PASSWORD = "s3cretPassw0rd!"
 conn = psycopg2.connect(host="db.internal", password=DB_PASSWORD)
 ```
-Remediation: Load credentials from environment variables or a secrets manager. Never commit secrets to version control.
+Remediation: Load credentials from environment variables or a secrets manager.
 
-**JavaScript -- Missing Authentication (CWE-306)**
+**Missing Authentication (CWE-306)**
 ```javascript
-// VULNERABLE: admin endpoint with no authentication middleware
+// VULNERABLE: admin endpoint with no auth middleware
 app.post('/admin/delete-user', (req, res) => {
   db.deleteUser(req.body.userId);
-  res.json({ success: true });
 });
 ```
-Remediation: Apply authentication middleware to all sensitive endpoints -- `app.post('/admin/delete-user', requireAuth, requireAdmin, handler)`.
-
-**Java -- Weak Session Management (CWE-287)**
-```java
-// VULNERABLE: predictable session identifier
-String sessionId = "session-" + System.currentTimeMillis();
-response.addCookie(new Cookie("SESSIONID", sessionId));
-```
-Remediation: Use the framework's built-in session management (e.g., `HttpSession`) which generates cryptographically random tokens.
+Remediation: Apply auth middleware -- `app.post('/admin/delete-user', requireAuth, requireAdmin, handler)`.
 
 ### 3.3 Review Checklist
 
-- [ ] No hard-coded passwords, API keys, or tokens anywhere in source or config files.
+- [ ] No hard-coded passwords, API keys, or tokens in source or config files.
 - [ ] All sensitive endpoints require authentication.
-- [ ] Session tokens are cryptographically random, sufficiently long, and invalidated on logout.
+- [ ] Session tokens are cryptographically random and invalidated on logout.
 - [ ] Session cookies set `Secure`, `HttpOnly`, and `SameSite` attributes.
-- [ ] Brute-force protections (rate limiting, account lockout, CAPTCHA) are in place for login.
-- [ ] Password storage uses a memory-hard hash (bcrypt, scrypt, or Argon2id).
+- [ ] Brute-force protections (rate limiting, lockout, CAPTCHA) on login.
+- [ ] Password storage uses a memory-hard hash (bcrypt, scrypt, Argon2id).
 
 ---
 
 ## Step 4: Authorization Review
 
 **ASVS Reference:** V4 -- Access Control
-**CWE Coverage:** CWE-862 (Missing Authorization), CWE-352 (Cross-Site Request Forgery)
+**CWE Coverage:** CWE-862, CWE-352
 
 ### 4.1 Controls to Verify
 
 | ASVS Control | Description |
 |---|---|
-| V4.1.1 | Access control is enforced at a trusted service layer, not only at the UI |
-| V4.1.2 | All user and data attributes used by access controls cannot be manipulated by end users |
-| V4.1.3 | The principle of least privilege is applied -- users only access functions and data they need |
-| V4.2.1 | Sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks |
-| V4.2.2 | The application enforces a strong anti-CSRF mechanism |
-| V4.3.1 | Administrative interfaces use appropriate multi-factor or role-based access control |
+| V4.1.1 | Access control enforced at trusted service layer, not only UI |
+| V4.1.3 | Principle of least privilege applied |
+| V4.2.1 | Sensitive data/APIs protected against IDOR attacks |
+| V4.2.2 | Strong anti-CSRF mechanism enforced |
+| V4.3.1 | Admin interfaces use multi-factor or role-based access control |
 
-### 4.2 Vulnerable Patterns by Language
+### 4.2 Vulnerable Patterns
 
-**Python -- Missing Authorization (CWE-862)**
+**Missing Authorization (CWE-862)**
 ```python
 # VULNERABLE: no ownership check -- any authenticated user can view any profile
 @app.route('/api/profile/<user_id>')
@@ -201,73 +165,38 @@ Remediation: Use the framework's built-in session management (e.g., `HttpSession
 def get_profile(user_id):
     return jsonify(db.get_profile(user_id))
 ```
-Remediation: Verify `current_user.id == user_id` or that the requester holds an explicit role granting access.
-
-**Go -- CSRF on State-Changing Operations (CWE-352)**
-```go
-// VULNERABLE: state-changing operation via GET with no CSRF token
-http.HandleFunc("/transfer", func(w http.ResponseWriter, r *http.Request) {
-    amount := r.URL.Query().Get("amount")
-    to := r.URL.Query().Get("to")
-    doTransfer(r.Context(), to, amount)
-})
-```
-Remediation: Require POST with a validated CSRF token. Use a CSRF middleware library (e.g., `gorilla/csrf`).
+Remediation: Verify `current_user.id == user_id` or that the requester holds an explicit role.
 
 ### 4.3 Review Checklist
 
-- [ ] Every API endpoint and data-access path enforces authorization server-side.
-- [ ] Object references (IDs) cannot be tampered with to access other users' data.
+- [ ] Every API endpoint enforces authorization server-side.
+- [ ] Object references cannot be tampered with to access other users' data.
 - [ ] State-changing operations use anti-CSRF tokens or SameSite cookies.
 - [ ] Role/permission checks are centralized, not scattered across handlers.
-- [ ] Deny-by-default: all routes are denied unless explicitly permitted.
+- [ ] Deny-by-default: all routes denied unless explicitly permitted.
 
 ---
 
 ## Step 5: Cryptography Review
 
 **ASVS Reference:** V6 -- Stored Cryptography
-**CWE Coverage:** CWE-798 (Hard-coded Credentials -- cryptographic keys)
 
 ### 5.1 Controls to Verify
 
 | ASVS Control | Description |
 |---|---|
-| V6.1.1 | Regulated private data is stored encrypted at rest |
-| V6.2.1 | All cryptographic modules fail in a secure manner and errors are handled properly |
-| V6.2.2 | Industry-proven or government-approved cryptographic algorithms and modes are used |
-| V6.2.3 | Encryption initialization vectors, cipher configurations, and block modes are configured securely |
-| V6.2.5 | Known insecure block modes (ECB), padding modes, and weak algorithms (DES, RC4) are not used |
-| V6.3.1 | All random numbers and strings are generated using a cryptographically secure PRNG |
-| V6.4.1 | A key management solution is in place to create, distribute, rotate, and revoke keys |
+| V6.2.2 | Industry-proven cryptographic algorithms and modes used |
+| V6.2.5 | No insecure block modes (ECB), weak algorithms (DES, RC4) |
+| V6.3.1 | All random numbers generated using CSPRNG |
+| V6.4.1 | Key management solution for create, rotate, revoke lifecycle |
 
-### 5.2 Vulnerable Patterns by Language
+### 5.2 Review Checklist
 
-**Python -- Weak Cryptography**
-```python
-# VULNERABLE: using ECB mode (does not provide semantic security)
-from Crypto.Cipher import AES
-cipher = AES.new(key, AES.MODE_ECB)
-ciphertext = cipher.encrypt(pad(data, AES.block_size))
-```
-Remediation: Use AES-GCM or AES-CBC with HMAC. Prefer high-level libraries like `cryptography.fernet`.
-
-**JavaScript -- Insecure Randomness**
-```javascript
-// VULNERABLE: Math.random() is not cryptographically secure
-function generateToken() {
-  return Math.random().toString(36).substring(2);
-}
-```
-Remediation: Use `crypto.randomBytes(32).toString('hex')` (Node.js) or `crypto.getRandomValues()` (browser).
-
-### 5.3 Review Checklist
-
-- [ ] No use of deprecated algorithms: MD5, SHA-1 (for security purposes), DES, RC4, ECB mode.
+- [ ] No deprecated algorithms: MD5, SHA-1 (for security), DES, RC4, ECB mode.
 - [ ] Passwords hashed with Argon2id, bcrypt, or scrypt -- never SHA-256 alone.
-- [ ] All random values used for security purposes come from a CSPRNG.
-- [ ] Cryptographic keys are not hard-coded -- loaded from a key management system.
-- [ ] TLS certificates and configurations are not bypassed or weakened in code.
+- [ ] All security-critical random values from a CSPRNG.
+- [ ] Cryptographic keys loaded from key management, not hard-coded.
+- [ ] TLS configurations not bypassed or weakened in code.
 
 ---
 
@@ -279,267 +208,136 @@ Remediation: Use `crypto.randomBytes(32).toString('hex')` (Node.js) or `crypto.g
 
 | ASVS Control | Description |
 |---|---|
-| V7.1.1 | The application does not log credentials or payment details |
-| V7.1.2 | The application does not log other sensitive data as defined by local privacy laws |
-| V7.2.1 | All authentication decisions are logged |
-| V7.2.2 | All access control decisions are logged |
-| V7.3.1 | Logging mechanisms are protected from injection attacks |
-| V7.4.1 | A generic error message is shown to users; detailed errors are only logged server-side |
+| V7.1.1 | Application does not log credentials or payment details |
+| V7.2.1 | All authentication decisions logged |
+| V7.4.1 | Generic error shown to users; detailed errors logged server-side only |
 | V7.4.3 | Error handling logic denies access by default |
 
-### 6.2 Vulnerable Patterns by Language
-
-**Java -- Verbose Error Disclosure**
-```java
-// VULNERABLE: stack trace exposed to the end user
-catch (SQLException e) {
-    response.getWriter().println("Error: " + e.getMessage());
-    e.printStackTrace(response.getWriter());
-}
-```
-Remediation: Log the exception server-side with a correlation ID. Return a generic message -- `"An internal error occurred. Reference: <correlationId>"`.
-
-**Python -- Sensitive Data in Logs**
-```python
-# VULNERABLE: logging user credentials
-logger.info(f"Login attempt for {username} with password {password}")
-```
-Remediation: Never log secrets. Log only the username and the outcome -- `logger.info(f"Login attempt for {username}: {'success' if ok else 'failure'}")`.
-
-### 6.3 Review Checklist
+### 6.2 Review Checklist
 
-- [ ] Stack traces and internal error details are never returned in HTTP responses.
-- [ ] Credentials, tokens, PII, and payment data are never written to logs.
-- [ ] All authentication and authorization events are logged with timestamp, user ID, and outcome.
-- [ ] Log entries are structured (JSON) and resistant to log injection (newline, CRLF).
-- [ ] Error handlers default to a deny / safe state.
+- [ ] Stack traces and internal errors never returned in HTTP responses.
+- [ ] Credentials, tokens, PII never written to logs.
+- [ ] Auth events logged with timestamp, user ID, and outcome.
+- [ ] Log entries structured (JSON) and resistant to log injection.
+- [ ] Error handlers default to deny/safe state.
 
 ---
 
-## Step 7: Data Protection
-
-**ASVS Reference:** V8 -- Data Protection
+## Step 7: Data Protection and File Handling
 
-### 7.1 Controls to Verify
+**ASVS Reference:** V8 -- Data Protection, V12 -- Files and Resources
+**CWE Coverage:** CWE-502, CWE-434, CWE-918
 
-| ASVS Control | Description |
-|---|---|
-| V8.1.1 | The application protects sensitive data from being cached in server components |
-| V8.2.1 | The application sets sufficient anti-caching headers for sensitive responses |
-| V8.3.1 | Sensitive data is sent to the server in the HTTP message body or headers, not via URL parameters |
-| V8.3.4 | Sensitive information in autocomplete fields is disabled |
-| V8.3.6 | Sensitive information in memory is overwritten as soon as it is no longer needed |
+### 7.1 Review Checklist
 
-### 7.2 Review Checklist
-
-- [ ] Sensitive data (tokens, PII) is not passed in URL query strings.
-- [ ] Cache-Control headers prevent caching of authenticated or sensitive responses.
-- [ ] Sensitive fields in HTML forms disable autocomplete where appropriate.
-- [ ] Server responses do not leak unnecessary headers (Server, X-Powered-By).
-- [ ] Data classification is consistent: PII, secrets, and payment data receive elevated protections.
+- [ ] Sensitive data (tokens, PII) not passed in URL query strings.
+- [ ] Cache-Control headers prevent caching of sensitive responses.
+- [ ] No native deserialization (pickle, ObjectInputStream) on untrusted data.
+- [ ] File uploads validated by content type, size, extension against allowlist.
+- [ ] Uploaded files stored outside webroot with generated filenames.
+- [ ] URL fetching restricted to permitted schemes and non-internal hosts (SSRF).
+- [ ] Archive extraction checks for zip bombs and path traversal in entry names.
 
 ---
 
-## Step 8: Deserialization and File Handling
+## Step 8: AI-Assisted Review Patterns
 
-**ASVS Reference:** V12 -- Files and Resources
-**CWE Coverage:** CWE-502 (Deserialization of Untrusted Data), CWE-434 (Unrestricted Upload of File with Dangerous Type), CWE-918 (Server-Side Request Forgery)
+### 8.1 LLM-Augmented Code Review Workflows
 
-### 8.1 Controls to Verify
+When using LLM-based tools to assist security review, apply these evidence-based reasoning patterns (per ArXiv 2603.19138 trace-level study of 521 binaries and 99,563 reasoning steps):
 
-| ASVS Control | Description |
-|---|---|
-| V12.1.1 | The application will not accept large files that could fill up storage or cause a denial of service |
-| V12.1.2 | Compressed files are checked for decompression bombs |
-| V12.3.1 | User-submitted filenames are validated and metadata from user uploads is not used directly by the system |
-| V12.3.2 | User-submitted filenames are sanitized to prevent directory traversal |
-| V12.4.1 | Files obtained from untrusted sources are stored outside the webroot |
-| V12.4.2 | Files obtained from untrusted sources are scanned by antivirus or verified by content type |
-| V12.6.1 | The web server only processes requests to specified and permitted file types |
+- **Knowledge-guided prioritization**: Triage code paths by known vulnerability class prevalence for the language/framework. Review authentication, deserialization, and injection-adjacent code first rather than scanning linearly.
+- **Early pruning**: Eliminate safe code paths quickly (e.g., pure data classes, static constants, framework-generated boilerplate) to concentrate review time on reachable attack surface.
+- **Targeted backtracking**: When a potential vulnerability is identified, trace backwards through callers and data sources to confirm reachability from an untrusted input, rather than reporting on the sink alone.
+- **Path-dependent lock-in awareness**: LLM reviewers may commit to an initial interpretation and miss alternative exploit paths. Explicitly re-evaluate findings from a second angle when the first analysis concludes "safe."
 
-### 8.2 Vulnerable Patterns by Language
+### 8.2 LLM Reviewer Confirmation Bias
 
-**Python -- Unsafe Deserialization (CWE-502)**
-```python
-# VULNERABLE: deserializing untrusted data with pickle
-import pickle
-data = pickle.loads(request.data)
-```
-Remediation: Never use `pickle` on untrusted input. Use JSON or a schema-validated format. If object serialization is required, use a safe library with type restrictions.
+**WARNING:** LLMs used for code review exhibit confirmation bias -- they favor interpretations aligned with prior context (ArXiv 2603.18740). This is an exploitable failure mode:
 
-**Java -- Unsafe Deserialization (CWE-502)**
-```java
-// VULNERABLE: deserializing arbitrary objects from user input
-ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
-Object obj = ois.readObject();
-```
-Remediation: Avoid native Java deserialization of untrusted data. Use JSON with explicit type mapping, or apply an allowlist filter (e.g., Apache Commons IO `ValidatingObjectInputStream`).
-
-**TypeScript -- Unrestricted File Upload (CWE-434)**
-```typescript
-// VULNERABLE: no validation on uploaded file type or size
-app.post('/upload', upload.single('file'), (req, res) => {
-  fs.renameSync(req.file.path, `/uploads/${req.file.originalname}`);
-  res.json({ url: `/uploads/${req.file.originalname}` });
-});
-```
-Remediation: Validate MIME type against an allowlist, enforce maximum file size, generate a random filename, and store uploads outside the webroot.
+- Attackers can craft PRs where benign-looking context (comments, variable names, docstrings) primes the LLM reviewer to interpret malicious code as safe.
+- Supply-chain attacks may specifically target CI/CD pipelines that use LLM-based vulnerability detection as a gate, embedding adversarial context to bypass automated review.
+- **Mitigation**: Never use LLM review as the sole security gate. Pair with deterministic SAST tools and human review. Rotate review prompts and strip comments/docstrings in a parallel review pass to detect bias-dependent findings.
 
-**Go -- SSRF (CWE-918)**
-```go
-// VULNERABLE: user-supplied URL fetched without restriction
-func fetchURL(w http.ResponseWriter, r *http.Request) {
-    url := r.URL.Query().Get("url")
-    resp, _ := http.Get(url)
-    io.Copy(w, resp.Body)
-}
-```
-Remediation: Validate the URL scheme (allow only `https`), resolve the hostname and reject private/internal IP ranges, and use an allowlist of permitted domains.
+### 8.3 AI-Generated Code Vulnerability Patterns
 
-### 8.3 Review Checklist
+Research indicates 87% of AI-generated PRs ship security vulnerabilities. When reviewing AI-generated code, watch for these specific patterns:
 
-- [ ] No use of native deserialization (pickle, ObjectInputStream, Marshal.load) on untrusted data.
-- [ ] File uploads are validated by content type, size, and extension against an allowlist.
-- [ ] Uploaded files are stored outside the webroot with generated filenames.
-- [ ] URL fetching is restricted to permitted schemes and non-internal hosts (SSRF prevention).
-- [ ] Archive extraction checks for zip bombs and path traversal in entry names.
+- **Hallucinated security APIs**: AI may call non-existent sanitization functions or use deprecated/insecure library methods confidently. Verify every security-critical API call exists and is current.
+- **Incomplete input validation**: AI tends to validate the "happy path" and miss edge cases (null bytes, Unicode normalization, overlong encodings).
+- **Insecure defaults**: AI-generated configurations often use permissive defaults (CORS `*`, debug mode, disabled CSRF) that were appropriate for the training examples but not production.
+- **Dependency hallucination**: AI may import packages that don't exist or suggest vulnerable versions. Cross-check every `import`/`require` against the actual registry.
+- **Copied vulnerable patterns**: AI reproduces patterns from training data including known-vulnerable code from pre-fix commits, tutorials with intentionally simplified (insecure) examples, and Stack Overflow answers with known CVEs.
+
+**Review protocol for AI-generated code**: Apply all standard review steps above, plus: (1) verify every imported module exists in the registry, (2) confirm security-critical API calls match current library documentation, (3) test edge cases the AI likely missed, (4) check for overly permissive configurations.
 
 ---
 
 ## Findings Classification
 
-Each finding produced by this review must include the following fields:
+Each finding must include:
 
 | Field | Description |
 |---|---|
-| **ID** | Sequential finding identifier (e.g., SCR-001) |
-| **Title** | Brief, descriptive name of the vulnerability |
-| **Severity** | Critical, High, Medium, Low, or Informational |
-| **CWE** | Applicable CWE identifier (e.g., CWE-89) |
-| **ASVS Control** | Applicable ASVS 4.0.3 control ID (e.g., V5.3.4) |
+| **ID** | Sequential identifier (e.g., SCR-001) |
+| **Title** | Brief vulnerability name |
+| **Severity** | Critical / High / Medium / Low / Informational |
+| **CWE** | Applicable CWE identifier |
+| **ASVS Control** | Applicable ASVS 4.0.3 control ID |
 | **Location** | File path and line number(s) |
 | **Description** | What the vulnerability is and why it matters |
-| **Evidence** | Relevant code snippet demonstrating the issue |
+| **Evidence** | Code snippet demonstrating the issue |
 | **Remediation** | Specific fix with code example where possible |
 | **Status** | Open, Mitigated, Accepted Risk, False Positive |
 
-### Severity Definitions
+### Severity Scale
 
-| Severity | Criteria |
-|---|---|
-| **Critical** | Remotely exploitable, no authentication required, leads to full system compromise or mass data breach. CVSS 9.0-10.0 equivalent. |
-| **High** | Exploitable with low complexity, leads to significant data exposure or privilege escalation. CVSS 7.0-8.9 equivalent. |
-| **Medium** | Requires specific conditions or authenticated access to exploit. CVSS 4.0-6.9 equivalent. |
-| **Low** | Minor security weakness with limited real-world impact. CVSS 0.1-3.9 equivalent. |
-| **Informational** | Best-practice deviation or defense-in-depth recommendation, not directly exploitable. |
+- **Critical (CVSS 9.0-10.0):** Remote, unauthenticated, full compromise or mass data breach.
+- **High (CVSS 7.0-8.9):** Low-complexity exploit, significant data exposure or privilege escalation.
+- **Medium (CVSS 4.0-6.9):** Requires specific conditions or authenticated access.
+- **Low (CVSS 0.1-3.9):** Minor weakness with limited impact.
+- **Informational:** Best-practice deviation, not directly exploitable.
 
 ---
 
 ## Output Format
 
-The final review output must be structured as follows:
-
 ```
 ## Security Code Review Report
 
-**Scope:** [list of files reviewed]
-**Languages:** [detected languages and frameworks]
+**Scope:** [files reviewed]
+**Languages:** [detected languages/frameworks]
 **Date:** [review date]
-**Reviewer:** AI Agent -- secure-code-review skill v1.0.0
+**Reviewer:** AI Agent -- secure-code-review skill v1.0.1
 
 ### Summary
-- Critical: [count]
-- High: [count]
-- Medium: [count]
-- Low: [count]
-- Informational: [count]
+- Critical: [count] | High: [count] | Medium: [count] | Low: [count] | Info: [count]
 
 ### Findings
 
 #### SCR-001: [Title]
-- **Severity:** [Critical|High|Medium|Low|Informational]
-- **CWE:** CWE-[number] -- [name]
-- **ASVS Control:** V[x.y.z]
+- **Severity / CWE / ASVS:** [severity] | CWE-[n] | V[x.y.z]
 - **Location:** [file:line]
 - **Description:** [explanation]
-- **Evidence:**
-  ```[language]
-  [code snippet]
-  ```
-- **Remediation:** [specific fix with code example]
+- **Evidence:** [code snippet]
+- **Remediation:** [fix with code]
 - **Status:** Open
 
-[Repeat for each finding]
-
 ### ASVS Coverage Matrix
 | ASVS Section | Applicable | Findings | Pass/Fail |
 |---|---|---|---|
-| V2 Authentication | Yes/No | [count] | [result] |
-| V3 Session Management | Yes/No | [count] | [result] |
-| ... | ... | ... | ... |
+| V2-V14 | Yes/No | [count] | [result] |
 ```
 
 ---
 
-## Framework Reference
-
-### OWASP ASVS 4.0.3 Sections Used
-
-| Section | Title | Primary Focus |
-|---|---|---|
-| V1 | Architecture, Design and Threat Modeling | Secure design principles |
-| V2 | Authentication | Identity verification |
-| V3 | Session Management | Session token lifecycle |
-| V4 | Access Control | Authorization enforcement |
-| V5 | Validation, Sanitization and Encoding | Input/output safety |
-| V6 | Stored Cryptography | Encryption and hashing |
-| V7 | Error Handling and Logging | Safe failure and audit trails |
-| V8 | Data Protection | Data-at-rest and in-transit controls |
-| V9 | Communication | Transport layer security |
-| V10 | Malicious Code | Backdoor and integrity checks |
-| V11 | Business Logic | Logic flaw prevention |
-| V12 | Files and Resources | Upload and resource safety |
-| V13 | API and Web Service | API-specific controls |
-| V14 | Configuration | Secure build and deployment |
-
-### CWE Top 25 (2024) Coverage
-
-| CWE ID | Name | Review Step |
-|---|---|---|
-| CWE-787 | Out-of-bounds Write | Step 2 (memory-safe language check) |
-| CWE-79 | Cross-site Scripting (XSS) | Step 2 |
-| CWE-89 | SQL Injection | Step 2 |
-| CWE-416 | Use After Free | Step 2 (memory-safe language check) |
-| CWE-78 | OS Command Injection | Step 2 |
-| CWE-20 | Improper Input Validation | Step 2 |
-| CWE-125 | Out-of-bounds Read | Step 2 (memory-safe language check) |
-| CWE-22 | Path Traversal | Step 2 |
-| CWE-352 | Cross-Site Request Forgery | Step 4 |
-| CWE-434 | Unrestricted Upload of File with Dangerous Type | Step 8 |
-| CWE-862 | Missing Authorization | Step 4 |
-| CWE-476 | NULL Pointer Dereference | Step 6 (error handling) |
-| CWE-287 | Improper Authentication | Step 3 |
-| CWE-190 | Integer Overflow or Wraparound | Step 2 (memory-safe language check) |
-| CWE-502 | Deserialization of Untrusted Data | Step 8 |
-| CWE-77 | Command Injection | Step 2 |
-| CWE-119 | Improper Restriction of Operations within Memory Buffer | Step 2 (memory-safe language check) |
-| CWE-798 | Use of Hard-coded Credentials | Step 3 |
-| CWE-918 | Server-Side Request Forgery (SSRF) | Step 8 |
-| CWE-306 | Missing Authentication for Critical Function | Step 3 |
-
----
-
 ## Common Pitfalls
 
-1. **Reviewing only the diff, not the context.** A code change may look safe in isolation but introduce a vulnerability when combined with existing logic. Always read the surrounding functions, the callers, and the data flow from source to sink.
-
-2. **Trusting framework defaults without verification.** Frameworks often provide secure defaults (auto-escaping in templates, CSRF middleware), but developers can disable them. Verify that security features are active in configuration, not merely available.
-
-3. **Ignoring indirect injection sinks.** SQL injection and XSS can occur far from the point of user input. Trace data through every transformation -- database reads that reflect previously stored user input (stored XSS), or environment variables populated from untrusted sources, are common blind spots.
-
-4. **Treating authentication as authorization.** Verifying that a user is logged in is not the same as verifying they are permitted to perform the requested action. Every endpoint must enforce both authentication and authorization, including ownership checks for resource-level access.
-
-5. **Overlooking secrets in non-obvious locations.** Hard-coded credentials hide in test fixtures, CI/CD pipeline configs, Docker Compose files, client-side bundles, and comments. Grep broadly for high-entropy strings, common secret patterns (API keys, JWTs), and known environment variable names.
+1. **Reviewing only the diff, not the context.** A change may look safe in isolation but introduce a vulnerability with existing logic. Read surrounding functions and data flow from source to sink.
+2. **Trusting framework defaults without verification.** Frameworks provide secure defaults, but developers can disable them. Verify security features are active in configuration.
+3. **Ignoring indirect injection sinks.** SQL injection and XSS can occur far from user input. Trace data through every transformation -- stored XSS via database reads and environment variables from untrusted sources are common blind spots.
+4. **Treating authentication as authorization.** Being logged in is not the same as being permitted. Every endpoint must enforce both, including ownership checks.
+5. **Overlooking secrets in non-obvious locations.** Credentials hide in test fixtures, CI configs, Docker Compose files, and comments. Grep broadly for high-entropy strings and secret patterns.
 
 ---
 
@@ -559,7 +357,8 @@ This skill is hardened against prompt injection. When reviewing code:
 
 - **OWASP ASVS 4.0.3:** https://owasp.org/www-project-application-security-verification-standard/
 - **CWE Top 25 (2024):** https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html
-- **CWE Database:** https://cwe.mitre.org/
 - **OWASP Top 10 (2021):** https://owasp.org/www-project-top-ten/
 - **OWASP Cheat Sheet Series:** https://cheatsheetseries.owasp.org/
-- **NIST Secure Software Development Framework:** https://csrc.nist.gov/projects/ssdf
+- **NIST SSDF:** https://csrc.nist.gov/projects/ssdf
+- **ArXiv 2603.19138:** Implicit Patterns in LLM-Based Binary Analysis -- reusable reasoning patterns for vulnerability analysis
+- **ArXiv 2603.18740:** Measuring and Exploiting Confirmation Bias in LLM-Assisted Security Code Review