## Existing Defense Refutation (Kill Mandate)

> Your goal is to refute the defect report. Only conclusive code evidence can refute.
> Core question: detection reported a vulnerability or defect, but an effective defense mechanism already exists in the code that was overlooked. This includes manually written defenses and framework built-in defenses.

### Applicable Scenarios

- Security vulnerability related defects (injection, XSS, path traversal, SSRF, CSRF, deserialization)
- Concurrency issue related defects (race conditions, data races)
- Exception handling related defects (uncaught exceptions, exception information leakage)
- Resource management related defects (resource leaks, connections not closed)

### Refutation Process

1. **Locate defense positions**: Search for defense mechanisms on the Source→Sink path (for security vulnerabilities) or around the problematic code
2. **Evaluate defense effectiveness**: Whitelist + type conversion is usually effective; blacklist replacement is easily bypassed
3. **Determination**: Found effective defense → Kill; Defense is bypassable → Not refuted; No defense → Not refuted

### Refutation Patterns

#### Security Defenses

| Defense Type | Search Command | Effectiveness Judgment |
|---------|---------|-----------|
| Input validation | `Grep` to search for `whitelist`/`allowedValues`/`enum`/`zod`/`joi`/`class-validator` | Whitelist + type conversion → Effective → Kill |
| Parameterized queries | `Read` to check whether queries use parameterization: `db.query("... WHERE id = ?", [id])`, ORM `.where({field: value})` | Parameterized → Effective → Kill |
| Output encoding | `Grep` to search for `escapeHtml()`/`encodeURIComponent()`/`encodeForHTML()`/`DOMPurify.sanitize()` | Well-known library encoding → Effective → Kill |
| Sanitization functions | `Grep` to search for `sanitize()`/`escape()`/`strip_tags()` | Well-known library (DOMPurify, Bleach) → Effective; Custom regex → Needs judgment |

**Tool chain**:
- For security vulnerabilities: First `Read` to get the complete Source→Sink path, then `Grep` to search for defenses on the path

#### Concurrency Defenses

| Defense Type | Search Command | Effectiveness Judgment |
|---------|---------|-----------|
| Lock mechanisms | `Grep` to search for `synchronized`/`Lock`/`ReentrantLock`/`mutex`/`RLock`/`sync.Mutex` | Protects the contested region → Kill |
| Atomic operations | `Grep` to search for atomic updates: `UPDATE ... SET count = count - 1`, `INCR`/`DECR`/`SETNX` | Operation is atomic → Kill |
| Optimistic locking | `Grep` to search for `@Version`/`version` fields/CAS operations | Optimistic lock coverage → Kill |

#### Exception Handling Defenses

| Defense Type | Search Command | Effectiveness Judgment |
|---------|---------|-----------|
| Global exception handler | `Grep` to search for `@ControllerAdvice`/`@ExceptionHandler`/`app.use((err, req, res, next) =>`/`ErrorHandler` | Global catch → Kill |
| Compensation/rollback logic | `Grep` to search for `rollback`/`compensate`/`undo`/`revert` | Compensation covers all failure paths → Kill |
| finally cleanup | `Read` to check cleanup logic in `finally` blocks | finally coverage → Kill |

#### Resource Management Defenses

| Defense Type | Search Command | Effectiveness Judgment |
|---------|---------|-----------|
| try-with-resources | `Grep` to search for `try (` + resource declaration | Auto-close → Kill |
| using declaration | `Grep` to search for `using (`/`using var` | Auto-Dispose → Kill |
| defer release | `Grep` to search for `defer ` + resource release call | Delayed release → Kill |
| RAII/smart pointers | `Grep` to search for `std::unique_ptr`/`std::shared_ptr`/`std::make_unique` | Destructor auto-release → Kill |

#### Framework Built-in Defenses

Security protections automatically provided by frameworks, which detection often overlooks:

| Framework Defense | Identification Method | Determination |
|---------|---------|------|
| React JSX auto-escaping | `Read` to check whether JSX syntax `{variable}` is used (not `dangerouslySetInnerHTML`) | JSX defaults to escaping → Kill |
| Vue template auto-escaping | `Read` to check whether `{{ variable }}` is used (not `v-html`) | Template defaults to escaping → Kill |
| Angular auto-escaping | `Read` to check whether `{{ variable }}` is used (not `[innerHTML]` + `DomSanitizer`) | Default escaping → Kill |
| ORM auto-parameterization | `Read` to check ORM usage (standard queries in Sequelize/TypeORM/Hibernate) | ORM parameterization → Kill |
| Connection pool auto-management | `Read` to check connection pool configuration (return rather than close) | Connection pool management → Kill |
| Framework transaction management | `Grep` to search for `@Transactional`/`@transactional`/`atomic()` and confirm it takes effect at the Service layer | Framework transaction → Kill |
| CSRF protection | `Grep` to search for CSRF token mechanisms (Spring Security, Django CSRF middleware) | Framework CSRF → Kill |
| Security middleware | `Grep` to search for `helmet()`/`Django security middleware`/`CSP headers` | Security middleware → Kill |

### Refutation Determination Rules

- **Kill condition**: Found an effective defense mechanism on the problem path, and that defense can indeed prevent the defect from being triggered
- **Not refuted condition**: No defense found, or the found defense can be bypassed (e.g., blacklist replacement, partial parameterization)
- **Downgrade Kill**: Defense is only effective under specific conditions (e.g., requires admin permission to trigger) → Downgrade severity rather than Kill

### Degradation Strategy

- When tools are unavailable, judge based only on already-read code context
- When unable to confirm defense effectiveness, mark "defense not fully verified", this strategy is determined as "not refuted"
