Patch Management Policy
Software Patch Management and Vulnerability Remediation Policy
Last Updated: May 19, 2026
Policy Owner: AI Bizlutions, LLC
1. Purpose
This policy establishes procedures for the timely identification, evaluation, testing, and deployment of security patches across all software dependencies and runtime environments operated by AI Bizlutions. The goal is to minimize the window of exposure to known vulnerabilities and maintain a secure platform for all customers.
This policy is aligned with NIST SP 800-40 Rev. 4 (Guide to Enterprise Patch Management Planning) and CIS Controls v8 Control 7 (Continuous Vulnerability Management).
2. Scope
This policy applies to the following components:
- npm dependencies — frontend root packages and backend/ packages
- Node.js runtime — Lambda managed runtime (currently Node.js 20.x)
- AWS managed services — DynamoDB, S3, API Gateway, CloudFront, SES
- Operating system — AWS-managed Lambda execution environment
3. Severity Classification
| Severity |
CVSS Score Range |
Examples |
| Critical |
9.0 or above |
Remote code execution, authentication bypass |
| High |
7.0 – 8.9 |
Privilege escalation, data exposure |
| Medium |
4.0 – 6.9 |
Cross-site scripting (XSS), information disclosure |
| Low |
0.1 – 3.9 |
Minor information leak, denial-of-service requiring local access |
Note: Severity classification is aligned with CVSS v3.1 as published by the National Vulnerability Database (NVD).
4. Remediation SLA
| Severity |
Maximum Time to Remediate |
SLA Clock Starts |
| Critical |
24 hours |
Detection timestamp |
| High |
72 hours |
Detection timestamp |
| Medium |
7 calendar days |
Detection timestamp |
| Low |
30 calendar days |
Detection timestamp |
SLA is measured from the moment a vulnerability is detected by automated tooling or manually reported, whichever is earlier.
5. Responsibility Matrix
| Severity |
Responsible Party |
Process |
| Critical |
Developer on-call |
Immediate hotfix branch + expedited deploy |
| High |
Sprint team |
Current sprint priority |
| Medium |
Sprint team |
Next sprint planning |
| Low |
Backlog |
Prioritized in grooming session |
6. Automated Scanning
- GitHub Dependabot — automatically creates pull requests for vulnerable dependencies.
- npm audit in CI/CD —
npm audit --audit-level=high runs before every deployment; Critical and High findings block the deploy.
- Dependabot security alerts — reviewed weekly; all Critical/High alerts triaged within SLA.
- GitHub code scanning — static analysis for common vulnerability patterns.
7. Patch Deployment Process
- Detect vulnerability via automated scan, advisory subscription, or manual report.
- Classify severity per Section 3 using CVSS base score.
- Create tracking issue with severity label and SLA deadline.
- Develop fix (dependency version bump, code patch, or compensating control).
- Test in development environment.
- Deploy via push to main branch (standard deployment pipeline).
- Verify remediation with post-deploy npm audit.
8. Exception Process
When an SLA cannot be met, the following is required:
- Written risk acceptance filed as a GitHub Issue with
risk-acceptance label.
- Documented compensating controls that reduce exposure.
- Planned remediation date (must not exceed 2x the original SLA).
- Approval from engineering lead.
- Re-assessment every 30 days until resolved.
9. AWS Managed Services
AWS manages patching for the Lambda runtime environment, DynamoDB, API Gateway, CloudFront, S3, and SES under the shared responsibility model. AI Bizlutions is not responsible for OS-level or hypervisor-level patches on these services.
Platform responsibility includes:
- Keep Lambda runtime version current (currently Node.js 20.x).
- Monitor AWS Security Bulletins for service-level advisories.
- Upgrade runtime within 90 days of a new LTS release becoming available on Lambda.
10. Reporting
A monthly vulnerability posture summary is produced including:
- Total open vulnerabilities by severity.
- SLA compliance rate (percentage remediated within SLA).
- Mean time to remediation (MTTR) by severity.
- Active risk acceptances and exceptions.
- Trend analysis (month-over-month).
The report is delivered to the engineering lead on the first business day of each month.
11. Compliance References
- NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning
- CIS Controls v8 Control 7 — Continuous Vulnerability Management
- SOC 2 CC7.1 — Detection of Changes
- ISO 27001:2022 A.8.8 — Management of technical vulnerabilities
12. Review and Updates
This policy is reviewed annually or upon significant infrastructure change.
Version 1.0 — Effective May 19, 2026.
Next scheduled review: May 2027.