Criterios de Mejores Prácticas FLOSS (Insignia de Oro)
Este es el conjunto de mejores prácticas para proyectos de Software Libre/Abierto y de Código Abierto (FLOSS) para lograr la insignia de oro de Mejores Prácticas de la Open Source Security Foundation (OpenSSF). Puede mostrar esta lista con solo los criterios o con información adicional. El conjunto completo de criterios también está disponible.
Consulte la discusión de criterios para obtener más información sobre estos criterios.
Oro
Fundamentos
Prerrequisitos
Supervisión del proyecto
-
El proyecto DEBE tener un "bus factor" de 2 o más.
{URL de cumplimiento}
[bus_factor]
-
El proyecto DEBE tener al menos dos contribuidores significativos no asociados.
{URL de cumplimiento}
[contributors_unassociated]
Otro
-
El proyecto DEBE incluir una declaración de derechos de autor en cada archivo fuente, identificando al titular de los derechos de autor (por ejemplo, los contribuidores de [nombre del proyecto]).
{Justificación de cumplimiento}
[copyright_per_file]
-
El proyecto DEBE incluir una declaración de licencia en cada archivo fuente. Esto PUEDE hacerse incluyendo lo siguiente dentro de un comentario cerca del comienzo de cada archivo: SPDX-License-Identifier: [expresión de licencia SPDX para el proyecto].
{Justificación de cumplimiento}
[license_per_file]
Control de cambios
Repositorio público para el control de versiones de código fuente
-
El repositorio de código fuente del proyecto DEBE usar un software de control de versiones distribuido común (por ejemplo, git o mercurial).
{Justificación de cumplimiento}
[repo_distributed]
-
El proyecto DEBE identificar claramente tareas pequeñas que puedan ser realizadas por contribuyentes nuevos o casuales.
{URL de cumplimiento}
[small_tasks]
-
El proyecto DEBE requerir autenticación de dos factores (2FA) para desarrolladores para cambiar un repositorio central o acceder a datos sensibles (como informes de vulnerabilidad privados). Este mecanismo 2FA PUEDE usar mecanismos sin mecanismos criptográficos como SMS, aunque eso no se recomienda.
{Justificación de cumplimiento}
[require_2FA]
-
La autenticación de dos factores (2FA) del proyecto DEBERÍA usar mecanismos criptográficos para prevenir la suplantación de identidad. La 2FA basada en el Servicio de Mensajes Cortos (SMS), por sí sola, NO cumple este criterio, ya que no está cifrada.
{Justificación de cumplimiento}
[secure_2FA]
Calidad
Estándares de codificación
-
El proyecto DEBE documentar sus requisitos de revisión de código, incluyendo cómo se lleva a cabo la revisión de código, qué debe verificarse, y qué se requiere para que sea aceptable.
{Justificación de N/A}
{URL de cumplimiento}
[code_review_standards]
-
El proyecto DEBE tener al menos el 50% de todas las modificaciones propuestas revisadas antes del lanzamiento por una persona distinta del autor, para determinar si es una modificación valiosa y libre de problemas conocidos que argumentarían en contra de su inclusión
{Justificación de cumplimiento}
[two_person_review]
Sistema de construcción funcional
-
El proyecto DEBE tener una construcción reproducible. Si no ocurre construcción (por ejemplo, lenguajes de scripting donde el código fuente se usa directamente en lugar de ser compilado), seleccione "no aplicable" (N/A).
{Justificación de N/A}
{URL de cumplimiento}
[build_reproducible]
Suite de pruebas automatizadas
-
Una suite de pruebas DEBE ser invocable de una manera estándar para ese lenguaje.
{URL de cumplimiento}
[test_invocation]
-
El proyecto DEBE implementar integración continua, donde el código nuevo o modificado se integra frecuentemente en un repositorio de código central y se ejecutan pruebas automatizadas sobre el resultado.
{URL de cumplimiento}
[test_continuous_integration]
-
El proyecto DEBE tener suite(s) de pruebas automatizadas FLOSS que proporcionen al menos 90% de cobertura de sentencias si hay al menos una herramienta FLOSS que pueda medir este criterio en el lenguaje seleccionado.
{Justificación de N/A}
{Justificación de cumplimiento}
[test_statement_coverage90]
-
El proyecto DEBE tener suite(s) de pruebas automatizadas FLOSS que proporcionen al menos 80% de cobertura de ramas si hay al menos una herramienta FLOSS que pueda medir este criterio en el lenguaje seleccionado.
{Justificación de N/A}
{Justificación de cumplimiento}
[test_branch_coverage80]
Seguridad
Use buenas prácticas criptográficas
-
El software producido por el proyecto DEBE 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 DEBEN 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).
{N/A permitido}
{Justificación de cumplimiento}
[crypto_used_network]
-
El software producido por el proyecto DEBE, si soporta o usa TLS, soportar al menos la versión 1.2 de TLS. Tenga en cuenta que el predecesor de TLS se llamaba SSL. Si el software no usa TLS, seleccione "no aplicable" (N/A).
{N/A permitido}
{Justificación de cumplimiento}
[crypto_tls12]
Entrega garantizada contra ataques de hombre en el medio (MITM)
-
El sitio web del proyecto, el repositorio (si es accesible a través de la web) y el sitio de descarga (si está separado) DEBEN incluir encabezados clave de endurecimiento con valores no permisivos.
{URL de cumplimiento}
[hardened_site]
Otros problemas de seguridad
-
El proyecto DEBE haber realizado una revisión de seguridad dentro de los últimos 5 años. Esta revisión DEBE considerar los requisitos de seguridad y el límite de seguridad.
{Justificación de cumplimiento}
[security_review]
-
Los mecanismos de endurecimiento DEBEN usarse en el software producido por el proyecto para que los defectos del software tengan menos probabilidades de resultar en vulnerabilidades de seguridad.
{Justificación de N/A}
{URL de cumplimiento}
[hardening]
Análisis
Análisis dinámico de código
-
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.
{Justificación de N/A}
{Justificación de cumplimiento}
[dynamic_analysis]
-
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.
{Justificación de N/A}
{Justificación de cumplimiento}
[dynamic_analysis_enable_assertions]