Criterios de Mejores Prácticas FLOSS (Insignia de Aprobación)

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 aprobación 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 para todos los niveles de insignia también está disponible.

Consulte la discusión de criterios para obtener más información sobre estos criterios.

Básico

Fundamentos

Contenido básico del sitio web del proyecto

El sitio web del proyecto DEBE describir sucintamente qué hace el software (¿qué problema resuelve?). ^{[description_good]}
El sitio web del proyecto DEBE proporcionar información sobre cómo: obtener, proporcionar comentarios (como informes de errores o mejoras), y contribuir al software. ^[interact]
La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) {URL de cumplimiento} ^{[contribution]}
La información sobre cómo contribuir DEBERÍA incluir los requisitos para las contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). {URL de cumplimiento} ^{[contribution_requirements]}

Licencia FLOSS

El software producido por el proyecto DEBE ser publicado como FLOSS. ^{[floss_license]}
Se SUGIERE que cualquier licencia(s) requerida(s) para el software producido por el proyecto sea aprobada por la Open Source Initiative (OSI). ^{[floss_license_osi]}
El proyecto DEBE publicar la(s) licencia(s) de sus resultados en una ubicación estándar en su repositorio de código fuente. {URL de cumplimiento} ^{[license_location]}

Documentación

El proyecto DEBE proporcionar documentación básica para el software producido por el proyecto. {Justificación de N/A} ^{[documentation_basics]}
El proyecto DEBE proporcionar documentación de referencia que describa la interfaz externa (tanto entrada como salida) del software producido por el proyecto. {Justificación de N/A} ^{[documentation_interface]}

Otro

Los sitios del proyecto (sitio web, repositorio y URLs de descarga) DEBEN admitir HTTPS usando TLS. ^{[sites_https]}
El proyecto DEBE tener uno o más mecanismos para la discusión (incluyendo cambios propuestos y problemas) que sean buscables, permitan que los mensajes y temas sean direccionables mediante URL, permitan que nuevas personas participen en algunas de las discusiones y no requieran la instalación del lado del cliente de software propietario. ^[discussion]
El proyecto DEBERÍA proporcionar documentación en inglés y ser capaz de aceptar informes de errores y comentarios sobre el código en inglés. ^[english]
El proyecto DEBE ser mantenido. ^[maintained]

Control de cambios

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

El proyecto DEBE tener un repositorio público para el control de versiones de código fuente que sea legible públicamente y tenga URL. ^{[repo_public]}
El repositorio fuente del proyecto DEBE rastrear qué cambios se realizaron, quién realizó los cambios y cuándo se realizaron los cambios. ^[repo_track]
Para permitir la revisión colaborativa, el repositorio de código fuente del proyecto DEBE incluir versiones provisionales para revisión entre lanzamientos; NO DEBE incluir solo versiones finales. ^{[repo_interim]}
Se SUGIERE que se use software de control de versiones distribuido común (por ejemplo, git) para el repositorio de código fuente del proyecto. ^{[repo_distributed]}

Numeración única de versión

Los resultados del proyecto DEBEN tener un identificador de versión único para cada lanzamiento destinado a ser usado por los usuarios. ^{[version_unique]}
Se SUGIERE que se use el formato de numeración de versiones Semantic Versioning (SemVer) o Calendar Versioning (CalVer) para los lanzamientos. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro. ^{[version_semver]}
Se SUGIERE que los proyectos identifiquen cada lanzamiento dentro de su sistema de control de versiones. Por ejemplo, se SUGIERE que quienes usen git identifiquen cada lanzamiento usando etiquetas de git. ^{[version_tags]}

Notas de lanzamiento

El proyecto DEBE proporcionar, en cada lanzamiento, notas de lanzamiento que sean un resumen legible por humanos de los cambios principales en ese lanzamiento para ayudar a los usuarios a determinar si deben actualizar y cuál será el impacto de la actualización. Las notas de lanzamiento NO DEBEN ser la salida bruta de un registro de control de versiones (por ejemplo, los resultados del comando "git log" no son notas de lanzamiento). Los proyectos cuyos resultados no están destinados para su reutilización en múltiples ubicaciones (como el software para un solo sitio web o servicio) Y emplean entrega continua PUEDEN seleccionar "N/A". {Justificación de N/A} {URL de cumplimiento} ^{[release_notes]}
Las notas de lanzamiento DEBEN identificar cada vulnerabilidad de tiempo de ejecución conocida públicamente que se corrigió en este lanzamiento y que ya tenía una asignación de CVE o similar cuando se creó el lanzamiento. Este criterio puede marcarse como no aplicable (N/A) si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica (por ejemplo, como suele ser cierto para las actualizaciones del kernel). Este criterio se aplica solo a los resultados del proyecto, no a sus dependencias. Si no hay notas de lanzamiento o no ha habido vulnerabilidades conocidas públicamente, elija N/A. {Justificación de N/A} ^{[release_notes_vulns]}

Informes

Proceso de reporte de errores

El proyecto DEBE proporcionar un proceso para que los usuarios envíen informes de errores (por ejemplo, usando un rastreador de issues o una lista de correo). {URL de cumplimiento} ^{[report_process]}
El proyecto DEBERÍA usar un rastreador de issues para rastrear problemas individuales. ^{[report_tracker]}
El proyecto DEBE reconocer la mayoría de los informes de errores enviados en los últimos 2-12 meses (inclusive); la respuesta no necesita incluir una solución. ^{[report_responses]}
El proyecto DEBERÍA responder a la mayoría (>50%) de las solicitudes de mejora en los últimos 2-12 meses (inclusive). ^{[enhancement_responses]}
El proyecto DEBE tener un archivo públicamente disponible para informes y respuestas para búsquedas posteriores. {URL de cumplimiento} ^{[report_archive]}

Proceso de informe de vulnerabilidad

El proyecto DEBE publicar el proceso para informar vulnerabilidades en el sitio del proyecto. {URL de cumplimiento} ^{[vulnerability_report_process]}
Si se admiten informes de vulnerabilidades privadas, el proyecto DEBE incluir cómo enviar la información de una manera que se mantenga privada. {N/A permitido} {URL de cumplimiento} ^{[vulnerability_report_private]}
El tiempo de respuesta inicial del proyecto para cualquier informe de vulnerabilidad recibido en los últimos 6 meses DEBE ser menor o igual a 14 días. {N/A permitido} ^{[vulnerability_report_response]}

Calidad

Sistema de construcción funcional

Si el software generado por el proyecto requiere ser construido para su uso, el proyecto DEBE proporcionar un sistema de compilación que pueda satisfactoriamente reconstruir automáticamente el software a partir del código fuente. {N/A permitido} ^[build]
Se SUGIERE que se utilicen herramientas comunes para construir el software. {N/A permitido} ^{[build_common_tools]}
El proyecto DEBERÍA ser construible usando solo herramientas FLOSS. {N/A permitido} ^{[build_floss_tools]}

Suite de pruebas automatizadas

El proyecto DEBE usar al menos un conjunto de pruebas automatizado que se publique públicamente como FLOSS (este conjunto de pruebas puede mantenerse como un proyecto FLOSS separado). El proyecto DEBE mostrar claramente o documentar cómo ejecutar el conjunto(s) de pruebas (por ejemplo, a través de un script de integración continua (CI) o mediante documentación en archivos como BUILD.md, README.md, o CONTRIBUTING.md). ^[test]
Un conjunto de pruebas DEBERÍA ser invocable de forma estándar para ese lenguaje. ^{[test_invocation]}
Se SUGIERE que el conjunto de pruebas cubra la mayoría (o idealmente todas) las ramas de código, campos de entrada y funcionalidad. ^[test_most]
Se SUGIERE que el proyecto implemente 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). ^{[test_continuous_integration]}

Pruebas de nueva funcionalidad

El proyecto DEBE tener una política general (formal o no) de que a medida que se agrega nueva funcionalidad importante al software producido por el proyecto, se deben agregar pruebas de esa funcionalidad a un conjunto de pruebas automatizado. ^{[test_policy]}
El proyecto DEBE tener evidencia de que la test_policy para agregar pruebas se ha cumplido en los cambios más recientes importantes al software producido por el proyecto. ^{[tests_are_added]}
Se SUGIERE que esta política sobre la adición de pruebas (vea test_policy) esté documentada en las instrucciones para propuestas de cambios. ^{[tests_documented_added]}

Banderas de advertencia

El proyecto DEBE habilitar una o más marcas de advertencia del compilador, un modo de lenguaje "seguro", o usar una herramienta "linter" separada para buscar errores de calidad del código o errores simples comunes, si existe al menos una herramienta FLOSS que pueda implementar este criterio en el lenguaje seleccionado. {N/A permitido} ^[warnings]
El proyecto DEBE abordar las advertencias. {N/A permitido} ^{[warnings_fixed]}
Se SUGIERE que los proyectos sean máximamente estrictos con las advertencias en el software producido por el proyecto, cuando sea práctico. {N/A permitido} ^{[warnings_strict]}

Seguridad

Conocimiento de desarrollo seguro

El proyecto DEBE tener al menos un desarrollador principal que sepa cómo diseñar software seguro. (Ver 'detalles' para los requisitos exactos.) ^{[know_secure_design]}
Al menos uno de los desarrolladores principales del proyecto DEBE conocer tipos comunes de errores que conducen a vulnerabilidades en este tipo de software, así como al menos un método para contrarrestar o mitigar cada uno de ellos. ^{[know_common_errors]}

Use buenas prácticas criptográficas

El software producido por el proyecto DEBE usar, por defecto, solo protocolos y algoritmos criptográficos que estén públicamente publicados y revisados por expertos (si se usan protocolos y algoritmos criptográficos). {N/A permitido} ^{[crypto_published]}
Si el software producido por el proyecto es una aplicación o una librería, y su propósito principal no es implementar criptografía, entonces DEBE SOLAMENTE invocar un software específicamente diseñado para implementar funciones criptográficas; NO DEBERÍA volver a implementar el suyo. {N/A permitido} ^{[crypto_call]}
Toda funcionalidad en el software producido por el proyecto que dependa de criptografía DEBE ser implementable usando FLOSS. {N/A permitido} ^{[crypto_floss]}
Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN usar longitudes de clave predeterminadas que al menos cumplan con los requisitos mínimos de NIST hasta el año 2030 (como se declaró en 2012). DEBE ser posible configurar el software de modo que las longitudes de clave más pequeñas estén completamente deshabilitadas. {N/A permitido} ^{[crypto_keylength]}
Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBEN depender de algoritmos criptográficos rotos (por ejemplo, MD4, MD5, DES simple, RC4, Dual_EC_DRBG), o usar modos de cifrado que son inapropiados para el contexto, a menos que sean necesarios para implementar un protocolo interoperable (donde el protocolo implementado es la versión más reciente de ese estándar ampliamente soportada por el ecosistema de red, ese ecosistema requiere el uso de tal algoritmo o modo, y ese ecosistema no ofrece ninguna alternativa más segura). La documentación DEBE describir cualquier riesgo de seguridad relevante y cualquier mitigación conocida si estos algoritmos o modos rotos son necesarios para un protocolo interoperable. {N/A permitido} ^{[crypto_working]}
Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBERÍAN depender de algoritmos o modos criptográficos con debilidades serias conocidas (por ejemplo, el algoritmo hash criptográfico SHA-1 o el modo CBC en SSH). {N/A permitido} ^{[crypto_weaknesses]}
Los mecanismos de seguridad dentro del software producido por el proyecto DEBERÍAN implementar confidencialidad directa perfecta para protocolos de acuerdo de claves de modo que una clave de sesión derivada de un conjunto de claves a largo plazo no pueda ser comprometida si una de las claves a largo plazo es comprometida en el futuro. {N/A permitido} ^[crypto_pfs]
Si el software producido por el proyecto causa el almacenamiento de 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). Ver también OWASP Password Storage Cheat Sheet. {N/A permitido} ^{[crypto_password_storage]}
Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN generar todas las claves criptográficas y nonces utilizando un generador de números aleatorios criptográficamente seguro, y NO DEBEN hacerlo usando generadores que son criptográficamente inseguros. {N/A permitido} ^{[crypto_random]}

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

El proyecto DEBE usar un mecanismo de entrega que contrarreste los ataques MITM. Usar https o ssh+scp es aceptable. ^{[delivery_mitm]}
Un hash criptográfico (por ejemplo, un sha1sum) NO DEBE recuperarse a través de http y usarse sin verificar una firma criptográfica. ^{[delivery_unsigned]}

Vulnerabilidades públicamente conocidas corregidas

NO DEBE haber vulnerabilidades sin parchar de severidad media o superior que hayan sido conocidas públicamente durante más de 60 días. ^{[vulnerabilities_fixed_60_days]}
Los proyectos DEBERÍAN corregir todas las vulnerabilidades críticas rápidamente después de que se reporten. ^{[vulnerabilities_critical_fixed]}

Otros problemas de seguridad

Los repositorios públicos NO DEBEN filtrar una credencial privada válida (por ejemplo, una contraseña funcional o una clave privada) que esté destinada a limitar el acceso público. ^{[no_leaked_credentials]}

Análisis

Análisis estático de código

Al menos una herramienta de análisis de código estático (más allá de las advertencias del compilador y los modos de lenguaje "seguros") DEBE aplicarse a cualquier lanzamiento de producción importante propuesto del software antes de su lanzamiento, si hay al menos una herramienta FLOSS que implemente este criterio en el lenguaje seleccionado. {Justificación de N/A} {Justificación de cumplimiento} ^{[static_analysis]}
Se SUGIERE que al menos una de las herramientas de análisis estático utilizadas para el criterio static_analysis incluya reglas o enfoques para buscar vulnerabilidades comunes en el lenguaje o entorno analizado. {N/A permitido} ^{[static_analysis_common_vulnerabilities]}
Todas las vulnerabilidades explotables de severidad media y superior descubiertas con el análisis de código estático DEBEN corregirse de manera oportuna después de que se confirmen. {N/A permitido} ^{[static_analysis_fixed]}
Se SUGIERE que el análisis de código fuente estático ocurra en cada commit o al menos diariamente. {N/A permitido} ^{[static_analysis_often]}

Análisis dinámico de código

Se SUGIERE que al menos una herramienta de análisis dinámico se aplique a cualquier lanzamiento de producción importante propuesto del software antes de su lanzamiento. ^{[dynamic_analysis]}
Se SUGIERE que si el software producido por el proyecto incluye software escrito usando un lenguaje no seguro en memoria (por ejemplo, C o C++), entonces se use rutinariamente al menos una herramienta dinámica (por ejemplo, un fuzzer o escáner de aplicaciones web) en combinación con un mecanismo para detectar problemas de seguridad de memoria como desbordamientos de búfer. Si el proyecto no produce software escrito en un lenguaje no seguro en memoria, elija "no aplicable" (N/A). {N/A permitido} ^{[dynamic_analysis_unsafe]}
Se SUGIERE que el proyecto use una configuración para al menos algún análisis dinámico (como pruebas o fuzzing) que habilite muchas aserciones. En muchos casos estas aserciones no deberían estar habilitadas en compilaciones de producción. ^{[dynamic_analysis_enable_assertions]}
Todas las vulnerabilidades explotables de severidad media y superior descubiertas con análisis de código dinámico DEBEN ser corregidas de manera oportuna después de que sean confirmadas. {N/A permitido} ^{[dynamic_analysis_fixed]}