Skip to content

VULNERABILITY_EXCEPTIONS.md

Latest commit

 

History

History
72 lines (50 loc) · 3.08 KB

VULNERABILITY_EXCEPTIONS.md

File metadata and controls

72 lines (50 loc) · 3.08 KB
Raw

Vulnerability Exception Process & Policy

This document details the formal process for requesting, evaluating, approving, and documenting exceptions for accepted or unpatchable vulnerabilities in SwiftRemit dependencies, container images, or code.

Overview

When a security vulnerability is identified in a third-party dependency or container base image, our default policy requires immediate remediation according to the SLA (see VULNERABILITY_RESPONSE_SLA.md).

However, in cases where:

  1. No upstream patch is available from the package maintainer,
  2. The vulnerability is a confirmed false positive or non-exploitable in our specific execution environment,
  3. Upgrading would introduce critical breaking changes requiring architectural refactoring,

a formal Security Exception may be granted for a limited time.

Exception Request Process

1. Exception Request Criteria

To request a vulnerability exception, the requesting engineer must document:

  • CVE / Advisory ID (e.g. CVE-2026-12345 or RUSTSEC-2026-0001)
  • Package & Affected Version: Specific library or image name
  • Severity & CVSS Score: Critical / High / Medium / Low
  • Justification / Non-Exploitability Proof: Detailed technical evidence explaining why the vulnerable code path is unneeded, unreachable, or mitigated by existing controls (e.g. WAF, input sanitization, network isolation).
  • Mitigating Controls: Additional security mechanisms implemented to contain risk.
  • Expiration Date: Maximum exception window (Critical: max 14 days, High: max 30 days).

2. Approval Matrix

Vulnerability Severity Required Approval Max Exception Duration
Critical Head of Security + VP Engineering 14 Days
High Lead Security Engineer 30 Days
Medium / Low Tech Lead / Staff Engineer 90 Days

Documenting & Configuring Exceptions

Approved exceptions MUST be registered in both documentation and automated tool configuration files:

A. Rust / Cargo (deny.toml & audit.toml)

Rust advisory suppressions are configured in deny.toml under [advisories]:

[advisories]
ignore = [
    # RUSTSEC-2024-0001: Unused dependency in test scope, upstream fix pending (Expires: 2026-08-30)
    "RUSTSEC-2024-0001",
]

B. Container Scans (.trivyignore)

Trivy container exceptions are specified in .trivyignore with required expiration comments:

# CVE-2026-1111: Base image OS vulnerability, no patch available yet. Mitigated by network policy. (Approved by @security, Expires: 2026-08-30)
CVE-2026-1111

C. Node.js / npm Audit (package.json overrides)

In Node.js services, unpatchable sub-dependency vulnerabilities are resolved via overrides in package.json or documented in AUDIT_EXCEPTIONS.json.

Audit & Review Cycle

  • Bi-Weekly Audit Review: The Security Team reviews all active exceptions bi-weekly.
  • Automated Expiry Alerts: Exceptions reaching their expiration date automatically fail CI builds until renewed or patched.