Introduction

The FOLIO open source project takes security very seriously. As with any software efforts security vulnerabilities will be discovered over time. These could originate with the FOLIO code itself or appear in third party dependencies.  In either case it is important to resolve security vulnerabilities as soon as possible. 

This document describes the policies to which the FOLIO project will conform with regards to the discovery of such vulnerabilities. It covers how they are to be reported, evaluated and communicated - both within the project and the broader community. While the desire is to remain as open as possible with the reporting of vulnerabilities, it is recognized that not all vulnerabilities carry the same risk and impact. Consequently, disclosures of vulnerabilities may be embargoed for a short period of time. Ultimately, the goal is to provide and announce workarounds and resolution as soon as possible without putting production instances at risk.

Definitions

• Security Vulnerability: a defect which might allow an attacker to compromise a Folio system or its operations. Such compromises would include, but not are not limited to: unauthorized data access or destruction; denial of service attacks; arbitrary code execution; adding unauthorized functionality to a Folio system. 
• Exploit: an exploit is a recipe or tool that has been created around a security vulnerability thus elevating it from theoretical to practical.
• Zero-Day: A zero-day vulnerability or exploit is one which as been discovered but not yet reported. As such it presents the greatest risk since no known workarounds or resolutions have been established.
• Embargo. A reported defect may not be publicly revealed due to its high sensitivity, risk or scope, in which case it is said to be embargoed.

Reporting and Tracking Security Vulnerabilities

Security vulnerabilities may be discovered in a number of ways. Some may be discovered directly by developers or during testing and thus be known from the onset to be security related defectsdefect. In other circumstances a previously reported defect may be recognized to be security related at a later time.

Reporting security vulnerabilities via email.

Potential security related defects and vulnerabilities can be communicated to the project using the email address security@folio.org. This is a no-reply email address that will capture the report for triage purposes and notify the Security Team.  It’s the responsibility of the Security Team to handle vulnerabilities reported this way.

Reporting security vulnerabilities directly in Jira

FOLIO implements defect tracking in Jira. In particular the SECURITY Jira project is used to track the complete report workflow.. 

For any Folio Jira user:

• Any newly reported defect that is believed to be security-related should be tagged with the “Security” label, in the relevant project.
• Any existing defect that is discovered to be security-related should be tagged with the “Security” label in the relevant project.
• Any newly-reported defect that is deemed to pose a significant risk should be filed directly against the SECURITY Jira project where it will be automatically embargoed. 
• Only the FOLIO Security Team has read access to the SECURITY project
• Reported security defects will be triaged by the Security Team. 

Security Team

The FOLIO Security Team consists of a group of individuals who have been selected by the FOLIO project to oversee the identification and resolution of security vulnerabilities reported against FOLIO. The FOLIO Security Team works in close collaboration with the Technical Council and the development team of the affected component. The composition of the Security Team is determined by the FOLIO project governance bodies.

The first responsibility of the Security Team is to perform a triage of reported security vulnerabilities. Each reported security defect is evaluated by the team according to several criteria in order to establish its severity. See Triage Process section.

• Reported vulnerabilities will either be moved to the active vulnerability list, or be rejected.
• Any vulnerability on the active vulnerability list will be assigned a measure of its risk and severity
• Vulnerabilities on the active vulnerability list will be ranked in order of priority.

The second responsibility of the Security Team is to manage the lifecycle of identified security vulnerabilities. This includes maintaining the list of prioritized vulnerability defects, as well as identifying and overseeing the individual or team tasked with resolving the defect. It is the responsibility of the Security Team to declare security vulnerabilities as resolved and communicate their resolution to the public in a responsible manner.

The third responsibility of this team is to provide appropriate notifications to the Folio community and broader public. See also Notifications Mechanisms section below. 

• A brief public facing notification will be made with the acceptance (post-triage) of any newly identified security vulnerability.
• Notifications of workarounds will be distributed once available
• Resolution of vulnerability defects will also produce notifications.

Triage Process

Evaluating reported security vulnerabilities.

The evaluation of reported security vulnerabilities is the responsibility of the Security Team. The goal of triaging is to identify each new vulnerability and establish whether and when it should be: disclosed publicly; disclosed to select groups of stakeholders and appropriate code maintainers; or embargoed.

Multiple factors are taken into account

• Impact. What is the level of damage that could be achieved by an exploit of the vulnerability? (For example, a small issue that affects all modules.) Does it potentially lead to exposing sensitive data?
• Scope. Is the vulnerability isolated to a small part of Folio or does it potentially affect the entire FOLIO system? (For example, an issue that completely exposes all data, but for only one module.)
• Urgency. How easy is it to create a vulnerability? Is this a Zero-Day vulnerability or exploit? (For example: an exploit already exists in the wild for this vulnerability)

The triage process involves managing the SECURITY project and the defects reported within. Furthermore, defects reported in other projects and tagged as “Security” will be reviewed and potentially added to the SECURITY project with a link to the original. Embargoed vulnerabilities will only remain visible in the SECURITY project.

Triaging also includes identifying duplicate reports of security vulnerabilities. This is particularly likely to happen in cases where a previously reported vulnerability has been embargoed and thus not visible to additional reporters.

The result of triage is to produce a reduced set of vulnerability defects which can then be addressed by the appropriate developer or development team in order of priority ranking.

Assigning a vulnerability score

The Common Vulnerability Scoring System (CVSS) can be used to assign a single numeric score to a reported vulnerability. This score may be included as part of any public notification of newly discovered security vulnerabilities. The CVSS score being only a single numeric value does not of itself establish the priority of resolution.

Resolving Vulnerabilities

The resolution of vulnerabilities is the responsibility of developers or development teams. The management and tracking of the resolution is the responsibility of the Security Team.

Once a security vulnerability has been triaged and risk has been assessed, the Security Team links the corresponding SECURITY Jira issue to a mitigation issue in the appropriate project, creating an issue if necessary. The Security Team is then responsible for identifying and notifying the team or individual who will develop the fix.  Access to the issue will be controlled via the “Security Level” field in Jira, particularly in the case of embargoed vulnerabilities.

Providing Workarounds

If a workaround exists for the issue, it should immediately be communicated to the public.

Providing Defect Fixes

Once a fix has been identified and implemented, a patch release should be made for the most recent version of the affected software as soon as possible.

Removing a Vulnerability from Embargo

When a fix or workaround is available, the security issue can be removed from embargo, i.e. can now be viewed by the public. Simultaneously a Notification of the appropriate type (workaround or resolution) will be issued. See Notification Mechanisms for details.

Backporting Policy for Defect Fixes

In addition to patching the most recent version of the affected software, it will often be necessary to backport the fix to earlier versions as well (within reason).

• Security Team’s responsibility is to provide guidance as to the risk, feasibility and necessity of backporting the fix to specific versions.
• Notification will include the set of versions which will provide the fix. 
• Folio project support policies will also inform which versions should receive the fix.

Notifications 

As indicated above it is the responsibility of the Security Team to provide notifications at various points during the vulnerability lifecycle. 

Notification Types

There are three broad categories of notifications.

• Acknowledgment. At acceptance of a new security defect a general acknowledgment of a vulnerability is made to all. It will deliberately not contain any specifics. Includes recognition of third party vulnerabilities.
• Workaround. Description of immediate changes which can be used to mitigate against the vulnerability until a resolution is available.
• Resolution. The approved solution to a security defect

Notification Recipients

The following recipient groups exist with the following order - where the earlier groups are included in the latter.

Security Team

• The Security Team is not a recipient of notifications, it is the source of notifications.

Public

The public at large who have access to the least restrictive notification. Obviously, includes both the Security Team and all FOLIO Project Committees and SIGs.

• Can access unrestricted notifications.
• Has very limited information for embargoed security defects
• Immediate notification of resolution

Notification Mechanisms

Multiple communication channels are available to the project

• Slack channels: private or public 
• Email distribution list(s)
• FOLIO Wiki Security Team Space