discovery-media-player

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 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».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

 Элементы управления 24/24

  • Элементы управления


    Когда пользователь пытается прочитать или изменить чувствительный ресурс в авторитетном репозитории проекта, система ДОЛЖНА требовать от пользователя прохождения процесса многофакторной аутентификации. [OSPS-AC-01.01]
    Обеспечьте многофакторную аутентификацию для системы контроля версий проекта, требуя от соавторов предоставления второй формы аутентификации при доступе к конфиденциальным данным или изменении настроек репозитория. Для этой меры приемлемы passkeys (ключи доступа).

    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]
    Настройте конвейер выпуска проекта так, чтобы он получал данные только с веб-сайтов, API-ответов и других служб, которые используют зашифрованные каналы, такие как SSH или HTTPS для передачи данных.

    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 или эквивалент для исключения файлов, которые могут содержать конфиденциальную информацию. Используйте pre-commit хуки и автоматизированные инструменты сканирования для обнаружения и предотвращения включения конфиденциальных данных в коммиты.

    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.



    Пока проект активен, он ОБЯЗАН иметь один или несколько механизмов для публичных обсуждений предлагаемых изменений и препятствий в использовании. [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.



    Пока проект активен, лицензия на исходный код ОБЯЗАНА соответствовать определению Open Source от OSI или определению свободного программного обеспечения от FSF. [OSPS-LE-02.01]
    Добавьте файл LICENSE в репозиторий проекта с лицензией, которая является одобренной лицензией Open Source Initiative (OSI), или свободной лицензией, одобренной Фондом свободного программного обеспечения (FSF). Примеры таких лицензий включают 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]
    Если с выпущенными программными активами включена другая лицензия, убедитесь, что это одобренная лицензия Open Source Initiative (OSI) или свободная лицензия, одобренная Free Software Foundation (FSF). Примеры таких лицензий включают 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]
    Используйте общую систему контроля версий (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



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Julien Arthapignet и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Julien Arthapignet.
2026-08-22 00:19:58 UTC, последнее изменение сделано 2026-08-25 12:37:10 UTC. Последний раз условия для получения значка были выполнены 2026-08-22 07:59:01 UTC.