Language selection


Patch management guideline


Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Applying patches (security updates, etc.) at the earliest possibility limits exposure to software vulnerabilities.

This document establishes the guidelines for patch management within the Canadian Digital Service (“CDS”).


This guidance focuses on all CDS-built assets and services and to CDS staff who create, deploy, or support these assets and services.


Internal Site Reliability Engineering

Site Reliability Engineering (SRE) is responsible for maintaining any tooling that is developed by the SRE Team (e.g. custom GitHub integrations, secret management, CDS-wide load testing tools) which are used by CDS teams.

SRE will also help surface security issues for teams to act upon.

CDS Teams

CDS development leads and their teams are responsible for ensuring that software they manage is maintained through regular software updates and patching. 

Where no patch is available for a known vulnerability, CDS teams are responsible for triaging those vulnerabilities and determining other risk mitigation approaches.

CDS teams are responsible for ensuring a complete and accurate inventory of assets.

Platform Core Services Team

The Platform Core Services team is responsible for routinely assessing compliance with the patch management standard and will provide guidance to all the stakeholder groups in relation to issues of security and patch management.

Patching recommendations

  • CDS team leads or their delegates are responsible for the assessment and remediation of system components and software under their management or supervision. 
  • All patches or configuration changes should be deployed to system components and software as set out in the timeframes in the Patching Schedule below.
  • Patches with a severity rating of ‘Critical/Very High’ should be installed within seven (7) days. 
  • Where the deployment of patches rated as ‘Critical/Very High’ is not possible within seven (7) days, either appropriate compensating controls or a temporary means of mitigation should be applied.
  • If no remediation is available to address a vulnerability, the relevant Head of should approve any compensating or mitigating controls or, where no fix is available, approve the acceptance of risk.
  • Remediation steps should be documented by team leads and a timeframe identified for review and future patching.
  • Shorter timeframes for patching may be needed based on the assessed severity and potential/actual impact (e.g. zero-day vulnerabilities).


Teams should keep all systems libraries and software up to date by incorporating small incremental changes at a manageable and regular cadence.

Automate patch management

Onboard your project to Renovate.

Teams can enable the Renovate GitHub app on the project’s GitHub repository. This will create the Renovate configuration pull request (PR). Once the configuration is merged, use the Dependency Dashboard to create and merge the pin dependency PR.

Patching schedule

Minor and patch releases

Each sprint should have an item to test and merge the Renovate minor, patch and pin PRs as they are automatically created each week.

Major releases

Major version updates should be evaluated on the Dependency Dashboard and addressed at least once every 2 sprints. Cycles may take longer to update code to accommodate a major release, so this should be incorporated similarly to a small feature addition.

Security Vulnerabilities

Vulnerability PRs should be merged according to our patching timelines which are based on severity and exploit availability.

In order to protect CDS assets and services from known vulnerabilities, security patches should be deployed in a suitable time frame, based on severity and exploit availability, as set out below:

SeverityPublic exploit availableNo known exploit
Critical / Very High24 hours7 days
High48 hours2 weeks
Medium7 daysMonthly
Low2 weeksMonthly

When to silence an update


Close the PR containing the update with a comment explaining why it’s not being addressed or merged at this time. This will keep it tracked in the Renovate Dependency Dashboard and allow it to be applied easily in the future.


Update the project’s Renovate config directly with an ignoreDeps block for the dependency. Include an explanation for this change in the PR that updates the Renovate config.

GitHub vulnerability alerts

Our project repos will also receive vulnerability alerts from GitHub. These should go through the same vulnerability assessment and patching process as a Renovate PR.

If a vulnerability is found that does not impact the project, it can be dismissed using the Dismiss alert button by providing a reason, along with a comment explaining the dismissal.

Vulnerability assessments

Patch management is prioritized based on the severity of the vulnerability the patch addresses.  In most cases, severity ratings are based on the Common Vulnerability Scoring System (CVSS).

In addition to the CVSS severity ratings, there are additional factors that go into determining a tailored severity rating for CDS use of the vulnerability component(s).

Risk LevelExamples
Extreme riskVulnerability allows remote code executionCritical business systems and information are affectedExploits exist and are in useSystem is connected to the Internet and doesn’t have mitigation controls in place
High riskVulnerability allows remote code executionCritical business system information is affectedExploits exist and are in useSystem is in a protected enclave with strong access controls
Medium riskVulnerability allows attacker to impersonate a legitimate user on a remote access solutionSystem is exposed to unauthenticated usersSystem requires two factor authentication and administrator level remote login is disallowed
Low riskVulnerability requires authenticated users to perform malicious actions (e.g. SQL injection)Affected system contains non sensitive, publicly available informationExisting mitigation controls make exploitation unlikely or very difficult
Source: Top 10 IT security action items: No. 2 patch operating systems and applications – ITSM.10.096 (Table 1)

Patching exceptions

There may be instances where risk mitigation may be preferable to patching. Where risk mitigation may be preferable, the risk mitigation alternative selected should be determined through an outage risk to exposure comparison. 

There may also be instances where a vulnerability is determined not to impact the project. Where this is the case, the determination regarding impact should be documented and the vulnerability can be dismissed.

Where the deployment of ‘critical’ or ‘very high’ security patches within seven days is not possible, either appropriate compensating controls or a temporary means of mitigation should be applied to reduce the exposure. 

Factors to consider when assessing patching timelines and approach include:

  • The likelihood of risk and whether exploitation has already been observed
  • Exposure of the systems or services – are they internet-accessible or government-wide?
  • Consider the context of the vulnerability, including severity rating by the vendor, attack complexity, whether there is protected data on the system, etc.
  • Are there workarounds or temporary solutions to help mitigate the risk?

Performance indicators

Monitoring and reporting on the indicators below will allow us to evaluate the effectiveness and efficiency of our patch management approach. 


  • The percentage of systems and applications within the organization inventoried and covered by automated patch management

Efficiency and effectiveness:

  • Critical patches will be applied within seven days
  • Number of untriaged vulnerabilities per product, grouped by severity
  • How often products are automatically checked for compliance
  • The percentage of products patched within 7, 14, 30 days after a vulnerability is identified
  • The percentage of products within the organization that have no untriaged vulnerabilities
  • Average time elapsed between a patch’s availability and its production deployment per level of severity rating


Date modified: