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 defects. 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.

If the Security Team is unable to accurately assess the risk/impact of a security vulnerability, it will engage the appropriate developer or development team to help with assessment.

• The Security Team will provide information about the vulnerability and known exploits in the defect.
• The defect will be assigned to the appropriate development team, setting the owner to the development team's product owner, or technical lead if the team does not have a product owner.
• The Security Team leaves a comment in the defect indicating that the Security Team needs help from the development team assessing the risk/impact, at-mentioning the development team's product owner and technical lead.
• Development teams will set aside some time each sprint to perform these assessments if/when needed.

The expectation is that assessment will occur in a timely fashion.

Targeting releases

Once triage is complete, one or more target releases will be recommended by the Security Team.  A target release will not be recommended until risk/impact are assessed and explained. 

If the recommendation is for a hotfix release, approval is required.  Approvals are requested on an per-flower-release basis and only apply to that release.

• In cases where the problem is specific to a single module, the development team will obtain the required approval and follow the usual release processes.
• In cases where the problem spans multiple modules, the Security Team will engage the release coordinator (Oleksii Petrenko) via the #release_bug_triage Slack channel. 
  • The release coordinator will assist with the approval process and orchestrate the releases across the development teams involved.

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.

Estimated time for a triage process

While most security issues will be triaged during weekly Security Team meetings, it's also the responsibility of the Security Team to recognize when a reported vulnerability needs to be processed more urgently.  When required, internal slack communication and/or ad-hoc meetings will be utilized.

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.

The Security team may recommend a particular resolution, provide the development team with several acceptable options, or leave it entirely up to the development team to decide on the best approach.    

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.

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
  → The nature of the vulnerability will determine which slack channel(s) are used for notifications.  For instance, if remediation and/or workarounds for a vulnerability require action to be taken by system operators, the #sys-ops channel will be used. 
  
• Email distribution list FOLIO Sysops SIG
  
• FOLIO Wiki Security Team Space
  → If warranted, either due to impact, complexity, etc., wiki pages may be created to serve as a place to consolidate information and guidance.  One example of this is Log4Shell.

Notification Timing

The timing of notifications depends on several factors, include the type of notification and urgency of the vulnerability.  Notifications are a shared responsibility among Security Team members.  Availability will dictate which member will send a notification.

• Acknowledgement - response time starts when vulnerability is reported:
  • P1 vulnerability → As soon as possible - within 1 business day.
  • P2 vulnerability → Within 1 week or sooner
  • > P2 vulnerability → explicit notification not required, management and communication is handled within the JIRA issue
• Workaround - response time starts when vulnerability is acknowledged:
  • P1 vulnerability → As soon as possible, but sooner as 2 business days
  •  P2 vulnerability → As soon as available, but sooner as 1 week
  • > P2 vulnerability - explicit notification not required, management and communication is handled within the JIRA issue
  • If there is no additional guidance or workaround to provide within this timeframe, it will be send out a message with an update.
• Resolution:
  •  P1 + P2 vulnerability → As soon as available
  •  > P2 vulnerability → explicit notification not required, management and communication is handled within the JIRA issue

Workflow Diagram