Astetik

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


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

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

        

 Fundamentos 13/13 ●

 Control de cambios 9/9 ●

  • Repositorio público para el control de versiones de código fuente


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un repositorio público para el control de versiones de código fuente que sea legible públicamente y tenga URL. [repo_public]
    La URL PUEDE ser la misma que la URL del proyecto. El proyecto PUEDE utilizar ramas privadas (no públicas) en casos específicos, mientras que el cambio no se divulga públicamente (por ejemplo, para corregir una vulnerabilidad antes de que se revele al público).

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    ¡Suficiente para una insignia!

    El repositorio fuente del proyecto DEBE rastrear qué cambios se realizaron, quién realizó los cambios y cuándo se realizaron los cambios. [repo_track]

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    ¡Suficiente para una insignia!

    Para permitir la revisión colaborativa, el repositorio de código fuente del proyecto DEBE incluir versiones provisionales para revisión entre lanzamientos; NO DEBE incluir solo versiones finales. [repo_interim]
    Los proyectos PUEDEN optar por omitir versiones provisionales específicas de sus repositorios de código fuente públicos (por ejemplo, las que corrigen vulnerabilidades de seguridad específicas no públicas, pueden nunca ser lanzadas públicamente o incluyen material que no puede ser publicado legalmente y no están en el lanzamiento final).

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    ¡Suficiente para una insignia!

    Se SUGIERE que se use software de control de versiones distribuido común (por ejemplo, git) para el repositorio de código fuente del proyecto. [repo_distributed]
    Git no se requiere específicamente y los proyectos pueden usar un software de control de versiones centralizado (como subversion) con justificación.

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


  • Numeración única de versión


    ¡Suficiente para una insignia!

    Los resultados del proyecto DEBEN tener un identificador de versión único para cada lanzamiento destinado a ser usado por los usuarios. [version_unique]
    Esto PUEDE cumplirse de diversas maneras, incluyendo IDs de commit (como el ID de commit de git o el ID de changeset de mercurial) o un número de versión (incluyendo números de versión que usan versionado semántico o esquemas basados en fechas como AAAAMMDD).

    Released results have unique tag/version identities and source commit IDs. Latest published historical release is v1.16; current protected source version 2.0.0 is explicitly unpublished. Evidence: https://github.com/autonomio/astetik/releases/tag/v1.16 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/pyproject.toml https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    ¡Suficiente para una insignia!

    Se SUGIERE que se use el formato de numeración de versiones Semantic Versioning (SemVer) o Calendar Versioning (CalVer) para los lanzamientos. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro. [version_semver]
    Los proyectos generalmente deberían preferir el formato que esperan sus usuarios, por ejemplo, porque es el formato normal usado por su ecosistema. Muchos ecosistemas prefieren SemVer, y SemVer es generalmente preferido para interfaces de programación de aplicaciones (APIs) y kits de desarrollo de software (SDKs). CalVer tiende a ser usado por proyectos que son grandes, tienen un número inusualmente grande de dependencias desarrolladas independientemente, tienen un alcance en constante cambio o son sensibles al tiempo. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro, porque incluir un nivel micro soporta ramas mantenidas simultáneamente cuando eso se vuelva necesario. Otros formatos de numeración de versiones pueden usarse como números de versión, incluyendo IDs de commit de git o IDs de changeset de mercurial, siempre que identifiquen versiones de manera única. Sin embargo, algunas alternativas (como los IDs de commit de git) pueden causar problemas como identificadores de lanzamiento, porque los usuarios pueden no ser capaces de determinar fácilmente si están actualizados. El formato de ID de versión puede no ser importante para identificar lanzamientos de software si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua).

    The currently maintained source follows three-component SemVer with a mandatory per-PR bump gate. Historical PyPI versions such as 1.16 followed Python version syntax and were not strict three-component SemVer. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Semantic-Versioning.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/governance/version_gate.py


    ¡Suficiente para una insignia!

    Se SUGIERE que los proyectos identifiquen cada lanzamiento dentro de su sistema de control de versiones. Por ejemplo, se SUGIERE que quienes usen git identifiquen cada lanzamiento usando etiquetas de git. [version_tags]

    Released historical versions have Git tags, and the configured release process derives a unique v<project.version> tag for future explicitly authorized releases. Evidence: https://github.com/autonomio/astetik/tags https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Making-Release.md


  • Notas de lanzamiento


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar, en cada lanzamiento, notas de lanzamiento que sean un resumen legible por humanos de los cambios principales en ese lanzamiento para ayudar a los usuarios a determinar si deben actualizar y cuál será el impacto de la actualización. Las notas de lanzamiento NO DEBEN ser la salida bruta de un registro de control de versiones (por ejemplo, los resultados del comando "git log" no son notas de lanzamiento). Los proyectos cuyos resultados no están destinados para su reutilización en múltiples ubicaciones (como el software para un solo sitio web o servicio) Y emplean entrega continua PUEDEN seleccionar "N/A". (URL requerida) [release_notes]
    Las notas de lanzamiento PUEDEN implementarse de diversas maneras. Muchos proyectos las proporcionan en un archivo llamado "NEWS", "CHANGELOG" o "ChangeLog", opcionalmente con extensiones como ".txt", ".md" o ".html". Históricamente el término "change log" significaba un registro de cada cambio, pero para cumplir con estos criterios lo que se necesita es un resumen legible por humanos. Las notas de lanzamiento PUEDEN proporcionarse mediante mecanismos del sistema de control de versiones como el flujo de trabajo GitHub Releases.

    Latest distributed release v1.16 has human-readable notes identifying Hatch migration and minor fixes. Current 2.0 source has a reviewed human-readable changelog; future notes are generated from that reviewed section rather than raw git logs. Evidence: https://github.com/autonomio/astetik/releases/tag/v1.16 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/CHANGELOG.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    ¡Suficiente para una insignia!

    Las notas de lanzamiento DEBEN identificar cada vulnerabilidad de tiempo de ejecución conocida públicamente que se corrigió en este lanzamiento y que ya tenía una asignación de CVE o similar cuando se creó el lanzamiento. Este criterio puede marcarse como no aplicable (N/A) si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica (por ejemplo, como suele ser cierto para las actualizaciones del kernel). Este criterio se aplica solo a los resultados del proyecto, no a sus dependencias. Si no hay notas de lanzamiento o no ha habido vulnerabilidades conocidas públicamente, elija N/A. [release_notes_vulns]
    Este criterio ayuda a los usuarios a determinar si una actualización dada corregirá una vulnerabilidad que es conocida públicamente, para ayudar a los usuarios a tomar una decisión informada sobre la actualización. Si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica en sus computadoras, pero en su lugar deben depender de uno o más intermediarios para realizar la actualización (como suele ser el caso de un kernel y software de bajo nivel que está entrelazado con un kernel), el proyecto puede elegir "no aplicable" (N/A) en su lugar, ya que esta información adicional no será útil para esos usuarios. De manera similar, un proyecto puede elegir N/A si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua). Este criterio solo se aplica a los resultados del proyecto, no a sus dependencias. Enumerar las vulnerabilidades de todas las dependencias transitivas de un proyecto se vuelve difícil de manejar a medida que aumentan y varían las dependencias, y es innecesario ya que las herramientas que examinan y rastrean dependencias pueden hacer esto de una manera más escalable.

    No publicly known Astetik runtime vulnerability with a CVE or comparable advisory was found in GitHub advisories or the OSV PyPI package query. The criterion concerns project vulnerabilities, not transitive dependencies. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query


 Informes 8/8 ●

  • Proceso de reporte de errores


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar un proceso para que los usuarios envíen informes de errores (por ejemplo, usando un rastreador de issues o una lista de correo). (URL requerida) [report_process]

    SUPPORT and issue templates describe how to submit a versioned reproducible report using the public GitHub issue tracker. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/SUPPORT.md https://github.com/autonomio/astetik/issues


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA usar un rastreador de issues para rastrear problemas individuales. [report_tracker]

    Live GitHub repository metadata has has_issues=true; issues are the documented bug and contribution tracker. Evidence: https://api.github.com/repos/autonomio/astetik https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SUPPORT.md


    ¡Suficiente para una insignia!

    El proyecto DEBE reconocer la mayoría de los informes de errores enviados en los últimos 2-12 meses (inclusive); la respuesta no necesita incluir una solución. [report_responses]

    Complete GitHub issue inventory has no human bug reports or enhancement requests submitted between 2025-10-02 and 2026-08-02, the 2–12 month evaluation window. This does not claim old unanswered historical issues were acknowledged. Evidence: https://github.com/autonomio/astetik/issues?q=is%3Aissue+created%3A2025-10-02..2026-08-02


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA responder a la mayoría (>50%) de las solicitudes de mejora en los últimos 2-12 meses (inclusive). [enhancement_responses]
    La respuesta PUEDE ser 'no' o una discusión sobre sus méritos. El objetivo es simplemente que haya alguna respuesta a algunas solicitudes, lo que indica que el proyecto todavía está activo. Para los propósitos de este criterio, los proyectos no necesitan contar solicitudes falsas (por ejemplo, de spammers o sistemas automatizados). Si un proyecto ya no está realizando mejoras, por favor seleccione "no cumplido" e incluya la URL que aclare esta situación a los usuarios. Si un proyecto tiende a estar abrumado por el número de solicitudes de mejora, por favor seleccione "no cumplido" y explique.

    Complete GitHub issue inventory has no human bug reports or enhancement requests submitted between 2025-10-02 and 2026-08-02, the 2–12 month evaluation window. This does not claim old unanswered historical issues were acknowledged. Evidence: https://github.com/autonomio/astetik/issues?q=is%3Aissue+created%3A2025-10-02..2026-08-02


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un archivo públicamente disponible para informes y respuestas para búsquedas posteriores. (URL requerida) [report_archive]

    GitHub issue and PR discussions are public, searchable, URL-addressable, and accessible through a browser without installing proprietary client software. Evidence: https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/pulls


  • Proceso de informe de vulnerabilidad


    ¡Suficiente para una insignia!

    El proyecto DEBE publicar el proceso para informar vulnerabilidades en el sitio del proyecto. (URL requerida) [vulnerability_report_process]
    Los proyectos alojados en GitHub DEBERÍAN considerar habilitar el informe privado de una vulnerabilidad de seguridad. Los proyectos en GitLab DEBERÍAN considerar usar su capacidad para informar privadamente una vulnerabilidad. Los proyectos PUEDEN identificar una dirección de correo en https://PROJECTSITE/security, a menudo en la forma security@example.org. Este proceso de informe de vulnerabilidades PUEDE ser el mismo que su proceso de informe de errores. Los informes de vulnerabilidades PUEDEN ser siempre públicos, pero muchos proyectos tienen un mecanismo de informe de vulnerabilidades privado.

    SECURITY documents how to report vulnerabilities privately by arranging a channel through the established author contact, warns against public exploitable details, and defines useful report contents. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/SECURITY.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/MAINTAINERS.md


    ¡Suficiente para una insignia!

    Si se admiten informes de vulnerabilidades privadas, el proyecto DEBE incluir cómo enviar la información de una manera que se mantenga privada. (URL requerida) [vulnerability_report_private]
    Los ejemplos incluyen un informe privado de defectos enviado en la web usando HTTPS (TLS) o un correo electrónico cifrado utilizando OpenPGP. Si los informes de vulnerabilidades son siempre públicos (por lo que nunca hay informes de vulnerabilidades privados), seleccione "no aplicable" (N/A).

    GitHub private vulnerability reporting is enabled for Astetik. Reports are submitted privately over GitHub HTTPS at https://github.com/autonomio/astetik/security/advisories/new . Live repository setting verified 2026-10-02; reporters should not publish exploitable details in public issues. Evidence: https://github.com/autonomio/astetik/security/advisories/new https://github.com/autonomio/astetik/security/policy


    ¡Suficiente para una insignia!

    El tiempo de respuesta inicial del proyecto para cualquier informe de vulnerabilidad recibido en los últimos 6 meses DEBE ser menor o igual a 14 días. [vulnerability_report_response]
    Si no ha habido vulnerabilidades reportadas en los últimos 6 meses, elija "no aplicable" (N/A).

    The primary maintainer confirms no private vulnerability reports were received in the past 12 months as of 2026-10-02. No public Astetik vulnerability report or advisory was found in the last six months. Thus there is no initial-response interval to claim; the official criterion permits N/A when no vulnerabilities were reported in that period. Evidence: https://github.com/autonomio/astetik/security/advisories


 Calidad 13/13 ●

 Seguridad 16/16 ●

  • Conocimiento de desarrollo seguro


    ¡Suficiente para una insignia!

    El proyecto DEBE tener al menos un desarrollador principal que sepa cómo diseñar software seguro. (Ver 'detalles' para los requisitos exactos.) [know_secure_design]
    Esto requiere comprender los siguientes principios de diseño, incluyendo los 8 principios de Saltzer y Schroeder:
    • economía de mecanismo (mantener el diseño lo más simple y pequeño posible, por ejemplo, adoptando simplificaciones radicales)
    • valores predeterminados seguros ante fallas (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto)
    • mediación completa (cada acceso que pueda ser limitado debe ser verificado por autoridad y ser no evitable)
    • diseño abierto (los mecanismos de seguridad no deben depender de la ignorancia del atacante de su diseño, sino de información más fácilmente protegida y modificable como claves y contraseñas)
    • separación de privilegios (idealmente, el acceso a objetos importantes debe depender de más de una condición, de modo que vencer un sistema de protección no permita el acceso completo. Por ejemplo, la autenticación multifactor, como requerir tanto una contraseña como un token de hardware, es más fuerte que la autenticación de un solo factor)
    • mínimo privilegio (los procesos deben operar con el mínimo privilegio necesario)
    • mecanismo menos común (el diseño debe minimizar los mecanismos comunes a más de un usuario y de los que dependen todos los usuarios, por ejemplo, directorios para archivos temporales)
    • aceptabilidad psicológica (la interfaz humana debe estar diseñada para facilitar su uso - diseñar para "menos sorpresa" puede ayudar)
    • superficie de ataque limitada (la superficie de ataque - el conjunto de los diferentes puntos donde un atacante puede intentar entrar o extraer datos - debe ser limitada)
    • validación de entradas con listas de permitidos (las entradas típicamente deben verificarse para determinar si son válidas antes de aceptarse; esta validación debe usar listas de permitidos (que solo aceptan valores conocidos como buenos), no listas de denegados (que intentan listar valores conocidos como malos)).
    Un "desarrollador principal" en un proyecto es cualquier persona que esté familiarizada con la base de código del proyecto, se sienta cómoda haciendo cambios en él y sea reconocida como tal por la mayoría de los demás participantes en el proyecto. Un desarrollador principal típicamente haría una serie de contribuciones durante el año pasado (a través de código, documentación o respondiendo preguntas). Los desarrolladores típicamente serían considerados desarrolladores principales si iniciaron el proyecto (y no han dejado el proyecto hace más de tres años), tienen la opción de recibir información sobre un canal privado de reporte de vulnerabilidades (si existe uno), pueden aceptar commits en nombre del proyecto, o realizar versiones finales del software del proyecto. Si solo hay un desarrollador, ese individuo es el desarrollador principal. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir el diseño. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

    Mikko Kotila, Astetik primary maintainer/developer, explicitly confirms understanding all specified secure-design principles: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability, limited attack surface, and allowlist input validation. Confirmation given 2026-10-02; implementation controls are documented in the assurance case. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/MAINTAINERS.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    ¡Suficiente para una insignia!

    Al menos uno de los desarrolladores principales del proyecto DEBE conocer tipos comunes de errores que conducen a vulnerabilidades en este tipo de software, así como al menos un método para contrarrestar o mitigar cada uno de ellos. [know_common_errors]
    Los ejemplos (dependiendo del tipo de software) incluyen inyección SQL, inyección de SO, desbordamiento de búfer clásico, cross-site scripting, falta de autenticación y falta de autorización. Ver el CWE/SANS top 25 o OWASP Top 10 para listas comúnmente usadas. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir errores de implementación comunes que conducen a vulnerabilidades. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

    Mikko Kotila, Astetik primary maintainer/developer, explicitly confirms knowing common vulnerability classes relevant to this library and at least one mitigation for each, including injection, unsafe deserialization, path traversal, missing authorization, secret leakage, and vulnerable dependencies. Confirmation given 2026-10-02; the assurance case records the project trust boundaries and relevant controls. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


  • Use buenas prácticas criptográficas

    Tenga en cuenta que algunos programas de software no necesitan usar mecanismos criptográficos. Si su proyecto produce software que (1) incluye, activa o habilita funcionalidad de cifrado, y (2) podría ser liberado desde los Estados Unidos (EE.UU.) hacia fuera de los EE.UU. o a una persona que no sea ciudadana de los EE.UU., es posible que esté legalmente obligado a tomar algunos pasos adicionales. Típicamente esto solo implica enviar un correo electrónico. Para más información, consulte la sección de cifrado de Understanding Open Source Technology & US Export Controls.

    ¡Suficiente para una insignia!

    El software producido por el proyecto DEBE usar, por defecto, solo protocolos y algoritmos criptográficos que estén públicamente publicados y revisados por expertos (si se usan protocolos y algoritmos criptográficos). [crypto_published]
    Estos criterios criptográficos no siempre aplican porque algunos programas de software no necesitan usar capacidades criptográficas directamente.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    ¡Suficiente para una insignia!

    Si el software producido por el proyecto es una aplicación o una librería, y su propósito principal no es implementar criptografía, entonces DEBE SOLAMENTE invocar un software específicamente diseñado para implementar funciones criptográficas; NO DEBERÍA volver a implementar el suyo. [crypto_call]

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    ¡Suficiente para una insignia!

    Toda funcionalidad en el software producido por el proyecto que dependa de criptografía DEBE ser implementable usando FLOSS. [crypto_floss]
    Ver el Open Standards Requirement for Software by the Open Source Initiative.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN usar longitudes de clave predeterminadas que al menos cumplan con los requisitos mínimos de NIST hasta el año 2030 (como se declaró en 2012). DEBE ser posible configurar el software de modo que las longitudes de clave más pequeñas estén completamente deshabilitadas. [crypto_keylength]
    Estas longitudes mínimas de bits son: clave simétrica 112, módulo de factorización 2048, clave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 y hash 224 (el hash de contraseñas no está cubierto por esta longitud de bits, se puede encontrar más información sobre el hash de contraseñas en el criterio crypto_password_storage). Ver https://www.keylength.com para una comparación de recomendaciones de longitud de clave de varias organizaciones. El software PUEDE permitir longitudes de clave más pequeñas en algunas configuraciones (idealmente no lo haría, ya que esto permite ataques de degradación, pero las longitudes de clave más cortas a veces son necesarias para la interoperabilidad).

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBEN depender de algoritmos criptográficos rotos (por ejemplo, MD4, MD5, DES simple, RC4, Dual_EC_DRBG), o usar modos de cifrado que son inapropiados para el contexto, a menos que sean necesarios para implementar un protocolo interoperable (donde el protocolo implementado es la versión más reciente de ese estándar ampliamente soportada por el ecosistema de red, ese ecosistema requiere el uso de tal algoritmo o modo, y ese ecosistema no ofrece ninguna alternativa más segura). La documentación DEBE describir cualquier riesgo de seguridad relevante y cualquier mitigación conocida si estos algoritmos o modos rotos son necesarios para un protocolo interoperable. [crypto_working]
    El modo ECB casi nunca es apropiado porque revela bloques idénticos dentro del texto cifrado como lo demuestra el ECB penguin, y el modo CTR a menudo es inapropiado porque no realiza autenticación y causa duplicados si el estado de entrada se repite. En muchos casos es mejor elegir un modo de algoritmo de cifrado de bloque diseñado para combinar secreto y autenticación, por ejemplo, Galois/Counter Mode (GCM) y EAX. Los proyectos PUEDEN permitir a los usuarios habilitar mecanismos rotos (por ejemplo, durante la configuración) cuando sea necesario para la compatibilidad, pero entonces los usuarios saben que lo están haciendo.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBERÍAN depender de algoritmos o modos criptográficos con debilidades serias conocidas (por ejemplo, el algoritmo hash criptográfico SHA-1 o el modo CBC en SSH). [crypto_weaknesses]
    Las preocupaciones sobre el modo CBC en SSH se discuten en CERT: SSH CBC vulnerability.

    Project integrity digests use hashlib.sha256. No MD5/SHA1 security mechanism or home-grown cipher was found in runtime. Repository delivery uses platform HTTPS/signing primitives. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_json.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_source_file.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_result.py


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad dentro del software producido por el proyecto DEBERÍAN implementar confidencialidad directa perfecta para protocolos de acuerdo de claves de modo que una clave de sesión derivada de un conjunto de claves a largo plazo no pueda ser comprometida si una de las claves a largo plazo es comprometida en el futuro. [crypto_pfs]

    The installed local scientific library does not implement a network key-agreement protocol or session encryption. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Overview/Boundary.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    ¡Suficiente para una insignia!

    Si el software producido por el proyecto causa el almacenamiento de 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). Ver también OWASP Password Storage Cheat Sheet. [crypto_password_storage]
    Este criterio se aplica solo cuando el software está forzando la autenticación de usuarios usando contraseñas para usuarios externos (también conocida como autenticación entrante), como aplicaciones web del lado del servidor. No se aplica en casos donde el software almacena contraseñas para autenticarse en otros sistemas (también conocida como autenticación saliente, por ejemplo, el software implementa un cliente para algún otro sistema), ya que al menos partes de ese software deben tener acceso a menudo a la contraseña sin hash.

    The installed local scientific library does not authenticate external users or store authentication passwords. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN generar todas las claves criptográficas y nonces utilizando un generador de números aleatorios criptográficamente seguro, y NO DEBEN hacerlo usando generadores que son criptográficamente inseguros. [crypto_random]
    Un generador de números aleatorios criptográficamente seguro puede ser un generador de números aleatorios de hardware, o puede ser un generador de números pseudo-aleatorios criptográficamente seguro (CSPRNG) que usa un algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow o Fortuna. Ejemplos de llamadas a generadores de números aleatorios seguros incluyen java.security.SecureRandom de Java y window.crypto.getRandomValues de JavaScript. Ejemplos de llamadas a generadores de números aleatorios inseguros incluyen java.util.Random de Java y Math.random de JavaScript.

    Astetik does not generate cryptographic keys or nonces. Scientific determinism/content identities are SHA-256 hashes, not randomly generated secrets. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


  • Entrega garantizada contra ataques de hombre en el medio (MITM)


    ¡Suficiente para una insignia!

    El proyecto DEBE usar un mecanismo de entrega que contrarreste los ataques MITM. Usar https o ssh+scp es aceptable. [delivery_mitm]
    Un mecanismo aún más fuerte es publicar el software con paquetes firmados digitalmente, ya que eso mitiga los ataques en el sistema de distribución, pero esto solo funciona si los usuarios pueden estar seguros de que las claves públicas para las firmas son correctas y si los usuarios realmente verificarán la firma.

    The public repository and source downloads use HTTPS, as do PyPI package downloads. The project does not instruct users to accept unsigned hashes obtained over HTTP. Evidence: https://github.com/autonomio/astetik https://pypi.org/project/astetik/ https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    ¡Suficiente para una insignia!

    Un hash criptográfico (por ejemplo, un sha1sum) NO DEBE recuperarse a través de http y usarse sin verificar una firma criptográfica. [delivery_unsigned]
    Estos "hash" se pueden modificar en tránsito.

    The public repository and source downloads use HTTPS, as do PyPI package downloads. The project does not instruct users to accept unsigned hashes obtained over HTTP. Evidence: https://github.com/autonomio/astetik https://pypi.org/project/astetik/ https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


  • Vulnerabilidades públicamente conocidas corregidas


    ¡Suficiente para una insignia!

    NO DEBE haber vulnerabilidades sin parchar de severidad media o superior que hayan sido conocidas públicamente durante más de 60 días. [vulnerabilities_fixed_60_days]
    La vulnerabilidad debe ser parcheada y publicada por el proyecto mismo (los parches pueden desarrollarse en otro lugar). Una vulnerabilidad se convierte en conocida públicamente (para este propósito) una vez que tiene un CVE con información publicada públicamente sin muro de pago (reportada, por ejemplo, en la National Vulnerability Database) o cuando el proyecto ha sido informado y la información ha sido publicada al público (posiblemente por el proyecto). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Nota: esto significa que los usuarios podrían quedar vulnerables a todos los atacantes en todo el mundo durante hasta 60 días. Este criterio es a menudo mucho más fácil de cumplir que lo que Google recomienda en Rebooting responsible disclosure, porque Google recomienda que el período de 60 días comience cuando se notifica al proyecto incluso si el informe no es público. También tenga en cuenta que este criterio de insignia, como otros criterios, se aplica al proyecto individual. Algunos proyectos son parte de organizaciones paraguas más grandes o proyectos más grandes, posiblemente en múltiples capas, y muchos proyectos alimentan sus resultados a otras organizaciones y proyectos como parte de una cadena de suministro potencialmente compleja. Un proyecto individual a menudo no puede controlar el resto, pero un proyecto individual puede trabajar para publicar un parche de vulnerabilidad de manera oportuna. Por lo tanto, nos enfocamos únicamente en el tiempo de respuesta del proyecto individual. Una vez que un parche está disponible del proyecto individual, otros pueden determinar cómo lidiar con el parche (por ejemplo, pueden actualizar a la versión más nueva o pueden aplicar solo el parche como una solución seleccionada).

    No publicly known medium-or-higher Astetik runtime vulnerability was found in GitHub advisories or the OSV package database. Live Scorecard configuration findings are separately tracked and do not establish exploitable project vulnerabilities older than 60 days. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query https://github.com/autonomio/astetik/security/code-scanning


    ¡Suficiente para una insignia!

    Los proyectos DEBERÍAN corregir todas las vulnerabilidades críticas rápidamente después de que se reporten. [vulnerabilities_critical_fixed]

    No confirmed critical Astetik vulnerability is currently known from the public advisory/OSV audit, and the primary maintainer confirms no private vulnerability reports in the past 12 months. There is no outstanding confirmed critical vulnerability or historical fix interval to misrepresent. Critical reports are prioritized for immediate triage and prompt remediation; this answer does not invent a past response-time result. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query


  • Otros problemas de seguridad


    ¡Suficiente para una insignia!

    Los repositorios públicos NO DEBEN filtrar una credencial privada válida (por ejemplo, una contraseña funcional o una clave privada) que esté destinada a limitar el acceso público. [no_leaked_credentials]
    Un proyecto PUEDE filtrar credenciales de "muestra" para pruebas y bases de datos sin importancia, siempre que no estén destinadas a limitar el acceso público.

    GitHub secret-scanning alert 1 is resolved as false_positive after independent analysis: the detected bytes span adjacent WB_A3 country-code and WOE_ID geographic-ID fields in countries.dbf record 184 (North Korea), matching public Natural Earth v4.0.0 attributes. The matched value is geographical metadata, not a credential. No valid private credential is identified in the public repository audit. Evidence: https://github.com/autonomio/astetik/security/secret-scanning/1 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/extras/countries.dbf https://raw.githubusercontent.com/nvkelso/natural-earth-vector/v4.0.0/50m_cultural/ne_50m_admin_0_countries.dbf


 Análisis 8/8 ●


Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/15154/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-02 06:55:56 UTC, última actualización el 2026-10-02 09:51:47 UTC. Última obtención de la insignia de nivel básico el 2026-10-02 09:07:57 UTC.