discovery-media-player

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia base en la página de su proyecto. El estado de la insignia base se ve así: El nivel de insignia base para el proyecto 14197 es baseline-2 Aquí se explica cómo insertar la insignia base:
Puede mostrar el estado de su insignia base insertando esto en su archivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14197/baseline)](https://www.bestpractices.dev/projects/14197)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/14197"><img src="https://www.bestpractices.dev/projects/14197/baseline"></a>


Estos son los criterios de Nivel Base 1. Estos son los criterios de la versión v2026.02.19.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

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

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

 Controles 24/24

  • Controles


    Cuando un usuario intenta leer o modificar un recurso sensible en el repositorio autorizado del proyecto, el sistema DEBE requerir que el usuario complete un proceso de autenticación multifactor. [OSPS-AC-01.01]
    Aplique la autenticación multifactor para el sistema de control de versiones del proyecto, requiriendo que los colaboradores proporcionen una segunda forma de autenticación al acceder a datos sensibles o modificar la configuración del repositorio. Las claves de acceso (passkeys) son aceptables para este control.

    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.



    Cuando se agrega un nuevo colaborador, el sistema de control de versiones DEBE requerir asignación manual de permisos, o restringir los permisos del colaborador a los privilegios más bajos disponibles por defecto. [OSPS-AC-02.01]
    La mayoría de los sistemas de control de versiones públicos están configurados de esta manera. Asegúrese de que el sistema de control de versiones del proyecto siempre asigne los permisos más bajos disponibles a los colaboradores por defecto cuando se agreguen, otorgando permisos adicionales solo cuando sea necesario.

    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.



    Cuando se intenta un commit directo en la rama principal del proyecto, un mecanismo de aplicación DEBE evitar que se aplique el cambio. [OSPS-AC-03.01]
    Si el VCS está centralizado, establezca protección de rama en la rama principal en el VCS del proyecto. Alternativamente, use un enfoque descentralizado, como el del kernel de Linux, donde los cambios se proponen primero en otro repositorio, y fusionar cambios en el repositorio principal requiere un acto separado específico.

    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.



    Cuando se intenta eliminar la rama principal del proyecto, el sistema de control de versiones DEBE tratar esto como una actividad sensible y requerir confirmación explícita de la intención. [OSPS-AC-03.02]
    Establezca protección de rama en la rama principal en el sistema de control de versiones del proyecto para evitar la eliminación.

    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.



    Cuando un pipeline de CI/CD acepta un parámetro de entrada, ese parámetro DEBE ser saneado y validado antes de usarse en el pipeline. [OSPS-BR-01.01]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de metadatos que correspondan a fuentes no confiables. Esto incluye datos como nombres de ramas, mensajes de confirmación, etiquetas, títulos de solicitudes de incorporación e información del autor.

    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.



    Cuando un flujo de CI/CD opera sobre instantáneas de código no confiable, DEBE impedir el acceso a credenciales y activos privilegiados de CI/CD. [OSPS-BR-01.03]
    Los flujos de CI/CD deben aislar las instantáneas de código no confiable de las credenciales y activos privilegiados. En particular, los proyectos deben tener cuidado de garantizar que los flujos de trabajo que compilan o ejecutan código antes de su revisión por un colaborador no tengan acceso a las credenciales de 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.



    Cuando el proyecto lista un URI como un canal oficial del proyecto, ese URI DEBE ser entregado exclusivamente usando canales cifrados. [OSPS-BR-03.01]
    Configure los sitios web y sistemas de control de versiones del proyecto para usar canales cifrados como SSH o HTTPS para la transmisión de datos. Asegúrese de que todas las herramientas y dominios referenciados en la documentación del proyecto solo puedan accederse a través de canales cifrados.

    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.



    Cuando el proyecto lista una URI como un canal de distribución oficial, esa URI DEBE ser entregada exclusivamente usando canales cifrados. [OSPS-BR-03.02]
    Configure el pipeline de lanzamiento del proyecto para que solo obtenga datos de sitios web, respuestas de API y otros servicios que utilicen canales cifrados como SSH o HTTPS para la transmisión de datos.

    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.



    El proyecto DEBE prevenir el almacenamiento no intencionado de datos sensibles no cifrados, como secretos y credenciales, en el sistema de control de versiones. [OSPS-BR-07.01]
    Configure .gitignore o equivalente para excluir archivos que puedan contener información sensible. Use hooks de pre-commit y herramientas de escaneo automatizado para detectar y prevenir la inclusión de datos sensibles en los commits.

    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.



    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir guías de usuario para toda la funcionalidad básica. [OSPS-DO-01.01]
    Cree guías de usuario o documentación para toda la funcionalidad básica del proyecto, explicando cómo instalar, configurar y usar las características del proyecto. Si hay acciones peligrosas o destructivas disponibles, incluya advertencias altamente visibles.

    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.



    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una guía para reportar defectos. [OSPS-DO-02.01]
    Se recomienda que los proyectos utilicen el gestor de incidencias predeterminado de su VCS. Si se utiliza una fuente externa, asegúrese de que la documentación del proyecto y la guía de contribución expliquen claramente y de manera visible cómo usar el sistema de reporte. Se recomienda que la documentación del proyecto también establezca expectativas sobre cómo se clasificarán y resolverán los defectos.

    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.



    Mientras esté activo, el proyecto DEBE tener uno o más mecanismos para discusiones públicas sobre cambios propuestos y obstáculos de uso. [OSPS-GV-02.01]
    Establezca uno o más mecanismos para discusiones públicas dentro del proyecto, como listas de correo, mensajería instantánea o gestores de incidencias, para facilitar la comunicación abierta y la retroalimentación.

    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.



    Mientras esté activo, la documentación del proyecto DEBE incluir una explicación del proceso de contribución. [OSPS-GV-03.01]
    Cree un archivo CONTRIBUTING.md o un directorio CONTRIBUTING/ para delinear el proceso de contribución, incluyendo los pasos para enviar cambios e interactuar con los mantenedores del proyecto.

    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.



    Mientras esté activo, la licencia para el código fuente DEBE cumplir con la Definición de Código Abierto de OSI o la Definición de Software Libre de FSF. [OSPS-LE-02.01]
    Agregue un archivo LICENSE al repositorio del proyecto con una licencia que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Liberar al dominio público cumple con este control si no hay otros gravámenes como patentes.

    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.



    Mientras esté activo, la licencia para los activos de software lanzados DEBE cumplir con la Definición de Código Abierto de OSI o la Definición de Software Libre de FSF. [OSPS-LE-02.02]
    Si se incluye una licencia diferente con los activos de software lanzados, asegúrese de que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Tenga en cuenta que la licencia para los activos de software lanzados puede ser diferente a la del código fuente.

    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.



    Mientras esté activo, la licencia para el código fuente DEBE ser mantenida en el archivo LICENSE, archivo COPYING o directorio LICENSE/ del repositorio correspondiente. [OSPS-LE-03.01]
    Incluya la licencia del código fuente del proyecto en el archivo LICENSE, archivo COPYING o directorio LICENSE/ del proyecto para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

    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.



    Mientras esté activo, la licencia para los activos de software lanzados DEBE estar incluida en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes. [OSPS-LE-03.02]
    Incluya la licencia de los activos de software lanzados del proyecto en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

    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.



    Mientras esté activo, el repositorio de código fuente del proyecto DEBE ser legible públicamente en una URL estática. [OSPS-QA-01.01]
    Use un VCS común como GitHub, GitLab o Bitbucket. Asegúrese de que el repositorio sea legible públicamente. Evite la duplicación o creación de mirrors de repositorios a menos que la documentación altamente visible aclare la fuente principal. Evite cambios frecuentes en el repositorio que impactarían la URL del repositorio. Asegúrese de que el repositorio sea público.

    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.



    El sistema de control de versiones DEBE contener un registro legible públicamente de todos los cambios realizados, quién los realizó y cuándo se realizaron los cambios. [OSPS-QA-01.02]
    Use un VCS común como GitHub, GitLab o Bitbucket para mantener un historial de commits legible públicamente. Evite aplastar o reescribir commits de una manera que oscurecería al autor de cualquier commit.

    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.



    Cuando el sistema de gestión de paquetes lo admita, el repositorio de código fuente DEBE contener una lista de dependencias que contabilice las dependencias directas del lenguaje. [OSPS-QA-02.01]
    Esto puede tomar la forma de un gestor de paquetes o un archivo de dependencias del lenguaje que enumere todas las dependencias directas como package.json, Gemfile o 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.



    Mientras esté activa, la documentación del proyecto DEBE contener una lista de cualquier código base que se considere subproyecto. [OSPS-QA-04.01]
    Documente cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento. Esta documentación debe incluir el estado e intención de la respectiva base de código.

    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.



    Mientras esté activo, el sistema de control de versiones NO DEBE contener artefactos ejecutables generados. [OSPS-QA-05.01]
    Elimine los artefactos ejecutables generados en el sistema de control de versiones del proyecto. Se recomienda que cualquier escenario donde un artefacto ejecutable generado parezca crítico para un proceso como las pruebas, en su lugar debería generarse en el momento de la compilación o almacenarse por separado y obtenerse durante un paso de pipeline específico y bien documentado.

    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.



    Mientras esté activo, el sistema de control de versiones NO DEBE contener artefactos binarios no revisables. [OSPS-QA-05.02]
    No agregue ningún artefacto binario no revisable al sistema de control de versiones del proyecto. Esto incluye binarios de aplicaciones ejecutables, archivos de biblioteca y artefactos similares. No incluye activos como imágenes gráficas, archivos de sonido o música y contenido similar que típicamente se almacena en formato binario.

    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.



    Mientras esté activa, la documentación del proyecto DEBE contener contactos de seguridad. [OSPS-VM-02.01]
    Cree un archivo security.md (o con nombre similar) que contenga contactos de seguridad para el proyecto.

    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



Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Julien Arthapignet y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Julien Arthapignet.
Entrada creada el 2026-08-22 00:19:58 UTC, última actualización el 2026-08-25 12:37:10 UTC. Última obtención de la insignia de nivel básico el 2026-08-22 07:59:01 UTC.