discovery-media-player

遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法;如果规范或假设是错误的,即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是,遵循最佳做法可以帮助改善项目的成果。例如,一些做法可以在发布之前进行多人评估,这可以帮助您找到其他难以找到的技术漏洞,并帮助建立信任,并希望不同公司的开发人员之间进行重复的交互。要获得徽章,必须满足所有“必须”和“禁止”的条款,满足所有“应该”条款或有合适的理由,所有“建议”条款必须满足或未满足(至少希望考虑)。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表

如果这是您的项目,请在项目页面上显示您的基准徽章状态!基准徽章状态如下所示: 项目14197的基准徽章等级为baseline-2 以下是如何嵌入基准徽章:
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14197/baseline)](https://www.bestpractices.dev/projects/14197)
或者将其嵌入到HTML中:
<a href="https://www.bestpractices.dev/projects/14197"><img src="https://www.bestpractices.dev/projects/14197/baseline"></a>


这些是基准等级1的标准。 这些是标准版本 v2026.02.19。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 常规

    请注意,其他项目可能使用相同的名称。

    Self-hosted document viewer: per-recipient tracked links, reading analytics, live presentation. The core knows nothing about the app hosting it.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”,“BSD-2-Clause”,“BSD-3-Clause”,“GPL-2.0+”,“LGPL-3.0 +”,“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言,请将它们列为逗号分隔值(可选空格),并将它们从最多到最少使用。如果有长列表,请至少列出前三个最常见的列表。如果没有语言(例如,这是仅文档或仅测试项目),请使用单个字符“ - ”。请使用每种语言的常规大小写,例如“JavaScript”。
    通用平台枚举(CPE)是用于信息技术系统,软件和软件包的结构化命名方案。在报告漏洞时,它可用于多个系统和数据库。

 控制 24/24

  • 控制


    当用户尝试读取或修改项目权威存储库中的敏感资源时,系统必须要求用户完成多因素认证过程。 [OSPS-AC-01.01]
    为项目的版本控制系统强制执行多因素认证,要求协作者在访问敏感数据或修改存储库设置时提供第二种形式的认证。通行密钥对于此控制是可接受的。

    The authoritative repository is hosted on GitHub, which requires two-factor authentication for every account that contributes code; accounts that do not enrol lose write access. Sensitive actions on this repository — pushing, changing settings, publishing a release — therefore require a second factor enforced by the platform, and the maintainer account has 2FA enabled.



    当添加新的协作者时,版本控制系统必须要求手动分配权限,或默认将协作者权限限制为可用的最低权限。 [OSPS-AC-02.01]
    大多数公共版本控制系统都是这样配置的。确保项目的版本控制系统在添加协作者时始终默认分配最低可用权限,仅在必要时授予额外权限。

    GitHub grants no write access implicitly. The repository is public, so reading requires no account and no grant at all, and any write role must be assigned per person through an explicit invitation accepted by that person. The repository is owned by a personal account with no organisation-wide default grants and no collaborator teams, so there is no path by which a new collaborator receives more than read access without a deliberate act.



    当尝试直接提交到项目的主分支时,强制机制必须阻止该更改的应用。 [OSPS-AC-03.01]
    如果VCS是集中式的,请在项目的VCS中对主分支设置分支保护。或者,使用去中心化方法,如Linux内核的方法,即先在另一个仓库中提出更改,将更改合并到主仓库需要特定的单独操作。

    main is a protected branch and is the repository default. Changes reach it only through pull requests: a direct push is rejected by the branch protection rule, and the required checks must pass first — lint, typecheck, 1515 tests across 144 files, and the supply-chain guards that verify every GitHub Action is pinned to a commit SHA, that container base images are pinned to a digest, and that the committed browser bundles still match their TypeScript sources.



    当尝试删除项目的主分支时,版本控制系统必须将此视为敏感活动,并要求明确确认意图。 [OSPS-AC-03.02]
    在项目的版本控制系统中对主分支设置分支保护以防止删除。

    main is protected, and GitHub refuses deletion of a protected branch outright rather than prompting for confirmation. It is additionally the repository's default branch, which cannot be deleted at all until another branch is designated as default — a deliberate settings change made by the owner.



    当CI/CD管道接受输入参数时,该参数必须在管道中使用之前进行清理和验证。 [OSPS-BR-01.01]
    CI/CD 流水线应对所有来自不可信来源的元数据输入进行清理(引用、转义或在期望值时退出)。这包括分支名称、提交消息、标签、拉取请求标题和作者信息等数据。

    The only workflow that reads untrusted metadata is .github/workflows/cla.yml, triggered by pull_request_target and issue_comment. Every untrusted value — comment body, comment author login and id, pull request number — is handed to the script through the env: block and read from the environment, never interpolated into a run: line, so none of it can be parsed as shell. All eight workflows were checked: no ${{ github.event.* }} expression is expanded inside any shell command anywhere in the repository.



    当 CI/CD 流水线对不可信代码快照进行操作时,它必须阻止访问特权 CI/CD 凭据和资产。 [OSPS-BR-01.03]
    CI/CD 流水线应将不可信代码快照与特权凭据和资产隔离。特别是,项目应谨慎确保在协作者审查之前构建或执行代码的工作流无法访问 CI/CD 凭据。

    Workflows that run untrusted code hold no privileged credentials, and the workflow that holds credentials never runs untrusted code. ci.yml runs on pull_request with permissions: contents: read only. cla.yml runs with write scopes but checks out the base branch (ref: github.event.repository.default_branch), never the pull request head, so contributor code is never executed under the elevated token. release.yml declares permissions: {} at workflow level and grants the narrowest scope per job; npm publication uses OIDC trusted publishing, so no long-lived registry token exists in the repository to be stolen. All 35 action references across the eight workflows are pinned to 40-character commit SHAs, enforced by a CI guard.



    当项目将URI列为官方项目渠道时,该URI必须仅通过加密渠道交付。 [OSPS-BR-03.01]
    配置项目的网站和版本控制系统使用SSH或HTTPS等加密渠道进行数据传输。确保项目文档中引用的所有工具和域名只能通过加密渠道访问。

    Every official URI is HTTPS: the repository, the homepage and bugs URLs declared in package.json, the security policy, the issue tracker, and every link in README.md, CONTRIBUTING.md, SECURITY.md, SUPPORT.md and the docs/ directory. A scan of the documentation and the manifest found no http:// URL other than loopback addresses used as local development examples.



    当项目将URI列为官方分发渠道时,该URI必须仅通过加密渠道交付。 [OSPS-BR-03.02]
    配置项目的发布管道,仅从使用SSH或HTTPS等加密渠道进行数据传输的网站、API响应和其他服务获取数据。

    Releases travel only over authenticated channels. The npm package is published via OIDC trusted publishing (id-token: write, no stored token), which attaches a signed provenance attestation binding the tarball to the workflow and commit that built it. Container images go to GHCR with build provenance attestations. Source archives are served by GitHub Releases over HTTPS. Container base images are pinned by sha256 digest and all GitHub Actions by commit SHA, each enforced by a CI guard, so the inputs to a release are as authenticated as its outputs.



    项目必须防止在版本控制系统中意外存储未加密的敏感数据,例如机密和凭据。 [OSPS-BR-07.01]
    配置.gitignore或等效文件以排除可能包含敏感信息的文件。使用预提交钩子和自动扫描工具来检测和防止在提交中包含敏感数据。

    Three layers. .gitignore excludes .env and .env.* so the usual carrier never becomes a tracked file. tools/secrets-en-clair.mjs inspects every git-tracked file and refuses seven classes of credential recognisable by form — PEM private keys, AWS access key ids, GitHub, npm and Slack tokens, Google API keys, Stripe live keys — plus Supabase service_role JWTs identified by decoding the token payload, so the publishable key, which is meant to reach a browser, is not flagged. It additionally enforces the convention that in any .env* file a variable whose name denotes a secret carries no value, which catches the credential that has no recognisable form. The guard runs both in CI and in the pre-push hook that npm install places in every clone, so a credential is refused before it reaches the remote rather than reported after. Findings name the file, the line and the kind of credential and never the value, because a CI log on a public repository is itself public. The remote's push protection covers the residual case the local guard cannot see: a secret committed and then removed in a later commit, which still travels in the history.



    当项目发布版本后,项目文档必须包含所有基本功能的用户指南。 [OSPS-DO-01.01]
    为项目的所有基本功能创建用户指南或文档,说明如何安装、配置和使用项目的功能。如果存在任何已知的危险或破坏性操作,请包含高度可见的警告。

    README.md covers installation, configuration and use, opening with a two-minute quickstart. The docs/ directory holds ARCHITECTURE, API, CONFIGURATION (every environment variable, with the rule that a variable absent from the list does not exist), HOST-CONTRACT, MIGRATIONS, RETENTION and RELEASING, indexed by docs/README.md which routes the three audiences — integrators, operators, evaluators — to the right document. examples/ holds runnable integrations for standalone, Express and Vercel, pinned to the current version, with a CI guard that fails if they fall behind what main declares.



    当项目发布版本后,项目文档必须包含缺陷报告指南。 [OSPS-DO-02.01]
    建议项目使用其VCS默认问题跟踪器。如果使用外部来源,请确保项目文档和贡献指南清晰且明显地解释如何使用报告系统。建议项目文档还设定缺陷将如何分类和解决的期望。

    SUPPORT.md states where each kind of report goes, what to include, and why — the version, the deployment shape, the exact URL that misbehaves, and what the server logged. Three issue forms exist: bug_report.yml, feature_request.yml and question.yml. Blank issues are disabled so every report arrives structured. .github/ISSUE_TEMPLATE/config.yml routes security reports away from the public tracker to the policy in SECURITY.md.



    在活跃期间,项目必须有一个或多个机制用于公开讨论提议的更改和使用障碍。 [OSPS-GV-02.01]
    在项目中建立一个或多个公开讨论机制,例如邮件列表、即时消息或问题跟踪器,以促进开放的沟通和反馈。

    The public GitHub issue tracker, with a dedicated Question form alongside bug reports and feature requests, and public pull requests where proposed changes are discussed before merging. Both are open to anyone with a GitHub account. GitHub Discussions is deliberately disabled: the Question issue form serves that role, and .github/ISSUE_TEMPLATE/config.yml records why — the Discussions link previously produced a 404 for anyone who clicked it, from the very page that promises help.



    在活跃期间,项目文档必须包含贡献流程的说明。 [OSPS-GV-03.01]
    创建一个CONTRIBUTING.md或CONTRIBUTING/目录来概述贡献流程,包括提交更改的步骤以及与项目维护者互动的方式。

    CONTRIBUTING.md explains getting set up, running the test benches, what review looks for, how generated files are handled, signing the CLA, commit and branch conventions, and the project's one rule: a behaviour worth keeping is worth a test that fails without it. AGENTS.md records the conventions that are not evident from the file tree, marking which are enforced by a guard and which only by review. CLA.md states the contributor licence agreement, checked automatically on every pull request by .github/workflows/cla.yml.



    活跃期间,源代码的许可证必须符合OSI开源定义或FSF自由软件定义。 [OSPS-LE-02.01]
    向项目的代码仓库添加一个LICENSE文件,其中包含开放源代码促进会(OSI)批准的许可证,或自由软件基金会(FSF)批准的自由许可证。此类许可证的示例包括MIT、BSD 2-Clause、BSD 3-Clause修订版、Apache 2.0、较宽松GNU通用公共许可证(LGPL)和GNU通用公共许可证(GPL)。如果没有其他限制(如专利),发布到公共领域可以满足此控制要求。

    The source is licensed AGPL-3.0-or-later, which is both OSI-approved and classified as free by the FSF. One file is deliberately different: src/bridge.ts, the message contract a host application imports to talk to the player, is MIT — also OSI-approved and FSF-free — so that integrating with the player is not itself encumbered. Both licences meet the definition.



    活跃期间,已发布软件资产的许可证必须符合OSI开源定义或FSF自由软件定义。 [OSPS-LE-02.02]
    如果已发布软件资产包含不同的许可证,请确保它是开放源代码促进会(OSI)批准的许可证,或自由软件基金会(FSF)批准的自由许可证。此类许可证的示例包括MIT、BSD 2-Clause、BSD 3-Clause修订版、Apache 2.0、较宽松GNU通用公共许可证(LGPL)和GNU通用公共许可证(GPL)。请注意,已发布软件资产的许可证可能与源代码的许可证不同。

    The released assets carry the same licences as the source: package.json declares "license": "AGPL-3.0-or-later", and no separate or additional licence applies to the published npm package, the container image, or the GitHub Release archives. Both AGPL-3.0-or-later and the MIT licence covering src/bridge.ts are OSI-approved and FSF-free.



    活跃期间,源代码的许可证必须保存在相应仓库的LICENSE文件、COPYING文件或LICENSE/目录中。 [OSPS-LE-03.01]
    将项目的源代码许可证包含在项目的LICENSE文件、COPYING文件或LICENSE/目录中,以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库,请确保每个仓库都包含许可证文件。

    LICENSE at the repository root holds the full text of the GNU Affero General Public License v3. LICENSE-MIT, alongside it, holds the MIT text covering src/bridge.ts. The project is a single repository, so both files sit at the top level of the only codebase, and README.md links to each from its Licence section.



    活跃期间,已发布软件资产的许可证必须包含在已发布的源代码中,或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中。 [OSPS-LE-03.02]
    将项目的已发布软件资产许可证包含在已发布的源代码中,或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中,以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库,请确保每个仓库都包含许可证文件。

    The files array in package.json lists LICENSE and LICENSE-MIT explicitly, so both are inside every published npm tarball alongside the release assets. Each GitHub Release is cut from a tag whose tree contains both files at the root, and the container image is built from that same tree.



    活跃期间,项目的源代码仓库必须在静态URL上可公开读取。 [OSPS-QA-01.01]
    使用常见的版本控制系统(VCS),如GitHub、GitLab或Bitbucket。确保仓库可公开读取。避免重复或镜像仓库,除非有高度可见的文档说明主要来源。避免频繁更改会影响仓库URL的仓库。确保仓库是公开的。

    The repository is publicly readable without an account at the static URL https://github.com/Juli1artha/discovery-media-player. It is the single authoritative source; there is no mirror or duplicate to create ambiguity about which copy is primary, and the URL has not changed.



    版本控制系统必须包含所有更改的可公开读取的记录,包括谁进行了更改以及更改的时间。 [OSPS-QA-01.02]
    使用常见的版本控制系统(VCS),如GitHub、GitLab或Bitbucket来维护可公开读取的提交历史记录。避免压缩或重写提交,以免掩盖任何提交的作者。

    The full git history is public and complete. Every commit carries its author and timestamp, and every change lands through a pull request whose number is in the commit subject, so the discussion behind a change is reachable from the change itself. History on main is never rewritten: force-pushing is not part of the workflow, and a pre-push hook refuses pushes to a branch whose pull request has already been merged, precisely so that work cannot silently detach from the recorded history.



    当包管理系统支持时,源代码仓库必须包含一个依赖项列表,该列表涵盖直接的语言依赖项。 [OSPS-QA-02.01]
    这可以采用包管理器或语言依赖文件的形式,列举所有直接依赖项,如package.json、Gemfile或go.mod。

    package.json enumerates every direct dependency: one runtime dependency, pdfjs-dist, pinned to an exact version because it is the rendering engine and its upgrade is a decision rather than a routine bump, plus the development toolchain. package-lock.json is committed, so the full transitive graph is resolved and reproducible from a clean npm ci. Dependabot watches three ecosystems — npm, GitHub Actions and Docker — with major upgrades deliberately separated from patches so a major cannot hide inside a grouped pull request.



    活跃期间,项目文档必须包含被视为子项目的任何代码库的列表。 [OSPS-QA-04.01]
    记录由项目生成并编译到发布版本中的任何附加子项目代码仓库。此文档应包括相应代码库的状态和意图。

    Not applicable: the project is a single repository. No subproject codebase is compiled into a release, and nothing outside https://github.com/Juli1artha/discovery-media-player contributes source to the published package or container image, so there is no list of codebases to document.



    活跃期间,版本控制系统中不得包含生成的可执行工件。 [OSPS-QA-05.01]
    删除项目版本控制系统中生成的可执行工件。建议在任何情况下,如果生成的可执行工件对测试等过程至关重要,应该在构建时生成,或单独存储并在特定的、有详细文档记录的管道步骤中获取。

    Every tracked file was checked by content type. The only binary is examples/demo/documents/sample.pdf, a 2 KB sample document that exists so the demo has something to display — a content asset of exactly the kind this control excludes, not an application binary or a library. There are no executables, archives, object files or compiled libraries anywhere in version control.



    活跃期间,版本控制系统中不得包含无法审查的二进制工件。 [OSPS-QA-05.02]
    不要将任何无法审查的二进制工件添加到项目的版本控制系统中。这包括可执行应用程序二进制文件、库文件和类似的工件。这不包括资产,如图形图像、声音或音乐文件以及通常以二进制格式存储的类似内容。

    No compiled or executable artifact is committed. Two generated files are tracked — server/browser.generated.js and server/shared.generated.js, about 23 KB of plain JavaScript in total — because the serverless targets this player is designed for build nothing at deploy time. They are human-readable text that diffs normally in review, each carries a header naming the TypeScript sources it was produced from, and CI rebuilds them on every run and fails if the result differs by a byte from what is committed. A committed bundle therefore cannot diverge from the source it claims to come from, which is the risk this control exists to prevent.



    在活动期间,项目文档必须包含安全联系人。 [OSPS-VM-02.01]
    创建一个security.md(或类似名称)文件,其中包含项目的安全联系人。

    The project offers two private reporting channels, and SECURITY.md documents both: GitHub private vulnerability reporting (the repository's Security tab, "Report a vulnerability") and the direct address security@3d-discovery.fr — with an acknowledgement within 72 hours and an assessment within 7 days. The issue-template chooser points reporters to the private form before anything public. https://github.com/Juli1artha/discovery-media-player/blob/main/SECURITY.md



该数据可在社区数据许可协议 – 许可性,版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据,无论是否经过修改,只要数据接收方在共享数据时提供本协议文本。请注明Julien Arthapignet和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者: Julien Arthapignet.
最后更新于 2026-08-22 00:19:58 UTC, 最后更新于 2026-08-25 12:37:10 UTC。 最后在 2026-08-22 07:59:01 UTC 获得通过徽章。