# Action Guidelines > Use this decision tree to determine the appropriate action for each CVE. - Skill: `tools-only/action-guidelines` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/action-guidelines` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/action-guidelines/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-29 - Page: https://skillmd.com/skills/tools-only/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:** ```markdown **Action**: Immediate upgrade required **Urgency**: Critical - Address within 24-48 hours **Steps**: 1. Upgrade `` from `` to `` 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 @ # pip pip install == # maven # Update pom.xml: ``` **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 `` from `` to `` 3. Update dependent code if needed 4. Test thoroughly before deployment **Breaking changes**: **Command**: ```bash ``` **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 `` from `` to `` 3. Test as part of regular QA process **Command**: ```bash ``` **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**: - 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 ``` ``` ### 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**: - 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): - **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:** ```markdown **Action**: Apply mitigation (temporary) **Urgency**: **Mitigation options**: 1. **Configuration change**: ``` ``` 2. **Code-level workaround**: ```


   ```

3. **Network-level protection**:
   - Add WAF rule: 
   - Restrict access: 

4. **Input validation**:
   ```
   
   ```

**Effectiveness**: 

**Long-term plan**: Upgrade to `` when feasible
```

## Special Cases

### Case 1: No Fix Available

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

**Status**: No fix available yet

**Mitigation**:


**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

```markdown
**Action**: Evaluate upgrade path

**Issue**: Fix version contains breaking changes

**Options**:
1. **Accept breaking changes**: Upgrade and refactor code
   - Estimated effort: 
   - Risk: 

2. **Apply mitigation**: Keep current version with workaround
   - Mitigation: 
   - Risk: 

3. **Partial upgrade**: Upgrade to intermediate version
   - Version: 
   - Trade-offs: 

**Recommendation**: 
```

### Case 3: Transitive Dependency

```markdown
**Action**: Upgrade parent dependency

**Issue**: CVE in transitive dependency ``

**Root cause**: Pulled in by `@`

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

   # pip requirements.txt
   ==  # override transitive
   ```

**Verification**:
```bash
# Check resolved version
npm ls 
pip show 
```
```

### Case 4: Multiple CVEs in Same Package

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

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

**Upgrade**: `` from `` to ``

**Combined risk score**: 

**Priority**: 

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

## Recommendation Priority Matrix

| Risk Score | Reachable | Exploit Available | Recommended Action | Timeline |
|------------|-----------|-------------------|-------------------|----------|
| 80-100     | Yes       | Yes               | Immediate upgrade | 24-48h   |
| 80-100     | Yes       | No                | Immediate upgrade | 24-48h   |
| 80-100     | No        | Yes               | Upgrade within days | 3-5 days |
| 60-79      | Yes       | Yes               | Upgrade within days | 3-5 days |
| 60-79      | Yes       | No                | Upgrade within days | 3-5 days |
| 60-79      | No        | Any               | Monitor or defer | 2-4 weeks |
| 40-59      | Yes       | Any               | Next cycle | 2-4 weeks |
| 40-59      | No        | Any               | Monitor | As convenient |
| 20-39      | Any       | Any               | Monitor or defer | As convenient |
| 0-19       | Any       | Any               | Ignore with justification | N/A |

## 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