Criterios de Mejores Prácticas FLOSS (Insignia de Plata)

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

Plata

Fundamentos

Prerrequisitos

El proyecto DEBE lograr una insignia de nivel aprobado. ^{[achieve_passing]}

Contenido básico del sitio web del proyecto

La información sobre cómo contribuir DEBE incluir los requisitos para contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). {URL de cumplimiento} ^{[contribution_requirements]}

Supervisión del proyecto

El proyecto DEBERÍA tener un mecanismo legal donde todos los desarrolladores de cantidades no triviales de software del proyecto afirmen que están legalmente autorizados para hacer estas contribuciones. El enfoque más común y fácilmente implementado para hacer esto es usando un Certificado de Origen del Desarrollador (DCO), donde los usuarios agregan "signed-off-by" en sus commits y el proyecto enlaza al sitio web DCO. Sin embargo, esto PUEDE implementarse como un Acuerdo de Licencia de Contribuidor (CLA), u otro mecanismo legal. {URL de cumplimiento} ^[dco]
El proyecto DEBE definir y documentar claramente su modelo de gobernanza del proyecto (la forma en que toma decisiones, incluyendo roles clave). {URL de cumplimiento} ^[governance]
El proyecto DEBE adoptar un código de conducta y publicarlo en una ubicación estándar. {URL de cumplimiento} ^{[code_of_conduct]}
El proyecto DEBE definir y documentar públicamente claramente los roles clave en el proyecto y sus responsabilidades, incluyendo cualquier tarea que esos roles deban realizar. DEBE quedar claro quién tiene qué rol(es), aunque esto podría no estar documentado de la misma manera. {URL de cumplimiento} ^{[roles_responsibilities]}
El proyecto DEBE poder continuar con una interrupción mínima si cualquier persona muere, queda incapacitada o de otro modo no puede o no está dispuesta a continuar el soporte del proyecto. En particular, el proyecto DEBE poder crear y cerrar issues, aceptar cambios propuestos y lanzar versiones de software, dentro de una semana de confirmación de la pérdida de soporte de cualquier individuo. Esto PUEDE hacerse asegurando que alguien más tenga las claves, contraseñas y derechos legales necesarios para continuar el proyecto. Los individuos que ejecutan un proyecto FLOSS PUEDEN hacer esto proporcionando claves en una caja de seguridad y un testamento que proporcione los derechos legales necesarios (por ejemplo, para nombres DNS). {URL de cumplimiento} ^{[access_continuity]}
El proyecto DEBERÍA tener un "factor de autobús" de 2 o más. {URL de cumplimiento} ^[bus_factor]

Documentación

El proyecto DEBE tener una hoja de ruta documentada que describa lo que el proyecto tiene la intención de hacer y no hacer durante al menos el próximo año. {URL de cumplimiento} ^{[documentation_roadmap]}
El proyecto DEBE incluir documentación de la arquitectura (también conocida como diseño de alto nivel) del software producido por el proyecto. Si el proyecto no produce software, seleccione "no aplicable" (N/A). {Justificación de N/A} {URL de cumplimiento} ^{[documentation_architecture]}
El proyecto DEBE documentar lo que el usuario puede y no puede esperar en términos de seguridad del software producido por el proyecto (sus "requisitos de seguridad"). {N/A permitido} {URL de cumplimiento} ^{[documentation_security]}
El proyecto DEBE proporcionar una guía de "inicio rápido" para nuevos usuarios para ayudarles a hacer algo rápidamente con el software. {Justificación de N/A} {URL de cumplimiento} ^{[documentation_quick_start]}
El proyecto DEBE hacer un esfuerzo para mantener la documentación consistente con la versión actual de los resultados del proyecto (incluido el software producido por el proyecto). Cualquier defecto de documentación conocido que lo haga inconsistente DEBE ser corregido. Si la documentación es generalmente actual, pero incluye erróneamente alguna información antigua que ya no es verdadera, simplemente trátelo como un defecto, luego rastree y corrija como de costumbre. {Justificación de N/A} {Justificación de cumplimiento} ^{[documentation_current]}
La página frontal del repositorio del proyecto y/o el sitio web DEBEN identificar e hipervincular cualquier logro, incluida esta insignia de mejores prácticas, dentro de las 48 horas del reconocimiento público de que el logro ha sido alcanzado. {URL de cumplimiento} ^{[documentation_achievements]}

Accesibilidad e internacionalización

El proyecto (tanto los sitios del proyecto como los resultados del proyecto) DEBERÍA seguir las mejores prácticas de accesibilidad para que las personas con discapacidades puedan participar en el proyecto y utilizar los resultados del proyecto cuando sea razonable hacerlo. {Justificación de N/A} {Justificación de cumplimiento} ^{[accessibility_best_practices]}
El software producido por el proyecto DEBERÍA estar internacionalizado para permitir una fácil localización para la cultura, región o idioma de la audiencia objetivo. Si la internacionalización (i18n) no aplica (por ejemplo, el software no genera texto destinado a usuarios finales y no ordena texto legible por humanos), seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[internationalization]}

Otro

Si los sitios del proyecto (sitio web, repositorio y URLs de descarga) almacenan 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). Si los sitios del proyecto no almacenan contraseñas para este propósito, seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[sites_password_security]}

Control de cambios

Versiones anteriores

El proyecto DEBE mantener las versiones antiguas más utilizadas del producto o proporcionar una ruta de actualización a versiones más nuevas. Si la ruta de actualización es difícil, el proyecto DEBE documentar cómo realizar la actualización (por ejemplo, las interfaces que han cambiado y los pasos detallados sugeridos para ayudar con la actualización). {Justificación de N/A} {Justificación de cumplimiento} ^{[maintenance_or_update]}

Informes

Proceso de reporte de errores

El proyecto DEBE usar un sistema de seguimiento de incidencias para rastrear problemas individuales. {Justificación de N/A} {Justificación de cumplimiento} ^{[report_tracker]}

Proceso de informe de vulnerabilidad

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). {Justificación de N/A} {URL de cumplimiento} ^{[vulnerability_report_credit]}
El proyecto DEBE tener un proceso documentado para responder a los informes de vulnerabilidades. {URL de cumplimiento} ^{[vulnerability_response_process]}

Calidad

Estándares de codificación

El proyecto DEBE identificar las guías de estilo de codificación específicas para los lenguajes principales que utiliza, y requerir que las contribuciones generalmente cumplan con ellas. {Justificación de N/A} {URL de cumplimiento} ^{[coding_standards]}
El proyecto DEBE hacer cumplir automáticamente su o sus estilos de codificación seleccionados si existe al menos una herramienta FLOSS que pueda hacerlo en el o los lenguajes seleccionados. {Justificación de N/A} {Justificación de cumplimiento} ^{[coding_standards_enforced]}

Sistema de construcción funcional

Los sistemas de construcción para binarios nativos DEBEN honrar las variables (de entorno) del compilador y enlazador relevantes que se les pasen (por ejemplo, CC, CFLAGS, CXX, CXXFLAGS y LDFLAGS) y pasarlas a las invocaciones del compilador y enlazador. Un sistema de construcción PUEDE extenderlas con banderas adicionales; NO DEBE simplemente reemplazar los valores proporcionados con los suyos. Si no se están generando binarios nativos, seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[build_standard_variables]}
El sistema de construcción e instalación DEBERÍA preservar la información de depuración si se solicita en las banderas relevantes (por ejemplo, no se usa "install -s"). Si no hay sistema de construcción o instalación (por ejemplo, bibliotecas JavaScript típicas), seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[build_preserve_debug]}
El sistema de construcción para el software producido por el proyecto NO DEBE construir recursivamente subdirectorios si hay dependencias cruzadas en los subdirectorios. Si no hay sistema de construcción o instalación (por ejemplo, bibliotecas JavaScript típicas), seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[build_non_recursive]}
El proyecto DEBE poder repetir el proceso de generar información desde archivos fuente y obtener exactamente el mismo resultado bit por bit. Si no ocurre construcción (por ejemplo, lenguajes de scripting donde el código fuente se usa directamente en lugar de compilarse), seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[build_repeatable]}

Sistema de instalación

El proyecto DEBE proporcionar una forma de instalar y desinstalar fácilmente el software producido por el proyecto usando una convención comúnmente utilizada. {Justificación de N/A} {Justificación de cumplimiento} ^{[installation_common]}
El sistema de instalación para usuarios finales DEBE honrar las convenciones estándar para seleccionar la ubicación donde se escriben los artefactos construidos en el momento de la instalación. Por ejemplo, si instala archivos en un sistema POSIX, DEBE honrar la variable de entorno DESTDIR. Si no hay sistema de instalación o no hay convención estándar, seleccione "no aplicable" (N/A). {Justificación de N/A} {Justificación de cumplimiento} ^{[installation_standard_variables]}
El proyecto DEBE proporcionar una forma para que los potenciales desarrolladores instalen rápidamente todos los resultados del proyecto y el entorno de soporte necesario para realizar cambios, incluidas las pruebas y el entorno de pruebas. Esto DEBE realizarse utilizando una convención de uso común. {Justificación de N/A} {Justificación de cumplimiento} ^{[installation_development_quick]}

Componentes mantenidos externamente

El proyecto DEBE enumerar las dependencias externas de manera procesable por computadora. {Justificación de N/A} {URL de cumplimiento} ^{[external_dependencies]}
Los proyectos DEBEN monitorear o verificar periódicamente sus dependencias externas (incluidas las copias de conveniencia) para detectar vulnerabilidades conocidas, y corregir las vulnerabilidades explotables o verificarlas como no explotables. {Justificación de N/A} {Justificación de cumplimiento} ^{[dependency_monitoring]}
El proyecto DEBE:
1. facilitar la identificación y actualización de componentes reutilizados mantenidos externamente; o
2. utilizar los componentes estándar proporcionados por el sistema o lenguaje de programación.
Entonces, si se encuentra una vulnerabilidad en un componente reutilizado, será fácil actualizar ese componente. {Justificación de N/A} {Justificación de cumplimiento} ^{[updateable_reused_components]}
El proyecto DEBERÍA evitar el uso de funciones y APIs obsoletas o en desuso cuando estén disponibles alternativas FLOSS en el conjunto de tecnología que utiliza (su "pila tecnológica") y para una supermayoría de los usuarios que el proyecto admite (para que los usuarios tengan acceso directo a la alternativa). {Justificación de N/A} {Justificación de cumplimiento} ^{[interfaces_current]}

Suite de pruebas automatizadas

Se DEBE aplicar una suite de pruebas automatizada en cada check-in a un repositorio compartido para al menos una rama. Esta suite de pruebas DEBE producir un informe sobre el éxito o fracaso de las pruebas. {Justificación de cumplimiento} ^{[automated_integration_testing]}
El proyecto DEBE agregar pruebas de regresión a una suite de pruebas automatizada para al menos el 50% de los errores corregidos en los últimos seis meses. {Justificación de N/A} {Justificación de cumplimiento} ^{[regression_tests_added50]}
El proyecto DEBE tener suite(s) de pruebas automatizadas FLOSS que proporcionen al menos un 80% de cobertura de declaraciones si existe 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_coverage80]}

Pruebas de nueva funcionalidad

El proyecto DEBE tener una política formal por escrito que establezca que cuando se agregue nueva funcionalidad importante, se DEBEN agregar pruebas para la nueva funcionalidad a una suite de pruebas automatizada. {Justificación de N/A} {Justificación de cumplimiento} ^{[test_policy_mandated]}
El proyecto DEBE incluir, en sus instrucciones documentadas para propuestas de cambios, la política de que se deben agregar pruebas para nueva funcionalidad importante. {Justificación de N/A} {Justificación de cumplimiento} ^{[tests_documented_added]}

Banderas de advertencia

Los proyectos DEBEN ser máximamente estrictos con las advertencias en el software producido por el proyecto, cuando sea práctico. {Justificación de N/A} {Justificación de cumplimiento} ^{[warnings_strict]}

Seguridad

Conocimiento de desarrollo seguro

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). {Justificación de N/A} {Justificación de cumplimiento} ^{[implement_secure_design]}

Use buenas prácticas criptográficas

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). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_weaknesses]}
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. {N/A permitido} {Justificación de cumplimiento} ^{[crypto_algorithm_agility]}
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). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_credential_agility]}
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). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_used_network]}
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). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_tls12]}
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). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_certificate_verification]}
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). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_verification_private]}

Lanzamiento seguro

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). {Justificación de N/A} {Justificación de cumplimiento} ^{[signed_releases]}
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. {Justificación de cumplimiento} ^{[version_tags_signed]}

Otros problemas de seguridad

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. {Justificación de N/A} {Justificación de cumplimiento} ^{[input_validation]}
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. {Justificación de N/A} {Justificación de cumplimiento} ^[hardening]
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 de cumplimiento} ^{[assurance_case]}

Análisis

Análisis estático de código

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. {Justificación de N/A} {Justificación de cumplimiento} ^{[static_analysis_common_vulnerabilities]}

Análisis dinámico de código

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). {Justificación de N/A} {Justificación de cumplimiento} ^{[dynamic_analysis_unsafe]}