How to triage vulnerabilities

This guide is here to assist services in triaging application security defects and to help them identify where issues are and how to appropriately deal with them based on risk levels.

Sources of security defects

A security defect can come from a number of different tools, some of which are supported by CISD in terms of reporting and maintenance. Defects could also be reported to teams via the Vulnerability Disclosure Programme, or through a scheduled pen test.

GHAST = GitHub Advanced Security Tab
CAP = Continuous Assurance Platform

Source	Tool(s)	Locations	Supported by CISD?
Software Composition Analysis (SCA)	Dependabot	GHAST/CAP	Yes
Static Application Security Testing (SAST)	CodeQL SonarCloud Semgrep	GHAST/CAP GHAST/CAP CAP	Yes Yes Yes
Secret Scanning	GitHub Secret Scanning	GHAST/CAP	Yes - Public repos only
Vulnerability Disclosure Programme (VDP)	Reports submitted via Hackerone	Team preferred communication	Yes
Penetration Tests	Reports submitted to team	N/A - Digital Service Lead	Yes - mitigation plan

Monitoring for security defects

Application security defects produced by tooling such as SCA, SAST and Secret Scanning are discovered automatically and sent to central locations for analysis by the team. Digital Service teams must monitor their GitHub Security tabs and/or the Continuous Assurance Platform for their services regularly to ensure that any potential security vulnerabilities are fixed in a timely manner and within DfE SLAs for their associated risk level.

GitHub Advanced Security Tab

The GitHub Advanced Security tab is where the majority of your regular application security defects are likely to be displayed, the tab also allows you to dismiss vulnerabilities that you consider to be fixed/false positive/within risk tolerances.

Issues will only show in this tab for SAST scans if the repository is public - Dependabot will still be shown as it is free for all repos

This will change in future when we procure GitHub Enterprise with Advanced Security.

Continuous Assurance Platform

The Continuous Assurance Platform contains a series of dashboards in Splunk that displays all of the supported tooling output as well as repository security benchmarking. These dashboards can display all relevant issues relating to a repository in order of risk level to help teams to triage and prioritise mitigations.

GitHub Policy as Code reusable workflow

Public repositories

As part of CISDs commitment to helping service teams meet Secure by Design requirements for vulnerability discovery, a reusable workflow was created that runs custom CodeQL SAST scans enabling teams to get started with advanced scanning with little configuration required.

If your repository is public then by default it will scan your code with CodeQL and then it will run Policy as Code against your repository and display the output in the GitHub Actions comments. You can also choose to allow the workflow to "break" builds when the risk tolerance of issues found in your repo are too high, allowing you to review the security tab or continuous assurance platform.

Private repositories

We are aware that although UK Government guidelines state that we should code in the open, there are still cases where we might have some private repositories for security reasons.

In this case, the reusable workflow will opt to run Semgrep against your code, the results of which will create an artifact in the GitHub Actions run, which will be sent to the Continuous Assurance Platform on an overnight schedule ready to be viewed in Splunk the next day. If you would like to view the results immediately, you can download the artifact yourself or view the output in GitHub Actions logs.

Vulnerability Disclosure Programme

The vulnerability disclosure programme (VDP) run by CISD includes

Triaging

Triaging issues involves identifying, prioritising and resolving security defects. DfE expects services do follow a triaging process for all vulnerabilities and for it to be done as part of their normal weekly tasks.

The main objective is to track all defects and to ensure the correct resolution in a timely manner.

Things to consider when triaging issues include:

• whether the defect is valid in the context of the application
• if the defect is worth fixing or if the effort involved is disproportionate to the risk
• how quickly should the issue be fixed? Based on the impact of the issue and the likelihood of it being exploited
• which components are impacted by the vulnerability
• severity of the defect
• what the correct response should be based on the severity?
• what context can be used to help assess the issue? Such as:
• which users could be impacted?
• what type of data is handled by the application (e.g. PII, sensitive student data, secrets, encryption keys)?
• what would be the risk to the organisation if it were to be exploited?

Critical and High risk issues should be assessed and resolved immediately.

Please refer to DfE SLAs to ensure you are complying with expected timeframes for fixing vulnerabilities.

Triage process

DfE CISD recommends that services have triage sessions whenever there is a large number of defects to review. Otherwise, it should be part of everyday BAU tasks for an assigned engineer to review any outstanding issues and have them triaged for fixing or for the product manager to put the time into the sprint planning.

For larger security defect sessions, you may want to include:

• product owner/manager
• lead dev
• other developers

1. Defect review

Firstly, review all of the issues starting with the most critical.

Reviewing a defect means:

• checking to see if the issues are real security vulnerabilities or whether they are false positives
• assessing if the issue has risen due to a poorly designed feature and if it could exist in other places
• deciding if a new pattern or library needs to be produced or adjusted
• determining the mitigation that needs developing and suggesting how long the fix should take to produce.

2. Defect assessment

Once you've reviewed the defects, make sure that you have ordered them in terms of risk level.

If there are multiple issues with the same risk level, you can order them based on:

• effort and time to fix
• likelihood of exploitation

3. Mitigation assignment

The final step involves assigning the issue to an engineer for fixing, including sizing and other processes for ticket creation (different based on the team's own agile processes).

How to dismiss a finding in GitHub

Findings that are found to be False Positives or that have been Fixed must be closed in the GitHub Security tab.

You should:

• mark the alert as a False Positive in the GitHub security tab and add an appropriate reason, GitHub should automatically recognise that it's been fixed - if it does not, you can close it as fixed manually
• add the Jira/Trello/DevOps ticket number to the comment for tracking purposes

Critical and High severity defects must only be dismissed as “False Positive”, “Won’t Fix” or “Rejected“ with the CISD team guidance.

Teams must not dismiss Critical and High defects without an appropriate reason and without agreeing with the Security Architecture Team.