Skip to main content

FOSSA Guide: Open Source Compliance and Security

1. Introduction: Managing Our Open Source Dependencies​

The XOPS platform is built on the shoulders of giants. We leverage thousands of open source software (OSS) packages to accelerate our development and deliver a world-class product. With this great power comes great responsibility. We must ensure that our use of OSS is compliant with all legal licenses and free from known security vulnerabilities.

FOSSA is our centralized platform for managing open source compliance and security. It automatically scans our codebases, identifies all dependencies (direct and transitive), and checks them against our defined license and security policies.

Core Mission: To enable our developers to use open source freely and safely, while protecting the company and our customers from legal and security risks associated with OSS.

2. Usage in Handbook Sections​

FOSSA is a critical, automated gate in our development process:

  • Platform Operations and Maintenance: FOSSA provides the definitive inventory of all open source software used in our platform, a crucial piece of data for security audits and due diligence.
  • GitHub Actions Guide: The FOSSA scan is a mandatory, non-skippable step in our standard CI/CD pipeline. A build will fail if a high-risk vulnerability or a non-compliant license is detected.
  • Customer Success and QBRs: For enterprise customers who require it, we can generate a Software Bill of Materials (SBOM) from FOSSA to provide transparency into our dependencies.

3. Policy Configuration: Our Rules of the Road​

Our FOSSA policies are designed to be pragmatic, balancing security and legal rigor with development velocity. The policies are managed by the SRE and Legal teams.

  • License Policy: We maintain a "deny list" of licenses that are incompatible with our commercial product.
    • Denied Licenses: Any license that has a "strong copyleft" provision that could require us to open-source our own proprietary code (e.g., GPL-2.0, GPL-3.0, AGPL-3.0).
    • Approved Licenses: Permissive licenses are automatically approved (e.g., MIT, Apache-2.0, BSD).
    • Needs Review: Licenses that require manual review by the legal team (e.g., MPL-2.0).
  • Security Vulnerability Policy: We have a zero-tolerance policy for known vulnerabilities.
    • Build Fail: The CI/CD pipeline will fail if any dependency has a Critical or High severity vulnerability that has a known fix.
    • Alert: A Medium or Low severity vulnerability will generate an alert and a "tech debt" ticket in Jira, but will not block the build.

4. Verbose Workflow: FOSSA in the CI/CD Pipeline​

This workflow shows how FOSSA protects us from a vulnerable dependency being added to the codebase.

  1. Developer Adds Dependency: A developer adds some-cool-library==1.2.3 to their service's requirements.txt file to use a new feature.
  2. Open Pull Request: The developer opens a PR to merge their change into the main branch.
  3. FOSSA Scan Triggers: In the GitHub Actions workflow for the PR, the fossa-scan job runs. FOSSA fetches the code, resolves all dependencies (including transitive ones), and checks them against our policies.
  4. Vulnerability Detected & Build Fails: FOSSA discovers that version 1.2.3 of some-cool-library has a High severity remote code execution (RCE) vulnerability (CVE-2026-12345). Because this violates our security policy, the FOSSA action fails, which in turn fails the entire CI build. The PR is blocked from being merged.
  5. Automated Issue Creation: FOSSA's GitHub integration automatically opens a new Issue in the repository.
    • Title: FOSSA: High-Severity Vulnerability Found in some-cool-library==1.2.3
    • Body: The issue contains details about the vulnerability, a link to the CVE, and a suggested remediation (e.g., "Upgrade to version 1.2.4").
  6. Developer Remediates: The developer sees the failed build and the new GitHub issue. They update their requirements.txt to use some-cool-library==1.2.4, which contains the security fix.
  7. Build Passes: They push the change to their PR, the FOSSA scan re-runs, finds no more critical vulnerabilities, and the build passes. The PR can now be reviewed and merged.

5. Generating a Software Bill of Materials (SBOM)​

An SBOM is a formal, structured list of all software components, libraries, and modules that are part of our platform. It is becoming an increasingly common requirement from large enterprise customers and for regulatory compliance.

How to Generate an SBOM:​

  1. Navigate to the FOSSA UI: Go to the project for the service you need an SBOM for.
  2. Select the Release: Choose the specific release/build that you want to generate the report for.
  3. Export Report: Click on "Export" and choose the desired format. We support the two main industry standards:
    • SPDX (Software Package Data Exchange): A comprehensive format that is an open standard for SBOM information.
    • CycloneDX: A lightweight SBOM standard designed for use in application security contexts.
  4. Deliver to Customer: Provide the exported report to the customer via the secure channel established by the Customer Success team.

This process should only be done upon request and with approval from the Customer Success and Legal teams.