FINOS Explained: Governance, Projects and Common Cloud Controls

FINOS, the Fintech Open Source Foundation, is the Linux Foundation's umbrella organisation for open source software and open standards in financial services. It began as the Symphony Software Foundation, relaunched under the FINOS name on 24 April 2018, and became a Linux Foundation organisation in April 2020. Banks, asset managers, market infrastructure firms and technology companies fund it; a Governing Board, a Technical Oversight Committee and a five stage project lifecycle govern its work.

This guide goes one level deeper than our posts on open source foundation governance models, Linux Foundation and Apache governance and software supply chain controls for banks. Every rule, threshold and date below comes from the FINOS community handbook, project repositories and sites, the Linux Foundation, archived FINOS announcements, the OpenSSF and the text of DORA. Where we could not confirm something, we say so.

Key takeaways

• FINOS describes itself as "an umbrella organization under the Linux Foundation" for financial services. Its about page reports more than 100 member organisations, more than 50 open source projects, open standards and special interest groups, and more than 2,000 contributors.
• Corporate membership has four tiers: Platinum, Gold, Silver and Associate. FINOS members must also be Linux Foundation members. Membership is not required to contribute to an existing project, but only members can propose new projects, standards or special interest groups.
• The Governing Board has one representative per Platinum member, up to five elected Gold representatives and one elected Silver representative, with ranked choice voting. The Technical Oversight Committee (TOC) has 12 members serving two year terms and approves lifecycle transitions.
• The lifecycle, updated in 2026 to align closely with the CNCF maturity model, has five stages: Forming, Labs, Incubating, Graduated and Archived. Labs projects must show OpenSSF OSPS Baseline Maturity Level 1, Incubating projects Level 2 and Graduated projects Level 3.
• Every FINOS software project is licensed under Apache 2.0. Third party dependencies are sorted into Category A (allowed), Category B (allowed with notices) and Category X (not allowed, including every version of the GPL, LGPL and AGPL).
• The responsible disclosure policy routes reports through GitHub private vulnerability reporting or security@finos.org, and now tells maintainers to escalate actively exploited vulnerabilities and severe incidents to the Linux Foundation's CRA steward.
• Common Cloud Controls (CCC) is an open standard of technology neutral controls for public cloud services. Its per service catalogues for object storage, networking, IAM, logging, monitoring and databases were tagged as v2026.06 release candidates on 17 June 2026.
• DORA has applied since 17 January 2025. Article 28 makes financial entities "fully responsible" for compliance when they use ICT third party services. A foundation's governance helps your due diligence; it does not replace it.

What is FINOS?

FINOS's about page says its purpose is "to accelerate collaboration and innovation in financial services through the adoption of open source software, standards and best practices." Its charter mission, quoted on the same page, frames it as a community "designed by regulated industry participants" to solve industry wide problems together.

That description matters for how you read everything else. FINOS is not a general purpose software foundation that happens to host some finance code. It exists because firms that compete with each other in markets have a lot of plumbing in common: desktop applications that need to pass context to each other, trade data that needs a shared model, cloud deployments that every supervisor asks about in nearly the same way, and now AI systems that model risk teams need to approve.

When was FINOS founded, and what was the Symphony Software Foundation?

The history has three steps, and the dates are worth getting right because many secondary sources blur them.

We could not find a primary source that states the exact founding date of the Symphony Software Foundation. Its archived site shows it was active by mid 2016, and the 2018 announcement quotes a firm describing itself as "a founding member of the Symphony Software Foundation", but neither gives a founding day. If you need a precise year for a filing, treat "2016" as approximate.

For scale: the 2020 announcement credited FINOS's "35 members and wider community" and described more than 300 contributors and over 75 repositories. The current about page reports over 100 members and 2,000 plus contributors.

Who are FINOS's members?

FINOS publishes its member list on its website. We do not reproduce names here. By category, the membership includes:

• Sell side institutions: global and regional banks, including investment banks and broker dealers.
• Buy side firms: asset managers, hedge funds and other investment firms.
• Market infrastructure: exchanges, data providers and post trade utilities.
• Technology companies: cloud providers, enterprise software companies, open source vendors and consultancies that build for financial services.
• Individual supporters: people recognised through the Individual Supporter program for significant contributions, who receive certain member benefits without a corporate membership.

The same mix shows up in project governance: Common Cloud Controls steering committee members come from banks, a market data group, an asset manager, a consultancy and an enterprise open source company, and the README says they "hold their seats as individuals, on their own merit."

How is FINOS governed?

FINOS governance has a corporate layer (who funds it and who decides strategy) and a community layer (how projects run day to day). The community handbook's governance page describes both.

Membership tiers and the funding documents

FINOS has "four tiers of corporate membership (Platinum, Gold, Silver and Associate), each with different rights and obligations" under its funding documents. Two documents carry most of the weight:

• The Charter is described as "the Foundation's constitution". It sets out the mission, members' rights and responsibilities, the Governing Board's authority and procedures, and other foundation policies.
• The Participation Agreement is what members sign to join. It sets fees and terms and binds members to the Charter. It also requires FINOS members to be Linux Foundation members at any level and to stay within the Linux Foundation's Good Standing Policy.

The handbook is explicit that participation and membership are different things: "Membership is NOT required to contribute to existing FINOS projects." What membership buys is the right to start things. Only members can propose new software projects, sponsor outside projects, propose standards projects or propose special interest groups.

The Governing Board

The Governing Board oversees the foundation and is led by the FINOS executive director. The composition rules are precise:

Elections use ranked choice voting. Day to day operations are run by the FINOS staff team. The board approves new open standards projects and new special interest groups, approves changes to project governance rules, and each year picks a few "strategic initiatives" that get extra staff attention.

The Technical Oversight Committee

The TOC is "FINOS's technical governing body." It has 12 members drawn from FINOS members and the wider community, each serving a two year term. Its documented responsibilities include maintaining and evolving the lifecycle stage definitions, approving transitions into Incubating, Graduated and Archived, approving new contributions in consultation with the Governing Board, and resolving disputes between maintainers and anyone proposing an archival. FINOS staff, not the TOC, accept new projects into the Labs stage.

Project level governance

Projects are "self-governing" within FINOS policies and the Open Source Definition. The default policy for software projects, published in the FINOS software project blueprint, is a governance by contribution model: "Project maintainers have the last word on technical matters, reaching decisions by consensus if possible and by vote if necessary." Anyone who has made a substantial contribution of any kind can be nominated as a maintainer.

Standards projects are different. New standards projects are recommended to use the Community Specification process, and every participant is bound by its IP rules "even if their only contribution is participation in project meetings." That is why the Common Cloud Controls README requires every participant to sign the Community Specification Contributor License Agreement before joining calls.

Special interest groups are forums rather than code projects. Their documents are published under CC BY 4.0. All projects and SIGs must follow the FINOS Collaborative Principles, the meeting procedures and the Linux Foundation Antitrust Policy, which the handbook says prohibits all potentially anticompetitive conduct. For a foundation whose members compete in the same markets, the antitrust policy is not boilerplate; it is the thing that makes shared work possible at all.

Reporting to the board

Live metrics for every project are public on the FINOS project activity dashboard, and periodic health reports built from them go through the TOC to the Governing Board.

How does the FINOS project lifecycle work?

The lifecycle is the single most useful governance signal for an adopter, because it is visible on every project's README as a badge and because each stage carries written, checkable requirements. The handbook says the lifecycle "serves as a recognition of governance transparency, community health" and of functional and non functional maturity, and that it was "updated in 2026" to align closely with the CNCF maturity model.

The five stages at a glance

Forming

Forming is optional: a Platinum member can work privately with other members "to gauge viability and evaluate interest ahead of formal contribution." Forming projects are not public and are expected to open source within one year, so adopters rarely meet one.

Labs

Labs is the default entry stage for new projects and for hackathon output. Labs projects live in the separate finos-labs organisation precisely so that nobody mistakes them for mature software. Ongoing requirements include development activity since the last health review, LICENSE, NOTICE and CONTRIBUTING files that meet FINOS compliance rules, "use of an automated build and release pipeline when releases are made", released artifacts published under a FINOS namespace, and "Demonstrated adherence to Maturity Level 1 of the Open Source Project Security Baseline".

The handbook's notes for evaluators are refreshingly blunt. A Labs project is "not guaranteed to be 'finished'" from a functional or quality perspective, documentation "may be primitive or non-existent", and backwards compatibility "is unlikely to be a priority."

Incubating

To incubate, a project must keep all Labs requirements and add: at least two maintainers from different organisations, one of which is a FINOS member; active use by at least two financial services organisations; at least one detailed adoption story; consistent use of its CONTRIBUTING workflow; a public roadmap or backlog. Ongoing requirements add public issue tracking, prompt replies, a presentation at a public TOC meeting every six months, "Pre-release integration with a FINOS-approved dependency and license scanner", build and release processes with no "private or undocumented steps", and OSPS Baseline Level 2.

The scanning requirement means an incubating project should already know what it pulls in.

Graduated

Graduation adds the heaviest requirements: adherence to the roadmap during incubation, self sufficiency without significant staff support, a production ready major release announced on the FINOS announce list (v1.0.0 or higher is recommended), maintainers from at least three organisations, active use by at least five organisations with at least three in financial services, two or more public adoption stories, a published responsible disclosure policy, and documentation that starts with a clear financial services value proposition.

Ongoing, a Graduated project must follow semantic versioning from v1.0.0 upward (major for incompatible changes, minor for compatible features, patch for compatible fixes), show OSPS Baseline Level 3, and co-maintain a community sustainability plan with FINOS staff. The handbook adds a caveat adopters should remember: open source projects "do not provide a formal SLA."

Archived

A project is archived when it is "no longer actively developed, for any reason." The handbook says archived projects "may no longer actively address new issues, including security vulnerabilities" and "cannot publish anything, of any kind." Anyone can request archival publicly; if the lead maintainer agrees, or the team does not respond within 14 days, the TOC formalises it. A project with no activity of any kind (releases, commits, pull requests, mailing list traffic, documentation or issue updates) for 180 days becomes eligible.

For a regulated adopter, an archived dependency is a component whose vulnerabilities may never be fixed upstream.

Which projects does FINOS host, and what do they solve?

FINOS hosts two kinds of collaborative project: open source software projects and open standards projects. The full list, with lifecycle stage filters, is on the FINOS landscape. The projects below are the ones most people ask about. We checked each one's repository metadata through the GitHub API on 24 October 2026.

FDC3

FDC3 stands for the Financial Desktop Connectivity and Collaboration Consortium. Its mission is to let desktop applications in financial workflows "interoperate in a plug-and-play fashion, without prior bi-lateral agreements." The standard defines intents (standard verbs one application can ask another to perform), a context data format (so an instrument or contact means the same thing in every application), a REST based App Directory, Desktop Agent API operations and Agent Bridging. The current documentation is for version 3.0.

In practice, choosing an instrument in one application can broadcast that context to charting, research and order entry applications from different vendors. That also makes the desktop agent a message bus between applications with different trust levels, which is worth threat modelling.

Legend

Legend provides "an end-to-end data platform experience covering the full data lifecycle." Its core is Legend Studio, a visual data modelling environment, backed by an execution engine and the Legend Pure language, which the README describes as "an immutable functional language based on the Unified Modeling Language (UML)". Legend can translate models to JSON Schema, Protobuf and Avro, and it builds in constructs for ownership, validation and provenance. FINOS also runs a hosted shared instance for the community. The README carries an Incubating badge and the project publishes a Docker image called legend-omnibus for local trials.

Morphir

Morphir is "a multi-language system built on a data format that captures an application's domain model and business logic in a technology agnostic manner." The idea is that business rules (for example, how a regulatory calculation is defined) are written once, stored in a standard format, and then translated into different languages and platforms instead of being re-implemented by hand in each system.

Common Domain Model

The CDM is "a standardized, machine-readable, and machine-executable model that represents financial products, trades in those products, and the lifecycle events of those trades." It is a standards project with its own dedicated EasyCLA instance, which the handbook mentions alongside FDC3.

What happened to Perspective?

Perspective, a streaming data visualisation component, was long associated with FINOS. The GitHub API now redirects the old finos/perspective repository to perspective-dev/perspective, and that README carries OpenJS Foundation branding and copyright. If your inventory still records Perspective as a FINOS project, update the record: the governance, disclosure contacts and lifecycle rules that apply to it are no longer FINOS's. The handbook explicitly allows projects to "Graduate to another LF foundation (if scope / audience has grown beyond finance)," and this is the kind of move that changes who you call when a vulnerability appears. We did not find a primary source giving the date of the move, so we do not state one.

What are the FINOS Common Cloud Controls?

FINOS Common Cloud Controls (CCC) "is an open standard project that describes consistent controls for compliant public cloud deployments in the financial services (FS) sector." The README says it aims to develop "a unified set of cybersecurity, resiliency, and compliance controls for common services across the major cloud service providers." The project site puts the pitch more directly: controls "written once and usable across every major cloud provider."

Why it exists

Every regulated firm that moves a workload to a public cloud must show its supervisor that storage is encrypted, access is logged and the network is segmented, and each firm has historically written its own version of those controls. CCC's site says cloud platforms "were not designed with the specific requirements of financial services in mind." The fix is a shared baseline firms, providers and auditors can all point at.

How the standard is structured

The project site describes three layers:

1. A Core Catalog: "a foundational baseline of reusable, technology-agnostic threat and control definitions."
2. Technology specific catalogues: one per service type, which import core definitions and add the capabilities, threats and controls specific to that service.
3. Assessment requirements: "Every control ships with tightly scoped, verifiable assessment requirements" that teams can turn into scans, code analysis or behavioural checks in pipelines.

The project's GitHub releases show how far that has gone. On 17 June 2026 the project tagged v2026.06-rc1 release candidates for these service catalogues:

These are release candidates, not final releases, so treat them as near final drafts. The README recommends downloading "the latest release PDF or Markdown for your target service" as the basis for your own organisation's control catalogue.

Compliant Financial Infrastructure

Alongside the catalogues, the Compliant Financial Infrastructure (CFI) work delivers "actual implementations of cloud infrastructure meeting CCC standards" and open source validators that test real deployments against the catalogues. The validators live in the finos-labs organisation, which by the lifecycle rules above means they are Labs stage software: useful and open, but not yet held to incubation requirements.

Governance of CCC

CCC is a standards project led by a Technical Steering Committee, with working groups for communications, security, taxonomy, the website and CFI. Every participant signs the Community Specification Contributor License Agreement before joining calls.

Common Controls for AI Services

The FINOS CCC page also introduces "Common Controls for AI Services", described as an open project "to create technology-neutral baseline standards for AI usage across cloud and hybrid environments," peer reviewed governance frameworks and real time validation mechanisms the page calls "Regulation-as-Code". We did not find a published catalogue release for it, so treat it as early work.

What is the FINOS AI Governance Framework?

The AI Governance Framework is "a comprehensive collection of risks and mitigations that support on-boarding, development of, and running Generative AI solutions" in financial services. The site we fetched carried the date 20 October 2025. The repository is licensed CC BY 4.0, and its README badge shows Incubating.

What is in it

The framework is a catalogue. Risks are grouped as operational, security, and regulatory and compliance. Mitigations are grouped as preventative and detective. Examples of risks on the site include hallucination and inaccurate outputs, foundation model versioning, non-deterministic behaviour, availability of a third party foundation model, information leaked to a vector store, tampering with the foundation model, data poisoning, prompt injection, agent action authorisation bypass, tool chain manipulation and multi-agent trust boundary violations. The site says it maps these to "the EU AI Act, NIST, OWASP, ISO 42001 and others" through a regulatory references index.

Two entries are directly about the software supply chain. "Tampering With the Foundational Model" describes supply chain risks to third party models, including tampering with "training data, model weights, or infrastructure components such as GPU firmware and ML libraries." "Availability of Foundational Model" covers dependence on third party hosted inference. If you are writing an AI third party risk assessment under DORA, those two entries are a reasonable place to start.

How it is meant to be used

The README describes a "deeply practical use-case led approach": pick a realistic use case, threat model it, select mitigations. The group is not building its own models, and the framework covers both in-house models and externally hosted models reached through APIs.

How do FINOS controls relate to regulator expectations?

Neither CCC nor the AI Governance Framework is a regulation, and FINOS does not claim either is endorsed by a supervisor. Their value is that they translate recurring supervisory expectations into shared, testable artefacts. Under DORA, that translation lands on a few specific articles.

DORA in one paragraph

Regulation (EU) 2022/2554, the Digital Operational Resilience Act, was published in the Official Journal on 27 December 2022. Its final article says: "It shall apply from 17 January 2025." EIOPA's summary says it covers 20 types of financial entity as well as ICT third party service providers, and it creates an EU wide oversight framework for critical ICT third party providers.

Article 28 and third party risk

Article 28(1)(a) is the sentence every vendor risk team should know: financial entities using ICT services "shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law." Article 28 then requires:

• an ICT third party risk strategy, reviewed regularly, for entities other than the smallest (Article 28(2));
• a register of information covering "all contractual arrangements on the use of ICT services provided by ICT third-party service providers", available in full to the competent authority on request (Article 28(3));
• before contracting, an assessment of whether the service supports a critical or important function, identification of all relevant risks including concentration risk, due diligence on the provider, and assessment of conflicts of interest (Article 28(4));
• contracting only with providers that "comply with appropriate information security standards" (Article 28(5)).

DORA defines ICT services broadly as "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis", including software or firmware updates provided by hardware vendors.

Where open source fits under DORA

A FINOS library you download and run yourself is not a contract with an ICT third party service provider. There is no counterparty to put in the register. That does not make it a risk free zone. The component still runs inside your ICT systems, and DORA's general ICT risk management framework still applies to it. Commercial products and managed services built on open source, on the other hand, can fall squarely under Article 28.

Foundation governance helps here. A firm documenting why it trusts a FINOS component can point to written, external facts: lifecycle stage, independent maintainer organisations, OSPS Baseline level, disclosure policy and dependency licence categories. Those are the due diligence questions Article 28(4)(d) asks of a vendor, asked of a community.

Common Cloud Controls helps on the cloud side in a similar way. Instead of each firm writing a bespoke control set for a provider's object storage, it can start from the CCC object storage catalogue, map it to its own supervisory obligations, and use the assessment requirements as testable evidence. The CCC site's line for regulators is to "Map your jurisdiction's requirements to a common framework rather than enforcing bespoke interpretations of cloud risk." Whether a given supervisor accepts that mapping is up to the supervisor.

For more on how open source program offices are taking on these duties under the EU's other big law, see our post on the OSPO as open source steward under the Cyber Resilience Act.

How do regulated firms use FINOS for open source governance?

Open Source Readiness

FINOS runs an Open Source Readiness (OSR) initiative and publishes a body of knowledge at osr.finos.org aimed at firms that want to consume and contribute to open source safely. Its article on CLAs and DCOs, for example, explains why contributor agreements exist, the difference between individual and corporate CLAs, and "the practical implications of these for organisations consuming and contributing to open source."

Licence compliance by category

The FINOS licence categories are useful outside FINOS because they mirror the Apache Software Foundation's categories, which many legal teams already know:

The handbook makes every project team responsible for keeping each dependency within these rules "at all times," and warns that "no automated tool can resolve these questions definitively." For an adopter, the practical consequence is good news: a well run FINOS project should not pull a Category X dependency into your product. You should still check, because transitive dependencies change between releases.

OSPO practices

The FINOS rules map onto what a bank's open source program office (OSPO) already does: the lifecycle stage as an intake gate, the licence categories as a starting policy, the DCO and CLA rules for staff who send fixes upstream, and the disclosure policy for routing advisories. None of it replaces your own policy.

What does FINOS require of its projects on security?

Security requirements come from three places: the lifecycle stages (OSPS Baseline levels and scanning), the responsible disclosure policy, and the contribution provenance rules.

OSPS Baseline levels

The OpenSSF Open Source Project Security Baseline is "a set of security controls that projects should meet to demonstrate a strong security posture," organised "by maturity level and category." The baseline site says downstream consumers "should specify their compliance against a specific version." FINOS ties Labs to Level 1, Incubating to Level 2 and Graduated to Level 3. The lifecycle pages do not name a baseline version, so if you rely on this mapping in a policy, record the baseline version you checked against. Our OpenSSF explainer covers the baseline and the OpenSSF's other guidance in more depth.

Dependency and licence scanning

From Incubating onward, projects must integrate "a FINOS-approved dependency and license scanner" before release. The handbook's code validation page lists the scanners FINOS provides across languages for licence checks, legal reports, code scanning, library vulnerability checks and test coverage. Incubating and Graduated projects should be able to tell you what scanning they run.

Responsible disclosure

The FINOS Security Vulnerabilities Responsible Disclosure Policy sets the process:

1. Reporters go to the project's security tab at github.com/finos/project-name/security, read any SECURITY.md, and use "Report a vulnerability" where enabled.
2. If private reporting is not enabled, they email a maintainer listed in MAINTAINERS.md and copy security@finos.org; if no maintainer email exists, they write to security@finos.org directly.
3. Nobody opens a public issue. The policy says "Commit messages should not make ANY reference to the security nature of the commit."
4. Maintainers fix the issue in a temporary private fork created from the draft advisory, request a CVE through GitHub, release the fix, backport it to supported release lines where appropriate, and then publish the advisory.

The policy also says FINOS "does not operate a bug bounty program."

CRA escalation

The most recent addition is CRA escalation. FINOS projects "are supported under the Linux Foundation CRA stewardship framework." Maintainers must escalate to the Linux Foundation steward, copying security@finos.org, if the project has "reliable evidence that a malicious actor has exploited" a vulnerability, or suffers "a security compromise of the project's own IT infrastructure." Ordinary vulnerabilities "with no evidence of exploitation are not CRA escalation events." Projects must document this in SECURITY.md. For an adopter in the EU, this is the clearest sign of how a FINOS project will behave when something is actively exploited.

Contribution provenance

FINOS software projects use the DCO by default, with sign offs enforced by the DCO2 GitHub App as a required status check. The handbook tells maintainers they "must not" use the app's override to pass a pull request whose commits are not signed off, because "Doing so undermines the policy FINOS relies on for contribution provenance." Labs projects always use the DCO. Projects can use CLAs through EasyCLA when maintainers request it; standards projects use the Community Specification CLA.

Step by step: evaluate a FINOS project for adoption in a regulated environment

The steps below use only public data and standard tools. Replace legend with the project you are assessing. Keep the output: it becomes your due diligence record.

Step 1: Confirm it is still a FINOS project, and its lifecycle stage

Projects move between stages and sometimes leave the foundation. Check the repository and the README badge first.

# Repository metadata: archived flag, last push, licence, and whether it redirected elsewhere
curl -sL https://api.github.com/repos/finos/legend \
  | jq '{full_name, archived, pushed_at, created_at, license: .license.spdx_id}'

# Lifecycle badge in the README (labs, incubating, graduated or archived)
curl -sL https://raw.githubusercontent.com/finos/legend/master/README.md \
  | grep -oE 'badge-(forming|labs|incubating|graduated|archived)' | sort -u

If full_name comes back under a different organisation, the project has moved. If the badge says archived, stop: the handbook says archived projects may not address new vulnerabilities and cannot publish anything. Cross check the badge against the FINOS landscape, because README badges are maintained by hand.

Step 2: Check maintainers and activity

Incubating needs maintainers from two organisations, Graduated from three. Look at MAINTAINERS.md and recent commit authors.

curl -sL https://raw.githubusercontent.com/finos/legend/master/MAINTAINERS.md | head -40

# Distinct commit authors in the last 90 days on the default branch
git clone --filter=blob:none https://github.com/finos/legend.git && cd legend
git log --since="90 days ago" --format='%aN' | sort -u | wc -l

Compare activity with the 180 day inactivity trigger for archival. A project with no commits, releases or issue activity for close to six months is a candidate for archival, whatever its badge says.

Step 3: Check release cadence and versioning

Graduated projects must follow semantic versioning from v1.0.0. Check that releases exist and that they are recent.

curl -sL "https://api.github.com/repos/finos/legend/releases?per_page=10" \
  | jq -r '.[] | "\(.tag_name)\t\(.published_at)\t\(.prerelease)"'

For standards projects like CCC, tags carry a per catalogue version such as storage/object/v2026.06-rc1. Note whether the version you plan to adopt is a release candidate.

Step 4: Check the security policy and advisories

# Is there a SECURITY.md, and does it include CRA escalation guidance?
curl -sL https://raw.githubusercontent.com/finos/legend/master/SECURITY.md \
  | grep -iE 'report a vulnerability|security@finos.org|steward' || echo "No SECURITY.md or no reporting text found"

# Published advisories for the repository
curl -sL https://api.github.com/repos/finos/legend/security-advisories \
  | jq -r '.[] | "\(.ghsa_id)\t\(.severity)\t\(.published_at)\t\(.summary)"'

If an Incubating project has no SECURITY.md, record the gap and ask the maintainers.

Step 5: Check the licence and the dependency licences

The project itself should be Apache 2.0. Confirm the LICENSE and NOTICE files, then generate a software bill of materials (SBOM) for the version you will run and check dependency licences against your own policy.

head -5 LICENSE
cat NOTICE* 2>/dev/null | head -20

# Java projects (Legend, Morphir JVM components): CycloneDX SBOM via the CycloneDX Maven plugin
mvn -q org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
ls target/bom.*

# JavaScript projects (for example FDC3 packages): npm can emit a CycloneDX SBOM
npm sbom --sbom-format cyclonedx > fdc3-sbom.cdx.json

# Python components
pip install pip-audit && pip-audit -r requirements.txt

Check the SBOM's licence fields against the FINOS categories: anything that looks like Category X (GPL, LGPL, AGPL, a proprietary licence) in a FINOS project is a finding to raise upstream.

Step 6: Scan what you will actually run

Scan the exact artifacts you deploy, not just the source tree. If you use the Safeguard CLI, it can scan a directory, a container image or an existing SBOM and write JSON results under ./output:

safeguard scan --dir .
safeguard scan --image finos/legend-omnibus:latest
safeguard scan --sbom target/bom.json

Step 7: Record the decision

Write a short record your second line risk team can read: project, version, lifecycle stage and date checked, maintainer organisations, last release date, SECURITY.md present, advisory history, project licence, dependency licence result, scan result, and who owns updates internally. If the component sits inside a product or service you buy, add it to the information you hold about that ICT third party arrangement under DORA Article 28.

Step by step: contribute a fix to a FINOS project

Suppose your evaluation found a bug, or a dependency that needs bumping. FINOS makes contributing straightforward, but the provenance rules are strict.

For a security vulnerability

Do not open a public issue or pull request. Use the repository's "Report a vulnerability" button, or email a maintainer and copy security@finos.org, as described above. Maintainers will invite you into a temporary private fork to work on the fix.

For an ordinary fix in a DCO project

git clone https://github.com/finos/<project>.git && cd <project>
git switch -c fix/bump-dependency

# Make the change, then commit with a Signed-off-by line (the DCO sign off)
git commit -s -m "Bump dependency to fixed version"

# Forgot to sign off? Amend the last commit
git commit --amend -s --no-edit

# Sign off every commit on the branch since main
git rebase --signoff main

git push origin fix/bump-dependency

The DCO2 check on the pull request confirms every commit has a valid Signed-off-by line.

For a project that uses a CLA

When you open the pull request, the EasyCLA bot checks whether you are covered. If you contribute as part of your job, your company's CLA Manager (usually someone with signing authority) signs the Corporate CLA once and authorises you by GitHub username, email domain or GitHub organisation. The handbook notes that non standards FINOS projects share one EasyCLA group, so being covered for one usually covers you for all of them, while FDC3 and CDM each use a dedicated instance. If the bot does not re-run, comment /easycla on the pull request.

For a standards project

Projects such as CCC require the Community Specification CLA before you even join calls. The CCC README says that raising a pull request to add yourself to its participants.yaml file walks you through the signing process.

How does FINOS compare with OpenSSF, the OpenJS Foundation and the Eclipse Foundation?

These organisations solve different problems, so the comparison is about fit, not rank.

Two relationships are worth spelling out. FINOS consumes OpenSSF output directly: its lifecycle uses the OSPS Baseline, and its handbook asks every maintainer to take the free OpenSSF secure software development courses and to pursue an OpenSSF Best Practices badge. And projects can leave FINOS for another Linux Foundation foundation when their audience outgrows finance, as Perspective's current OpenJS branding shows. See our OpenJS Foundation explainer and our Eclipse Foundation explainer.

Common mistakes

• Treating "FINOS project" as a quality label. A Labs project and a Graduated project are both FINOS projects. The handbook says Labs software is not guaranteed to be finished. Check the badge and the landscape every time.
• Checking the stage once. Health reviews run every six months, and projects can be archived after repeated failures or 180 days of inactivity. Re-check at every major upgrade, and at least twice a year.
• Missing a project that moved. A component can leave FINOS for another foundation. Your inventory, your contacts for vulnerability reports and your licence assumptions should follow it.
• Assuming foundation scanning covers your build. Incubating and Graduated projects scan their own dependencies before release. Your build resolves its own dependency tree, often with different versions. Scan what you ship.
• Confusing CCC release candidates with final releases. The June 2026 catalogue tags are rc1. Fine for building your control set; note the status in anything you show a supervisor.
• Reading DORA as "open source is out of scope". A downloaded library is not a third party contract, but it still runs inside your ICT systems, and products built on open source can be ICT services under Article 28.
• Filing a public issue for a vulnerability. The disclosure policy forbids it. Use private reporting or security@finos.org.

FAQ

When did FINOS join the Linux Foundation?

The Linux Foundation announced on 9 April 2020 that FINOS would become a Linux Foundation organisation and that it had agreed to acquire FINOS's operating assets.

Was FINOS previously called the Symphony Software Foundation?

Yes. The Symphony Software Foundation announced its launch as FINOS on 24 April 2018, broadening its scope from projects around one messaging platform to the whole financial services industry.

Do I need to be a FINOS member to contribute?

No. The handbook says membership is not required to contribute to existing FINOS projects. You must follow the project's DCO or CLA rules. Only members can propose new projects, standards or special interest groups.

What are the FINOS project lifecycle stages?

Forming, Labs, Incubating, Graduated and Archived. The TOC approves moves into Incubating, Graduated and Archived; FINOS staff accept projects into Labs. Each active stage maps to an OpenSSF OSPS Baseline maturity level from 1 to 3.

What licence do FINOS projects use?

Software projects must be licensed under Apache 2.0 and may only depend on Category A or Category B licences. Standards projects use the Community Specification licence and CLA. The AI Governance Framework repository is CC BY 4.0.

What are the FINOS Common Cloud Controls?

An open standard of technology neutral security, resiliency and compliance controls for common public cloud services, organised as a core catalogue plus per service catalogues with testable assessment requirements. Release candidates for eight service catalogues were tagged on 17 June 2026.

How do I report a vulnerability in a FINOS project?

Use the "Report a vulnerability" button on the project's GitHub security tab. If that is not available, email a maintainer from MAINTAINERS.md and copy security@finos.org. Never open a public issue. FINOS does not run a bug bounty.

Does using FINOS projects help with DORA compliance?

It can support it, but it does not deliver it. DORA Article 28 keeps financial entities "fully responsible" for compliance when they rely on ICT third parties. FINOS lifecycle data, disclosure policies and Common Cloud Controls give you documented, external evidence for due diligence and control mapping; the risk assessment is still yours.

Is FINOS a CRA open source steward?

The handbook says FINOS projects are supported under the Linux Foundation CRA stewardship framework, with maintainers escalating actively exploited vulnerabilities and severe incidents to the Linux Foundation steward. If you sell a product containing FINOS code in the EU, you remain the manufacturer for that product.

Where Safeguard fits

Safeguard is not a foundation, a licence clearance service or a cloud control catalogue, and it does not assess a FINOS project's lifecycle stage for you. The fit is on the adopter side, after you have decided to use a component. The FINOS libraries, images and SDKs you run are ordinary dependencies in ordinary repositories and container images. Safeguard can scan them with safeguard scan --dir ., --image <name> for a container image or --sbom <file> for an SBOM you already have, write JSON results under ./output, and show in the platform which of your projects contain a given component and version. Vulnerability matching, reachability analysis and policy gates apply to those components the same way they apply to everything else you ship, which gives a DORA due diligence record something current to point at. Safeguard does not replace the foundation's own disclosure process, does not validate cloud configurations against CCC catalogues, and does not assess AI models against the AI Governance Framework.

A FINOS project can be well governed and still ship a release that carries a vulnerable transitive dependency, and when a project is archived the handbook is clear that new vulnerabilities may never be fixed upstream. The gap between a published fix and your production build, and the gap before a fix exists at all, are where regulated adopters carry most of their open source risk.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The demo uses an npm project; the same ask, approve and test loop applies when the dependency to move sits in an application that embeds FDC3 packages or another FINOS JavaScript library.

Click through it at your own pace, or open it full screen.

Banks often keep build machines and data platforms on internal networks. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal, so a self hosted Legend deployment or an internal build of a FINOS component can be checked where it lives.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. A third party risk analyst preparing a DORA due diligence note could then ask which projects carry a given FINOS component version, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• FINOS: About us
• FINOS home page
• FINOS community handbook: Foundation governance
• FINOS community handbook: Project lifecycle
• FINOS community handbook: Forming stage
• FINOS community handbook: Labs stage
• FINOS community handbook: Incubating stage
• FINOS community handbook: Graduated stage
• FINOS community handbook: Archived stage
• FINOS community handbook: Contribution requirements
• FINOS community handbook: License categories
• FINOS community handbook: DCO on GitHub
• FINOS community handbook: EasyCLA
• FINOS Security Vulnerabilities Responsible Disclosure Policy
• FINOS community handbook: Code validation
• FINOS community handbook: Ensure FINOS project security with LF training and OpenSSF
• Linux Foundation: Fintech Open Source Foundation joins Linux Foundation (9 April 2020)
• Archived FINOS press release: Symphony Software Foundation becomes FINOS (24 April 2018)
• Archived Symphony Software Foundation home page (January 2017 snapshot)
• FINOS Common Cloud Controls project page
• FINOS Common Cloud Controls site
• FINOS Common Cloud Controls README
• FINOS Common Cloud Controls releases
• FINOS AI Governance Framework
• FINOS AI Governance Framework README
• FDC3 introduction
• Legend README
• Morphir
• FINOS Common Domain Model
• Perspective README (perspective-dev)
• FINOS Open Source Readiness: CLAs and DCOs
• OpenSSF Open Source Project Security Baseline
• OpenSSF: About
• OpenJS Foundation: About
• Eclipse Foundation: About
• Regulation (EU) 2022/2554 (DORA), Official Journal text
• EIOPA: Digital Operational Resilience Act

Last reviewed: 24 October 2026. FINOS handbook pages, lifecycle stages and project locations change over time; check the current page and each project's badge before relying on a specific rule.