bip32-descriptors

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 16116 es baseline-3 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/16116/baseline)](https://www.bestpractices.dev/projects/16116)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/16116"><img src="https://www.bestpractices.dev/projects/16116/baseline"></a>


Estos son los criterios de Nivel Base 3. Estos son los criterios de la versión v2026.08.28.

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

        

 Fundamentos

  • General

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

    BIP32 keys, output script descriptors and miniscript, built on btclib

    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 21/21 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando se asigna permisos a un trabajo en un pipeline de CI/CD, el código fuente o configuración DEBE asignar solo los privilegios mínimos necesarios para la actividad correspondiente. [OSPS-AC-04.02]
    Configure los pipelines de CI/CD del proyecto para asignar los permisos más bajos disponibles a usuarios y servicios por defecto, elevando los permisos solo cuando sea necesario para tareas específicas. En algunos sistemas de control de versiones, esto puede ser posible a nivel organizacional o de repositorio. Si no es posible, establezca los permisos en el nivel superior del pipeline.

    Every workflow sets permissions: contents: read at the top, and a job adds a write scope only where it uses it. zizmor's excessive-permissions audit runs in the required lint check. https://github.com/btclib-org/.github/blob/main/README.md#what-every-workflow-does


    ¡Suficiente para una insignia!

    Los flujos de CI/CD que aceptan entradas de colaboradores de confianza DEBEN sanear y validar dichas entradas antes de utilizarlas en el flujo. [OSPS-BR-01.04]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de colaboradores en ejecuciones explícitas de flujos de trabajo. Aunque los colaboradores son generalmente de confianza, las entradas manuales a un flujo de trabajo no pueden revisarse y podrían ser abusadas por una toma de control de cuenta o una amenaza interna.

    A workflow_dispatch input is either mutation.yml's profile, a choice from a fixed list (all, keys or descriptors), or verified-signatures.yml's before and after, which the called workflow reads through env: and refuses unless they are commit shas. A release tag's name is checked against the package version before anything is built. https://github.com/btclib-org/bip32-descriptors/blob/main/.github/workflows/mutation.yml


    ¡Suficiente para una insignia!

    Cuando se crea un lanzamiento oficial, todos los activos dentro de ese lanzamiento DEBEN estar claramente asociados con el identificador del lanzamiento u otro identificador único para el activo. [OSPS-BR-02.02]
    Asigne un identificador de versión único a cada activo de software producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Ejemplos incluyen SemVer, CalVer, o git commit id.

    Every release asset carries the version in its file name, as v2026.10.31's do: the sdist (bip32_descriptors-2026.10.31.tar.gz), the wheel (bip32_descriptors-2026.10.31-py3-none-any.whl), the CycloneDX SBOM (bip32_descriptors-2026.10.31.cdx.json) and the attestation bundle (v2026.10.31.intoto.jsonl). The attestation binds each asset to its digest. https://github.com/btclib-org/bip32-descriptors/releases/tag/v2026.10.31


    ¡Suficiente para una insignia!

    El proyecto DEBE definir una política para gestionar secretos y credenciales utilizados por el proyecto. La política debe incluir directrices para almacenar, acceder y rotar secretos y credenciales. [OSPS-BR-07.02]
    Documente cómo se gestionan y utilizan los secretos y credenciales dentro del proyecto. Esto debe incluir detalles sobre cómo se almacenan los secretos (por ejemplo, utilizando una herramienta de gestión de secretos), cómo se controla el acceso y cómo se rotan o actualizan los secretos. Asegúrese de que la información sensible no esté codificada directamente en el código fuente ni almacenada en sistemas de control de versiones.

    A secret is an environment secret that only the owners reach. A secret kept in any other store is recorded in the REPOSITORY.md of the repository that uses it, and btclib-org/.github's tests/secrets_test.py refuses an unrecorded one. A secret is rotated when an owner changes or an exposure is suspected. The secrets kept outside an environment are rotated before they are a year old, and the list is reviewed yearly. https://github.com/btclib-org/.github/blob/main/README.md#tokens-publishing-scanning


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la integridad y autenticidad de los activos del lanzamiento. [OSPS-DO-03.01]
    Las instrucciones en el proyecto deben contener información sobre la tecnología utilizada, los comandos a ejecutar y la salida esperada. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    SECURITY.md gives the gh attestation verify command for the release assets, and RELEASING.md the check that rebuilds the sdist and the wheel from their tag. https://github.com/btclib-org/bip32-descriptors/blob/main/SECURITY.md#supported-versions


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la identidad esperada de la persona o proceso que crea el lanzamiento del software. [OSPS-DO-03.02]
    La identidad esperada puede estar en forma de IDs de clave utilizados para firmar, emisor e identidad de un certificado sigstore, u otras formas similares. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    The verify command pins the signer and the source: --owner btclib-org, --signer-workflow the organization's reusable-build.yml and --source-ref the release tag, and it compares the certificate's sourceRepositoryIdentifier with this repository's id, which a rename keeps. It passes on the v2026.10.31 sdist, wheel and SBOM. https://github.com/btclib-org/bip32-descriptors/blob/main/SECURITY.md#supported-versions


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una declaración descriptiva sobre el alcance y la duración del soporte para cada lanzamiento. [OSPS-DO-04.01]
    Para comunicar el alcance y la duración del soporte para los activos de software lanzados del proyecto, el proyecto debe tener un archivo SUPPORT.md, una sección "Soporte" en SECURITY.md, u otra documentación que explique el ciclo de vida del soporte, incluyendo la duración esperada del soporte para cada lanzamiento, los tipos de soporte proporcionados (por ejemplo, corrección de errores, actualizaciones de seguridad), y cualquier política o procedimiento relevante para obtener soporte.

    SECURITY.md's Supported versions: only the latest release is supported, a fix ships as a new release, and nothing is backported. https://github.com/btclib-org/bip32-descriptors/blob/main/SECURITY.md#supported-versions


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE proporcionar una declaración descriptiva sobre cuándo los lanzamientos o versiones ya no recibirán actualizaciones de seguridad. [OSPS-DO-05.01]
    Para comunicar el alcance y la duración del soporte para correcciones de seguridad, el proyecto debe tener un SUPPORT.md u otra documentación que explique la política del proyecto para actualizaciones de seguridad.

    SECURITY.md: only the latest release is supported, so a release stops receiving security updates when the next one is published. https://github.com/btclib-org/bip32-descriptors/blob/main/SECURITY.md#supported-versions


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE tener una política que exija que los colaboradores de código sean revisados antes de otorgarles permisos elevados a recursos sensibles. [OSPS-GV-04.01]
    Publique una política exigible en la documentación del proyecto que requiera que los colaboradores de código sean revisados y aprobados antes de otorgarles permisos elevados a recursos sensibles, como aprobación de fusiones o acceso a secretos. Se recomienda que la verificación incluya establecer un linaje justificable de identidad, como confirmar la asociación del colaborador con una organización confiable conocida.

    A grant of write or admin, to any repository of the organization, is an issue in btclib-org/.github that states the reason, and an owner other than the one asking approves it there. https://github.com/btclib-org/.github/blob/main/GOVERNANCE.md#how-a-decision-is-made


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, todos los activos de software compilados lanzados DEBEN ser entregados con una lista de materiales de software. [OSPS-QA-02.02]
    Se recomienda generar automáticamente SBOMs en el momento de la compilación utilizando una herramienta que haya sido verificada para precisión. Esto permite a los usuarios ingerir estos datos en un enfoque estandarizado junto con otros proyectos en su entorno.

    The release is pure Python. Every GitHub release attaches a CycloneDX SBOM generated from the built wheel and covered by the release attestation. v2026.10.31's, bip32_descriptors-2026.10.31.cdx.json, lists btclib, ecc and typing-extensions as required and btclib-secp256k1 as optional. https://github.com/btclib-org/bip32-descriptors/releases/latest


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento que comprenda múltiples repositorios de código fuente, todos los subproyectos DEBEN aplicar requisitos de seguridad que sean tan estrictos o más estrictos que la base de código principal. [OSPS-QA-04.02]
    Cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento debe aplicar requisitos de seguridad según sea aplicable al estado e intención de la base de código respectiva. Además de seguir los requisitos correspondientes de la Línea Base OSPS, esto puede incluir requerir una revisión de seguridad, asegurar que esté libre de vulnerabilidades y asegurar que esté libre de problemas de seguridad conocidos.

    The project has no additional subproject repository: each release is built from this one repository. btclib, ecc and btclib-secp256k1, which it depends on, are released separately from their own repositories, held to the same standard. https://github.com/btclib-org/bip32-descriptors/blob/main/pyproject.toml


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE documentar claramente cuándo y cómo se ejecutan las pruebas. [OSPS-QA-06.02]
    Agregue una sección a la documentación de contribución que explique cómo ejecutar las pruebas localmente y cómo ejecutar las pruebas en el pipeline de CI/CD. La documentación debe explicar qué están probando las pruebas y cómo interpretar los resultados.

    CONTRIBUTING.md's The environment and the gates gives the command that runs the suite, and tests/README.md the integration tests' switches. CONTRIBUTING.md's What gates a merge, and what only reports lists the workflows that run them on every pull request, on main and on a schedule, and which of them gate a merge. https://github.com/btclib-org/bip32-descriptors/blob/main/CONTRIBUTING.md#what-gates-a-merge-and-what-only-reports


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE incluir una política de que todos los cambios importantes al software producido por el proyecto deben agregar o actualizar pruebas de la funcionalidad en un conjunto de pruebas automatizado. [OSPS-QA-06.03]
    Agregue una sección a la documentación de contribución que explique la política para agregar o actualizar pruebas. La política debe explicar qué constituye un cambio importante y qué pruebas deben agregarse o actualizarse.

    The policy is 100% line and branch coverage (CONTRIBUTING.md, standard section 8). pyproject.toml sets fail_under = 100, so untested new code fails the required test check. https://github.com/btclib-org/bip32-descriptors/blob/main/pyproject.toml


    ¡Suficiente para una insignia!

    Cuando se realiza un commit a la rama principal, el sistema de control de versiones del proyecto DEBE requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos. [OSPS-QA-07.01]
    Configure el sistema de control de versiones del proyecto para requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos en la rama de lanzamiento o principal. Esto se puede lograr requiriendo que un pull request sea revisado y aprobado por al menos otro colaborador antes de que pueda fusionarse.

    The main-self-merge ruleset requires one approving review from somebody other than the author before any merge to main. It dismisses an approval on a new push. It has no bypass actor. https://github.com/btclib-org/.github/blob/main/README.md#branch-protection-and-rulesets


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar un modelado de amenazas y análisis de superficie de ataque para comprender y protegerse contra ataques en rutas de código críticas, funciones e interacciones dentro del sistema. [OSPS-SA-03.02]
    El modelado de amenazas es una actividad donde el proyecto examina la base de código, procesos asociados e infraestructura, interfaces, componentes clave y "piensa como un hacker" y hace una lluvia de ideas sobre cómo el sistema puede ser vulnerado o comprometido. Cada amenaza identificada se enumera para que el proyecto pueda pensar en cómo evitar proactivamente o cerrar cualquier brecha/vulnerabilidad que pueda surgir. Asegúrese de que esto se actualice para nuevas características o cambios importantes.

    ASSURANCE_CASE.md's Threat model names what is defended, the adversaries and what is not defended, and Trust boundaries maps the attack surface where untrusted input enters, each argument naming the file, test or workflow behind it. https://github.com/btclib-org/bip32-descriptors/blob/main/ASSURANCE_CASE.md#threat-model


    ¡Suficiente para una insignia!

    Cualquier vulnerabilidad en los componentes de software que no afecte al proyecto DEBE ser contabilizada en un documento VEX, complementando el informe de vulnerabilidad con detalles de no explotabilidad. [OSPS-VM-04.02]
    Establezca un feed VEX comunicando el estado de explotabilidad de vulnerabilidades conocidas, incluyendo detalles de evaluación o cualquier mitigación implementada que impida que el código vulnerable sea ejecutado.

    The CycloneDX SBOM a release attaches lists, in its vulnerabilities array, every vulnerability that the tree's .github/vex.toml judges not to affect the release, with the reason. A tree with no such judgement has no vex.toml, and its SBOM has no vulnerabilities key. https://github.com/btclib-org/.github/blob/main/README.md#12-releasing


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE incluir una política que defina un umbral para la corrección de los hallazgos de SCA relacionados con vulnerabilidades y licencias. [OSPS-VM-05.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Análisis de Composición de Software (SCA) relacionados con vulnerabilidades y licencias. Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    The standard sets the threshold: actions/dependency-review-action fails a pull request that adds or changes a dependency with an advisory of moderate severity or above, or with a licence outside the allow-list. Its settings are one file, btclib-org/.github's .github/dependency-review.yml. https://github.com/btclib-org/.github/blob/main/.github/dependency-review.yml https://github.com/btclib-org/.github/blob/main/README.md#tokens-publishing-scanning


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE incluir una política para abordar las infracciones de SCA antes de cualquier lanzamiento. [OSPS-VM-05.02]
    Documente una política en el proyecto para abordar los resultados aplicables del Análisis de Composición de Software antes de cualquier lanzamiento, y agregue verificaciones de estado que comprueben el cumplimiento de esa política antes del lanzamiento.

    release.yml runs uv audit over everything the wheel can require: btclib, ecc and typing-extensions, and through the secp256k1 extra btclib-secp256k1, cffi and pycparser. Every publish job needs it to succeed. An advisory, or a service it cannot reach, stops the release. The only exemption is an id that the tree's own .github/vex.toml, carried into the release's signed SBOM, states as not affecting it. https://github.com/btclib-org/.github/blob/main/README.md#12-releasing


    ¡Suficiente para una insignia!

    Todos los cambios a la base de código del proyecto DEBEN ser evaluados automáticamente contra una política documentada de dependencias maliciosas y vulnerabilidades conocidas en las dependencias, y bloqueados en caso de infracciones, excepto cuando se declaren y se supriman por no ser explotables. [OSPS-VM-05.03]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Análisis de Composición de Software en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    The required lint check audits the whole uv.lock, every dependency group, on every pull request that is not a draft: check_audit.py --all-groups runs uv audit, which reads OSV's malicious-package (MAL-) entries as well as advisories. Any such entry fails the check, and so does an OSV that cannot be reached. The audit's only exemption is a .github/vex.toml entry, reviewed like any other change. The required Dependency review check also blocks a change that adds a dependency with an advisory of moderate severity or above, or a known licence outside the allow-list, apart from the packages dependency-review.yml exempts by name; a dependency with no detected licence is reported but does not fail. https://github.com/btclib-org/.github/blob/main/README.md#12-releasing https://github.com/btclib-org/.github/blob/main/README.md#tokens-publishing-scanning


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE incluir una política que defina un umbral para la corrección de los hallazgos de SAST. [OSPS-VM-06.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Pruebas de Seguridad de Aplicaciones Estáticas (SAST). Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    The standard's section 5 sets a threshold of zero for ruff: select = ALL, bandit's S rules included, and each finding is fixed or suppressed in place with a reason. zizmor holds workflows to the same, in the required lint check. CodeQL runs on every pull request, but the standard sets no threshold for its alerts. https://github.com/btclib-org/.github/blob/main/README.md#5-ruff


    ¡Suficiente para una insignia!

    Todos los cambios a la base de código del proyecto DEBEN ser evaluados automáticamente contra una política documentada de debilidades de seguridad y bloqueados en caso de infracciones, excepto cuando se declaren y se supriman por no ser explotables. [OSPS-VM-06.02]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    The required lint check runs .pre-commit-config.yaml on every pull request (ruff with the S rules, strict mypy, zizmor, detect-secrets) and blocks the merge on any finding not suppressed in place with a reason. CodeQL also runs on every pull request but is not a required check. https://github.com/btclib-org/bip32-descriptors/blob/main/.github/workflows/lint.yml



Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/16116/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consulte nuestro sistema de propuestas de automatización para saber cómo hacerlo. 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 Ferdinando Ametrano y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Ferdinando Ametrano.
Entrada creada el 2026-10-31 10:16:11 UTC, última actualización el 2026-11-01 09:17:08 UTC. Última obtención de la insignia de nivel básico el 2026-11-01 01:50:34 UTC.