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

El proyecto DEBE lograr una insignia de nivel plata. ^{[achieve_silver]}

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

Detalles:

Los contribuidores están asociados si son pagados para trabajar por la misma organización (como empleado o contratista) y la organización se beneficia de los resultados del proyecto. Las subvenciones financieras no cuentan como ser de la misma organización si pasan a través de otras organizaciones (por ejemplo, las subvenciones científicas pagadas a diferentes organizaciones de una fuente gubernamental o de ONG común no hacen que los contribuidores estén asociados). Alguien es un contribuidor significativo si ha hecho contribuciones no triviales al proyecto en el último año. Ejemplos de buenos indicadores de un contribuidor significativo son: haber escrito al menos 1,000 líneas de código, haber contribuido 50 commits, o haber contribuido al menos 20 páginas de documentación.

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

Detalles:

Esto PUEDE hacerse incluyendo lo siguiente dentro de un comentario cerca del comienzo de cada archivo: "Copyright the [project name] contributors.". Vea "Copyright Notices in Open Source Software Projects" de Steve Winslow.
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]}

Detalles:

Esto también PUEDE hacerse incluyendo una declaración en lenguaje natural que identifique la licencia. El proyecto también PUEDE incluir una URL estable que apunte al texto de la licencia, o el texto completo de la licencia. Tenga en cuenta que el criterio license_location requiere que la licencia del proyecto esté en una ubicación estándar. Vea este tutorial de SPDX para obtener más información sobre expresiones de licencia SPDX. Observe la relación con copyright_per_file, cuyo contenido típicamente precedería la información de la licencia.

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

Detalles:

Esta identificación típicamente se hace marcando issues seleccionados en un rastreador de issues con una o más etiquetas que el proyecto usa para el propósito, por ejemplo, up-for-grabs, first-timers-only, "Small fix", microtask, o IdealFirstBug. Estas nuevas tareas no necesitan implicar agregar funcionalidad; pueden ser mejorar la documentación, agregar casos de prueba, o cualquier otra cosa que ayude al proyecto y ayude al contribuyente a entender más sobre el proyecto.
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]

Detalles:

Un mecanismo 2FA que cumpla con este criterio sería una aplicación de Contraseña de Un Solo Uso Basada en Tiempo (TOTP) que genera automáticamente un código de autenticación que cambia después de un cierto período de tiempo. Tenga en cuenta que GitHub soporta TOTP.

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

Detalles:

Vea también two_person_review y contribution_requirements.
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]}

Detalles:

Una construcción reproducible significa que múltiples partes pueden rehacer independientemente el proceso de generar información desde archivos fuente y obtener exactamente el mismo resultado bit por bit. En algunos casos, esto puede resolverse forzando algún tipo de orden. Los desarrolladores de JavaScript pueden considerar usar npm shrinkwrap y webpack OccurrenceOrderPlugin. Los usuarios de GCC y clang pueden encontrar útil la opción -frandom-seed. El entorno de construcción (incluido el conjunto de herramientas) a menudo puede definirse para partes externas especificando el hash criptográfico de un contenedor o máquina virtual específicos que pueden usar para reconstruir. El proyecto de construcciones reproducibles tiene documentación sobre cómo hacer esto.

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

Detalles:

En la mayoría de los casos, esto significa que cada desarrollador que trabaja a tiempo completo en el proyecto se integra al menos diariamente.
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]}

Detalles:

Tenga en cuenta que se sabe que GitHub y GitLab cumplen con esto. Sitios como https://securityheaders.com/ pueden verificar esto rápidamente. Los encabezados clave de endurecimiento son: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (como "nosniff"), y X-Frame-Options. Los sitios web totalmente estáticos sin capacidad de iniciar sesión a través de las páginas web podrían omitir algunos encabezados de endurecimiento con menos riesgo, pero no hay una manera confiable de detectar tales sitios, por lo que requerimos estos encabezados incluso si son sitios totalmente estáticos.

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

Detalles:

Esto PUEDE ser realizado por los miembros del proyecto y/o una evaluación independiente. Esta evaluación PUEDE estar respaldada por herramientas de análisis estático y dinámico, pero también debe haber una revisión humana para identificar problemas (particularmente en el diseño) que las herramientas no pueden detectar.
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]}