Talos

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

 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]

    Public GitHub tracker exists.

    https://github.com/autonomio/talos/issues


  • Proceso de informe de vulnerabilidad


    ¡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]

    The maintainer confirms compliance with crediting reporters of vulnerability reports resolved during the preceding12months, except those requesting anonymity. No report count, individual report, private narrative or response timestamp is invented. If a separately confirmed zero-resolution denominator is supplied, the official N/A option can instead be used.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md
    https://www.bestpractices.dev/en/criteria/1?details=true#vulnerability_report_credit


    No es 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.

    Reporting routes and reporter-credit policy exist, but a complete documented acknowledgement, triage, remediation, coordinated disclosure and closure process is absent from the merged source. Root prepares that process on the next branch; historic compliance remains a separate fact.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md


 Calidad 12/19 ●

 Seguridad 4/13 ●

  • Conocimiento de desarrollo seguro


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

    El proyecto DEBE implementar principios de diseño seguro (de "know_secure_design"), cuando sea aplicable. Si el proyecto no está produciendo software, seleccione "no aplicable" (N/A). [implement_secure_design]
    Por ejemplo, los resultados del proyecto deberían tener valores predeterminados seguros (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto). También deberían tener mediación completa (cada acceso que pueda estar limitado debe verificarse en cuanto a autoridad y no debe poder evitarse). Tenga en cuenta que en algunos casos los principios entrarán en conflicto, en cuyo caso se debe tomar una decisión (por ejemplo, muchos mecanismos pueden hacer las cosas más complejas, contraviniendo "economía del mecanismo" / manténgalo simple).

  • 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!

    Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBEN depender de algoritmos criptográficos o modos con debilidades graves conocidas (por ejemplo, el algoritmo de 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.

    SHA-256 artifact/source checks; no SHA1/MD5 security mechanism identified in Talos runtime.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/experiment/provenance.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/backends/adapters.py


    Apenas suficiente para una insignia.

    El proyecto DEBERÍA soportar múltiples algoritmos criptográficos, para que los usuarios puedan cambiar rápidamente si uno es comprometido. Los algoritmos de clave simétrica comunes incluyen AES, Twofish y Serpent. Las alternativas de algoritmos criptográficos hash comunes incluyen SHA-2 (incluyendo SHA-224, SHA-256, SHA-384 y SHA-512) y SHA-3. [crypto_algorithm_agility]

    Manifest identifiers intentionally schema-coupled to SHA256; no selectable hash agility. Delegated SSH/TLS algorithms negotiate externally. SHOULD may be unmet with provenance-schema migration explanation; do not change manifest identity merely for badge.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/experiment/serialization.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/store.py


    No es suficiente para una insignia.

    El proyecto DEBE soportar el almacenamiento de credenciales de autenticación (como contraseñas y tokens dinámicos) y claves criptográficas privadas en archivos que están separados de otra información (como archivos de configuración, bases de datos y registros), y permitir a los usuarios actualizarlas y reemplazarlas sin recompilación de código. Si el proyecto nunca procesa credenciales de autenticación y claves criptográficas privadas, seleccione "no aplicable" (N/A). [crypto_credential_agility]

    Executing the current ambience sampler reaches a dependency-owned embedded RANDOM.ORG API credential without a caller credential-file or environment configuration argument. A local replacement reads caller-owned private API key files on every request and verifies rotation without changing source; it remains unmerged. Git credential rotation alone does not clear the sampler finding.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/reducers/sample_reducer.py


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

    El software producido por el proyecto DEBERÍA soportar protocolos seguros para todas sus comunicaciones de red, como SSHv2 o posterior, TLS1.2 o posterior (HTTPS), IPsec, SFTP y SNMPv3. Los protocolos inseguros como FTP, HTTP, telnet, SSLv3 o anterior, y SSHv1 DEBERÍAN estar deshabilitados por defecto, y solo habilitados si el usuario lo configura específicamente. Si el software producido por el proyecto no soporta comunicaciones de red, seleccione "no aplicable" (N/A). [crypto_used_network]

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

    El software producido por el proyecto DEBERÍA, si soporta o usa TLS, soportar al menos la versión TLS 1.2. Tenga en cuenta que el predecesor de TLS se llamaba SSL. Si el software no usa TLS, seleccione "no aplicable" (N/A). [crypto_tls12]

    No es suficiente para una insignia.

    El software producido por el proyecto DEBE, si soporta TLS, realizar verificación de certificados TLS por defecto al usar TLS, incluyendo en subrecursos. Si el software no usa TLS, seleccione "no aplicable" (N/A). [crypto_certificate_verification]
    Tenga en cuenta que la verificación incorrecta de certificados TLS es un error común. Para más información, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. y "Do you trust this application?" por Michael Catanzaro.

    Executing the current quantum sampler through its distributed Chances0.1.9 dependency reaches urlopen with CERT_NONE and check_hostname=False. A verified stdlib replacement with TLS1.2+, chain/hostname checks and redirect refusal is implemented locally and tested against real loopback TLS servers; it remains unmerged. Other standard dataset/Git transports do not clear this positive finding.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/reducers/sample_reducer.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml


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

    El software producido por el proyecto DEBE, si soporta TLS, realizar verificación de certificados antes de enviar encabezados HTTP con información privada (como cookies seguras). Si el software no usa TLS, seleccione "no aplicable" (N/A). [crypto_verification_private]

  • Lanzamiento seguro


    No es suficiente para una insignia.

    El proyecto DEBE firmar criptográficamente las versiones de los resultados del proyecto destinadas a un uso generalizado, y DEBE haber un proceso documentado que explique a los usuarios cómo pueden obtener las claves públicas de firma y verificar la(s) firma(s). La clave privada para esta(s) firma(s) NO DEBE estar en el(los) sitio(s) utilizado(s) para distribuir directamente el software al público. Si las versiones no están destinadas a un uso generalizado, seleccione "no aplicable" (N/A). [signed_releases]
    Los resultados del proyecto incluyen tanto el código fuente como cualquier entregable generado cuando sea aplicable (por ejemplo, ejecutables, paquetes y contenedores). Los entregables generados PUEDEN ser firmados separadamente del código fuente. Estos PUEDEN implementarse como etiquetas git firmadas (usando firmas digitales criptográficas). Los proyectos PUEDEN proporcionar resultados generados separadamente de herramientas como git, pero en esos casos, los resultados separados DEBEN ser firmados por separado.

    Latest published v1.4 remains unproven as signed. Merged deploy workflow supports signed provenance on a future authorized wheel/sdist publication. The next branch adds release assets and Sigstore bundles, but workflow code or a local build cannot establish an actual signed release. Await reviewed release execution and consumer verification; do not rewrite old tags.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/.github/workflows/deploy.yml
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/docs/Developer/Release-Policy.md
    https://github.com/autonomio/talos/releases/tag/v1.4


    Apenas suficiente para una insignia.

    Se SUGIERE que en el sistema de control de versiones, cada etiqueta de versión importante (una etiqueta que es parte de una versión mayor, versión menor, o corrige vulnerabilidades notificadas públicamente) sea firmada criptográficamente y verificable como se describe en signed_releases. [version_tags_signed]

    Current release script creates ordinary tags; latest v1.4 ref is commit object, no signed tag. SUGGESTED can be unmet; do not rewrite historical tags.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/scripts/create_release.py


  • Otros problemas de seguridad


    No es suficiente para una insignia.

    Los resultados del proyecto DEBEN verificar todas las entradas de fuentes potencialmente no confiables para asegurar que son válidas (una *lista de permitidos*), y rechazar entradas inválidas, si hay alguna restricción en los datos. [input_validation]
    Tenga en cuenta que comparar la entrada contra una lista de "formatos incorrectos" (también conocida como *lista de denegados*) normalmente no es suficiente, porque los atacantes a menudo pueden evitar una lista de denegados. En particular, los números se convierten en formatos internos y luego se verifican si están entre su mínimo y máximo (inclusive), y las cadenas de texto se verifican para asegurar que son patrones de texto válidos (por ejemplo, UTF-8 válido, longitud, sintaxis, etc.). Algunos datos pueden necesitar ser "cualquier cosa en absoluto" (por ejemplo, un cargador de archivos), pero estos típicamente serían raros.

    Current-source probes reproduce committed-manifest content tampering accepted under an unchanged lineage ID, objective direction sideways accepted, and string false accepted for boolean policy controls. Local regressions reject all of these before caller imports/source hydration, while preserving draft/historical identities; fixes remain unmerged and other constrained-input boundaries still require review.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/store.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/validator.py


    ¡Suficiente para una insignia!

    Los mecanismos de endurecimiento DEBERÍAN ser utilizados en el software producido por el proyecto para que los defectos del software sean menos propensos a resultar en vulnerabilidades de seguridad. [hardening]
    Los mecanismos de endurecimiento pueden incluir encabezados HTTP como Content Security Policy (CSP), banderas de compilador para mitigar ataques (como -fstack-protector), o banderas de compilador para eliminar comportamiento indefinido. Para nuestros propósitos, el menor privilegio no se considera un mecanismo de endurecimiento (el menor privilegio es importante, pero separado).

    Project produces interpreted local library/CLI, no account-serving runtime or native build. Describe memory-safe language/delegated platform hardening where applicable; least-privilege CI alone is explicitly not this hardening criterion.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md


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

    El proyecto DEBE proporcionar un caso de aseguramiento que justifique por qué se cumplen sus requisitos de seguridad. El caso de aseguramiento DEBE incluir: una descripción del modelo de amenazas, una identificación clara de los límites de confianza, un argumento de que se han aplicado principios de diseño seguro, y un argumento de que se han contrarrestado las debilidades de seguridad de implementación comunes. (URL requerida) [assurance_case]
    Un caso de aseguramiento es "un cuerpo documentado de evidencia que proporciona un argumento convincente y válido de que un conjunto especificado de afirmaciones críticas con respecto a las propiedades de un sistema están adecuadamente justificadas para una aplicación dada en un entorno dado" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Los límites de confianza son límites donde los datos o la ejecución cambian su nivel de confianza, por ejemplo, los límites de un servidor en una aplicación web típica. Es común enumerar principios de diseño seguro (como Saltzer y Schroeder) y debilidades de seguridad de implementación comunes (como el top 10 de OWASP o el top 25 de CWE/SANS), y mostrar cómo se contrarresta cada uno. El caso de aseguramiento de BadgeApp puede ser un ejemplo útil. Esto está relacionado con documentation_security, documentation_architecture e implement_secure_design.

 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'.

    Master CodeQL run36893895563 succeeded. The Python security analysis workflow is actually merged and executing.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/.github/workflows/pr_checks_codeql.yml
    https://github.com/autonomio/talos/actions/runs/36893895563


  • 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.

    No project-produced code in memory-unsafe language; native framework dependencies monitored separately.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml



Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/15140/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 16:30:01 UTC, última actualización el 2026-10-01 19:11:47 UTC.