Patch Management Policy

1. Purpose

This policy defines the requirements for identifying, evaluating, testing, and applying patches and updates across XBert’s application stack and cloud infrastructure. It ensures that known vulnerabilities are remediated in a timely manner to protect customer data and maintain system integrity.

2. Scope

This policy covers:

• Application dependencies (NuGet packages, npm packages, Python packages)
• Application frameworks (.NET, Angular, Node.js)
• Azure PaaS platform components (managed by Microsoft with XBert configuration responsibility)
• Third-party integrations and SDKs
• CI/CD pipeline tooling
• Developer workstations

3. Patch Classification and SLAs

Severity	Definition	Remediation SLA	Examples
Critical	Actively exploited vulnerability or remote code execution with no mitigating controls	48 hours from patch availability (or compensating controls applied within 24 hours if no patch available)	Zero-day exploits, critical CVEs with CVSS 9.0+
High	Significant vulnerability with known exploit or high impact potential	7 days	CVSS 7.0-8.9, authentication bypass, privilege escalation
Medium	Vulnerability with limited exploit potential or mitigating controls in place	30 days	CVSS 4.0-6.9, information disclosure, minor injection vectors
Low	Minor vulnerability or hardening improvement	Next scheduled release cycle	CVSS < 4.0, best-practice improvements

4. Patch Sources and Detection

4.1 Automated Vulnerability Detection

Tool	Scope	Frequency
GitHub Dependabot	NuGet, npm, pip package vulnerabilities	Continuous (automated PRs)
GitHub Security Advisories	Known vulnerabilities in dependencies	Continuous (notifications)
Microsoft Defender for Cloud	Azure infrastructure vulnerabilities	Continuous
npm audit	Frontend JavaScript dependencies	Every CI/CD build
dotnet list package —vulnerable	.NET NuGet dependencies	Every CI/CD build
OWASP tools (integrated in CI/CD)	Application security scanning	Every CI/CD build

4.2 Manual Monitoring

Source	Frequency	Owner
Microsoft Azure security advisories	Weekly review	Development Manager
Auth0 security bulletins	As published	Development Manager
.NET and Angular release notes	Per release	Lead developers
OWASP Top 10 updates	Annual review	CTO

5. Patch Process

5.1 Identification

1. Vulnerability detected via automated scanning or advisory notification
2. Severity classified per Section 3
3. Logged in patch tracking system (GitHub Issues)

5.2 Evaluation

1. Assess applicability to XBert systems
2. Determine if existing controls mitigate the risk (e.g., network restrictions, WAF rules)
3. Evaluate patch stability and potential for breaking changes
4. Identify affected systems and components

5.3 Testing

1. Apply patch in development environment
2. Run automated test suite (unit tests, integration tests)
3. Verify no regression in affected functionality
4. For Critical/High patches: expedited testing with focused scope
5. For Medium/Low patches: included in standard sprint testing

5.4 Deployment

• All patches are deployed via the CI/CD pipeline (Azure DevOps)
• No manual patches are applied directly to production
• Deployment follows the standard release process: Development > Staging > Production
• Azure App Service deployment slots enable zero-downtime deployments
• Rollback capability via slot swapping if issues are detected post-deployment

5.5 Verification

1. Verify patch applied successfully in production
2. Monitor application health and error rates post-deployment
3. Confirm vulnerability is remediated via re-scan
4. Update patch tracking record

6. Azure PaaS Platform Patching

As XBert uses Azure PaaS services, the underlying infrastructure patching responsibility is shared:

Component	Patching Responsibility	Notes
OS and runtime patches (App Service)	Microsoft (automatic)	Azure manages OS-level patching
.NET runtime updates	XBert (via App Service configuration)	Updated as part of release cycle
Azure SQL Database engine	Microsoft (automatic)	Managed service with automatic patching
Azure Functions runtime	Microsoft (automatic) with XBert runtime version selection	Updated per release cycle
SSL/TLS certificates	Azure-managed (auto-renewal)	Verified via SSL scanning

7. Application Dependency Management

7.1 Dependency Update Strategy

Dependency Type	Update Strategy	Frequency
Security patches (any severity)	Per SLA in Section 3	As detected
Minor version updates	Included in sprint work	Monthly
Major version updates	Planned and tested as dedicated work items	Quarterly evaluation
Framework upgrades (.NET, Angular)	Planned migration with full regression testing	Per major release cycle

7.2 Dependency Hygiene

• Lock files (package-lock.json, packages.lock.json) are committed to source control
• Dependencies are pinned to specific versions; no floating version ranges in production
• Unused dependencies are identified and removed during code reviews
• New dependencies require review for security posture, maintenance status, and licence compatibility

8. Emergency Patching

For Critical severity vulnerabilities:

1. CTO and Development Manager notified immediately
2. Expedited evaluation (is XBert affected? Are there mitigating controls?)
3. If affected: patch developed, tested, and deployed within 48 hours
4. If no patch available: implement compensating controls (e.g., WAF rules, feature disable, IP restrictions)
5. Communication to customers if data risk is identified (per Incident Response procedures)
6. Post-incident review to identify process improvements

9. Exceptions

Any deviation from patch SLAs requires:

1. Written approval from CTO
2. Documented business justification and risk acceptance
3. Compensating controls implemented
4. Defined target date for remediation
5. Entry in the exceptions register, reviewed quarterly

10. Reporting

Report	Frequency	Audience
Outstanding vulnerability summary	Weekly (Critical/High), Monthly (Medium/Low)	Development Manager
Patch compliance report	Monthly	CTO
Dependency health report (Dependabot)	Continuous (dashboard)	Development team
Exception register review	Quarterly	CTO

11. Roles and Responsibilities

Role	Responsibility
CTO	Policy owner; approves exceptions; reviews compliance reports
Development Manager	Manages patch prioritisation and deployment; monitors vulnerability feeds
Developers	Apply patches; test and deploy; maintain dependency hygiene
All Staff	Keep developer workstations updated; report suspected vulnerabilities

12. Change History

Version	Date	Changes
1.0	April 2026	Initial creation