Go back

Application patching

Issue sheet
Document location /nhsbsa-digital-playbook/technologies/tech-patching/
Title Application patching
Author Head of Software Engineering
Issued to DDaT
Last reviewed
Next review due

Revision history

Version Date Amended by Approved by Details
1.1 PT - Playbook release
1.0 PT Technical Design Authority Initial release

Keeping software up to date with the latest versions of runtimes and dependant libraries is a key mitigation to the OWASP Top Ten 2021, risk number 6: Vulnerable and Outdated Components

Patching and upgrading provides considerable benefit:

  • We have a pro-active approach to vulnerability management
    Regular patching embeds the practice as a normal activity, and so responding to vulnerable dependencies happens as a matter of course.
  • Our applications stay fresh as they are actively maintened
    Updating runtime, framework and library APIs encourages us to adopt best practices as they evolve.

Dependency management

All projects must use a dependency management system to specify the dependencies and versions of library code that they rely upon.

Do not commit binaries into source control

Checked in binaries are not managed with a manifest file, making it impossible to use standards tools to identify dependencies with vulnerabilities from source.

Binaries cause unnecessary and considerable bloat to the source code repository.

The NHSBSA approved package management tools are:

Java
Maven build using pom.xml
Node.js
NPM package management using package.json
Python
Pip package management using pyproject.toml
Always use virtual environments to isolate project-specific dependencies from a shared or base OS Python installation
Ruby
Bundle package management using Gemfile
Always use virtual environments to isolate project-specific dependencies from a shared or base OS Ruby installation

The build configuration file must be committed into source control, with a unique identifier for each dependency and a specific version. Using a dependency manifest with specific versions means:

  • built artifacts are reproducable
  • the configuration file may be used to detect dependencies that need upgrade

Patching schedule

Release Adoption Schedule

The NHSBSA maintains a Release Adoption Schedule that specifies the versions of runtimes and key frameworks:

  • Node.js
  • Java
  • Spring Boot
  • Spring Cloud
  • AWS Lambdas (Node and Java)
  • Ruby
  • PostgreSQL

Runtimes and application dependencies should be upgraded in a regular release cycle according to this schedule:

PATCH

Upgrade within 1 month of release

MINOR

Upgrade within three months of release

Consider avoiding MINOR version upgrades until the first patch release or 1 month after release. i.e. prefer x.y.1 over x.y.0

MAJOR

Upgrade within one year of release

Consider avoiding MAJOR version upgrades until the first patch release or 3 months after release. i.e. prefer x.0.1 over x.0.0

Early adopters of major releases should keep an active view of all patch releases.

Route to live

Dependency and Runtime patching MUST follow the standard route to live:

  • Local development environments
  • CI/CD build environment
  • Test environments
    Note: The term ‘test environment’ should encompass acceptance, UAT, performance and staging environments
  • Production

Non-compliance

Non-compliance to this patching guidance should be recorded as technical debt and a risk to the business.

Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.

Suggest a change to this page

Published:

Last reviewed:

Next review due: