discovery-media-player

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトである場合は、プロジェクトページにベースラインバッジステータスを表示してください!ベースラインバッジステータスは次のようになります: プロジェクト14197のベースラインバッジレベルはbaseline-2です ベースラインバッジを埋め込む方法は次のとおりです:
ベースラインバッジステータスを表示するには、マークダウンファイルに以下を埋め込みます:
[![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)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り(スペースを入れてもよい)としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合(例:ドキュメントだけ、またはテスト専用のプロジェクトの場合)、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください(例:「JavaScript」)。
    Common Platform Enumeration(CPE)は、情報技術(IT)システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

 管理策 24/24

  • 管理策


    ユーザーがプロジェクトの権威リポジトリにある機密リソースを読み取ったり変更したりしようとする場合、システムは多要素認証プロセスの完了をユーザーに要求しなければなりません。 [OSPS-AC-01.01]
    プロジェクトのバージョン管理システムに多要素認証を強制し、協力者が機密データにアクセスしたりリポジトリ設定を変更したりする際に第2の認証形式を提供するよう要求します。パスキーはこの管理として許容されます。

    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]
    バージョン管理システムが集中型の場合は、プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定してください。あるいは、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]
    プロジェクトでは、バージョン管理システムのデフォルトの課題追跡ツールを使用することをお勧めします。外部ソースが使用される場合は、プロジェクトドキュメントと貢献ガイドで報告システムの使用方法を明確かつ目立つように説明してください。プロジェクトドキュメントでは、欠陥がどのようにトリアージおよび解決されるかについての期待値を設定することもお勧めします。

    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.



    アクティブな間、プロジェクトには、提案された変更および使用上の障害に関する公開討論のための1つ以上のメカニズムがなければなりません。 [OSPS-GV-02.01]
    メーリングリスト、インスタントメッセージング、または課題追跡ツールなど、プロジェクト内の公開討論のための1つ以上のメカニズムを確立し、オープンなコミュニケーションとフィードバックを促進してください。

    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]
    OSI(Open Source Initiative)によって承認されたライセンス、またはFSF(Free Software Foundation)によって承認されたフリーライセンスを含むLICENSEファイルをプロジェクトのリポジトリに追加します。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License(LGPL)、およびGNU General Public License(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(Open Source Initiative)によって承認されたライセンス、またはFSF(Free Software Foundation)によって承認されたフリーライセンスであることを確認してください。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License(LGPL)、およびGNU General Public License(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]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用します。リポジトリが公開読み取り可能であることを確認してください。主要なソースを明確にする可視性の高いドキュメントがない限り、リポジトリの複製またはミラーリングを避けてください。リポジトリ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]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用して、公開読み取り可能なコミット履歴を維持します。コミットの作成者が不明瞭になるような方法でコミットをスカッシュまたは書き換えることは避けてください。

    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



このデータは、Community Data License Agreement – Permissive, Version 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にバッジ合格を達成しました。