This lexicon is intended to provide clear and consistent definitions for terms used in the Open Source Project Security Baseline. These definitions help ensure that criteria are interpreted accurately and consistently across projects.
Code provided by an external source that is executed by a system without validation or restriction.
A series of automated processes that compile and deploy software. Similar to the generic term CI/CD Pipelines, but this term excludes some pipelines, such as pre-merge status checks.
Any alteration of the project's codebase, CI/CD Pipelines, or documentation. This may include addition, deletion, or modification of content.
Automated pipelines for Continuous Integration and Continuous Delivery. Responsible for building, testing, and delivering changes. These pipelines integrate contributions frequently, enabling rapid and reliable software delivery. CI focuses on testing and building code, while CD delivers software to users.
In the context of the Open Source Project Security Baseline, CD refers only to continuous delivery, not to continuous deployment, as sometimes used elsewhere.
Entities who commit code or documentation to the project. Code contributors include collaborators or external participants who submit changes.
In the context of the Open Source Project Security Baseline, code contributors does not address non-code contributions such as designing, triaging, reviewing, or testing.
The collection of source code and related assets that make up the project. The codebase includes all files necessary to build and test the software. Lives in the repository, sometimes alongside documentation and CI/CD pipelines. The contents of the codebase are the primary deliverable in a release.
A user with access to the project's version control system who can commit to the codebase, approve changes, or manage the repository settings. Collaborators may have varying permission levels based on their role in the project.
A record of a single change submitted to the version control system. Each commit includes details such as the modifications made, the contributor who made them, and the timestamp of the change.
Errors or flaws in the software that cause it to produce incorrect or unintended results, or to behave in an unintended way. Defects can include bugs, vulnerabilities, or other issues that impact the software's functionality or security. Defects may have originally been intentional, but a change in environment or understanding has made them undesirable.
Defects in the software that can be leveraged by attackers to gain unauthorized access, execute arbitrary code, or cause other undesired outcomes.
A legal document that defines the terms under which the software can be used, modified, and distributed. May be stored at the top level of the repository in a file named LICENSE or within files in a directory named LICENSE/. The license applies to the codebase and any released software assets, unless otherwise stated.
Publicly acknowledged exploitable vulnerabilities that have been identified within the software. These vulnerabilities often have associated advisories, patches, or recommended mitigations.
An authentication method that requires two or more verification factors (e.g., a password and a token) to gain access to a resource. This method strengthens security by requiring multiple forms of identification.
The main development branch in the version control system, representing the latest stable codebase. Releases are typically made from this branch. Commonly named main or master. In some situations where branches are not featured, a repository with forked repositories will have the original repo acting as as an equivalent to the primary branch.
Written materials related to the project, such as user guides, developer guides, and contribution guidelines. These documents help users and developers understand, contribute to, and interact with the software. At release time, this may include [provenance] information, licensing details, and other metadata.
Information about the origin and history of the released software assets. This may include details about its development, dependencies, vulnerabilities, contributors, and licensing.
- (verb) The process of making a version-controlled bundle of assets available to users.
- (noun) A version-controlled bundle of code, documentation, and other assets made available to users. A release often includes release notes that describe the changes.
Deliverables provided to users as part of a release. These assets can include binaries, libraries, or containers.
A storage location managed by a version control system where the project's code, documentation, and other resources are stored. It tracks changes, manages collaborator permissions, and includes configuration options such as branch protection and access controls.
The process of identifying and cataloging all components and dependencies in a software codebase. SCA is essential for managing security vulnerabilities and ensuring compliance with organizational policies.
Automated tests or validations that run on commits before they are merged. Status checks ensure that any changes meet the project's quality and security standards.
A label assigned to a specific release of the software, such as v1.2.3. Commonly recommended formats are Semantic Versioning or Calendar Versioning.
A tool that tracks changes to files over time and facilitates collaboration among contributors. Examples of version control systems include Git, Subversion, and Mercurial.
The act of identifying and documenting exploitable vulnerabilities in released software assets. This may include privately or openly reporting vulnerabilities to maintainers, security teams, or the public, as well as tracking the resolution of these vulnerabilities.