Vulnerability Management Policy

Version: 1.0 Last Updated: 2025-12-17 Owner: Security Team Compliance: PCI-DSS 6.2, SOX 404, Basel III Cyber Risk

Overview
Scope
Vulnerability Severity Levels
Remediation SLAs
Scanning Process
Remediation Process
Exception Process
Reporting and Metrics
Roles and Responsibilities
Compliance Requirements

Overview

This document defines the vulnerability management policy for the Bindy DNS Controller project. The policy ensures that security vulnerabilities in dependencies, container images, and source code are identified, tracked, and remediated in a timely manner to maintain compliance with PCI-DSS, SOX, and Basel III requirements.

Objectives

Identify vulnerabilities in all software components before deployment
Remediate vulnerabilities within defined SLAs based on severity
Track and report vulnerability metrics for compliance audits
Prevent deployment of code with CRITICAL/HIGH vulnerabilities
Maintain audit trail of vulnerability management activities

Scope

This policy applies to:

Rust dependencies (direct and transitive) listed in Cargo.lock
Container base images (Debian, Alpine, etc.)
Container runtime dependencies (libraries, binaries)
Development dependencies used in CI/CD pipelines
Third-party libraries and tools

Out of Scope

Kubernetes cluster vulnerabilities (managed by platform team)
Infrastructure vulnerabilities (managed by operations team)
Application logic vulnerabilities (covered by code review process)

Vulnerability Severity Levels

Vulnerabilities are classified using the Common Vulnerability Scoring System (CVSS v3) and mapped to severity levels:

🔴 CRITICAL (CVSS 9.0-10.0)

Definition: Vulnerabilities that can be exploited remotely without authentication and lead to:

Remote code execution (RCE)
Complete system compromise
Data exfiltration of sensitive information
Denial of service affecting multiple systems

Examples:

Unauthenticated RCE in web server
SQL injection with admin access
Memory corruption leading to arbitrary code execution

SLA: 24 hours

🟠 HIGH (CVSS 7.0-8.9)

Definition: Vulnerabilities that can be exploited with limited user interaction or authentication and lead to:

Privilege escalation
Unauthorized data access
Significant denial of service
Bypass of authentication/authorization controls

Examples:

Authenticated RCE
Cross-site scripting (XSS) with session hijacking
Path traversal allowing file read/write
Insecure deserialization

SLA: 7 days

🟡 MEDIUM (CVSS 4.0-6.9)

Definition: Vulnerabilities that require significant user interaction or specific conditions and lead to:

Limited information disclosure
Localized denial of service
Minor authorization bypass
Reduced system functionality

Examples:

Information disclosure (non-sensitive data)
CSRF with limited impact
Reflected XSS
Resource exhaustion (single process)

SLA: 30 days

🔵 LOW (CVSS 0.1-3.9)

Definition: Vulnerabilities with minimal impact that require significant preconditions:

Cosmetic issues
Minor information disclosure
Difficult-to-exploit conditions
No direct security impact

Examples:

Version disclosure
Clickjacking on non-critical pages
Minor configuration issues

SLA: 90 days or next release

Remediation SLAs

Severity	CVSS Score	Detection to Fix	Approval to Deploy	Exceptions
🔴 CRITICAL	9.0-10.0	24 hours	4 hours	CISO approval required
🟠 HIGH	7.0-8.9	7 days	1 business day	Security lead approval
🟡 MEDIUM	4.0-6.9	30 days	Next sprint	Team lead approval
🔵 LOW	0.1-3.9	90 days	Next release	Auto-approved

SLA Clock

Starts: When vulnerability is first detected by automated scan
Pauses: When risk acceptance or exception is granted
Stops: When patch is deployed to production OR exception is approved

SLA Escalation

If SLA is at risk of being missed:

T-50%: Notification to team lead
T-80%: Notification to security team
T-100%: Escalation to CISO and incident response team

cargo audit for Rust dependencies
Trivy for container images

Process:

PR is opened or updated
CI workflow runs security scans
If CRITICAL/HIGH vulnerabilities found:
- CI fails
- PR is blocked from merging
- GitHub issue is created automatically
Developer must remediate before merge

Workflow: .github/workflows/pr.yaml

2. Scheduled Scanning

Frequency: Daily at 00:00 UTC

Tools:

cargo audit for dependencies
Trivy for published container images

Process:

Scan runs automatically via GitHub Actions
Results are uploaded to GitHub Security tab
If vulnerabilities found:
- GitHub issue is created with details
- Security team is notified
Vulnerabilities are tracked until remediation

Workflow: .github/workflows/security-scan.yaml

3. Release Scanning

Frequency: Every release tag

Tools:

cargo audit for final dependency snapshot
Trivy for release container image

Process:

Release is tagged
Security scans run before deployment
If CRITICAL/HIGH vulnerabilities found:
- Release fails
- Issue is created for emergency fix
Release proceeds only if all scans pass

Workflow: .github/workflows/release.yaml

Manual Scanning

Developers should run scans locally before committing:

# Scan Rust dependencies
cargo audit

# Scan container image
trivy image ghcr.io/firestoned/bindy:latest

Remediation Process

Step 1: Triage (Within 4 hours for CRITICAL, 24 hours for HIGH)

Verify vulnerability applies to Bindy:
- Check if vulnerable code path is used
- Verify affected version matches
- Assess exploitability in Bindy’s context
Assess impact:
- What data/systems are at risk?
- What is the attack vector?
- Is there a known exploit?
Determine remediation approach:
- Update dependency to patched version
- Apply workaround/mitigation
- Accept risk (if low impact)

Step 2: Remediation (Within SLA)

Option A: Update Dependency

# Update single dependency
cargo update -p <package-name>

# Verify fix
cargo audit

# Test
cargo test

Option B: Upgrade Major Version

# Update Cargo.toml
vim Cargo.toml  # Change version constraint

# Update lockfile
cargo update

# Test for breaking changes
cargo test

Option C: Apply Workaround

If no patch is available:

Disable vulnerable feature flag
Implement input validation
Add runtime checks
Document in SECURITY.md

Option D: Request Exception (See Exception Process)

Step 3: Verification

Run cargo audit to confirm vulnerability is resolved
Run cargo test to ensure no regressions
Run integration tests
Document fix in PR description

Step 4: Deployment

Create PR with fix
PR passes all CI checks (including security scans)
Code review and approval
Merge to main
Deploy to production
Close GitHub issue

Step 5: Post-Deployment

Verify vulnerability is resolved in production
Update metrics dashboard
Document lessons learned
Update runbooks if needed

Exception Process

When to Request an Exception

No patch available and vulnerability has low exploitability
Patch introduces breaking changes requiring extended migration
Vulnerability does not apply to Bindy’s use case
Compensating controls mitigate the risk

Exception Request Process

Create exception request (GitHub issue or security ticket):
- Vulnerability ID (CVE, RUSTSEC-ID)
- Severity and CVSS score
- Justification for exception
- Compensating controls
- Expiration date (max 90 days)
Approval required:
- CRITICAL: CISO approval
- HIGH: Security lead approval
- MEDIUM: Team lead approval
- LOW: Auto-approved

Document in SECURITY.md:

## Known Vulnerabilities (Risk Accepted)

### CVE-2024-XXXXX - <Package Name>
- **Severity:** HIGH
- **Affected Version:** 1.2.3
- **Status:** Risk Accepted
- **Justification:** Vulnerability requires local file system access, which is not available in Kubernetes pod security context.
- **Compensating Controls:** Pod security policy enforces readOnlyRootFilesystem=true
- **Expiration:** 2025-03-01
- **Approved By:** Jane Doe (Security Lead)
- **Date:** 2025-01-15

Review exceptions monthly:
- Check if patch is now available
- Verify compensating controls are still effective
- Renew or remediate before expiration

Reporting and Metrics

Weekly Report

Recipients: Development team, Security team

Contents:

New vulnerabilities detected
Vulnerabilities remediated
Open vulnerabilities by severity
SLA compliance percentage
Aging vulnerabilities (open >30 days)

Source: GitHub Security tab + automated report workflow

Monthly Report

Recipients: Management, Compliance team

Contents:

Vulnerability trends (month-over-month)
Mean time to remediate (MTTR) by severity
SLA compliance rate
Exception requests and approvals
Top 5 vulnerable dependencies
Compliance attestation

Source: Security metrics dashboard

Quarterly Report

Recipients: Executive team, Audit team

Contents:

Vulnerability management effectiveness
Policy compliance audit results
Risk acceptance report
Remediation process improvements
Compliance attestation (PCI-DSS, SOX, Basel III)

Source: Compliance reporting system

Key Metrics

Mean Time to Detect (MTTD): Time from CVE disclosure to detection in Bindy
- Target: <24 hours
Mean Time to Remediate (MTTR):
- CRITICAL: <24 hours
- HIGH: <7 days
- MEDIUM: <30 days
SLA Compliance Rate: Percentage of vulnerabilities remediated within SLA
- Target: >95%
Vulnerability Backlog: Open vulnerabilities by severity
- Target: Zero CRITICAL, <5 HIGH
Scan Coverage: Percentage of releases scanned
- Target: 100%