Action Guidelines

Action Guidelines

Decision Tree for CVE Recommendations

Use this decision tree to determine the appropriate action for each CVE.

START
  │
  ├─ Risk Score ≥ 80 (Critical)?
  │   └─ YES → IMMEDIATE UPGRADE
  │
  ├─ Risk Score 60-79 (High)?
  │   ├─ Fix available?
  │   │   ├─ YES → UPGRADE WITHIN DAYS
  │   │   └─ NO → APPLY MITIGATION + MONITOR
  │   │
  │   └─ Breaking changes in fix?
  │       ├─ YES → EVALUATE MITIGATION OPTIONS
  │       └─ NO → UPGRADE WITHIN DAYS
  │
  ├─ Risk Score 40-59 (Medium)?
  │   ├─ Reachable?
  │   │   ├─ YES → UPGRADE IN NEXT CYCLE
  │   │   └─ NO → MONITOR
  │   │
  │   └─ Exploit available?
  │       ├─ YES → UPGRADE WITHIN WEEKS
  │       └─ NO → MONITOR
  │
  ├─ Risk Score 20-39 (Low)?
  │   └─ MONITOR OR DEFER
  │
  └─ Risk Score < 20 (Minimal)?
      └─ IGNORE WITH JUSTIFICATION

Action Types

1. Immediate Upgrade (P0)

When to use:

• Risk score ≥ 80
• Critical severity + reachable + exploit available
• Active exploitation in the wild
• Zero-day with high impact

Recommendation template:

**Action**: Immediate upgrade required

**Urgency**: Critical - Address within 24-48 hours

**Steps**:
1. Upgrade `<package>` from `<current_version>` to `<fixed_version>`
2. Run full test suite to verify compatibility
3. Deploy to production with rollback plan ready
4. Monitor for any issues post-deployment

**Command**:
```bash
# npm
npm install <package>@<fixed_version>

# pip
pip install <package>==<fixed_version>

# maven
# Update pom.xml: <version><fixed_version></version>

Risk if not addressed:

### 2. Upgrade Within Days (P1)

**When to use:**
- Risk score 60-79
- High severity + reachable
- Public exploit available but not actively exploited
- Core dependency affected

**Recommendation template:**
```markdown
**Action**: Upgrade within 3-5 days

**Urgency**: High - Schedule upgrade in current sprint

**Steps**:
1. Review changelog for breaking changes
2. Upgrade `<package>` from `<current_version>` to `<fixed_version>`
3. Update dependent code if needed
4. Test thoroughly before deployment

**Breaking changes**: <list any breaking changes>

**Command**:
```bash
<upgrade command>

Alternative: If upgrade blocked, apply mitigation (see below)

### 3. Upgrade in Next Cycle (P2)

**When to use:**
- Risk score 40-59
- Medium severity + reachable
- No immediate exploit threat
- Non-critical dependency

**Recommendation template:**
```markdown
**Action**: Upgrade in next maintenance cycle

**Urgency**: Medium - Include in next release (2-4 weeks)

**Steps**:
1. Add to backlog for next sprint/release
2. Upgrade `<package>` from `<current_version>` to `<fixed_version>`
3. Test as part of regular QA process

**Command**:
```bash
<upgrade command>

Monitoring: Track for exploit developments

### 4. Monitor but Defer (P3)

**When to use:**
- Risk score 20-39
- Low severity or not reachable
- Theoretical vulnerability
- Development-only dependency

**Recommendation template:**
```markdown
**Action**: Monitor but defer upgrade

**Urgency**: Low - Address when convenient

**Rationale**: <why deferring is acceptable>
- Not reachable in production code
- Low severity with no known exploits
- Development-only dependency

**Monitoring plan**:
- Check monthly for exploit developments
- Re-evaluate if exploit becomes available
- Upgrade during next major version bump

**Command** (when ready):
```bash
<upgrade command>

### 5. Ignore with Justification (P4)

**When to use:**
- Risk score < 20
- Not reachable (confirmed)
- False positive
- Requires impractical attack conditions
- Effective compensating controls in place

**Recommendation template:**
```markdown
**Action**: Ignore (with justification)

**Rationale**: <specific reason>
- Vulnerable code path is not reachable
- Requires physical access / impractical conditions
- False positive (confirmed by security team)
- Effective mitigations already in place

**Compensating controls** (if applicable):
- <list existing mitigations>

**Documentation**: Add to security exceptions log

6. Apply Mitigation or Workaround (Alternative to Upgrade)

When to use:

• Upgrade blocked (breaking changes, compatibility issues)
• No fix available yet
• Temporary measure while planning upgrade

Recommendation template:

**Action**: Apply mitigation (temporary)

**Urgency**: <based on risk score>

**Mitigation options**:

1. **Configuration change**:

2. Code-level workaround:

   <code changes to avoid vulnerable path>
   

3. Network-level protection:

   • Add WAF rule:
   • Restrict access:

4. Input validation:

   <validation code>
   

Effectiveness:

Long-term plan: Upgrade to <fixed_version> when feasible

## Special Cases

### Case 1: No Fix Available

```markdown
**Action**: Apply mitigation + Monitor for fix

**Status**: No fix available yet

**Mitigation**:
<temporary mitigation steps>

**Monitoring**:
- Check weekly for security updates
- Subscribe to security advisories
- Consider alternative packages if fix delayed

**Escalation**: If no fix within 30 days, evaluate alternatives

Case 2: Breaking Changes in Fix

**Action**: Evaluate upgrade path

**Issue**: Fix version contains breaking changes

**Options**:
1. **Accept breaking changes**: Upgrade and refactor code
   - Estimated effort: <hours/days>
   - Risk: <refactoring risks>

2. **Apply mitigation**: Keep current version with workaround
   - Mitigation: <specific mitigation>
   - Risk: <residual risk>

3. **Partial upgrade**: Upgrade to intermediate version
   - Version: <intermediate_version>
   - Trade-offs: <what's gained/lost>

**Recommendation**: <preferred option with rationale>

Case 3: Transitive Dependency

**Action**: Upgrade parent dependency

**Issue**: CVE in transitive dependency `<package>`

**Root cause**: Pulled in by `<parent_package>@<version>`

**Solution**:
1. Upgrade `<parent_package>` to `<fixed_version>` (includes fixed transitive dep)
2. Or: Add explicit dependency override
   ```bash
   # npm
   npm install <package>@<fixed_version>

   # pip requirements.txt
   <package>==<fixed_version>  # override transitive

Verification:

# Check resolved version
npm ls <package>
pip show <package>

### Case 4: Multiple CVEs in Same Package

```markdown
**Action**: Single upgrade addresses multiple CVEs

**CVEs addressed**: CVE-XXXX-YYYY, CVE-XXXX-ZZZZ, ...

**Upgrade**: `<package>` from `<current>` to `<fixed>`

**Combined risk score**: <highest individual score>

**Priority**: <based on highest risk CVE>

**Note**: Single upgrade resolves all listed CVEs

Recommendation Priority Matrix

Validation Checklist

Before finalizing recommendation:

• Risk score calculated correctly
• Reachability confirmed (not assumed)
• Fix version verified to address CVE
• Breaking changes documented
• Upgrade command tested (if possible)
• Mitigation effectiveness validated
• Timeline realistic for team capacity
• Justification clear and documented