Skip to content

Vulnerability management policy (Secure by Design)

Terminology

Term Meaning / Application
Must This term is used to state a mandatory requirement of this policy
Should This term is used to state a recommended requirement of this policy
May This term is used to state an optional requirement of this policy

Purpose

The purpose of this policy is to identify, prioritise and mitigate vulnerabilities within DfE (Department for Education) digital services, infrastructure and software to preserve the confidentiality, integrity, and availability of DfE applications and data.

This policy is intended to ensure DfE is complying with Central Digital and Data Office (CDDO) Secure by Design principles and the Secure Software Development Lifecycle (SSDLC).

Scope

This policy refers to the management of vulnerabilities in DfE digital services, applications, infrastructure and development environments.

A digital service refers to an application that is provided to users and is built using software development practices.

This policy was produced to be in line with CDDO's Secure by Design mandate which is a Government scheme that aims to ensure services are developed using the Secure Software Development Lifecycle (SSDLC) and formalised risk management processes.

This policy is applicable to all DfE employees that produce, maintain or are responsible for digital services.

Responsibility

The digital service teams and portfolios are responsible for ensuring they mitigate vulnerabilities within their software and infrastructure.

Responsible Accountable Consulted Informed (RACI) matrix

Role

Activity		 CISO SROs Developers/DevOps Vulnerability management team Delivery managers (portfolio) Architects
Patching Azure servers A A R C I C
Patching software dependencies A A R C I C
Patching container images A A R C I C
Fixing SAST vulnerabilities A A R C I C
Fixing DAST vulnerabilities A A R C I C
Fixing VDP reported vulnerabilities A A R I I C
Risk management and appetite A R C C I C
Prioritisation of remediation A R C C I C
Monitoring for vulnerabilities A A R R I C
Organisation penetration tests A A C I I C

Other responsible owners

Exceptions

Exceptions to this policy are likely to occur. Request for exceptions may include additional time to remediate vulnerabilities, or to let certain systems function normally with vulnerabilities in place.

Exception requests must be made in writing to the Vulnerability Management team mailbox (vulnerability.management@education.gov.uk) and must contain:

  • the reason for the request
  • risk to the department of not following the policy
  • specific mitigations that will not be implemented
  • technical and other difficulties in applying patches
  • date of review

The VM team should also try and obtain confirmation from the Senior Responsible Officer (SRO) and Service Owner that the vulnerability has been approved and has been added to the Services Risk Register (where maintained). Each service is responsible for maintaining an appropriate risk register for their service.

Policy

Service level agreements (SLAs)

The service level agreement outlines how quickly vulnerabilities should be remediated based on their risk level. These timescales are shown in the table below:

Type Critical High Medium Low
Virtual machines 14 days 30 days 60 days 90 days
Container images 14 days 30 days 60 days 90 days
Software dependencies 14 days 30 days 60 days 90 days
SAST vulnerabilities 14 days 30 days 60 days 90 days
DAST vulnerabilities 14 days 30 days 60 days 90 days
Pen test results 14 days 30 days 60 days 90 days
Threat model results 14 days 30 days 60 days 90 days
Critical risk issues must be mitigated within 24 hours

You have 14 days to remediate a critical risk issue, but they must be mitigated within 24 hours to ensure DfE stays secure.

Virtual machines

Development teams are responsible for patching virtual machines they deploy into Azure.

Your vulnerability management process for virtual machines:

  • must be documented and approved by an ISO and the vulnerability management lead
  • must include daily monitoring of operating system and application patches available
  • should be automated wherever possible
  • must ensure that patches are installed within the appropriate SLAs
  • should include reviewing the Continuous Assurance Platform for a single pane of glass view of their benchmark compliance and vulnerability management status across Azure and GitHub

Containers

Development teams are responsible for patching container images that they:

  • use for development
  • deploy to AKS or other Azure container services
  • use for deployments in CI/CD pipelines

Your vulnerability management process for container images:

  • must be documented and approved by an ISO and the Vulnerability Management Lead
  • must include daily monitoring of container images
  • should be integrated into CI/CD pipelines to ensure vulnerable containers are not pushed to production
  • should be automated wherever possible
  • must ensure that patches are installed within the appropriate SLAs
  • should include reviewing the Continuous Assurance Platform for a single pane of glass review

Upstream base image vulnerabilities

It is a known issue that some common base images have vulnerabilities that can only be fixed by the upstream maintainers.

It is not considered an appropriate exception to not patch vulnerabilities in container images because of upstream problems.

Please work with CISD and your architects to ensure secure base images are used, either by finding appropriate secure base images, by building your own images or other means such as muiti-stage docker builds

To ensure that vulnerabilities in container images are patched within appropriate timescales teams must either:

Software dependencies

Development teams are responsible for patching software dependencies/libraries.

Your vulnerability management process for software dependencies/libraries:

  • must be documented and approved by an ISO and the vulnerability management lead
  • must include daily monitoring of dependencies
  • must be integrated into CI/CD pipelines and repository monitoring to ensure vulnerable libraries are not pushed to production
  • should be automated wherever possible (such as with the use of Dependabot) or other Software Composition Analysis (SCA) tool
  • must ensure that patches are installed within the appropriate SLAs
  • should include reviewing the Continuous Assurance Platform for a single pane of glass review

Static analysis software testing (SAST)

Development teams are responsible for assessing and fixing confirmed vulnerabilities raised by SAST scans.

Your vulnerability fixing process for SAST scans:

Dynamic analysis software testing (DAST)

Development teams are responsible for assessing and fixing confirmed vulnerabilities raised by DAST scans.

Your vulnerability management process for DAST scans:

  • must be documented and approved by an ISO and the vulnerability management lead
  • must include daily monitoring of DAST scan results
  • must be integrated into CI/CD pipelines and repository monitoring to ensure DAST vulnerabilities found in code are not pushed to production
  • should run scans in CI/CD pipelines against Dev/Test environments before production deployments
  • should include running authenticated scans to ensure the full application is tested
  • must ensure that patches are installed within the appropriate SLAs
  • should include reviewing the Continuous Assurance Platform for a single pane of glass review

Pen testing

Development teams are responsible for assessing and fixing confirmed vulnerabilities raised by penetration tests.

A vulnerability management process for penetration tests must be documented and approved by an ISO and the vulnerability management lead. Penetration tests must be conducted at least once per year or whenever there are significant changes to the application and/or infrastructure.

Output from the penetration tests must include a remediation plan that highlights all of the potential vulnerabilities that have been discovered.

The digital service teams must review the output and triage any issues following DfE approved vulnerability management triage processes.

Threat modelling

Development teams are responsible for producing threat models and mitigating the threats raised by them.

A vulnerability management process for threat modelling must be documented and approved by an ISO and the vulnerability management lead. Threat modelling must be conducted as part of the planning phase of all new feature developments.

Output from the threat models must include a remediation plan that highlights all of the potential threats that have been discovered.

The digital service teams must review the threats and triage any issues following DfE approved vulnerability management triage processes.

Assess

Development teams and Service Owners are responsible for assessing the vulnerabilities, threats and risks associated with a service.

The vulnerability management team are reponsible for escalating vulnerabilities to development teams and their SRO and/or service owner. This could include vulnerabilities that have passed SLA and require immediate attention or vulnerabilities that have been discovered and reported to DfE via the VDP.

The development team must follow a standardised vulnerability triage process.

A risk assessment should be conducted if it's:

  • unclear on how to remediate the vulnerability
  • unclear how long it will take to fix the vulnerability
  • unclear if it will be possible to fix at this time

A new risk must be added to the development team risk register should the issue be assessed. Risks raised on the risk register must be reported to the vulnerability management team and the ISO assigned to the team.

Prioritise

Vulnerabilities must be prioritised based on the SLAs for their risk level. The development teams should incorporate vulnerability remediation activities in their regular sprint planning.

Vulnerabilities that can be fixed via automated means (such as automated pull requests) should be fixed as daily tasks.

Remediate

The development teams are responsible for remediating vulnerabilities in their applications and infrastructure.

Remediation processes:

  • should be automated wherever possible
  • must include risk assessments where necessary
  • must include testing that remediation was successful
  • should have clearly communicated outcomes with stakeholders
  • must be undertaken within DfE mandated SLAs

Monitor

The development teams are responsible for monitoring vulnerabilities, threats, and risks that impact their application.

Development teams:

  • should monitor their automated tests for security issues to make sure they fix vulnerabilities in a timely manner
  • should use the DfE continuous assurance platform (CAP) to monitor for issues raised by SCA, SAST, Azure Defender Alerts, GitHub Secret Scans
  • must produce a vulnerability register should they choose not to use CAP

The vulnerability management team:

  • should subscribe to a threat information service to receive notifications of recently released patches and other software updates
  • must notify the Digital Data Technology (DDT) Senior Management team if vulnerabilities are not mitigated in a timely manner
  • must create a monthly report containing the status of all known vulnerabilities within the department
  • must triage vulnerabilities from the vulnerability disclosure programme to development teams that ensures the teams can fix vulnerabilities within SLAs

Revision history and decision records

Revision table

Date of change Author Review Date Version
2024-12-19 Samuel Pritchard 2025-12-19 v0.1

Approved by

Name Title Date Version
FULL_NAME TITLE YYYY-MM-DD v0.1

Policy updates and decision record

Decision Reason for decision Author (Job title) Date
Critical and high risk issue SLAs are 14 days This aligns with the Cyber Essentials guidelines approved by NCSC Andy Hoy (Vulnerability Management Lead) 2024-03-07

Appendix A: Glossary

Term Meaning in this context
Confirmed vulnerability The vulnerability has been triaged following DfE approved triage processes, has been confirmed as a real vulnerability.
Mitigation A fix that can be put in place (often quickly) to prevent a vulnerable component from being compromised. To make less severe and reduce the risk to DfE.
Remediation The complete fix that will ensure an issue has been completely resolved. Provide a remedy for the vulnerability.