Software and Hardware Patch Management Policy

1. Purpose

The purpose of this Software and Hardware Patch Management Policy is to ensure the timely identification, assessment, and remediation of known security vulnerabilities in all software and hardware systems used by Eververse. This policy ensures that vulnerabilities are promptly addressed, reducing the risk of unauthorized access, data breaches, and service disruption.

2. Scope

This policy applies to all software, libraries, and hardware used in Eververse’s infrastructure, including cloud-hosted applications, databases, software repositories, and other internal systems or third-party tools. The policy covers both the remediation of known vulnerabilities and regular security patching processes.

3. Automated Patch Management Tools

Eververse relies on automated tools to manage software patching and vulnerability remediation efficiently:

3.1 GitHub Security and Dependabot

• Dependabot: Automatically scans for outdated dependencies in Eververse’s repositories and submits pull requests for security updates.
• GitHub Security Alerts: GitHub notifies the development team of known vulnerabilities in the codebase. Once vulnerabilities are identified, pull requests are generated to patch the software, and these are prioritized for immediate review.

3.2 Hardware Patching

• Hardware vendors regularly release firmware or security patches for network devices, servers, and other hardware components. These patches are monitored, assessed, and applied during scheduled maintenance windows.

4. Patch Management Process

4.1 Vulnerability Identification

• Automated Monitoring: GitHub’s security alerts and Dependabot continuously monitor software dependencies for vulnerabilities. These alerts are reviewed daily to ensure that any critical vulnerabilities are promptly addressed.
• Vendor Notifications: Eververse tracks security advisories from hardware and software vendors for potential vulnerabilities that may impact the infrastructure.

4.2 Risk Assessment

• Each identified vulnerability is categorized based on its potential impact, using the following classification:
  • Critical: Vulnerabilities that pose immediate risk to sensitive data, system integrity, or service availability. These must be remediated within 24 hours.
  • High: Vulnerabilities that could allow unauthorized access or significant service disruption. These must be patched within 72 hours.
  • Medium: Vulnerabilities with moderate impact that could expose non-critical systems. These are addressed within 1 week.
  • Low: Minor vulnerabilities that pose little immediate threat but are patched during routine maintenance cycles.

4.3 Patch Testing and Deployment

• Pre-Production Testing: Patches are tested in a staging environment to ensure that they do not cause service interruptions or introduce new issues.
• Deployment: Once validated, patches are deployed to production systems via GitHub Actions for software and directly applied to cloud infrastructure for hardware.
• Rollback Procedures: If a patch introduces unforeseen issues, rollback mechanisms are in place to revert to a previous, stable version.

4.4 Post-Patch Review

• After applying patches, systems are monitored for any anomalies or performance issues. A review of the applied patches is conducted to ensure that vulnerabilities have been remediated effectively.

5. Scheduled Maintenance and Emergency Patching

• Scheduled Maintenance Windows: Regular patching of software and hardware is conducted during pre-defined maintenance windows to minimize disruption to Eververse's services.
• Emergency Patches: For critical vulnerabilities that pose an immediate risk, patches are applied outside of scheduled windows to ensure timely remediation.

6. Access Control and Evidence of Compliance

Patching and vulnerability remediation are strictly controlled through Access Control Policies to prevent unauthorized changes to critical systems.

6.1 Access Control Policy Overview

• Role-Based Access Control (RBAC): Access to apply patches or make changes to systems is limited to authorized personnel based on their role within the organization.
• Change Approval Process: All patches, especially for critical or high-risk systems, require approval from the CISO or designated security personnel before being applied.
• Audit Trails: All patching activities are logged via GitHub and cloud monitoring tools to maintain an audit trail of changes, ensuring compliance with internal and external security standards.

6.2 Evidence of Compliance

For more information on access control, please refer to the Access Control Policy.

7. Policy Review and Updates

This Software and Hardware Patch Management Policy will be reviewed annually, or more frequently as needed, in response to evolving security threats, operational changes, or new regulatory requirements.

8. Contact Information

For any questions or clarifications regarding this policy, please contact us.