Patch & Vulnerability Management Procedure
| Property | Value |
|---|
| Document ID | PROC-004 |
| Version | 1.0 |
| Status | Draft |
| Owner | Security Engineering Lead |
| Last Updated | 2026-01-11 |
| Next Review | 2027-01-11 |
| Related Controls | SOC 2: CC7.1 / ISO 27001: A.12.6 |
| Parent Policy | Change Management Policy (POL-006) |
1. Purpose
This procedure defines the process for identifying, assessing, and remediating security vulnerabilities in organizational systems. Effective vulnerability management reduces the risk of exploitation and maintains a strong security posture.
2. Scope
This procedure applies to:
- Systems: All servers, containers, applications, and infrastructure
- Components: Operating systems, libraries, dependencies, configurations
- Environments: Production, staging, development
- Responsible Parties: Security, DevOps, Development, IT Operations
3. Vulnerability Management Lifecycle
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Discover │───▶│ Assess │───▶│ Prioritize │───▶│ Remediate │───▶│ Verify │
│ │ │ │ │ │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Scanning CVSS/Risk Remediation Patch/Fix Rescan
& Detection Analysis Priority Deployment & Validate
4. Vulnerability Scanning
4.1 Scanning Types and Frequency
| Scan Type | Scope | Frequency | Tool Examples |
|---|
| Infrastructure Scan | Servers, VMs, network | Weekly | Nessus, Qualys, AWS Inspector |
| Container Image Scan | Docker images | Every build + weekly | Trivy, Snyk, Clair |
| Dependency Scan (SCA) | Application libraries | Every build + daily | Snyk, Dependabot, Renovate |
| SAST | Source code | Every PR/commit | Semgrep, SonarQube, CodeQL |
| DAST | Running applications | Weekly | OWASP ZAP, Burp Suite |
| Cloud Configuration | Cloud resources | Continuous | Prowler, ScoutSuite, AWS Config |
| Penetration Test | Full scope | Annually | External vendor |
4.2 Scanning Configuration
| Setting | Standard |
|---|
| Authenticated scans | Enabled (for internal scans) |
| Credential storage | Vault/secrets manager |
| Scan windows | Off-peak hours for production |
| Exclusions | Documented and approved |
| Rate limiting | Configured to prevent impact |
4.3 Continuous Scanning Pipeline
# Example CI/CD Integration
stages:
- dependency_scan: # Run on every commit
tool: snyk/trivy
fail_on: critical, high
- container_scan: # Run on image build
tool: trivy
fail_on: critical
- sast: # Run on PR
tool: semgrep
fail_on: high_confidence
- infrastructure: # Scheduled weekly
tool: prowler/inspector
report: security_team
5. Vulnerability Assessment
5.1 Risk Scoring
Use CVSS (Common Vulnerability Scoring System) with contextual factors:
| CVSS Base Score | Severity | Base Priority |
|---|
| 9.0 - 10.0 | Critical | Immediate |
| 7.0 - 8.9 | High | Urgent |
| 4.0 - 6.9 | Medium | Standard |
| 0.1 - 3.9 | Low | Planned |
5.2 Contextual Risk Factors
Adjust priority based on:
| Factor | Impact on Priority |
|---|
| Internet-facing | Increase priority |
| Contains sensitive data | Increase priority |
| Active exploitation (KEV) | Increase to Critical |
| Compensating controls | May decrease priority |
| Isolated network | May decrease priority |
| Development only | May decrease priority |
5.3 Exploitability Assessment
Check for active exploitation:
6. Remediation SLAs
6.1 Remediation Timelines
| Severity | Production | Non-Production | With Active Exploit |
|---|
| Critical | 7 days | 14 days | 48 hours |
| High | 30 days | 45 days | 7 days |
| Medium | 90 days | 120 days | 30 days |
| Low | 180 days | Best effort | 90 days |
6.2 Remediation Options
| Option | Description | When to Use |
|---|
| Patch | Apply vendor patch | Default approach |
| Upgrade | Upgrade to fixed version | Dependencies, containers |
| Workaround | Mitigating configuration | When patch unavailable |
| Compensating Control | Additional protection | Temporary measure |
| Accept Risk | Document and accept | Low risk, high effort |
| Decommission | Remove affected system | End of life systems |
6.3 Risk Acceptance
Risk acceptance requires:
7. Patch Management
7.1 Patch Categories
| Category | Description | Timeline |
|---|
| Emergency | Critical security, active exploit | 24-48 hours |
| Security | Security patches, not emergency | Per SLA above |
| Critical | Stability/availability patches | 30 days |
| Routine | Feature updates, minor fixes | Next maintenance window |
7.2 Patch Testing
| Environment | Requirement |
|---|
| Development | Initial validation |
| Staging | Full regression testing |
| Production (Canary) | Gradual rollout (10% → 50% → 100%) |
| Production (Full) | After canary validation |
7.3 Patch Workflow
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Identify │───▶│ Test │───▶│ Approve │───▶│ Deploy │───▶│ Verify │
│ Patch │ │ (Non-Prod) │ │ (CAB) │ │ Patch │ │ Success │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
7.4 Automated Patching
| System Type | Automation Approach |
|---|
| Cloud instances | Immutable infrastructure (rebuild) |
| Containers | Rebuild with updated base image |
| Kubernetes | Rolling deployment |
| Dependencies | Automated PRs (Dependabot, Renovate) |
| OS patches | Managed service or automation tool |
8. Dependency Management
8.1 Dependency Scanning
| Ecosystem | Tool | Integration |
|---|
| Node.js (npm) | Snyk, npm audit, Dependabot | CI/CD |
| Python (pip) | Snyk, Safety, Dependabot | CI/CD |
| Java (Maven) | Snyk, OWASP Dependency-Check | CI/CD |
| Go | Snyk, govulncheck | CI/CD |
| Containers | Trivy, Snyk | Registry scan |
8.2 Dependency Update Process
- Automated scan identifies vulnerable dependency
- Automated PR created with update
- CI tests run on PR
- Developer reviews and approves
- Merge and deploy per change management
8.3 Dependency Best Practices
9. Vulnerability Reporting
9.1 Reporting Cadence
| Report | Audience | Frequency |
|---|
| Vulnerability Dashboard | Security Team | Real-time |
| Open Vulnerabilities | IT/Dev Teams | Weekly |
| Executive Summary | Leadership | Monthly |
| Compliance Report | Auditors | Quarterly |
9.2 Key Metrics
| Metric | Target |
|---|
| Mean time to remediate (Critical) | <7 days |
| Mean time to remediate (High) | <30 days |
| Overdue vulnerabilities | 0 Critical, <5 High |
| Vulnerability backlog trend | Decreasing |
| SLA compliance rate | >95% |
10. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Security Team | Configure scans, triage results, track remediation |
| DevOps/SRE | Remediate infrastructure vulnerabilities, maintain automation |
| Development | Remediate application/dependency vulnerabilities |
| System Owners | Approve remediation, accept risk if needed |
| CISO | Approve risk acceptance, review metrics |
11. Implementation Checklist
Scanning Setup
Process Setup
12. Evidence Requirements
| Evidence Type | Description | Location | Retention |
|---|
| Scan Reports | Vulnerability scan results | Security tools | 1 year |
| Remediation Tickets | Patch/fix deployment tickets | Ticketing system | 3 years |
| Risk Acceptances | Approved risk acceptance records | GRC platform | Duration + 1 year |
| SLA Reports | Monthly remediation SLA metrics | Reports | 1 year |
| Penetration Test | Annual pentest report | Secure storage | 3 years |
13. Related Documents
14. Version History
| Version | Date | Author | Changes |
|---|
| 1.0 | 2026-01-11 | Security Engineering | Initial release |
| | | |
This document is classified as INTERNAL. Unauthorized distribution is prohibited.