FOSSAry
Definitions for open source, compliance, security, and FOSSA-specific terms — all in one place.
A
Active Security Issue
A vulnerability (CVE) detected in a project that has not yet been resolved or ignored. Active security issues are surfaced in the FOSSA Security dashboard and can trigger policy failures in CI/CD pipelines.
API Token
A credential used to authenticate calls to the FOSSA API or to push analysis results from the CLI and CI integrations. Tokens are created under Account Settings → Integrations and can be Push-Only (write scans) or Full (read and manage org data).
Attribution
License and copyright notices that must be reproduced when you distribute software that includes open source dependencies. FOSSA generates attribution reports and SBOM exports that list the obligations for each dependency in a project.
Audit Log
A timestamped record of significant actions taken across your FOSSA organization, filterable by date, topic, action, and user, and exportable for compliance review.
B
Branch
A named pointer to a specific line of development within a version control system. In FOSSA, projects are analyzed per-branch — each branch can have its own revisions, compliance status, and policy results.
Builds
A build consists of: "resolving" locators using fetchers, saving a list of those resolved locators, and scanning for licenses in the dependencies.
C
Complete Fix
A resolution state for a license or security issue where the underlying problem has been fully remediated — for example, upgrading a dependency to a version that no longer contains the vulnerability or problematic license.
Compliance Issue
An issue raised by FOSSA when a dependency's license violates your organization's policy. Also called a license issue or license compliance issue. Common examples include dependencies using GPL licenses in proprietary software.
Component
Could be a React Component, or a reference to a project dependency (also known as a package).
Container
Containers are units of software packaged with their libraries, dependencies, and other binaries. One major benefit to containers is the reliability of running software in different environments.
Copyleft
Copyleft is a way a creator can make their work open for anyone to use, modify, or distribute so long as any derivative work is bound to the same conditions.
CPE
Common Platform Enumeration — a standardized identifier for software products (vendor, product, version) used by vulnerability databases. FOSSA uses CPE strings to match components to CVEs, including in SBOM import and the public CPE Lookup API.
Custom License Scan
An organization-configured scan that searches your codebase for licenses defined by regular expressions. Custom license scans run on every `fossa analyze`, and matches appear in the FOSSA UI and reports under the name you give them.
Custom Risk Score
An organization-assigned severity score from 0 to 100 that overrides a vulnerability's standard severity. Scores map to Critical (90 to 100), High (70 to 89), Medium (40 to 69), and Low (1 to 39).
CVE
Common Vulnerabilities and Exposures — a publicly disclosed identifier for a specific security vulnerability. CVEs are used by FOSSA to identify and track security issues in your project's dependencies. Each CVE has a unique ID (e.g. CVE-2023-39956) and is assigned a severity score via CVSS.
CVSS
Common Vulnerability Scoring System — a standardized framework for rating the severity of security vulnerabilities on a scale from 0 to 10. FOSSA uses CVSS scores to help teams prioritize which vulnerabilities to address first.
CWE
Common Weakness Enumeration — a community-developed list of software and hardware weakness types (e.g. CWE-79: Cross-site Scripting). In FOSSA, security policies can use CWE allow and deny rules to control which weakness categories trigger policy failures.
CycloneDX
An OWASP standard for machine-readable SBOM documents, commonly serialized as JSON or XML. FOSSA can import and export CycloneDX SBOMs and embed VDR/VEX vulnerability statements in CycloneDX exports.
D
Declared License
A license explicitly stated in a package's manifest file (e.g. the `license` field in `package.json` or `composer.json`). FOSSA treats declared licenses as the primary license signal. Contrast with Discovered License.
Dependency
An open source package that your project relies on, whether declared directly in a manifest or pulled in transitively. FOSSA analyzes each dependency for licenses, vulnerabilities, and quality signals. See also: Direct Dependency and Transitive Dependency.
Dependency Lock
A pinned record of the exact versions of all dependencies (direct and transitive) resolved at a point in time. Lock files (e.g. `package-lock.json`, `yarn.lock`, `Gemfile.lock`) are used by FOSSA to produce deterministic, reproducible scans.
Direct Dependency
Dependencies imported into a project directly by a developer. See also: Transitive Dependency.
Discovered License
All licenses FOSSA identifies by scanning a dependency's source code files, including any licenses found beyond what is declared in the manifest. Discovered licenses provide a more complete picture of a dependency's license obligations than the declared license alone.
Dual / Multi-License
A project has a Dual or Multi-license if the user can choose between two or more licenses to adhere to. For example, Rust's error-stack is licensed as either Apache-2.0 or MIT.
E
Edge
A directed connection between two nodes in a dependency graph, representing that one dependency depends on another. Edges encode the direct and transitive relationships FOSSA uses to build a project's full dependency tree.
EPSS
Exploit Prediction Scoring System — a data-driven model that quantifies the probability of a CVE being exploited in the wild, using signals such as code execution context, CVE age, and known exploits. FOSSA surfaces EPSS scores to help teams prioritize vulnerabilities by real-world risk rather than severity alone.
F
Fetcher
The component of the FOSSA backend responsible for downloading a dependency's source code so its licenses can be detected. Each ecosystem or source has its own fetcher (for example npm, gem, git, go, mvn, pip, cargo, and archive), plus a custom fetcher for projects uploaded through the CLI. The first segment of a locator, the part before the "+", names which fetcher applies to that package: in npm+express$4.18.2, the npm fetcher retrieves express from the npm registry for license analysis.
FOSSA
An acronym for Free and Open Source Software Analysis. Also a cat-like carnivoran mammal from Madagascar.
fossabot
A FOSSA service account used for deep integrations with source hosts (for example Bitbucket Server application links). fossabot enables webhooks, scheduled re-scans, and pull request status checks on imported repositories.
H
Helm / Helm Charts
Helm is a tool that helps manage Kubernetes applications. Helm charts are packages containing YAML resources (deployments, services, secrets, config maps) that define the desired state of an application in a Kubernetes cluster.
Hubble
Internal FOSSA service that handles the backend resolution of analyses.
I
Ignored Security Issue
A vulnerability (CVE) that has been reviewed and deliberately suppressed in FOSSA. Ignored issues are excluded from policy checks and compliance reports. Ignores can be scoped to a single project revision, all versions of a package, or set to expire after a time period.
Issue
A policy violation detected by FOSSA in a project revision. Issues can be compliance issues (license violations), security issues (CVEs), or quality issues. Each issue has a status — active, resolved, or ignored — and can trigger CI/CD failures when unresolved.
Issue Scanner
A FOSSA configuration that controls whether licensing, security, or quality issues are detected for projects, which policy applies, and whether unresolved issues fail CI/CD checks. Defaults are set at the organization level and can be overridden per project.
L
License Conclusion
The process of determining a single dominant license per dependency by combining declared and discovered license data. License Conclusion drives policy evaluation and mirrors the SPDX `PackageLicenseConcluded` field.
License Correction
An organization-wide override that adds, changes, or removes license data on a dependency so FOSSA's detected licenses are accurate across every project and revision.
License Detection
The process by which FOSSA identifies the licenses associated with a dependency. FOSSA uses its license scanner (Themis) to scan source files, README files, and license files, combining declared and discovered license data to produce a complete license picture.
Licensing Policy
A set of rules that tells FOSSA which licenses and dependencies to approve, flag for review, or deny across your organization. Licensing policies raise compliance issues when a dependency violates an active rule.
Locator
FOSSA's internal unique identifier for a package or project. FOSSA's knowledge base, fetchers, and scanners all operate on locators. A locator has the form "<fetcher>+<package>$<revision>". For example, npm+express$4.18.2 identifies version 4.18.2 of the npm package express, and git+github.com/fossas/fossa-cli$abc123 identifies a Git revision of a repository. Projects uploaded through the CLI use the custom fetcher, producing a project locator such as custom+123/some-project-id, where 123 is your organization identifier.
Luge
A small, lightweight, one- or two-person sled.
M
Malicious Dependency
A dependency FOSSA has flagged as malware. Malicious dependencies raise a dedicated issue and a high-severity banner on the dependency.
Managed Dependency
A dependency FOSSA resolves through a package manager or imports from an SBOM, as opposed to a vendored or snippet-detected dependency.
Manual License
A license that has been manually assigned to a dependency by a FOSSA user, overriding the automatically detected license. Manual licenses are useful when FOSSA cannot detect a license or when a custom license agreement exists between your organization and a package author.
N
Neighbor
A node directly connected to a given node by a single edge in a dependency graph, such as an immediate dependency or dependent.
Node
Another name for a vertex in a dependency graph: a single dependency (package). FOSSA represents each resolved dependency as a node, connected by edges to the dependencies it relies on.
O
OIDC Provider
An OpenID Connect identity provider configured in FOSSA so external workloads can authenticate. Each provider defines trust relationships that grant a service account access based on required token claims and audiences.
Open Source
Software in which the original source code is publicly available and contains a license that grants rights to use, modify, and distribute it as users see fit.
Organization
The top-level FOSSA tenant for your company. An organization owns projects, policies, users, teams, and org-wide settings such as default issue scanners, license conclusion, and integrations.
P
Package Inventory
An organization-wide view that aggregates every package detected across all your projects into a single searchable inventory, with usage and vulnerability information for each package.
Package Label
A user-defined label you assign to packages, visible across your organization. Package labels help you group packages, drive filtering, and automate issue management, and are managed in organization settings.
Partial Fix
A resolution state for a license or security issue where some — but not all — affected packages or versions have been remediated. FOSSA tracks partial fixes to give teams visibility into progress without masking remaining risk.
PR Check
A pull request status check reported by FOSSA (often via GitHub) that blocks merges when new license compliance or security issues are introduced. Also called a GitHub status check.
Project
A project refers to a collection of source code. Projects can have dependencies (packages). Each package is its own project. User projects are owned by the organization; package projects live externally (e.g. on GitHub). Projects have branches and revisions.
Project Label
A user-defined label you apply to projects. Project labels let you filter projects on the Projects, Global Issues, and Global Reports pages, and are defined in organization settings.
Provided Project
A project whose dependencies are supplied to FOSSA, an upload project that requires mediated dependencies, rather than resolved by analyzing a build.
PURL
Package URL — a standardized identifier for software packages across registries (`pkg:type/namespace/name@version`). FOSSA uses PURLs in SBOM import and export for precise license and vulnerability matching.
Q
Quality Policy
Rules that evaluate dependency health signals (such as maintenance, popularity, and security posture) and raise quality issues when packages fall below your thresholds.
Quick Import
A FOSSA workflow that connects to a cloud or on-prem version control system and analyzes many repositories at once, automatically configuring webhooks, scheduled re-scans, and pull request checks.
R
RBAC
Role-Based Access Control — FOSSA's permission model that combines an organization role (Admin, Editor, Viewer) with team-scoped roles to control which projects, policies, and settings a user can access.
Release Group
A Release Group bundles multiple project revisions together under a shared policy, allowing teams to track compliance and security across an entire product or release at once. Each release within a group represents a snapshot of the included project revisions at a point in time.
Revision
A specific snapshot of a project at a point in time — typically corresponding to a commit, build, or version tag in version control. FOSSA analyzes and stores results per revision, allowing you to track how compliance and security posture changes over time.
S
SAML
Security Assertion Markup Language, an SSO protocol FOSSA supports for organization authentication, configured under the organization's authentication settings.
SBOM
A Software Bill of Materials (SBOM) is an inventory of the components and dependencies that make up a piece of software. Common SBOM format standards include SPDX and CycloneDX.
SBOM Import
A FOSSA project type created by importing an existing SBOM, such as a CycloneDX file, instead of scanning source code.
SBOM Policy
A set of rules in FOSSA that validates the structure and content of a Software Bill of Materials. SBOM policies can enforce requirements like the presence of vulnerability data (VDR), license information, and package identifiers across CycloneDX or SPDX documents.
SBOM Portal
A FOSSA-hosted portal where an organization can publish and share its SBOM files. Access can be public or controlled with portal tokens.
SCA
Software Composition Analysis (SCA) is an automated process that provides deep analysis of open source software — including its dependencies, licenses, and components.
Security Issues
A CVE (Common Vulnerabilities and Exposures) that has been detected for a project in FOSSA.
Security Policy
Rules that define which vulnerabilities FOSSA should flag or deny based on severity, exploitability, reachability, and other security signals. Security policies drive security issues and can fail CI/CD builds.
Service Account
A non-human FOSSA identity used for API and automation access, including OIDC trust relationships. Service accounts appear alongside users in organization settings.
Shift-left
A quality practice that tightens feedback loops by moving testing, quality, and security conversations earlier in the software development lifecycle (SDLC).
Single Sign-On (SSO)
Organization-level authentication that lets users sign in to FOSSA through an external identity provider. FOSSA supports methods including SAML, Google Workspace, and LDAP, optionally alongside email login.
Snippet Scanning
A FOSSA analysis feature that detects code snippets copied into your codebase from open source projects, surfacing matches that are not tracked as normal dependencies. Snippet results appear in a project's Inventory tab and are subject to source-code retention settings.
SOC 2 (SOCII)
A compliance standard developed by the AICPA that defines criteria for managing customer data based on five principles: security, availability, processing integrity, confidentiality, and privacy. FOSSA undergoes an annual third-party SOC 2 audit.
SPDX
Software Package Data Exchange — an ISO standard for documenting licenses, copyrights, and component metadata in SBOMs. FOSSA can import and export SPDX tag-value and JSON SBOMs.
Sub-component
Could be a transitive dependency or a React component nested within another React component, depending on context.
Successor
In a dependency graph, a node reached by following an outgoing edge from a given node: that node's direct dependency. A dependency's successors are the packages it directly requires.
T
Team
A group of FOSSA users with shared access to a set of projects and release groups. Team roles scope permissions within that group without granting org-wide access.
Themis
Themis is the FOSSA license scanner. It scans files for license and copyright information.
Transitive Dependency
Dependencies not directly imported into a project — they may be imported by a direct dependency or another transitive dependency. See also: Direct Dependency.
U
Upgrade Distance
How far a dependency must be upgraded, by major, minor, or patch version, to remediate a vulnerability. FOSSA uses upgrade distance to help prioritize fixable vulnerabilities.
V
VDR
Vulnerability Disclosure Report — structured vulnerability metadata (such as CVE details) embedded in CycloneDX SBOM exports. FOSSA can include VDR entries for open or closed security issues.
Vendored Dependency
A dependency whose source code is copied directly into your repository rather than pulled from a package manager. FOSSA can detect vendored dependencies and flag snippet matches against them.
Vertex
A single point in a dependency graph. In FOSSA's dependency graphs each vertex represents one dependency (package). Vertex and node are used interchangeably.
VEX
Vulnerability Exploitability eXchange — a standard for documenting why a known CVE is not exploitable in your environment. FOSSA records VEX justifications when you except vulnerability issues and can embed them in CycloneDX SBOMs.
Vulnerability
A weakness in software that may be exploitable, commonly tracked with a CVE identifier and severity score. FOSSA maps vulnerabilities to dependencies and surfaces them as security issues against your security policy.