letsgolang

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í:

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/11658/badge)](https://www.bestpractices.dev/projects/11658)

o insertando esto en su HTML:

<a href="https://www.bestpractices.dev/projects/11658"><img src="https://www.bestpractices.dev/projects/11658/badge"></a>

Estos son los criterios de nivel

. También puede ver los criterios de nivel

.

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

Análisis 2/2 ●

Análisis dinámico de código

Criterion [dynamic_analysis]
Cumplido

No cumplido

N/A

?

El proyecto DEBE aplicar al menos una herramienta de análisis dinámico a cualquier versión de producción principal propuesta del software producido por el proyecto antes de su lanzamiento. ^{[dynamic_analysis]}
Una herramienta de análisis dinámico examina el software ejecutándolo con entradas específicas. Por ejemplo, el proyecto PUEDE usar una herramienta de fuzzing (por ejemplo, American Fuzzy Lop) o un escáner de aplicaciones web (por ejemplo, OWASP ZAP o w3af). En algunos casos, el proyecto OSS-Fuzz puede estar dispuesto a aplicar pruebas de fuzzing a su proyecto. Para los propósitos de este criterio, la herramienta de análisis dinámico necesita variar las entradas de alguna manera para buscar varios tipos de problemas o ser una suite de pruebas automatizada con al menos 80% de cobertura de ramas. La página de Wikipedia sobre análisis dinámico y la página de OWASP sobre fuzzing identifican algunas herramientas de análisis dinámico. La(s) herramienta(s) de análisis PUEDEN estar enfocadas en buscar vulnerabilidades de seguridad, pero esto no es obligatorio.

The project employs an automated test suite that performs dynamic analysis by executing the installer in a controlled environment. The test suite varies inputs, such as Go versions and installation paths, to ensure the script behaves correctly under different scenarios. Furthermore, the code is executed with strict shell options (set -euo pipefail) which acts as a runtime error-detection mechanism. The dynamic tests specifically verify the security logic within the get_temporary_asset function, ensuring that umask settings, directory permissions, and trap cleanups function as intended during execution.
Criterion [dynamic_analysis_enable_assertions]
Cumplido

No cumplido

N/A

?

El proyecto DEBERÍA incluir muchas aserciones en tiempo de ejecución en el software que produce y verificar esas aserciones durante el análisis dinámico. ^{[dynamic_analysis_enable_assertions]}
Este criterio no sugiere habilitar aserciones durante la producción; eso depende completamente del proyecto y sus usuarios decidir. El enfoque de este criterio es en cambio mejorar la detección de fallas durante el análisis dinámico antes del despliegue. Habilitar aserciones en el uso de producción es completamente diferente de habilitar aserciones durante el análisis dinámico (como las pruebas). En algunos casos, habilitar aserciones en el uso de producción es extremadamente imprudente (especialmente en componentes de alta integridad). Hay muchos argumentos contra habilitar aserciones en producción, por ejemplo, las bibliotecas no deberían bloquear a los llamadores, su presencia puede causar rechazo por las tiendas de aplicaciones, y/o activar una aserción en producción puede exponer datos privados como claves privadas. Tenga en cuenta que en muchas distribuciones de Linux NDEBUG no está definido, por lo que assert() de C/C++ estará habilitado por defecto para producción en esos entornos. Puede ser importante usar un mecanismo de aserción diferente o definir NDEBUG para producción en esos entornos.
The project follows a fail-fast design philosophy, which incorporates a variety of runtime assertions to catch issues early during dynamic analysis and testing. These assertions are primarily aimed at validating conditions before the code proceeds to the next steps, ensuring that any violations are caught as soon as possible during development, without reaching production.

Key Mechanisms in Testing:
1. Strict Execution Mode: The script uses set -euo pipefail, which enforces a fail-fast mechanism, acting as a global assertion during testing. This ensures that the script immediately exits if a command fails or if an undefined variable is accessed, effectively preventing further erroneous execution.
2. Explicit State Assertions: Critical functions, such as get_temporary_asset, include manual assertions to verify assumptions about the environment. For instance, the script checks if umask was set correctly and ensures that file permissions match the expected security profile (700 or 600).
3. Defensive Validation: Internal parameters and conditions are validated using assertions. For example, the script checks if the correct number of arguments is passed (if $# -ne 1) and provides descriptive error messages to help developers catch issues early during testing.
These assertions help the project to detect potential faults dynamically during test executions, and while they are part of the project's testing process, they are not enabled in production builds, in line with best practices.

This approach enhances the reliability of the project by addressing many common issues during development, ensuring that production releases are stable and secure.

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 jcsxdev y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: jcsxdev.
Entrada creada el 2025-12-27 06:19:38 UTC, última actualización el 2025-12-27 08:43:46 UTC. Última obtención de la insignia de nivel básico el 2025-12-27 08:43:46 UTC.

letsgolang

Fundamentos 0/5 ●

General

Prerrequisitos

Supervisión del proyecto

Otro

Control de cambios 1/4 ●

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

Calidad 0/7 ●

Estándares de codificación

Sistema de construcción funcional

Suite de pruebas automatizadas

Seguridad 0/5 ●

Use buenas prácticas criptográficas

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

Otros problemas de seguridad

Análisis 2/2 ●

Análisis dinámico de código