# Security Vulnerability Response

Detailed procedures for responding to CVEs and security advisories.

## CVE Severity Classification

### CVSS Score Interpretation

| Score Range | Severity | Description |
|-------------|----------|-------------|
| 9.0 - 10.0 | **Critical** | Exploitable remotely, no authentication required, complete system compromise |
| 7.0 - 8.9 | **High** | Significant impact, may require some conditions |
| 4.0 - 6.9 | **Medium** | Limited impact or requires significant preconditions |
| 0.1 - 3.9 | **Low** | Minimal impact, difficult to exploit |

### Response Time Requirements

| Severity | Assessment | Remediation | Verification |
|----------|------------|-------------|--------------|
| Critical | 1 hour | 24 hours | Same day |
| High | 4 hours | 7 days | Within 48 hours |
| Medium | 24 hours | 30 days | Within 1 week |
| Low | 1 week | 90 days | Next release |

## Vulnerability Assessment Checklist

### Step 1: Confirm Affected

```bash
# Check if package is in your dependencies
npm ls <package-name>
# or
yarn why <package-name>
# or
pnpm why <package-name>
```

Questions to answer:
- [ ] Is the vulnerable version in our lock file?
- [ ] Is it a direct or transitive dependency?
- [ ] Is the vulnerable code path actually used in our application?

### Step 2: Analyze Attack Vector

Review the CVE details:

| Vector | Questions |
|--------|-----------|
| **Network** | Is the package exposed to network input? |
| **Local** | Can attackers access local filesystem? |
| **User Input** | Does user-controlled data reach the vulnerable code? |
| **Authentication** | Is the vulnerable path behind auth? |

### Step 3: Determine If Exploitable

Common scenarios where you may NOT be affected:
- Package is dev-only (`devDependencies`) and not in production build
- Vulnerable function is never called in your code
- Input to vulnerable function is always sanitized
- Network path to vulnerable code doesn't exist

**Document your reasoning** - "Not affected because X" is a valid conclusion, but must be evidenced.

## Patch Availability Assessment

### Patch Available

1. Check package changelog/releases
2. Verify fix is in latest version
3. Check compatibility with your version constraints
4. Plan upgrade using main workflow

### No Patch Available

If no official patch exists:

1. **Check for pre-release/beta with fix**
   ```bash
   npm view <package> versions --json | tail -20
   ```

2. **Check for fork with patch**
   - Search GitHub issues for the CVE
   - Look for community forks

3. **Evaluate alternatives**
   - Can you replace the package?
   - What's the migration effort?

4. **Implement temporary mitigation** (see below)

## Temporary Mitigations

When immediate patch isn't available:

### Input Validation

Add validation before vulnerable function:
```typescript
// Before using vulnerable library function
function sanitizeInput(input: unknown): SafeInput {
  // Validate and sanitize based on CVE details
  // Return safe version or throw
}
```

### Feature Disable

Disable vulnerable feature if non-critical:
```typescript
// Feature flag to disable vulnerable code path
if (config.FEATURE_X_ENABLED && !config.CVE_MITIGATION_MODE) {
  // Use vulnerable feature
}
```

### Network Isolation

If network-exploitable:
- Add WAF rules
- Rate limiting
- IP allowlisting

### Dependency Pinning

Lock to last known safe version:
```json
{
  "resolutions": {
    "vulnerable-package": "1.2.3"
  }
}
```

## Documentation Template

When documenting CVE response:

```markdown
## CVE-YYYY-XXXXX Response

**Package:** package-name@version
**Severity:** Critical/High/Medium/Low (CVSS: X.X)
**Discovered:** YYYY-MM-DD
**Resolved:** YYYY-MM-DD

### Assessment
- [ ] Confirmed affected: Yes/No
- [ ] Attack vector applicable: Yes/No
- [ ] Evidence: [link or explanation]

### Resolution
- [ ] Patch applied: version X.Y.Z
- [ ] Mitigation applied: [description]
- [ ] Verified: [test results]

### Timeline
- HH:MM - CVE detected
- HH:MM - Assessment complete
- HH:MM - Patch/mitigation applied
- HH:MM - Verification complete
```

## Automation Setup

### Continuous Monitoring

```yaml
# GitHub Actions example
name: Security Audit
on:
  schedule:
    - cron: '0 6 * * *'  # Daily at 6 AM
  push:
    paths:
      - '**/package-lock.json'
      - '**/yarn.lock'
      - '**/pnpm-lock.yaml'

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm audit --audit-level=high
```

### Alert Thresholds

Configure alerts based on severity:

| Severity | Alert Channel | Escalation |
|----------|--------------|------------|
| Critical | PagerDuty + Slack | Immediate |
| High | Slack #security | 4 hours |
| Medium | Daily digest | Weekly review |
| Low | Monthly report | Quarterly |

## Common Vulnerability Types

### Prototype Pollution

**Symptoms:** Objects gain unexpected properties
**Check:** Does library merge user input into objects?
**Mitigation:** Freeze prototypes, validate input shape

### ReDoS (Regular Expression DoS)

**Symptoms:** Regex hangs on crafted input
**Check:** Does library use regex on user input?
**Mitigation:** Input length limits, timeout

### Path Traversal

**Symptoms:** File access outside intended directory
**Check:** Does library handle file paths from user input?
**Mitigation:** Validate paths, use allowlists

### Command Injection

**Symptoms:** Shell commands executed with user input
**Check:** Does library spawn processes with user data?
**Mitigation:** Escape inputs, use parameterized commands

## Resources

- [NVD - National Vulnerability Database](https://nvd.nist.gov/)
- [GitHub Advisory Database](https://github.com/advisories)
- [Snyk Vulnerability Database](https://snyk.io/vuln/)
- [npm Security Advisories](https://www.npmjs.com/advisories)