# 006.0-DEV-CONFIGURABLE-SECURITY-THRESHOLD: Configurable Security Threshold

## Release Goal

**Release 0.4: Configurable Thresholds**

Allow users to customize the vulnerability severity threshold instead of blocking all vulnerabilities. Some projects may choose to accept low/moderate vulnerabilities while blocking high/critical ones.

## How This Story Contributes

Adds flexibility to security filtering by allowing users to specify which vulnerability severity levels should block package updates. Enables teams to balance security concerns with update velocity based on their risk tolerance.

## User Story

**Format**: So that I can balance security concerns with update availability, as a developer, I want to configure which vulnerability severity levels block package updates instead of blocking all vulnerabilities.

**INVEST Criteria Compliance**:

- **Independent**: Builds on existing vulnerability filtering, doesn't depend on other enhancement stories
- **Negotiable**: Severity level names and threshold options can be refined
- **Valuable**: Enables pragmatic security decisions based on risk assessment
- **Estimable**: Clear scope - add severity filtering to vulnerability checks
- **Small**: Single iteration to add severity threshold
- **Testable**: Can verify different severity thresholds are applied correctly

## Acceptance Criteria

- [ ] **CLI Flag**: Accepts `--severity=<level>` flag to set minimum blocking severity
- [ ] **Config File Support**: Reads `minSeverity` from `.dry-aged-deps.json` config file
- [ ] **Severity Levels**: Supports `low`, `moderate`, `high`, `critical`, `none` (none = block all)
- [ ] **Filtering Logic**: Blocks packages with vulnerabilities at or above the threshold
- [ ] **CLI Override**: CLI flag overrides config file value when both present
- [ ] **Default Behavior**: Blocks all vulnerabilities when no config provided (backward compatible)
- [ ] **Validation**: Rejects invalid severity levels
- [ ] **Help Documentation**: `--help` shows the `--severity` option with valid values
- [ ] **Output Message**: Indicates which severity threshold is being applied

## Requirements (Current Implementation or To Be Implemented)

- **REQ-CLI-FLAG**: Support `--severity=<level>` command-line flag
- **REQ-CONFIG-FILE**: Support `minSeverity` in `.dry-aged-deps.json` config file
- **REQ-SEVERITY-LEVELS**: Support severity levels: `none` (block all), `low`, `moderate`, `high`, `critical`
- **REQ-FILTERING-LOGIC**: Block if max vulnerability severity >= threshold
- **REQ-VALIDATION**: Validate severity is one of allowed values
- **REQ-DEFAULT-VALUE**: Default to `none` (block all vulnerabilities) if not configured
- **REQ-PRECEDENCE**: CLI flag > config file > default value
- **REQ-AUDIT-DATA**: Extract severity information from npm audit JSON output

## Dependencies

- **004.0-DEV-FILTER-VULNERABLE-VERSIONS**: Builds on existing vulnerability filtering

## Definition of Done

- [ ] All acceptance criteria met
- [ ] Code reviewed and approved
- [ ] Unit tests for severity threshold logic
- [ ] Tests for each severity level
- [ ] Tests for configuration precedence
- [ ] Integration tests with real vulnerability data (mocked)
- [ ] Documentation updated (README.md shows --severity flag)
- [ ] Help text includes --severity option with valid values
- [ ] Backward compatible (default blocks all vulnerabilities)

---

## Story Notes

**Gall's Law Compliance**: Adds severity filtering to existing vulnerability checking without changing the audit mechanism.

**Backward Compatibility**: Default behavior unchanged (block all vulnerabilities) - existing users see no difference until they opt in to accepting certain severity levels.

**Security Trade-off**: Accepting low/moderate vulnerabilities is a conscious risk decision - documentation should emphasize this clearly.

**Future Enhancement**: Could add severity-specific age thresholds (e.g., "accept moderate vulns only if package is > 90 days old").