Criterios de Mejores Prácticas FLOSS (Todos los Niveles)

Este es el conjunto de mejores prácticas para proyectos de Software Libre/Abierto y de Código Abierto (FLOSS) para lograr las insignias de Mejores Prácticas de la Open Source Security Foundation (OpenSSF) en los niveles de insignia de aprobación, plata y oro. Puede mostrar esta lista con solo los criterios o con información adicional. También puede ver solo los criterios de aprobación, plata y oro, así como estadísticas de criterios.

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

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]

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]

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]

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]

Nivel Base 1

General

Controles

  • Cuando un usuario intenta leer o modificar un recurso sensible en el repositorio autorizado del proyecto, el sistema DEBE requerir que el usuario complete un proceso de autenticación multifactor. {Justificación de N/A} {URL de cumplimiento} [osps_ac_01_01]
  • Cuando se agrega un nuevo colaborador, el sistema de control de versiones DEBE requerir asignación manual de permisos, o restringir los permisos del colaborador a los privilegios más bajos disponibles por defecto. {Justificación de N/A} {URL de cumplimiento} [osps_ac_02_01]
  • Cuando se intenta un commit directo en la rama principal del proyecto, un mecanismo de aplicación DEBE evitar que se aplique el cambio. {Justificación de N/A} {URL de cumplimiento} [osps_ac_03_01]
  • Cuando se intenta eliminar la rama principal del proyecto, el sistema de control de versiones DEBE tratar esto como una actividad sensible y requerir confirmación explícita de la intención. {Justificación de N/A} {URL de cumplimiento} [osps_ac_03_02]
  • Cuando un pipeline de CI/CD acepta un parámetro de entrada, ese parámetro DEBE ser saneado y validado antes de usarse en el pipeline. {Justificación de N/A} {URL de cumplimiento} [osps_br_01_01]
  • Cuando un flujo de CI/CD opera sobre instantáneas de código no confiable, DEBE impedir el acceso a credenciales y activos privilegiados de CI/CD. {Justificación de N/A} {URL de cumplimiento} {Futuro} [osps_br_01_03]
  • Cuando el proyecto lista un URI como un canal oficial del proyecto, ese URI DEBE ser entregado exclusivamente usando canales cifrados. {Justificación de N/A} {URL de cumplimiento} [osps_br_03_01]
  • Cuando el proyecto lista una URI como un canal de distribución oficial, esa URI DEBE ser entregada exclusivamente usando canales cifrados. {Justificación de N/A} {URL de cumplimiento} [osps_br_03_02]
  • El proyecto DEBE prevenir el almacenamiento no intencionado de datos sensibles no cifrados, como secretos y credenciales, en el sistema de control de versiones. {Justificación de N/A} {URL de cumplimiento} [osps_br_07_01]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir guías de usuario para toda la funcionalidad básica. {Justificación de N/A} {URL de cumplimiento} [osps_do_01_01]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una guía para reportar defectos. {Justificación de N/A} {URL de cumplimiento} [osps_do_02_01]
  • Mientras esté activo, el proyecto DEBE tener uno o más mecanismos para discusiones públicas sobre cambios propuestos y obstáculos de uso. {Justificación de N/A} {URL de cumplimiento} [osps_gv_02_01]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una explicación del proceso de contribución. {Justificación de N/A} {URL de cumplimiento} [osps_gv_03_01]
  • Mientras esté activo, la licencia para el código fuente DEBE cumplir con la Definición de Código Abierto de OSI o la Definición de Software Libre de FSF. {Justificación de N/A} {URL de cumplimiento} [osps_le_02_01]
  • Mientras esté activo, la licencia para los activos de software lanzados DEBE cumplir con la Definición de Código Abierto de OSI o la Definición de Software Libre de FSF. {Justificación de N/A} {URL de cumplimiento} [osps_le_02_02]
  • Mientras esté activo, la licencia para el código fuente DEBE ser mantenida en el archivo LICENSE, archivo COPYING o directorio LICENSE/ del repositorio correspondiente. {Justificación de N/A} {URL de cumplimiento} [osps_le_03_01]
  • Mientras esté activo, la licencia para los activos de software lanzados DEBE estar incluida en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes. {Justificación de N/A} {URL de cumplimiento} [osps_le_03_02]
  • Mientras esté activo, el repositorio de código fuente del proyecto DEBE ser legible públicamente en una URL estática. {Justificación de N/A} {URL de cumplimiento} [osps_qa_01_01]
  • El sistema de control de versiones DEBE contener un registro legible públicamente de todos los cambios realizados, quién los realizó y cuándo se realizaron los cambios. {Justificación de N/A} {URL de cumplimiento} [osps_qa_01_02]
  • Cuando el sistema de gestión de paquetes lo admita, el repositorio de código fuente DEBE contener una lista de dependencias que contabilice las dependencias directas del lenguaje. {Justificación de N/A} {URL de cumplimiento} [osps_qa_02_01]
  • Mientras esté activa, la documentación del proyecto DEBE contener una lista de cualquier código base que se considere subproyecto. {Justificación de N/A} {URL de cumplimiento} [osps_qa_04_01]
  • Mientras esté activo, el sistema de control de versiones NO DEBE contener artefactos ejecutables generados. {Justificación de N/A} {URL de cumplimiento} [osps_qa_05_01]
  • Mientras esté activo, el sistema de control de versiones NO DEBE contener artefactos binarios no revisables. {Justificación de N/A} {URL de cumplimiento} [osps_qa_05_02]
  • Mientras esté activa, la documentación del proyecto DEBE contener contactos de seguridad. {Justificación de N/A} {URL de cumplimiento} [osps_vm_02_01]
  • Cuando un pipeline de CI/CD usa un nombre de rama en su funcionalidad, ese valor de nombre DEBE ser saneado y validado antes de usarse en el pipeline. {Justificación de N/A} {URL de cumplimiento} {Obsoleto} [osps_br_01_02]

Nivel Base 2

General

Controles

  • Cuando una tarea de CI/CD se ejecuta sin permisos especificados, el sistema de CI/CD DEBE establecer por defecto los permisos de la tarea a los permisos más bajos otorgados en el pipeline. {Justificación de N/A} {URL de cumplimiento} [osps_ac_04_01]
  • Cuando se crea un lanzamiento oficial, ese lanzamiento DEBE ser asignado un identificador de versión único. {Justificación de N/A} {URL de cumplimiento} [osps_br_02_01]
  • Cuando se crea un lanzamiento oficial, ese lanzamiento DEBE contener un registro descriptivo de modificaciones funcionales y de seguridad. {Justificación de N/A} {URL de cumplimiento} [osps_br_04_01]
  • Cuando un pipeline de construcción y lanzamiento ingiere dependencias, DEBE usar herramientas estandarizadas donde estén disponibles. {Justificación de N/A} {URL de cumplimiento} [osps_br_05_01]
  • Cuando se crea un lanzamiento oficial, ese lanzamiento DEBE estar firmado o registrado en un manifiesto firmado que incluya los hashes criptográficos de cada activo. {Justificación de N/A} {URL de cumplimiento} [osps_br_06_01]
  • Cuando el proyecto ha realizado un lanzamiento, la documentación del proyecto DEBE incluir una descripción de cómo el proyecto selecciona, obtiene y rastrea sus dependencias. {Justificación de N/A} {URL de cumplimiento} [osps_do_06_01]
  • La documentación del proyecto DEBE incluir instrucciones sobre cómo compilar el software, incluyendo las bibliotecas, marcos, SDK y dependencias necesarias. {Justificación de N/A} {URL de cumplimiento} {Futuro} [osps_do_07_01]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una lista de miembros del proyecto con acceso a recursos sensibles. {Justificación de N/A} {URL de cumplimiento} [osps_gv_01_01]
  • Mientras esté activo, la documentación del proyecto DEBE incluir descripciones de los roles y responsabilidades para los miembros del proyecto. {Justificación de N/A} {URL de cumplimiento} [osps_gv_01_02]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una guía para contribuidores de código que incluya requisitos para contribuciones aceptables. {Justificación de N/A} {URL de cumplimiento} [osps_gv_03_02]
  • Mientras esté activo, el sistema de control de versiones DEBE requerir que todos los contribuidores de código afirmen que están legalmente autorizados para hacer las contribuciones asociadas en cada commit. {Justificación de N/A} {URL de cumplimiento} [osps_le_01_01]
  • Cuando se realiza un commit a la rama principal, cualquier verificación de estado automatizada para commits DEBE pasar o ser omitida manualmente. {Justificación de N/A} {URL de cumplimiento} [osps_qa_03_01]
  • Antes de que se acepte un commit, los pipelines de CI/CD del proyecto DEBEN ejecutar al menos un conjunto de pruebas automatizado para asegurar que los cambios cumplan las expectativas. {Justificación de N/A} {URL de cumplimiento} [osps_qa_06_01]
  • Cuando el proyecto ha realizado un lanzamiento, la documentación del proyecto DEBE incluir documentación de diseño que demuestre todas las acciones y actores dentro del sistema. {Justificación de N/A} {URL de cumplimiento} [osps_sa_01_01]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir descripciones de todas las interfaces de software externas de los activos de software liberados. {Justificación de N/A} {URL de cumplimiento} [osps_sa_02_01]
  • Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar una evaluación de seguridad para comprender los problemas de seguridad potenciales más probables e impactantes que podrían ocurrir dentro del software. {Justificación de N/A} {URL de cumplimiento} [osps_sa_03_01]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una política para la divulgación coordinada de vulnerabilidades (CVD), con un plazo de tiempo claro para la respuesta. {Justificación de N/A} {URL de cumplimiento} [osps_vm_01_01]
  • Mientras esté activo, la documentación del proyecto DEBE proporcionar un medio para el reporte privado de vulnerabilidades directamente a los contactos de seguridad dentro del proyecto. {Justificación de N/A} {URL de cumplimiento} [osps_vm_03_01]
  • Mientras esté activo, la documentación del proyecto DEBE publicar públicamente datos sobre las vulnerabilidades descubiertas. {Justificación de N/A} {URL de cumplimiento} [osps_vm_04_01]

Nivel Base 3

General

Controles

  • Cuando se asigna permisos a un trabajo en un pipeline de CI/CD, el código fuente o configuración DEBE asignar solo los privilegios mínimos necesarios para la actividad correspondiente. {Justificación de N/A} {URL de cumplimiento} [osps_ac_04_02]
  • Los flujos de CI/CD que aceptan entradas de colaboradores de confianza DEBEN sanear y validar dichas entradas antes de utilizarlas en el flujo. {Justificación de N/A} {URL de cumplimiento} {Futuro} [osps_br_01_04]
  • Cuando se crea un lanzamiento oficial, todos los activos dentro de ese lanzamiento DEBEN estar claramente asociados con el identificador del lanzamiento u otro identificador único para el activo. {Justificación de N/A} {URL de cumplimiento} [osps_br_02_02]
  • El proyecto DEBE definir una política para gestionar secretos y credenciales utilizados por el proyecto. La política debe incluir directrices para almacenar, acceder y rotar secretos y credenciales. {Justificación de N/A} {URL de cumplimiento} [osps_br_07_02]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la integridad y autenticidad de los activos del lanzamiento. {Justificación de N/A} {URL de cumplimiento} [osps_do_03_01]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la identidad esperada de la persona o proceso que crea el lanzamiento del software. {Justificación de N/A} {URL de cumplimiento} [osps_do_03_02]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una declaración descriptiva sobre el alcance y la duración del soporte para cada lanzamiento. {Justificación de N/A} {URL de cumplimiento} [osps_do_04_01]
  • Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE proporcionar una declaración descriptiva sobre cuándo los lanzamientos o versiones ya no recibirán actualizaciones de seguridad. {Justificación de N/A} {URL de cumplimiento} [osps_do_05_01]
  • Mientras esté activo, la documentación del proyecto DEBE tener una política que establezca que los colaboradores de código sean revisados antes de otorgarles permisos elevados a recursos sensibles. {Justificación de N/A} {URL de cumplimiento} [osps_gv_04_01]
  • Cuando el proyecto haya realizado un lanzamiento, todos los activos de software compilados lanzados DEBEN ser entregados con una lista de materiales de software. {Justificación de N/A} {URL de cumplimiento} [osps_qa_02_02]
  • Cuando el proyecto haya realizado un lanzamiento que comprenda múltiples repositorios de código fuente, todos los subproyectos DEBEN aplicar requisitos de seguridad que sean tan estrictos o más estrictos que la base de código principal. {Justificación de N/A} {URL de cumplimiento} [osps_qa_04_02]
  • Mientras esté activo, la documentación del proyecto DEBE documentar claramente cuándo y cómo se ejecutan las pruebas. {Justificación de N/A} {URL de cumplimiento} [osps_qa_06_02]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una política que establezca que todos los cambios importantes al software producido por el proyecto deben agregar o actualizar las pruebas de la funcionalidad en una suite de pruebas automatizada. {Justificación de N/A} {URL de cumplimiento} [osps_qa_06_03]
  • Cuando se realiza un commit a la rama principal, el sistema de control de versiones del proyecto DEBE requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos. {Justificación de N/A} {URL de cumplimiento} [osps_qa_07_01]
  • Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar un modelado de amenazas y análisis de superficie de ataque para comprender y protegerse contra ataques en rutas de código críticas, funciones e interacciones dentro del sistema. {Justificación de N/A} {URL de cumplimiento} [osps_sa_03_02]
  • Mientras esté activo, cualquier vulnerabilidad en los componentes de software que no afecte al proyecto DEBE ser contabilizada en un documento VEX, aumentando el informe de vulnerabilidad con detalles de no explotabilidad. {Justificación de N/A} {URL de cumplimiento} [osps_vm_04_02]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una política que defina un umbral para la remediación de hallazgos de SCA relacionados con vulnerabilidades y licencias. {Justificación de N/A} {URL de cumplimiento} [osps_vm_05_01]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una política para abordar violaciones de SCA antes de cualquier lanzamiento. {Justificación de N/A} {URL de cumplimiento} [osps_vm_05_02]
  • Mientras esté activo, todos los cambios en la base de código del proyecto DEBEN ser automáticamente evaluados contra una política documentada para dependencias maliciosas y vulnerabilidades conocidas en dependencias, y luego bloqueados en caso de violaciones, excepto cuando se declaren y supriman como no explotables. {Justificación de N/A} {URL de cumplimiento} [osps_vm_05_03]
  • Mientras esté activo, la documentación del proyecto DEBE incluir una política que defina un umbral para la remediación de hallazgos de SAST. {Justificación de N/A} {URL de cumplimiento} [osps_vm_06_01]
  • Mientras esté activo, todos los cambios en la base de código del proyecto DEBEN ser automáticamente evaluados contra una política documentada para debilidades de seguridad y bloqueados en caso de violaciones excepto cuando se declaren y supriman como no explotables. {Justificación de N/A} {URL de cumplimiento} [osps_vm_06_02]