/
DR-000046 - Security Dashboard

DR-000046 - Security Dashboard

Submitted Date

Jun 17, 2026

Approved Date

Jun 22, 2026

Status

APPROVED

Impact

MEDIUM

 

Overrides/Supersedes 

NA

RFC 

NA

Stakeholders

  • FOLIO Security Team

  • CC Chairs

    • @Paul Kloppenborg

    • @Tom Cramer

Contributors

  • @Craig McNally

Approvers

Background/Context

The project’s security scanning software is good at identifying vulnerabilities in individual repositories, but does not provide adequate visibility at a higher (project) level.  Snyk and Semgrep do not, for instance, provide a way to easily see/monitor trends in vulnerability counts, vulnerabilities per repository, age of known vulnerabilities, etc.  To close this gap, some scripts were developed which pull information from Snyk each day and push the data into a local Elasticsearch instance.  A dashboard was then developed to visualize the data using Kibana which comes bundled with Elasticsearch.  The local version of this PoC has so far been very helpful for the Security Team.

The problem is that it's presently all running locally on a laptop. This creates a single point of failure, with reliance on one member to perform maintenance and report findings since the rest of the Security team has no way to access the dashboard or Elasticsearch. It also means that there’s a risk of losing the dashboard and historical data if something were to happen to the laptop, something which has already happened once.

The PoC is just a starting point. There are plans to expand this by incorporating information from other sources such as Semgrep, which would provide an even more complete picture of FOLIO’s security posture.

The shell scripts that do the work of gathering the information and inserting it into Elasticsearch will transition to GitHub Actions. While this is out of scope for this DR, it is relevant. This isn’t a hard prerequisite, but aligns directionally with moving this to shared infrastructure.

image-20260615-142646.png
Actual (sanitized) screenshot of the dashboard. Taken from the “Security Team Overview - Who we are and what do we do?” WOLFcon '25 presentation.

Relevant WOLFcon 2025 session resources:

Assumptions

  • Setup and maintenance specifics will need to be worked out with FOLIO DevOps (who will do what)

    • Initial provisioning of the instance, backups, etc?

    • Installation/setup of the necessary tooling (E.g. Elasticsearch)?

    • OS-level patching and upkeep?

    • Restoration from backup if ever needed?

    • Etc.

  • A Compute Savings Plan with 3-year term and no upfront payment can/should be used. (Per @Peter Murray)

  • Built-in/native authentication will be used to restrict access to the Dashboard to FOLIO Security Team members. Each member will have a dedicated user account and credentials.

Constraints

We need to operate within the confines of the Elasticsearch licenses. This shouldn’t be difficult since we’re using this internally and have no plans to monetize this as a SaaS, etc.

AI-generated analysis of the applicability wrt licensing:

Because the FOLIO project is deploying Elasticsearch on project-funded cloud infrastructure solely to monitor its own software telemetry—with no intent to monetize or package it as a commercial service—you are completely clear of any licensing restrictions. [1, 2, 3]

Why This Fits the FOLIO Project Perfectly

  • Fully Open-Source via AGPLv3: Elastic reintroduced the GNU Affero General Public License v3 (AGPLv3) as a licensing option. This is an OSI-approved open-source license. Choosing AGPLv3 keeps your entire project stack aligned with open-source compliance standards. [1, 2, 3]

  • No Risk of "Service" Violations: The restrictive clauses in Elastic's alternative licenses—the Server Side Public License (SSPL) and Elastic License 2.0 (ELv2)—only trigger if you sell Elasticsearch as a managed SaaS product to third parties. Tracking internal FOLIO software operational data does not count as a managed service. [1, 2, 3]

  • Zero License Fees: All security tracking, log parsing, and Kibana dashboarding features needed for this infrastructure are available in the free, default distribution tiers. You will only pay for your underlying cloud compute and storage resources. [1, 2, 3, 4]

NOTE: While this has been reviewed by @Craig McNally as the submitter of this DR, others who are more familiar with licensing should review this for accuracy as well.

Rationale

  • OpenSearch and its dashboarding were considered, but Elasticsearch/Kibana are more mature. Features like Lens make this stack easier to work with.

  • Ideally the ES instance would be set up as a cluster for fault tolerance and redundancy. Given the nature of this data, it’s an acceptable risk to run just a single node as long as we have regular (nightly) backups (to S3) we can restore if needed. This is a cost saving measure.

    • A lengthy retention period is not necessary. Retaining snapshots for up to 2 weeks should be more than enough. This too will help keep costs under control.

  • The m6g.xlarge instance type was a compromise. The less capable m6g.large may suffice, but doesn’t provide much room to grow. As we start to see expanded usage, the m6g.xlarge instance type will give us some breathing room. The m6g.large instance size is recommended for development, while the m6g.2xlarge is recommended as the bare minimum for production. The primary concern here is memory. It is not recommended to use an instance type with less than 8GB of memory and never more than 32GB. The m6g.xlarge instance provides 16GB, right in the middle of that range.

  • Instance types that use graviton processors (those with 'g', like m6g) are cheaper, and known to perform just as well, if not better than instance types that use Intel processors.

Decision

The Technical Council endorses the request from the FOLIO Security Team for a single AWS EC2 instance (specifics below) for the purposes of creating a Security Dashboard. This dashboard will allow the Security Team to consolidate security findings from multiple sources, monitor trends, identify hotspots, and improve visibility into the project’s security posture in general.

Specs:

  • A single EC2 instance (m6g.xlarge) in us-east-1, with corresponding EBS storage volume (200GB), backed up nightly.

  • The “Compute Savings Plan” w/ 3 year term and no upfront payment can/should be used.

  • Estimated cost: $88/month → $1057/year

  • See attached PDF for formal estimation via the AWS Pricing Calculator.

Implications

  • Pros

    • Greater visibility into FOLIO’s security posture

      • Identify and monitor trends/hotspots (E.g. Mean Time To Remediation - MTTR, certain modules with many vulnerabilities, number of vulnerabilities reported each day/week/month/year, breakdown of vulnerabilities by technology stack/language/etc.)

      • Advanced querying

        • Which vulnerabilities have been reported, but not yet in JIRA?

        • Insight into the “age” of individual unpatched vulnerabilities. E.g. “CVE-XXXX-XXXXXX has high severity, was first reported 68 days ago, and has still not been addressed”

    • The dashboard and underlying Elasticsearch indices will be available to all FOLIO Security Team members, removing reliance on any given member.

    • Allows for expansion/improvements - E.g. integrate with Semgrep and other tools FOLIO uses

  • Cons

    • There is a cost associated with this

    • Initial setup will require some effort (e.g. by FOLIO DevOps), though ongoing maintenance and enhancements can be handled by the FOLIO Security Team.

    • By opening the dashboard and underlying Elasticsearch to additional people, there is inherently greater risk of vulnerability information being inadvertently disclosed or exposed. However, the Security Team already has access to this information via the scanner tooling (Snyk/Semgrep/etc.) directly. Furthermore, all members of the team have been vetted and approved by the Technical Council.

    • The dashboard has no HA (High Availability). This was a conscious decision based on cost and the given availability requirements. Planned or unplanned down times are never ideal, but in this situation they’re tolerable.

Other Related Resources