Chances

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 en la página de su proyecto. El estado de la insignia se ve así: El nivel de insignia para el proyecto 15137 es passing Aquí se explica cómo insertarla:
Puede mostrar el estado de su insignia insertando esto en su archivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15137/badge)](https://www.bestpractices.dev/projects/15137)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/15137"><img src="https://www.bestpractices.dev/projects/15137/badge"></a>


Estos son los criterios de nivel Plata. También puede ver los criterios de nivel Básico o Oro.

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

        

 Fundamentos 16/17 ●

  • General

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

    Scientific randomness from declared protocols, with verified arrays, explicit streams, execution receipts and conditional exact replay.

    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.

    Passing is earned. Silver proposals are grounded in merged source and execution evidence at https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/.bestpractices.json . PR #48 prepares authenticated source/distribution publication. Silver remains unearned: dependency findings, completed signed publication, access continuity, vulnerability-report credit, and the historical regression-test denominator remain unresolved. https://github.com/autonomio/chances/pull/48

  • Prerrequisitos


    ¡Suficiente para una insignia!

    El proyecto DEBE lograr una insignia de nivel aprobado. [achieve_passing]

  • Contenido básico del sitio web del proyecto


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBE incluir los requisitos para contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). (URL requerida) [contribution_requirements]

    CONTRIBUTING links the constitution, locked development setup, meaningful review brief, and required quality checks. The constitution defines PR acceptance, coding conventions, and the ten merge gates. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CONTRIBUTING.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CLAUDE.md


  • Supervisión del proyecto


    Apenas suficiente para una insignia.

    El proyecto DEBERÍA tener un mecanismo legal donde todos los desarrolladores de cantidades no triviales de software del proyecto afirmen que están legalmente autorizados para hacer estas contribuciones. El enfoque más común y fácilmente implementado para hacer esto es usando un Certificado de Origen del Desarrollador (DCO), donde los usuarios agregan "signed-off-by" en sus commits y el proyecto enlaza al sitio web DCO. Sin embargo, esto PUEDE implementarse como un Acuerdo de Licencia de Contribuidor (CLA), u otro mecanismo legal. (URL requerida) [dco]
    El DCO es el mecanismo recomendado porque es fácil de implementar, se rastrea en el código fuente, y git soporta directamente una función "signed-off" usando "commit -s". Para ser más efectivo, es mejor si la documentación del proyecto explica qué significa "signed-off" para ese proyecto. Un CLA es un acuerdo legal que define los términos bajo los cuales las obras intelectuales han sido licenciadas a una organización o proyecto. Un acuerdo de asignación de contribuidor (CAA) es un acuerdo legal que transfiere derechos en una obra intelectual a otra parte; no se requiere que los proyectos tengan CAAs, ya que tener CAA aumenta el riesgo de que los contribuidores potenciales no contribuyan, especialmente si el receptor es una organización con fines de lucro. Los CLAs de Apache Software Foundation (la licencia de contribuidor individual y el CLA corporativo) son ejemplos de CLAs, para proyectos que determinan que los riesgos de estos tipos de CLAs para el proyecto son menores que sus beneficios.

    A DCO, CLA, or equivalent contributor authorization mechanism is not currently required or documented. The project retains its MIT license and reviewed contribution process, but those are not represented as developer legal attestations. This SHOULD criterion has been considered; retrospective legal assertions will not be inferred from existing commits, and introducing a contribution-signoff obligation requires an explicit governance decision. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CONTRIBUTING.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/LICENSE https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md


    ¡Suficiente para una insignia!

    El proyecto DEBE definir y documentar claramente su modelo de gobernanza del proyecto (la forma en que toma decisiones, incluyendo roles clave). (URL requerida) [governance]
    Necesita haber alguna forma bien establecida y documentada de tomar decisiones y resolver disputas. En proyectos pequeños, esto puede ser tan simple como "el propietario del proyecto y líder toma todas las decisiones finales". Hay varios modelos de gobernanza, incluyendo dictador benevolente y meritocracia formal; para más detalles, ver Modelos de gobernanza. Tanto los enfoques centralizados (por ejemplo, un solo mantenedor) como los descentralizados (por ejemplo, grupo de mantenedores) se han utilizado con éxito en proyectos. La información de gobernanza no necesita documentar la posibilidad de crear un fork del proyecto, ya que eso siempre es posible para proyectos FLOSS.

    GOVERNANCE identifies maintainers as the decision authority for priority, release timing, review requirements, and project scope. MAINTAINERS assigns responsibilities and names the sole approving authority; CLAUDE defines the enforced contribution and review process. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/GOVERNANCE.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md


    ¡Suficiente para una insignia!

    El proyecto DEBE adoptar un código de conducta y publicarlo en una ubicación estándar. (URL requerida) [code_of_conduct]
    Los proyectos pueden ser capaces de mejorar la civilidad de su comunidad y establecer expectativas sobre la conducta aceptable adoptando un código de conducta. Esto puede ayudar a evitar problemas antes de que ocurran y hacer que el proyecto sea un lugar más acogedor para fomentar contribuciones. Esto debe enfocarse solo en el comportamiento dentro de la comunidad/lugar de trabajo del proyecto. Ejemplos de códigos de conducta son el código de conducta del kernel de Linux, el Código de Conducta del Pacto del Contribuidor, el Código de Conducta de Debian, el Código de Conducta de Ubuntu, el Código de Conducta de Fedora, el Código de Conducta de GNOME, el Código de Conducta de la Comunidad KDE, el Código de Conducta de la Comunidad Python, La Guía de Conducta de la Comunidad Ruby, y El Código de Conducta de Rust.

    The standard root CODE_OF_CONDUCT.md states expected and prohibited behavior, moderation consequences, and the route for reporting conduct issues to maintainers. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CODE_OF_CONDUCT.md


    ¡Suficiente para una insignia!

    El proyecto DEBE definir y documentar públicamente claramente los roles clave en el proyecto y sus responsabilidades, incluyendo cualquier tarea que esos roles deban realizar. DEBE quedar claro quién tiene qué rol(es), aunque esto podría no estar documentado de la misma manera. (URL requerida) [roles_responsibilities]
    La documentación para gobernanza y roles y responsabilidades puede estar en un solo lugar.

    MAINTAINERS names Mikko Kotila as maintainer and assigns release approval, security triage, issue prioritization, and merge decisions. It separately identifies bit-mis as required reviewing authority, with the review and environment activation process linked. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SETUP.md


    Información requerida desconocida, no es suficiente para una insignia.

    El proyecto DEBE poder continuar con una interrupción mínima si cualquier persona muere, queda incapacitada o de otro modo no puede o no está dispuesta a continuar el soporte del proyecto. En particular, el proyecto DEBE poder crear y cerrar issues, aceptar cambios propuestos y lanzar versiones de software, dentro de una semana de confirmación de la pérdida de soporte de cualquier individuo. Esto PUEDE hacerse asegurando que alguien más tenga las claves, contraseñas y derechos legales necesarios para continuar el proyecto. Los individuos que ejecutan un proyecto FLOSS PUEDEN hacer esto proporcionando claves en una caja de seguridad y un testamento que proporcione los derechos legales necesarios (por ejemplo, para nombres DNS). (URL requerida) [access_continuity]

    Unresolved maintainer fact: if either the maintainer or bit-mis becomes unable or unwilling to support the project, can another authorized person create and close issues, accept changes, and release software within one week, including repository/organization administration, release approval, PyPI access, and necessary legal authority? Who owns this continuity role, and where is the recovery procedure documented? Existing admin access alone does not prove publication capability or succession authority. No continuity attestation is inferred. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SETUP.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/.github/CODEOWNERS


    Apenas suficiente para una insignia.

    El proyecto DEBERÍA tener un "factor de autobús" de 2 o más. (URL requerida) [bus_factor]
    Un "factor de autobús" (también conocido como "factor de camión") es el número mínimo de miembros del proyecto que tienen que desaparecer repentinamente de un proyecto ("ser atropellados por un autobús") antes de que el proyecto se paralice debido a la falta de personal conocedor o competente. La herramienta truck-factor puede estimar esto para proyectos en GitHub. Para más información, ver Assessing the Bus Factor of Git Repositories de Cosentino et al.

    Only one current maintainer is publicly documented. Review and organization access do not by themselves establish that a second person has the scientific, security, and release knowledge needed to sustain the project. This SHOULD criterion has been considered: the small project currently retains centralized maintainership and its designated review authority, rather than claiming undocumented staffing or changing reviewer policy to satisfy a badge. Access continuity is assessed separately. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/GOVERNANCE.md


  • Documentación


    ¡Suficiente para una insignia!

    El proyecto DEBE tener una hoja de ruta documentada que describa lo que el proyecto tiene la intención de hacer y no hacer durante al menos el próximo año. (URL requerida) [documentation_roadmap]
    Es posible que el proyecto no logre la hoja de ruta, y eso está bien; el propósito de la hoja de ruta es ayudar a los posibles usuarios y colaboradores a comprender la dirección prevista del proyecto. No necesita ser detallada.

    The roadmap merged in PR #46 covers 2026-10-02 through 2027-10-31 and documents planned capabilities, maintenance priorities, and excluded scope for at least the next year. This source is on protected master. https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/docs/Roadmap.md https://github.com/autonomio/chances/pull/46


    ¡Suficiente para una insignia!

    El proyecto DEBE incluir documentación de la arquitectura (también conocida como diseño de alto nivel) del software producido por el proyecto. Si el proyecto no produce software, seleccione "no aplicable" (N/A). (URL requerida) [documentation_architecture]
    Una arquitectura de software explica las estructuras fundamentales de un programa, es decir, los componentes principales del programa, las relaciones entre ellos y las propiedades clave de estos componentes y relaciones.

    The package boundary documents major modules and their responsibilities, and the documentation hub explains the execution sequence from protocol validation through local generation, output checks, publication, verification, and replay. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/README.md


    ¡Suficiente para una insignia!

    El proyecto DEBE documentar lo que el usuario puede y no puede esperar en términos de seguridad del software producido por el proyecto (sus "requisitos de seguridad"). (URL requerida) [documentation_security]
    Estos son los requisitos de seguridad que el software tiene la intención de cumplir.

    The specification/receipt reference documents untrusted literal and array inputs, no pickle/callback execution, resource and output constraints, unsigned receipt integrity, and the exact-replay compatibility boundary. SECURITY and the assurance case distinguish these guarantees from authenticity, scientific suitability, and external compromise. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Specifications-and-Receipts.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Security-Assurance-Case.md


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar una guía de "inicio rápido" para nuevos usuarios para ayudarles a hacer algo rápidamente con el software. (URL requerida) [documentation_quick_start]
    La idea es mostrar a los usuarios cómo comenzar y hacer que el software haga algo. Esto es de importancia crítica para que los posibles usuarios puedan comenzar.

    The README provides source installation, a bounded normal draw, observable array shape, and a complete save/verify/replay workflow. It explicitly distinguishes the repository 2.0 API from historical 0.1 PyPI releases. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md


    ¡Suficiente para una insignia!

    El proyecto DEBE hacer un esfuerzo para mantener la documentación consistente con la versión actual de los resultados del proyecto (incluido el software producido por el proyecto). Cualquier defecto de documentación conocido que lo haga inconsistente DEBE ser corregido. Si la documentación es generalmente actual, pero incluye erróneamente alguna información antigua que ya no es verdadera, simplemente trátelo como un defecto, luego rastree y corrija como de costumbre. [documentation_current]
    La documentación PUEDE incluir información sobre diferencias o cambios entre versiones del software y/o enlaces a versiones anteriores de la documentación. La intención de este criterio es que se haga un esfuerzo por mantener la documentación consistente, no que la documentación deba ser perfecta.

    Canonical prose is maintained against the current API and version; generated installed mirrors and catalogs are checked for drift. Built-wheel documentation examples, portable links/fragments, version metadata, site build, and browser checks run in CI. This is evidence of an ongoing consistency effort, not a claim that documentation can contain no future defect. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Documentation-System.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/tests/package/test_documentation.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/scripts/build_catalog.py https://github.com/autonomio/chances/actions/runs/36921324501


    ¡Suficiente para una insignia!

    La página frontal del repositorio del proyecto y/o el sitio web DEBEN identificar e hipervincular cualquier logro, incluida esta insignia de mejores prácticas, dentro de las 48 horas del reconocimiento público de que el logro ha sido alcanzado. (URL requerida) [documentation_achievements]
    Un logro es cualquier conjunto de criterios externos que el proyecto ha trabajado específicamente para cumplir, incluidas algunas insignias. Esta información no necesita estar en la página frontal del sitio web del proyecto. Un proyecto que utiliza GitHub puede colocar los logros en la página frontal del repositorio agregándolos al archivo README.

    The repository README hyperlinks the earned Best Practices entry and live Scorecard evidence. The Passing achievement was added in PR 36 on the same day it was earned, within 48 hours; no Silver award is advertised. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md https://github.com/autonomio/chances/pull/36 https://www.bestpractices.dev/en/projects/15137


  • Accesibilidad e internacionalización


    ¡Suficiente para una insignia!

    El proyecto (tanto los sitios del proyecto como los resultados del proyecto) DEBERÍA seguir las mejores prácticas de accesibilidad para que las personas con discapacidades puedan participar en el proyecto y utilizar los resultados del proyecto cuando sea razonable hacerlo. [accessibility_best_practices]
    Para aplicaciones web, consulte las Pautas de Accesibilidad para el Contenido Web (WCAG 2.0) y su documento de apoyo Understanding WCAG 2.0; vea también información de accesibilidad de W3C. Para aplicaciones GUI, considere usar las pautas de accesibilidad específicas del entorno (como Gnome, KDE, XFCE, Android, iOS, Mac, y Windows). Algunas aplicaciones TUI (por ejemplo, programas `ncurses`) pueden hacer ciertas cosas para hacerse más accesibles (como la configuración `force-arrow-cursor` de `alpine`). La mayoría de las aplicaciones de línea de comandos son bastante accesibles tal como están. Este criterio es a menudo N/A, por ejemplo, para bibliotecas de programas. Aquí hay algunos ejemplos de acciones a tomar o problemas a considerar:
    • Proporcione alternativas de texto para cualquier contenido que no sea texto para que pueda transformarse en otras formas que las personas necesiten, como letra grande, braille, voz, símbolos o lenguaje más simple (pauta 1.1 de WCAG 2.0)
    • El color no se utiliza como el único medio visual de transmitir información, indicar una acción, solicitar una respuesta o distinguir un elemento visual. (pauta 1.4.1 de WCAG 2.0)
    • La presentación visual de texto e imágenes de texto tiene una relación de contraste de al menos 4.5:1, excepto para texto grande, texto incidental y logotipos (pauta 1.4.3 de WCAG 2.0)
    • Haga que toda la funcionalidad esté disponible desde un teclado (pauta 2.1 de WCAG)
    • Un proyecto basado en GUI o web DEBERÍA probar con al menos un lector de pantalla en las plataformas de destino (por ejemplo, NVDA, Jaws o WindowEyes en Windows; VoiceOver en Mac e iOS; Orca en Linux/BSD; TalkBack en Android). Los programas TUI PUEDEN trabajar para reducir el sobredibujo para evitar la lectura redundante por parte de los lectores de pantalla.

    The library and JSON CLI expose text-based interfaces. Documentation checks exercise keyboard navigation, skip links, light/dark themes, desktop/mobile layouts, and Axe WCAG 2 A/AA checks across representative page roles; images have text alternatives. The recorded CI passed these checks. Automated accessibility checks are not claimed to establish universal accessibility or a completed human screen-reader audit. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs-site/tests/docs.spec.js https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md https://github.com/autonomio/chances/actions/runs/36921324501


    Apenas suficiente para una insignia.

    El software producido por el proyecto DEBERÍA estar internacionalizado para permitir una fácil localización para la cultura, región o idioma de la audiencia objetivo. Si la internacionalización (i18n) no aplica (por ejemplo, el software no genera texto destinado a usuarios finales y no ordena texto legible por humanos), seleccione "no aplicable" (N/A). [internationalization]
    La localización "se refiere a la adaptación de un producto, aplicación o contenido de documento para satisfacer los requisitos de idioma, cultura y otros de un mercado objetivo específico (una configuración regional)". La internacionalización es el "diseño y desarrollo de un producto, aplicación o contenido de documento que permite una fácil localización para audiencias objetivo que varían en cultura, región o idioma". (Vea "Localization vs. Internationalization" de W3C.) El software cumple con este criterio simplemente estando internacionalizado. No se requiere localización para otro idioma específico, ya que una vez que el software ha sido internacionalizado, es posible que otros trabajen en la localización.

    Human-facing error messages and maintained prose are English; the package has no message-localization framework. This SHOULD criterion has been considered: scientific protocol identifiers, structured error codes, and receipt formats currently prioritize one stable interchange contract, and maintenance remains focused on the documented English audience. Human-facing strings could be localized separately in future without changing those identifiers. Because the CLI does generate user-facing messages, N/A is not claimed. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_errors.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Command-Line.md


  • Otro


    ¡Suficiente para una insignia!

    Si los sitios del proyecto (sitio web, repositorio y URLs de descarga) almacenan contraseñas para la autenticación de usuarios externos, las contraseñas DEBEN almacenarse como hashes iterados con un salt por usuario mediante el uso de un algoritmo de estiramiento de claves (iterado) (por ejemplo, Argon2id, Bcrypt, Scrypt o PBKDF2). Si los sitios del proyecto no almacenan contraseñas para este propósito, seleccione "no aplicable" (N/A). [sites_password_security]
    Tenga en cuenta que el uso de GitHub cumple con este criterio. Este criterio solo se aplica a las contraseñas utilizadas para la autenticación de usuarios externos en los sitios del proyecto (también conocida como autenticación entrante). Si los sitios del proyecto deben iniciar sesión en otros sitios (también conocida como autenticación saliente), es posible que necesiten almacenar tokens de autorización para ese propósito de manera diferente (ya que almacenar un hash sería inútil). Esto aplica el criterio crypto_password_storage a los sitios del proyecto, similar a sites_https.

    The repository and project communication use GitHub, which the official Silver criterion details explicitly accept. Chances operates no custom user-password database or authentication website; the documentation output is static. Package distribution uses PyPI rather than a project-operated login system. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs-site/product-docs.json https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances https://pypi.org/project/chances/ https://www.bestpractices.dev/en/criteria/1?details=true


 Control de cambios 1/1 ●

 Informes 2/3 ●

  • Proceso de reporte de errores


    ¡Suficiente para una insignia!

    El proyecto DEBE usar un sistema de seguimiento de incidencias para rastrear problemas individuales. [report_tracker]

    Users submit defects through the public GitHub issue tracker; the README requests a minimal protocol, package versions, and structured error. Public issue templates support bug and enhancement reports. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md https://github.com/autonomio/chances/issues/new/choose


  • Proceso de informe de vulnerabilidad


    Información requerida desconocida, no es suficiente para una insignia.

    El proyecto DEBE dar crédito al o a los reportadores de todos los informes de vulnerabilidades resueltos en los últimos 12 meses, excepto a los reportadores que soliciten anonimato. Si no ha habido vulnerabilidades resueltas en los últimos 12 meses, seleccione "no aplicable" (N/A). (URL requerida) [vulnerability_report_credit]

    Unresolved maintainer fact: between 2025-10-02 and 2026-10-02, were any vulnerability reports resolved, including private reports? If none, N/A is justified; otherwise provide the public fix/release/advisory URLs crediting each reporter who did not request anonymity. SECURITY promises credit, but a future policy and an empty public advisory list do not establish the handling of private historical reports. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances/security/advisories


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un proceso documentado para responder a los informes de vulnerabilidades. (URL requerida) [vulnerability_response_process]
    Esto está fuertemente relacionado con vulnerability_report_process, que requiere que haya una forma documentada de reportar vulnerabilidades. También está relacionado con vulnerability_report_response, que requiere respuesta a los informes de vulnerabilidades dentro de un cierto marco de tiempo.

    SECURITY documents private reporting, acknowledgement target, reproduction, impact/version triage, reporter coordination, prioritized critical fixes, disclosure, public fix notes, and reporter credit. These documented response steps are separate from historical response-time attestations. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md


 Calidad 17/19 ●

 Seguridad 12/13 ●

 Análisis 2/2 ●

  • Análisis estático de código


    ¡Suficiente para una insignia!

    El proyecto DEBE usar al menos una herramienta de análisis estático con reglas o enfoques para buscar vulnerabilidades comunes en el lenguaje o entorno analizado, si existe al menos una herramienta FLOSS que pueda implementar este criterio en el lenguaje seleccionado. [static_analysis_common_vulnerabilities]
    Las herramientas de análisis estático que están diseñadas específicamente para buscar vulnerabilidades comunes tienen más probabilidades de encontrarlas. Dicho esto, usar cualquier herramienta estática típicamente ayudará a encontrar algunos problemas, por lo que estamos sugiriendo pero no requiriendo esto para el nivel de insignia 'passing'.

    CodeQL Python analysis runs on master pushes, pull requests, and a weekly schedule. The proposed Chances 2.0 major release has passed this analysis before publication; the PR required the CodeQL status. Public ruleset and typing analysis provide additional static checks. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/.github/workflows/pr_checks_codeql.yml https://github.com/autonomio/chances/actions/runs/36887139299


  • Análisis dinámico de código


    ¡Suficiente para una insignia!

    Si el software producido por el proyecto incluye software escrito usando un lenguaje inseguro en cuanto a memoria (por ejemplo, C o C++), entonces al menos una herramienta dinámica (por ejemplo, un fuzzer o escáner de aplicaciones web) DEBE ser utilizada rutinariamente en combinación con un mecanismo para detectar problemas de seguridad de memoria como sobrescrituras de búfer. Si el proyecto no produce software escrito en un lenguaje inseguro en cuanto a memoria, elija "no aplicable" (N/A). [dynamic_analysis_unsafe]
    Ejemplos de mecanismos para detectar problemas de seguridad de memoria incluyen Address Sanitizer (ASAN) (disponible en GCC y LLVM), Memory Sanitizer, y valgrind. Otras herramientas potencialmente utilizadas incluyen thread sanitizer y undefined behavior sanitizer. También funcionarían aserciones generalizadas.

    The project-authored product code is Python, with JavaScript used by documentation tooling; the project does not produce C or C++ source. NumPy/SciPy and platform native publication APIs are external dependencies, not project-authored memory-unsafe-language source. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/pyproject.toml https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/chances/_publication.py



Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/15137/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 Mikko Kotila y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Mikko Kotila.
Entrada creada el 2026-10-01 15:58:41 UTC, última actualización el 2026-10-03 08:29:52 UTC. Última obtención de la insignia de nivel básico el 2026-10-01 16:42:28 UTC.