Introduction

Patch management is the process of identifying, acquiring, installing, and verifying patches for products and systems. This document outlines the procedures for managing patches to ensure that systems are up-to-date and secure.

Objectives

• Ensure the security and stability of IT systems.

• Minimize the risk of vulnerabilities.

• Maintain compliance with industry standards and regulations.

• Provide a structured approach to patch management.

Process

Identification

• Regularly check vendor websites, security bulletins, and automated tools for new patches especially from Azure and Zitadel.

• Use https://trivy.dev/ or comparable tool to automatically scan each build artifact for known vulnerabilities in the OS and code dependency layer, and regularly check results of the scans.

• Regularly check Bug Bounty Program reports for reported vulnerabilities.

• Regularly check GH Advanced Security CodeQL scan reports for potential vulnerabilities in Unique source code.

Automation

• Make scan results available in Github code scanning results for development teams, for every build artifact that is created for delivery to production systems

• Use renovate or dependabot to automatically create patches for libraries used in source code or the OS layer

• Automatically rebuild all images weekly to apply latest base image and OS vulnerability patches on a continuous basis

Evaluation

• Ensure patches compatibility with existing systems and applications

• Evaluate severity of each vulnerability based on CVSS 3.1 and apply according to timelines:

Exceptions

Vulnerability patching can exceed the timelines listed above for one or more of the following reasons. The reasons are documented internally and can be provided.

• Unique fixes vulnerabilities concerning confidentiality with higher priority than vulnerabilities concerning integrity and availability.

• Vulnerabilities that are not exploitable because they are compensated through another control, or not reachable, Unique fixes with a lower priority.

• Vulnerabilities that are of low severity and are not concerning confidentiality, Unique may exclude them from patching for a limited time.

• Vulnerabilities that do not yet have a patch but are accepted by the vendor are postponed until they have an official patch. The patch timeline starts when the vendor patch is made available.

• Vulnerabilities that are categorized as “won’t fix” by the vendor are handled on a case by case basis according to their severity in the context of the Unique systems. Unique may exclude them from patching for a limited time, or may decide to not patch them if not exploitable. Unique may also decide to apply a compensating measure that reduces impact and not patch them.

Reporting

• In case of Critical severity vulnerabilities that need immediate attention because of critical impact (e.g. Log4Shell, React2Shell), Unique will approach partners running Unique on their own environments with mitigation measures outside of patch management immediately, until a patch can be provided in the platform.

• In case of High or Critical severity vulnerabilities Unique reports the vulnerability and its details to partners running Unique on their own environments quarterly upon request

  • A Client can activate a proactive provision of the report as follows: Reach out to your Customer Success representative and provide them with a secure channel where you wish to receive the reports. Following this, the reports will be dispatched to the secure channel on a quarterly basis.

Deployment

• Test patches in test environments or on non-critical systems first

• Ensure backups are available before applying patches to production systems

• Apply patches during low-usage periods to minimize disruption if disruption is anticipated

Verification

• Verify that patches have been successfully applied, that systems are functioning correctly and that vulnerabilities are not exploitable anymore by reviewing CodeQL and Trivy scan results after patches were applied.

• Regularly review excluded vulnerabilities from the exceptions section for decision on continued exclusion.