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

  Detalles:

  Esto DEBE estar en un lenguaje que los usuarios potenciales puedan entender (por ejemplo, utiliza jerga mínima).

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

  Detalles:

  Se asume que los proyectos en GitHub usan "incidencias" y "pull requests" a menos que se indique lo contrario. Esta información puede ser breve, por ejemplo, indicando que el proyecto utiliza "pull requests", un gestor de incidencias o publicaciones en una lista de correo (Indíquese cuál)

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

  Detalles:

  FLOSS es software publicado de una manera que cumple con la Definición de Código Abierto o la Definición de Software Libre. Ejemplos de tales licencias incluyen CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Para nuestros propósitos, esto significa que la licencia DEBE ser:

  • una licencia aprobada por la Open Source Initiative (OSI), o
  • una licencia libre aprobada por la Free Software Foundation (FSF), o
  • una licencia libre aceptable para Debian main, o
  • una licencia "buena" según Fedora.

  El software PUEDE también estar licenciado de otras maneras (por ejemplo, "GPLv2 o propietario" es aceptable).

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

  Detalles:

  La OSI utiliza un proceso de aprobación riguroso para determinar qué licencias son OSS.

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

  Detalles:

  Una convención es publicar la licencia como un archivo de nivel superior llamado LICENSE o COPYING, que PUEDE ser seguido por una extensión como ".txt" o ".md". Una convención alternativa es tener un directorio llamado LICENSES que contenga archivo(s) de licencia; estos archivos generalmente se nombran según su identificador de licencia SPDX seguido de una extensión de archivo apropiada, como se describe en la Especificación REUSE. Tenga en cuenta que este criterio es solo un requisito para el repositorio de código fuente. NO necesita incluir el archivo de licencia al generar algo desde el código fuente (como un ejecutable, paquete o contenedor). Por ejemplo, al generar un paquete R para el Comprehensive R Archive Network (CRAN), siga la práctica estándar de CRAN: si la licencia es una licencia estándar, use la especificación de licencia corta estándar (para evitar instalar otra copia del texto) y liste el archivo LICENSE en un archivo de exclusión como .Rbuildignore. De manera similar, al crear un paquete Debian, puede poner un enlace en el archivo de derechos de autor al texto de la licencia en /usr/share/common-licenses, y excluir el archivo de licencia del paquete creado (por ejemplo, eliminando el archivo después de llamar a dh_auto_install). Alentamos a incluir información de licencia legible por máquina en formatos generados cuando sea práctico.

Documentación

• El proyecto DEBE proporcionar documentación básica para el software producido por el proyecto. {Justificación de N/A} ^{[documentation_basics]}

  Detalles:

  Esta documentación debe estar en algún medio (como texto o video) que incluya: cómo instalarlo, cómo iniciarlo, cómo usarlo (posiblemente con un tutorial usando ejemplos), y cómo usarlo de manera segura (por ejemplo, qué hacer y qué no hacer) si eso es un tema apropiado para el software. La documentación de seguridad no necesita ser larga. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. Si el proyecto no produce software, elija "no aplicable" (N/A).

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

  Detalles:

  La documentación de una interfaz externa explica a un usuario final o desarrollador cómo usarla. Esto incluiría su interfaz de programación de aplicaciones (API) si el software tiene una. Si es una biblioteca, documente las clases/tipos principales y los métodos/funciones que se pueden llamar. Si es una aplicación web, defina su interfaz URL (a menudo su interfaz REST). Si es una interfaz de línea de comandos, documente los parámetros y opciones que admite. En muchos casos es mejor si la mayor parte de esta documentación se genera automáticamente, de modo que esta documentación permanezca sincronizada con el software a medida que cambia, pero esto no es obligatorio. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. La documentación PUEDE generarse automáticamente (donde sea práctico, esta es a menudo la mejor manera de hacerlo). La documentación de una interfaz REST puede generarse usando Swagger/OpenAPI. La documentación de la interfaz del código PUEDE generarse usando herramientas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), y Doxygen (muchos). Simplemente tener comentarios en el código de implementación no es suficiente para satisfacer este criterio; necesita haber una manera fácil de ver la información sin leer todo el código fuente. Si el proyecto no produce software, elija "no aplicable" (N/A).

Otro

• Los sitios del proyecto (sitio web, repositorio y URLs de descarga) DEBEN admitir HTTPS usando TLS. ^{[sites_https]}

  Detalles:

  Esto requiere que la URL de la página de inicio del proyecto y la URL del repositorio de control de versiones comiencen con "https:", no "http:". Puede obtener certificados gratuitos de Let's Encrypt. Los proyectos PUEDEN implementar este criterio usando (por ejemplo) GitHub pages, GitLab pages, o SourceForge project pages. Si admite HTTP, le instamos a redirigir el tráfico HTTP a 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]

  Detalles:

  Ejemplos de mecanismos aceptables incluyen listas de correo archivadas, discusiones de issues y pull requests de GitHub, Bugzilla, Mantis y Trac. Los mecanismos de discusión asíncrona (como IRC) son aceptables si cumplen con estos criterios; asegúrese de que haya un mecanismo de archivo direccionable por URL. JavaScript propietario, aunque desaconsejado, está permitido.

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

  Detalles:

  El inglés es actualmente la lengua franca de la tecnología informática; el soporte del inglés aumenta el número de diferentes desarrolladores y revisores potenciales en todo el mundo. Un proyecto puede cumplir con este criterio incluso si el idioma principal de sus desarrolladores principales no es el inglés.

• El proyecto DEBE ser mantenido. ^[maintained]

  Detalles:

  Como mínimo, el proyecto debe intentar responder a informes de problemas y vulnerabilidades significativos. Un proyecto que está buscando activamente una insignia probablemente esté mantenido. Todos los proyectos y personas tienen recursos limitados, y los proyectos típicos deben rechazar algunos cambios propuestos, por lo que los recursos limitados y los rechazos de propuestas no indican por sí mismos un proyecto no mantenido.
  
  Cuando un proyecto sabe que ya no será mantenido, debe establecer este criterio como "No cumplido" y usar el o los mecanismos apropiados para indicar a otros que no está siendo mantenido. Por ejemplo, use "DEPRECATED" (OBSOLETO) como el primer encabezado de su README, agregue "DEPRECATED" cerca del comienzo de su página de inicio, agregue "DEPRECATED" al principio de la descripción del proyecto del repositorio de código, agregue una insignia no-maintenance-intended en su README y/o página de inicio, márquelo como obsoleto en cualquier repositorio de paquetes (por ejemplo, npm deprecate), y/o use el sistema de marcado del repositorio de código para archivarlo (por ejemplo, la configuración de "archive" de GitHub, el marcado "archived" de GitLab, el estado "readonly" de Gerrit, o el estado de proyecto "abandoned" de SourceForge). Se puede encontrar discusión adicional aquí.

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

  Detalles:

  La URL PUEDE ser la misma que la URL del proyecto. El proyecto PUEDE utilizar ramas privadas (no públicas) en casos específicos, mientras que el cambio no se divulga públicamente (por ejemplo, para corregir una vulnerabilidad antes de que se revele al público).

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

  Detalles:

  Los proyectos PUEDEN optar por omitir versiones provisionales específicas de sus repositorios de código fuente públicos (por ejemplo, las que corrigen vulnerabilidades de seguridad específicas no públicas, pueden nunca ser lanzadas públicamente o incluyen material que no puede ser publicado legalmente y no están en el lanzamiento final).

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

  Detalles:

  Git no se requiere específicamente y los proyectos pueden usar un software de control de versiones centralizado (como subversion) con justificación.

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

  Detalles:

  Esto PUEDE cumplirse de diversas maneras, incluyendo IDs de commit (como el ID de commit de git o el ID de changeset de mercurial) o un número de versión (incluyendo números de versión que usan versionado semántico o esquemas basados en fechas como AAAAMMDD).

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

  Detalles:

  Los proyectos generalmente deberían preferir el formato que esperan sus usuarios, por ejemplo, porque es el formato normal usado por su ecosistema. Muchos ecosistemas prefieren SemVer, y SemVer es generalmente preferido para interfaces de programación de aplicaciones (APIs) y kits de desarrollo de software (SDKs). CalVer tiende a ser usado por proyectos que son grandes, tienen un número inusualmente grande de dependencias desarrolladas independientemente, tienen un alcance en constante cambio o son sensibles al tiempo. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro, porque incluir un nivel micro soporta ramas mantenidas simultáneamente cuando eso se vuelva necesario. Otros formatos de numeración de versiones pueden usarse como números de versión, incluyendo IDs de commit de git o IDs de changeset de mercurial, siempre que identifiquen versiones de manera única. Sin embargo, algunas alternativas (como los IDs de commit de git) pueden causar problemas como identificadores de lanzamiento, porque los usuarios pueden no ser capaces de determinar fácilmente si están actualizados. El formato de ID de versión puede no ser importante para identificar lanzamientos de software si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua).

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

  Detalles:

  Las notas de lanzamiento PUEDEN implementarse de diversas maneras. Muchos proyectos las proporcionan en un archivo llamado "NEWS", "CHANGELOG" o "ChangeLog", opcionalmente con extensiones como ".txt", ".md" o ".html". Históricamente el término "change log" significaba un registro de cada cambio, pero para cumplir con estos criterios lo que se necesita es un resumen legible por humanos. Las notas de lanzamiento PUEDEN proporcionarse mediante mecanismos del sistema de control de versiones como el flujo de trabajo GitHub Releases.

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

  Detalles:

  Este criterio ayuda a los usuarios a determinar si una actualización dada corregirá una vulnerabilidad que es conocida públicamente, para ayudar a los usuarios a tomar una decisión informada sobre la actualización. Si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica en sus computadoras, pero en su lugar deben depender de uno o más intermediarios para realizar la actualización (como suele ser el caso de un kernel y software de bajo nivel que está entrelazado con un kernel), el proyecto puede elegir "no aplicable" (N/A) en su lugar, ya que esta información adicional no será útil para esos usuarios. De manera similar, un proyecto puede elegir N/A si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua). Este criterio solo se aplica a los resultados del proyecto, no a sus dependencias. Enumerar las vulnerabilidades de todas las dependencias transitivas de un proyecto se vuelve difícil de manejar a medida que aumentan y varían las dependencias, y es innecesario ya que las herramientas que examinan y rastrean dependencias pueden hacer esto de una manera más escalable.

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

  Detalles:

  La respuesta PUEDE ser 'no' o una discusión sobre sus méritos. El objetivo es simplemente que haya alguna respuesta a algunas solicitudes, lo que indica que el proyecto todavía está activo. Para los propósitos de este criterio, los proyectos no necesitan contar solicitudes falsas (por ejemplo, de spammers o sistemas automatizados). Si un proyecto ya no está realizando mejoras, por favor seleccione "no cumplido" e incluya la URL que aclare esta situación a los usuarios. Si un proyecto tiende a estar abrumado por el número de solicitudes de mejora, por favor seleccione "no cumplido" y explique.

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

  Detalles:

  Los proyectos alojados en GitHub DEBERÍAN considerar habilitar el informe privado de una vulnerabilidad de seguridad. Los proyectos en GitLab DEBERÍAN considerar usar su capacidad para informar privadamente una vulnerabilidad. Los proyectos PUEDEN identificar una dirección de correo en https://PROJECTSITE/security, a menudo en la forma security@example.org. Este proceso de informe de vulnerabilidades PUEDE ser el mismo que su proceso de informe de errores. Los informes de vulnerabilidades PUEDEN ser siempre públicos, pero muchos proyectos tienen un mecanismo de informe de vulnerabilidades privado.

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

  Detalles:

  Los ejemplos incluyen un informe privado de defectos enviado en la web usando HTTPS (TLS) o un correo electrónico cifrado utilizando OpenPGP. Si los informes de vulnerabilidades son siempre públicos (por lo que nunca hay informes de vulnerabilidades privados), seleccione "no aplicable" (N/A).

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

  Detalles:

  Si no ha habido vulnerabilidades reportadas en los últimos 6 meses, elija "no aplicable" (N/A).

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]

  Detalles:

  Un sistema de construcción determina qué acciones deben ocurrir para reconstruir el software (y en qué orden), y luego realiza esos pasos. Por ejemplo, puede invocar un compilador para compilar el código fuente. Si se crea un ejecutable a partir del código fuente, debe ser posible modificar el código fuente del proyecto y luego generar un ejecutable actualizado con esas modificaciones. Si el software producido por el proyecto depende de bibliotecas externas, el sistema de construcción no necesita construir esas bibliotecas externas. Si no hay necesidad de construir nada para usar el software después de modificar su código fuente, seleccione "no aplicable" (N/A).

• Se SUGIERE que se utilicen herramientas comunes para construir el software. {N/A permitido} ^{[build_common_tools]}

  Detalles:

  Por ejemplo: Maven, Ant, cmake, autotools, make o rake.

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

  Detalles:

  El proyecto PUEDE usar múltiples conjuntos de pruebas automatizadas (por ejemplo, uno que se ejecute rápidamente, versus otro que sea más exhaustivo pero requiera equipo especial). Hay muchos marcos de prueba y sistemas de soporte de pruebas disponibles, incluyendo Selenium (automatización de navegador web), Junit (JVM, Java), RUnit (R), testthat (R).

• Un conjunto de pruebas DEBERÍA ser invocable de forma estándar para ese lenguaje. ^{[test_invocation]}

  Detalles:

  Ejemplos: "make check", "mvn test" o "rake test".

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

  Detalles:

  Siempre que exista una política, incluso de boca en boca, que diga que los desarrolladores deben agregar pruebas al conjunto de pruebas automatizado para la nueva funcionalidad importante, seleccione "Cumplido".

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

  Detalles:

  La funcionalidad importante normalmente se mencionaría en las notas de lanzamiento. No se requiere perfección, simplemente evidencia de que las pruebas se están agregando típicamente en la práctica al conjunto de pruebas automatizado cuando se agrega nueva funcionalidad importante al software producido por el proyecto.

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

  Detalles:

  Sin embargo, incluso una regla informal es aceptable siempre que las pruebas se estén agregando en la práctica.

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]

  Detalles:

  Ejemplos de marcas de advertencia del compilador incluyen gcc/clang "-Wall". Ejemplos de un modo de lenguaje "seguro" incluyen JavaScript "use strict" y perl5's "use warnings". Una herramienta "linter" separada es simplemente una herramienta que examina el código fuente para buscar errores de calidad del código o errores simples comunes. Estos se habilitan típicamente dentro del código fuente o instrucciones de compilación.

• El proyecto DEBE abordar las advertencias. {N/A permitido} ^{[warnings_fixed]}

  Detalles:

  Estas son las advertencias identificadas por la implementación del criterio warnings. El proyecto debe corregir las advertencias o marcarlas en el código fuente como falsos positivos. Idealmente no habría advertencias, pero un proyecto PUEDE aceptar algunas advertencias (típicamente menos de 1 advertencia por 100 líneas o menos de 10 advertencias).

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

  Detalles:

  Algunas advertencias no pueden habilitarse efectivamente en algunos proyectos. Lo que se necesita es evidencia de que el proyecto está esforzándose por habilitar marcas de advertencia donde pueda, de modo que los errores se detecten temprano.

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

  Detalles:

  Esto requiere comprender los siguientes principios de diseño, incluyendo los 8 principios de Saltzer y Schroeder:

  • economía de mecanismo (mantener el diseño lo más simple y pequeño posible, por ejemplo, adoptando simplificaciones radicales)
  • valores predeterminados seguros ante fallas (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto)
  • mediación completa (cada acceso que pueda ser limitado debe ser verificado por autoridad y ser no evitable)
  • diseño abierto (los mecanismos de seguridad no deben depender de la ignorancia del atacante de su diseño, sino de información más fácilmente protegida y modificable como claves y contraseñas)
  • separación de privilegios (idealmente, el acceso a objetos importantes debe depender de más de una condición, de modo que vencer un sistema de protección no permita el acceso completo. Por ejemplo, la autenticación multifactor, como requerir tanto una contraseña como un token de hardware, es más fuerte que la autenticación de un solo factor)
  • mínimo privilegio (los procesos deben operar con el mínimo privilegio necesario)
  • mecanismo menos común (el diseño debe minimizar los mecanismos comunes a más de un usuario y de los que dependen todos los usuarios, por ejemplo, directorios para archivos temporales)
  • aceptabilidad psicológica (la interfaz humana debe estar diseñada para facilitar su uso - diseñar para "menos sorpresa" puede ayudar)
  • superficie de ataque limitada (la superficie de ataque - el conjunto de los diferentes puntos donde un atacante puede intentar entrar o extraer datos - debe ser limitada)
  • validación de entradas con listas de permitidos (las entradas típicamente deben verificarse para determinar si son válidas antes de aceptarse; esta validación debe usar listas de permitidos (que solo aceptan valores conocidos como buenos), no listas de denegados (que intentan listar valores conocidos como malos)).

  Un "desarrollador principal" en un proyecto es cualquier persona que esté familiarizada con la base de código del proyecto, se sienta cómoda haciendo cambios en él y sea reconocida como tal por la mayoría de los demás participantes en el proyecto. Un desarrollador principal típicamente haría una serie de contribuciones durante el año pasado (a través de código, documentación o respondiendo preguntas). Los desarrolladores típicamente serían considerados desarrolladores principales si iniciaron el proyecto (y no han dejado el proyecto hace más de tres años), tienen la opción de recibir información sobre un canal privado de reporte de vulnerabilidades (si existe uno), pueden aceptar commits en nombre del proyecto, o realizar versiones finales del software del proyecto. Si solo hay un desarrollador, ese individuo es el desarrollador principal. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir el diseño. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

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

  Detalles:

  Los ejemplos (dependiendo del tipo de software) incluyen inyección SQL, inyección de SO, desbordamiento de búfer clásico, cross-site scripting, falta de autenticación y falta de autorización. Ver el CWE/SANS top 25 o OWASP Top 10 para listas comúnmente usadas. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir errores de implementación comunes que conducen a vulnerabilidades. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

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

  Detalles:

  Estos criterios criptográficos no siempre aplican porque algunos programas de software no necesitan usar capacidades criptográficas directamente.

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

  Detalles:

  Ver el Open Standards Requirement for Software by the Open Source Initiative.

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

  Detalles:

  Estas longitudes mínimas de bits son: clave simétrica 112, módulo de factorización 2048, clave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 y hash 224 (el hash de contraseñas no está cubierto por esta longitud de bits, se puede encontrar más información sobre el hash de contraseñas en el criterio crypto_password_storage). Ver https://www.keylength.com para una comparación de recomendaciones de longitud de clave de varias organizaciones. El software PUEDE permitir longitudes de clave más pequeñas en algunas configuraciones (idealmente no lo haría, ya que esto permite ataques de degradación, pero las longitudes de clave más cortas a veces son necesarias para la interoperabilidad).

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

  Detalles:

  El modo ECB casi nunca es apropiado porque revela bloques idénticos dentro del texto cifrado como lo demuestra el ECB penguin, y el modo CTR a menudo es inapropiado porque no realiza autenticación y causa duplicados si el estado de entrada se repite. En muchos casos es mejor elegir un modo de algoritmo de cifrado de bloque diseñado para combinar secreto y autenticación, por ejemplo, Galois/Counter Mode (GCM) y EAX. Los proyectos PUEDEN permitir a los usuarios habilitar mecanismos rotos (por ejemplo, durante la configuración) cuando sea necesario para la compatibilidad, pero entonces los usuarios saben que lo están haciendo.

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

  Detalles:

  Las preocupaciones sobre el modo CBC en SSH se discuten en CERT: SSH CBC vulnerability.

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

  Detalles:

  Este criterio se aplica solo cuando el software está forzando la autenticación de usuarios usando contraseñas para usuarios externos (también conocida como autenticación entrante), como aplicaciones web del lado del servidor. No se aplica en casos donde el software almacena contraseñas para autenticarse en otros sistemas (también conocida como autenticación saliente, por ejemplo, el software implementa un cliente para algún otro sistema), ya que al menos partes de ese software deben tener acceso a menudo a la contraseña sin hash.

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

  Detalles:

  Un generador de números aleatorios criptográficamente seguro puede ser un generador de números aleatorios de hardware, o puede ser un generador de números pseudo-aleatorios criptográficamente seguro (CSPRNG) que usa un algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow o Fortuna. Ejemplos de llamadas a generadores de números aleatorios seguros incluyen java.security.SecureRandom de Java y window.crypto.getRandomValues de JavaScript. Ejemplos de llamadas a generadores de números aleatorios inseguros incluyen java.util.Random de Java y Math.random de JavaScript.

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

  Detalles:

  Un mecanismo aún más fuerte es publicar el software con paquetes firmados digitalmente, ya que eso mitiga los ataques en el sistema de distribución, pero esto solo funciona si los usuarios pueden estar seguros de que las claves públicas para las firmas son correctas y si los usuarios realmente verificarán la firma.

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

  Detalles:

  Estos "hash" se pueden modificar en tránsito.

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

  Detalles:

  La vulnerabilidad debe ser parcheada y publicada por el proyecto mismo (los parches pueden desarrollarse en otro lugar). Una vulnerabilidad se convierte en conocida públicamente (para este propósito) una vez que tiene un CVE con información publicada públicamente sin muro de pago (reportada, por ejemplo, en la National Vulnerability Database) o cuando el proyecto ha sido informado y la información ha sido publicada al público (posiblemente por el proyecto). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Nota: esto significa que los usuarios podrían quedar vulnerables a todos los atacantes en todo el mundo durante hasta 60 días. Este criterio es a menudo mucho más fácil de cumplir que lo que Google recomienda en Rebooting responsible disclosure, porque Google recomienda que el período de 60 días comience cuando se notifica al proyecto incluso si el informe no es público. También tenga en cuenta que este criterio de insignia, como otros criterios, se aplica al proyecto individual. Algunos proyectos son parte de organizaciones paraguas más grandes o proyectos más grandes, posiblemente en múltiples capas, y muchos proyectos alimentan sus resultados a otras organizaciones y proyectos como parte de una cadena de suministro potencialmente compleja. Un proyecto individual a menudo no puede controlar el resto, pero un proyecto individual puede trabajar para publicar un parche de vulnerabilidad de manera oportuna. Por lo tanto, nos enfocamos únicamente en el tiempo de respuesta del proyecto individual. Una vez que un parche está disponible del proyecto individual, otros pueden determinar cómo lidiar con el parche (por ejemplo, pueden actualizar a la versión más nueva o pueden aplicar solo el parche como una solución seleccionada).

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

  Detalles:

  Un proyecto PUEDE filtrar credenciales de "muestra" para pruebas y bases de datos sin importancia, siempre que no estén destinadas a limitar el acceso público.

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

  Detalles:

  Una herramienta de análisis de código estático examina el código de software (como código fuente, código intermedio o ejecutable) sin ejecutarlo con entradas específicas. Para los propósitos de este criterio, las advertencias del compilador y los modos de lenguaje "seguros" no cuentan como herramientas de análisis de código estático (estos típicamente evitan el análisis profundo porque la velocidad es vital). Algunas herramientas de análisis estático se centran en detectar defectos genéricos, otras se centran en encontrar tipos específicos de defectos (como vulnerabilidades), y algunas hacen una combinación. Ejemplos de tales herramientas de análisis de código estático incluyen cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (incluyendo FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, y HP Enterprise Fortify Static Code Analyzer. Se pueden encontrar listas más grandes de herramientas en lugares como la lista de Wikipedia de herramientas para análisis de código estático, información de OWASP sobre análisis de código estático, lista de NIST de analizadores de seguridad de código fuente, y lista de Wheeler de herramientas de análisis estático. Si no hay herramientas de análisis estático FLOSS disponibles para el(los) lenguaje(s) de implementación utilizado(s), puede seleccionar 'N/A'.

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

  Detalles:

  Las herramientas de análisis estático que están diseñadas específicamente para buscar vulnerabilidades comunes tienen más probabilidades de encontrarlas. Dicho esto, usar cualquier herramienta estática típicamente ayudará a encontrar algunos problemas, por lo que estamos sugiriendo pero no requiriendo esto para el nivel de insignia 'passing'.

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

  Detalles:

  Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Tenga en cuenta que el criterio vulnerabilities_fixed_60_days requiere que todas esas vulnerabilidades se corrijan dentro de los 60 días de hacerse públicas.

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

  Detalles:

  Una herramienta de análisis dinámico examina el software ejecutándolo con entradas específicas. Por ejemplo, el proyecto PUEDE usar una herramienta de fuzzing (por ejemplo, American Fuzzy Lop) o un escáner de aplicaciones web (por ejemplo, OWASP ZAP o w3af). En algunos casos, el proyecto OSS-Fuzz puede estar dispuesto a aplicar pruebas de fuzzing a su proyecto. Para los propósitos de este criterio, la herramienta de análisis dinámico necesita variar las entradas de alguna manera para buscar varios tipos de problemas o ser una suite de pruebas automatizada con al menos 80% de cobertura de ramas. La página de Wikipedia sobre análisis dinámico y la página de OWASP sobre fuzzing identifican algunas herramientas de análisis dinámico. La(s) herramienta(s) de análisis PUEDEN estar enfocadas en buscar vulnerabilidades de seguridad, pero esto no es obligatorio.

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

  Detalles:

  Ejemplos de mecanismos para detectar problemas de seguridad de memoria incluyen Address Sanitizer (ASAN) (disponible en GCC y LLVM), Memory Sanitizer, y valgrind. Otras herramientas potencialmente utilizadas incluyen thread sanitizer y undefined behavior sanitizer. También funcionarían aserciones generalizadas.

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

  Detalles:

  Este criterio no sugiere habilitar aserciones durante la producción; eso depende completamente del proyecto y sus usuarios decidir. El enfoque de este criterio es en cambio mejorar la detección de fallas durante el análisis dinámico antes del despliegue. Habilitar aserciones en el uso de producción es completamente diferente de habilitar aserciones durante el análisis dinámico (como las pruebas). En algunos casos, habilitar aserciones en el uso de producción es extremadamente imprudente (especialmente en componentes de alta integridad). Hay muchos argumentos contra habilitar aserciones en producción, por ejemplo, las bibliotecas no deberían bloquear a los llamadores, su presencia puede causar rechazo por las tiendas de aplicaciones, y/o activar una aserción en producción puede exponer datos privados como claves privadas. Tenga en cuenta que en muchas distribuciones de Linux NDEBUG no está definido, por lo que assert() de C/C++ estará habilitado por defecto para producción en esos entornos. Puede ser importante usar un mecanismo de aserción diferente o definir NDEBUG para producción en esos entornos.

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

  Detalles:

  Si no está ejecutando análisis de código dinámico y por lo tanto no ha encontrado ninguna vulnerabilidad de esta manera, elija "no aplicable" (N/A). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente.

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]

  Detalles:

  El DCO es el mecanismo recomendado porque es fácil de implementar, se rastrea en el código fuente, y git soporta directamente una función "signed-off" usando "commit -s". Para ser más efectivo, es mejor si la documentación del proyecto explica qué significa "signed-off" para ese proyecto. Un CLA es un acuerdo legal que define los términos bajo los cuales las obras intelectuales han sido licenciadas a una organización o proyecto. Un acuerdo de asignación de contribuidor (CAA) es un acuerdo legal que transfiere derechos en una obra intelectual a otra parte; no se requiere que los proyectos tengan CAAs, ya que tener CAA aumenta el riesgo de que los contribuidores potenciales no contribuyan, especialmente si el receptor es una organización con fines de lucro. Los CLAs de Apache Software Foundation (la licencia de contribuidor individual y el CLA corporativo) son ejemplos de CLAs, para proyectos que determinan que los riesgos de estos tipos de CLAs para el proyecto son menores que sus beneficios.

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

  Detalles:

  Necesita haber alguna forma bien establecida y documentada de tomar decisiones y resolver disputas. En proyectos pequeños, esto puede ser tan simple como "el propietario del proyecto y líder toma todas las decisiones finales". Hay varios modelos de gobernanza, incluyendo dictador benevolente y meritocracia formal; para más detalles, ver Modelos de gobernanza. Tanto los enfoques centralizados (por ejemplo, un solo mantenedor) como los descentralizados (por ejemplo, grupo de mantenedores) se han utilizado con éxito en proyectos. La información de gobernanza no necesita documentar la posibilidad de crear un fork del proyecto, ya que eso siempre es posible para proyectos FLOSS.

• El proyecto DEBE adoptar un código de conducta y publicarlo en una ubicación estándar. {URL de cumplimiento} ^{[code_of_conduct]}

  Detalles:

  Los proyectos pueden ser capaces de mejorar la civilidad de su comunidad y establecer expectativas sobre la conducta aceptable adoptando un código de conducta. Esto puede ayudar a evitar problemas antes de que ocurran y hacer que el proyecto sea un lugar más acogedor para fomentar contribuciones. Esto debe enfocarse solo en el comportamiento dentro de la comunidad/lugar de trabajo del proyecto. Ejemplos de códigos de conducta son el código de conducta del kernel de Linux, el Código de Conducta del Pacto del Contribuidor, el Código de Conducta de Debian, el Código de Conducta de Ubuntu, el Código de Conducta de Fedora, el Código de Conducta de GNOME, el Código de Conducta de la Comunidad KDE, el Código de Conducta de la Comunidad Python, La Guía de Conducta de la Comunidad Ruby, y El Código de Conducta de Rust.

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

  Detalles:

  La documentación para gobernanza y roles y responsabilidades puede estar en un solo lugar.

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

  Detalles:

  Un "factor de autobús" (también conocido como "factor de camión") es el número mínimo de miembros del proyecto que tienen que desaparecer repentinamente de un proyecto ("ser atropellados por un autobús") antes de que el proyecto se paralice debido a la falta de personal conocedor o competente. La herramienta truck-factor puede estimar esto para proyectos en GitHub. Para más información, ver Assessing the Bus Factor of Git Repositories de Cosentino et al.

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

  Detalles:

  Es posible que el proyecto no logre la hoja de ruta, y eso está bien; el propósito de la hoja de ruta es ayudar a los posibles usuarios y colaboradores a comprender la dirección prevista del proyecto. No necesita ser detallada.

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

  Detalles:

  Una arquitectura de software explica las estructuras fundamentales de un programa, es decir, los componentes principales del programa, las relaciones entre ellos y las propiedades clave de estos componentes y relaciones.

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

  Detalles:

  Estos son los requisitos de seguridad que el software tiene la intención de cumplir.

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

  Detalles:

  La idea es mostrar a los usuarios cómo comenzar y hacer que el software haga algo. Esto es de importancia crítica para que los posibles usuarios puedan comenzar.

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

  Detalles:

  La documentación PUEDE incluir información sobre diferencias o cambios entre versiones del software y/o enlaces a versiones anteriores de la documentación. La intención de este criterio es que se haga un esfuerzo por mantener la documentación consistente, no que la documentación deba ser perfecta.

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

  Detalles:

  Un logro es cualquier conjunto de criterios externos que el proyecto ha trabajado específicamente para cumplir, incluidas algunas insignias. Esta información no necesita estar en la página frontal del sitio web del proyecto. Un proyecto que utiliza GitHub puede colocar los logros en la página frontal del repositorio agregándolos al archivo README.

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

  Detalles:

  Para aplicaciones web, consulte las Pautas de Accesibilidad para el Contenido Web (WCAG 2.0) y su documento de apoyo Understanding WCAG 2.0; vea también información de accesibilidad de W3C. Para aplicaciones GUI, considere usar las pautas de accesibilidad específicas del entorno (como Gnome, KDE, XFCE, Android, iOS, Mac, y Windows). Algunas aplicaciones TUI (por ejemplo, programas `ncurses`) pueden hacer ciertas cosas para hacerse más accesibles (como la configuración `force-arrow-cursor` de `alpine`). La mayoría de las aplicaciones de línea de comandos son bastante accesibles tal como están. Este criterio es a menudo N/A, por ejemplo, para bibliotecas de programas. Aquí hay algunos ejemplos de acciones a tomar o problemas a considerar:

  • Proporcione alternativas de texto para cualquier contenido que no sea texto para que pueda transformarse en otras formas que las personas necesiten, como letra grande, braille, voz, símbolos o lenguaje más simple (pauta 1.1 de WCAG 2.0)
  • El color no se utiliza como el único medio visual de transmitir información, indicar una acción, solicitar una respuesta o distinguir un elemento visual. (pauta 1.4.1 de WCAG 2.0)
  • La presentación visual de texto e imágenes de texto tiene una relación de contraste de al menos 4.5:1, excepto para texto grande, texto incidental y logotipos (pauta 1.4.3 de WCAG 2.0)
  • Haga que toda la funcionalidad esté disponible desde un teclado (pauta 2.1 de WCAG)
  • Un proyecto basado en GUI o web DEBERÍA probar con al menos un lector de pantalla en las plataformas de destino (por ejemplo, NVDA, Jaws o WindowEyes en Windows; VoiceOver en Mac e iOS; Orca en Linux/BSD; TalkBack en Android). Los programas TUI PUEDEN trabajar para reducir el sobredibujo para evitar la lectura redundante por parte de los lectores de pantalla.

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

  Detalles:

  La localización "se refiere a la adaptación de un producto, aplicación o contenido de documento para satisfacer los requisitos de idioma, cultura y otros de un mercado objetivo específico (una configuración regional)". La internacionalización es el "diseño y desarrollo de un producto, aplicación o contenido de documento que permite una fácil localización para audiencias objetivo que varían en cultura, región o idioma". (Vea "Localization vs. Internationalization" de W3C.) El software cumple con este criterio simplemente estando internacionalizado. No se requiere localización para otro idioma específico, ya que una vez que el software ha sido internacionalizado, es posible que otros trabajen en la localización.

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

  Detalles:

  Tenga en cuenta que el uso de GitHub cumple con este criterio. Este criterio solo se aplica a las contraseñas utilizadas para la autenticación de usuarios externos en los sitios del proyecto (también conocida como autenticación entrante). Si los sitios del proyecto deben iniciar sesión en otros sitios (también conocida como autenticación saliente), es posible que necesiten almacenar tokens de autorización para ese propósito de manera diferente (ya que almacenar un hash sería inútil). Esto aplica el criterio crypto_password_storage a los sitios del proyecto, similar a sites_https.

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

  Detalles:

  Esto está fuertemente relacionado con vulnerability_report_process, que requiere que haya una forma documentada de reportar vulnerabilidades. También está relacionado con vulnerability_report_response, que requiere respuesta a los informes de vulnerabilidades dentro de un cierto marco de tiempo.

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

  Detalles:

  En la mayoría de los casos esto se hace haciendo referencia a alguna o algunas guías de estilo existentes, posiblemente enumerando las diferencias. Estas guías de estilo pueden incluir formas de mejorar la legibilidad y formas de reducir la probabilidad de defectos (incluyendo vulnerabilidades). Muchos lenguajes de programación tienen una o más guías de estilo ampliamente utilizadas. Ejemplos de guías de estilo incluyen las guías de estilo de Google y SEI CERT 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]}

  Detalles:

  Esto PUEDE implementarse usando herramientas de análisis estático y/o forzando el código a través de reformateadores de código. En muchos casos, la configuración de la herramienta está incluida en el repositorio del proyecto (ya que diferentes proyectos pueden elegir diferentes configuraciones). Los proyectos PUEDEN permitir excepciones de estilo (y típicamente lo harán); donde ocurran excepciones, DEBEN ser raras y documentadas en el código en sus ubicaciones, de modo que estas excepciones puedan ser revisadas y de modo que las herramientas puedan manejarlas automáticamente en el futuro. Ejemplos de tales herramientas incluyen ESLint (JavaScript), Rubocop (Ruby), y devtools check (R).

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

  Detalles:

  Debería ser fácil habilitar características especiales de construcción como Address Sanitizer (ASAN), o para cumplir con las mejores prácticas de fortificación de distribución (por ejemplo, activando fácilmente banderas del compilador para hacerlo).

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

  Detalles:

  Por ejemplo, establecer CFLAGS (C) o CXXFLAGS (C++) debería crear la información de depuración relevante si se utilizan esos lenguajes, y no deberían eliminarse durante la instalación. La información de depuración es necesaria para soporte y análisis, y también es útil para medir la presencia de características de fortificación en los binarios compilados.

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

  Detalles:

  La información de dependencias internas del sistema de construcción del proyecto debe ser precisa, de lo contrario, los cambios en el proyecto pueden no construirse correctamente. Las construcciones incorrectas pueden conducir a defectos (incluyendo vulnerabilidades). Un error común en sistemas de construcción grandes es usar una "construcción recursiva" o "make recursivo", es decir, una jerarquía de subdirectorios que contienen archivos fuente, donde cada subdirectorio se construye independientemente. A menos que cada subdirectorio sea completamente independiente, esto es un error, porque la información de dependencias es incorrecta.

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

  Detalles:

  Los usuarios de GCC y clang pueden encontrar útil la opción -frandom-seed; en algunos casos, esto puede resolverse forzando algún tipo de orden. Se pueden encontrar más sugerencias en el sitio de construcciones reproducibles.

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

  Detalles:

  Los ejemplos incluyen usar un administrador de paquetes (a nivel del sistema o del lenguaje), "make install/uninstall" (soportando DESTDIR), un contenedor en un formato estándar, o una imagen de máquina virtual en un formato estándar. El proceso de instalación y desinstalación (por ejemplo, su empaquetado) PUEDE ser implementado por un tercero siempre que sea FLOSS.

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

  Detalles:

  Esto PUEDE implementarse mediante un contenedor generado y/o script(s) de instalación. Las dependencias externas normalmente se instalarían invocando el/los gestor(es) de paquetes del sistema y/o del lenguaje, según external_dependencies.

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

  Detalles:

  Normalmente esto se hace utilizando las convenciones del gestor de paquetes y/o sistema de construcción. Tenga en cuenta que esto ayuda a implementar installation_development_quick.

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

  Detalles:

  Esto se puede hacer utilizando una herramienta de análisis de origen / verificación de dependencias / análisis de composición de software como Dependency-Check de OWASP, Nexus Auditor de Sonatype, Black Duck Software Composition Analysis de Synopsys, y Bundler-audit (para Ruby). Algunos gestores de paquetes incluyen mecanismos para hacer esto. Es aceptable si la vulnerabilidad de los componentes no puede ser explotada, pero este análisis es difícil y a veces es más fácil simplemente actualizar o corregir la parte.

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

  Detalles:

  Una forma típica de cumplir este criterio es utilizar sistemas de gestión de paquetes del sistema y del lenguaje de programación. Muchos programas FLOSS se distribuyen con "bibliotecas de conveniencia" que son copias locales de bibliotecas estándar (posiblemente bifurcadas). En sí, eso está bien. Sin embargo, si el programa *debe* usar estas copias locales (bifurcadas), entonces actualizar las bibliotecas "estándar" como una actualización de seguridad dejará estas copias adicionales aún vulnerables. Esto es especialmente un problema para sistemas basados en la nube; si el proveedor de la nube actualiza sus bibliotecas "estándar" pero el programa no las usa, entonces las actualizaciones en realidad no ayudan. Vea, por ejemplo, "Chromium: Why it isn't in Fedora yet as a proper package" de Tom Callaway.

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

  Detalles:

  Este requisito puede verse como un subconjunto de test_continuous_integration, pero enfocado solo en pruebas, sin requerir integración continua.

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

  Detalles:

  Hay muchas herramientas FLOSS disponibles para medir la cobertura de pruebas, incluidas gcov/lcov, Blanket.js, Istanbul, JCov y covr (R). Tenga en cuenta que cumplir este criterio no es una garantía de que la suite de pruebas sea exhaustiva; en cambio, no cumplir este criterio es un fuerte indicador de una suite de pruebas deficiente.

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

  Detalles:

  Por ejemplo, los resultados del proyecto deberían tener valores predeterminados seguros (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto). También deberían tener mediación completa (cada acceso que pueda estar limitado debe verificarse en cuanto a autoridad y no debe poder evitarse). Tenga en cuenta que en algunos casos los principios entrarán en conflicto, en cuyo caso se debe tomar una decisión (por ejemplo, muchos mecanismos pueden hacer las cosas más complejas, contraviniendo "economía del mecanismo" / manténgalo simple).

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

  Detalles:

  Tenga en cuenta que la verificación incorrecta de certificados TLS es un error común. Para más información, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. y "Do you trust this application?" por Michael Catanzaro.

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

  Detalles:

  Los resultados del proyecto incluyen tanto el código fuente como cualquier entregable generado cuando sea aplicable (por ejemplo, ejecutables, paquetes y contenedores). Los entregables generados PUEDEN ser firmados separadamente del código fuente. Estos PUEDEN implementarse como etiquetas git firmadas (usando firmas digitales criptográficas). Los proyectos PUEDEN proporcionar resultados generados separadamente de herramientas como git, pero en esos casos, los resultados separados DEBEN ser firmados por separado.

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

  Detalles:

  Tenga en cuenta que comparar la entrada contra una lista de "formatos incorrectos" (también conocida como *lista de denegados*) normalmente no es suficiente, porque los atacantes a menudo pueden evitar una lista de denegados. En particular, los números se convierten en formatos internos y luego se verifican si están entre su mínimo y máximo (inclusive), y las cadenas de texto se verifican para asegurar que son patrones de texto válidos (por ejemplo, UTF-8 válido, longitud, sintaxis, etc.). Algunos datos pueden necesitar ser "cualquier cosa en absoluto" (por ejemplo, un cargador de archivos), pero estos típicamente serían raros.

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

  Detalles:

  Los mecanismos de endurecimiento pueden incluir encabezados HTTP como Content Security Policy (CSP), banderas de compilador para mitigar ataques (como -fstack-protector), o banderas de compilador para eliminar comportamiento indefinido. Para nuestros propósitos, el menor privilegio no se considera un mecanismo de endurecimiento (el menor privilegio es importante, pero separado).

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

  Detalles:

  Un caso de aseguramiento es "un cuerpo documentado de evidencia que proporciona un argumento convincente y válido de que un conjunto especificado de afirmaciones críticas con respecto a las propiedades de un sistema están adecuadamente justificadas para una aplicación dada en un entorno dado" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Los límites de confianza son límites donde los datos o la ejecución cambian su nivel de confianza, por ejemplo, los límites de un servidor en una aplicación web típica. Es común enumerar principios de diseño seguro (como Saltzer y Schroeder) y debilidades de seguridad de implementación comunes (como el top 10 de OWASP o el top 25 de CWE/SANS), y mostrar cómo se contrarresta cada uno. El caso de aseguramiento de BadgeApp puede ser un ejemplo útil. Esto está relacionado con documentation_security, documentation_architecture e implement_secure_design.

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

  Detalles:

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

Otro

• El proyecto DEBE incluir una declaración de derechos de autor en cada archivo fuente, identificando al titular de los derechos de autor (por ejemplo, los contribuidores de [nombre del proyecto]). {Justificación de cumplimiento} ^{[copyright_per_file]}

  Detalles:

  Esto PUEDE hacerse incluyendo lo siguiente dentro de un comentario cerca del comienzo de cada archivo: "Copyright the [project name] contributors.". Vea "Copyright Notices in Open Source Software Projects" de Steve Winslow.

• El proyecto DEBE incluir una declaración de licencia en cada archivo fuente. Esto PUEDE hacerse incluyendo lo siguiente dentro de un comentario cerca del comienzo de cada archivo: SPDX-License-Identifier: [expresión de licencia SPDX para el proyecto]. {Justificación de cumplimiento} ^{[license_per_file]}

  Detalles:

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

Control de cambios

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

• El repositorio de código fuente del proyecto DEBE usar un software de control de versiones distribuido común (por ejemplo, git o mercurial). {Justificación de cumplimiento} ^{[repo_distributed]}
• El proyecto DEBE identificar claramente tareas pequeñas que puedan ser realizadas por contribuyentes nuevos o casuales. {URL de cumplimiento} ^{[small_tasks]}

  Detalles:

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

• El proyecto DEBE requerir autenticación de dos factores (2FA) para desarrolladores para cambiar un repositorio central o acceder a datos sensibles (como informes de vulnerabilidad privados). Este mecanismo 2FA PUEDE usar mecanismos sin mecanismos criptográficos como SMS, aunque eso no se recomienda. {Justificación de cumplimiento} ^{[require_2FA]}
• La autenticación de dos factores (2FA) del proyecto DEBERÍA usar mecanismos criptográficos para prevenir la suplantación de identidad. La 2FA basada en el Servicio de Mensajes Cortos (SMS), por sí sola, NO cumple este criterio, ya que no está cifrada. {Justificación de cumplimiento} ^[secure_2FA]

  Detalles:

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

Calidad

Estándares de codificación

• El proyecto DEBE documentar sus requisitos de revisión de código, incluyendo cómo se lleva a cabo la revisión de código, qué debe verificarse, y qué se requiere para que sea aceptable. {Justificación de N/A} {URL de cumplimiento} ^{[code_review_standards]}

  Detalles:

  Vea también two_person_review y contribution_requirements.

• El proyecto DEBE tener al menos el 50% de todas las modificaciones propuestas revisadas antes del lanzamiento por una persona distinta del autor, para determinar si es una modificación valiosa y libre de problemas conocidos que argumentarían en contra de su inclusión {Justificación de cumplimiento} ^{[two_person_review]}

Sistema de construcción funcional

• El proyecto DEBE tener una construcción reproducible. Si no ocurre construcción (por ejemplo, lenguajes de scripting donde el código fuente se usa directamente en lugar de ser compilado), seleccione "no aplicable" (N/A). {Justificación de N/A} {URL de cumplimiento} ^{[build_reproducible]}

  Detalles:

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

Suite de pruebas automatizadas

• Una suite de pruebas DEBE ser invocable de una manera estándar para ese lenguaje. {URL de cumplimiento} ^{[test_invocation]}
• El proyecto DEBE implementar integración continua, donde el código nuevo o modificado se integra frecuentemente en un repositorio de código central y se ejecutan pruebas automatizadas sobre el resultado. {URL de cumplimiento} ^{[test_continuous_integration]}

  Detalles:

  En la mayoría de los casos, esto significa que cada desarrollador que trabaja a tiempo completo en el proyecto se integra al menos diariamente.

• El proyecto DEBE tener suite(s) de pruebas automatizadas FLOSS que proporcionen al menos 90% de cobertura de sentencias si hay al menos una herramienta FLOSS que pueda medir este criterio en el lenguaje seleccionado. {Justificación de N/A} {Justificación de cumplimiento} ^{[test_statement_coverage90]}
• El proyecto DEBE tener suite(s) de pruebas automatizadas FLOSS que proporcionen al menos 80% de cobertura de ramas si hay al menos una herramienta FLOSS que pueda medir este criterio en el lenguaje seleccionado. {Justificación de N/A} {Justificación de cumplimiento} ^{[test_branch_coverage80]}

Seguridad

Use buenas prácticas criptográficas

• El software producido por el proyecto DEBE soportar protocolos seguros para todas sus comunicaciones de red, como SSHv2 o posterior, TLS1.2 o posterior (HTTPS), IPsec, SFTP y SNMPv3. Los protocolos inseguros como FTP, HTTP, telnet, SSLv3 o anterior, y SSHv1 DEBEN estar deshabilitados por defecto, y solo habilitados si el usuario lo configura específicamente. Si el software producido por el proyecto no soporta comunicaciones de red, seleccione "no aplicable" (N/A). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_used_network]}
• El software producido por el proyecto DEBE, si soporta o usa TLS, soportar al menos la versión 1.2 de TLS. Tenga en cuenta que el predecesor de TLS se llamaba SSL. Si el software no usa TLS, seleccione "no aplicable" (N/A). {N/A permitido} {Justificación de cumplimiento} ^{[crypto_tls12]}

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

• El sitio web del proyecto, el repositorio (si es accesible a través de la web) y el sitio de descarga (si está separado) DEBEN incluir encabezados clave de endurecimiento con valores no permisivos. {URL de cumplimiento} ^{[hardened_site]}

  Detalles:

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

Otros problemas de seguridad

• El proyecto DEBE haber realizado una revisión de seguridad dentro de los últimos 5 años. Esta revisión DEBE considerar los requisitos de seguridad y el límite de seguridad. {Justificación de cumplimiento} ^{[security_review]}

  Detalles:

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

• Los mecanismos de endurecimiento DEBEN usarse en el software producido por el proyecto para que los defectos del software tengan menos probabilidades de resultar en vulnerabilidades de seguridad. {Justificación de N/A} {URL de cumplimiento} ^[hardening]

Análisis

Análisis dinámico de código

• El proyecto DEBE aplicar al menos una herramienta de análisis dinámico a cualquier versión de producción principal propuesta del software producido por el proyecto antes de su lanzamiento. {Justificación de N/A} {Justificación de cumplimiento} ^{[dynamic_analysis]}
• El proyecto DEBERÍA incluir muchas aserciones en tiempo de ejecución en el software que produce y verificar esas aserciones durante el análisis dinámico. {Justificación de N/A} {Justificación de cumplimiento} ^{[dynamic_analysis_enable_assertions]}

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

  Detalles:

  Aplique la autenticación multifactor para el sistema de control de versiones del proyecto, requiriendo que los colaboradores proporcionen una segunda forma de autenticación al acceder a datos sensibles o modificar la configuración del repositorio. Las claves de acceso (passkeys) son aceptables para este control.

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

  Detalles:

  La mayoría de los sistemas de control de versiones públicos están configurados de esta manera. Asegúrese de que el sistema de control de versiones del proyecto siempre asigne los permisos más bajos disponibles a los colaboradores por defecto cuando se agreguen, otorgando permisos adicionales solo cuando sea necesario.

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

  Detalles:

  Si el VCS está centralizado, establezca protección de rama en la rama principal en el VCS del proyecto. Alternativamente, use un enfoque descentralizado, como el del kernel de Linux, donde los cambios se proponen primero en otro repositorio, y fusionar cambios en el repositorio principal requiere un acto separado específico.

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

  Detalles:

  Establezca protección de rama en la rama principal en el sistema de control de versiones del proyecto para evitar la eliminación.

• 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 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} ^{[osps_br_01_02]}
• 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]}

  Detalles:

  Configure los sitios web y sistemas de control de versiones del proyecto para usar canales cifrados como SSH o HTTPS para la transmisión de datos. Asegúrese de que todas las herramientas y dominios referenciados en la documentación del proyecto solo puedan accederse a través de canales cifrados.

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

  Detalles:

  Configure el pipeline de lanzamiento del proyecto para que solo obtenga datos de sitios web, respuestas de API y otros servicios que utilicen canales cifrados como SSH o HTTPS para la transmisión de datos.

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

  Detalles:

  Configure .gitignore o equivalente para excluir archivos que puedan contener información sensible. Use hooks de pre-commit y herramientas de escaneo automatizado para detectar y prevenir la inclusión de datos sensibles en los commits.

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

  Detalles:

  Cree guías de usuario o documentación para toda la funcionalidad básica del proyecto, explicando cómo instalar, configurar y usar las características del proyecto. Si hay acciones peligrosas o destructivas disponibles, incluya advertencias altamente visibles.

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

  Detalles:

  Se recomienda que los proyectos utilicen el gestor de incidencias predeterminado de su VCS. Si se utiliza una fuente externa, asegúrese de que la documentación del proyecto y la guía de contribución expliquen claramente y de manera visible cómo usar el sistema de reporte. Se recomienda que la documentación del proyecto también establezca expectativas sobre cómo se clasificarán y resolverán los defectos.

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

  Detalles:

  Establezca uno o más mecanismos para discusiones públicas dentro del proyecto, como listas de correo, mensajería instantánea o gestores de incidencias, para facilitar la comunicación abierta y la retroalimentación.

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

  Detalles:

  Cree un archivo CONTRIBUTING.md o un directorio CONTRIBUTING/ para delinear el proceso de contribución, incluyendo los pasos para enviar cambios e interactuar con los mantenedores del proyecto.

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

  Detalles:

  Agregue un archivo LICENSE al repositorio del proyecto con una licencia que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Liberar al dominio público cumple con este control si no hay otros gravámenes como patentes.

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

  Detalles:

  Si se incluye una licencia diferente con los activos de software lanzados, asegúrese de que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Tenga en cuenta que la licencia para los activos de software lanzados puede ser diferente a la del código fuente.

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

  Detalles:

  Incluya la licencia del código fuente del proyecto en el archivo LICENSE, archivo COPYING o directorio LICENSE/ del proyecto para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

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

  Detalles:

  Incluya la licencia de los activos de software lanzados del proyecto en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

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

  Detalles:

  Use un VCS común como GitHub, GitLab o Bitbucket. Asegúrese de que el repositorio sea legible públicamente. Evite la duplicación o creación de mirrors de repositorios a menos que la documentación altamente visible aclare la fuente principal. Evite cambios frecuentes en el repositorio que impactarían la URL del repositorio. Asegúrese de que el repositorio sea público.

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

  Detalles:

  Use un VCS común como GitHub, GitLab o Bitbucket para mantener un historial de commits legible públicamente. Evite aplastar o reescribir commits de una manera que oscurecería al autor de cualquier commit.

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

  Detalles:

  Esto puede tomar la forma de un gestor de paquetes o un archivo de dependencias del lenguaje que enumere todas las dependencias directas como package.json, Gemfile o go.mod.

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

  Detalles:

  Documente cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento. Esta documentación debe incluir el estado e intención de la respectiva base de código.

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

  Detalles:

  Elimine los artefactos ejecutables generados en el sistema de control de versiones del proyecto. Se recomienda que cualquier escenario donde un artefacto ejecutable generado parezca crítico para un proceso como las pruebas, en su lugar debería generarse en el momento de la compilación o almacenarse por separado y obtenerse durante un paso de pipeline específico y bien documentado.

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

  Detalles:

  No agregue ningún artefacto binario no revisable al sistema de control de versiones del proyecto. Esto incluye binarios de aplicaciones ejecutables, archivos de biblioteca y artefactos similares. No incluye activos como imágenes gráficas, archivos de sonido o música y contenido similar que típicamente se almacena en formato binario.

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

  Detalles:

  Cree un archivo security.md (o con nombre similar) que contenga contactos de seguridad para el proyecto.

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

  Detalles:

  Configure las configuraciones del proyecto para asignar los permisos más bajos disponibles a nuevos pipelines por defecto, otorgando permisos adicionales solo cuando sea necesario para tareas específicas.

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

  Detalles:

  Asigne un identificador de versión único a cada lanzamiento producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Los ejemplos incluyen SemVer, CalVer o ID de commit de git.

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

  Detalles:

  Asegúrese de que todos los lanzamientos incluyan un registro de cambios descriptivo. Se recomienda asegurar que el registro de cambios sea legible por humanos e incluya detalles más allá de los mensajes de commit, como descripciones del impacto de seguridad o relevancia para diferentes casos de uso. Para asegurar la legibilidad automática, coloque el contenido bajo un encabezado markdown como "## Changelog".

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

  Detalles:

  Use herramientas comunes para su ecosistema, como gestores de paquetes o herramientas de gestión de dependencias para ingerir dependencias en tiempo de construcción. Esto puede incluir usar un archivo de dependencias, archivo de bloqueo o manifiesto para especificar las dependencias requeridas, que luego son incorporadas por el sistema de construcción.

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

  Detalles:

  Firme todos los activos de software lanzados en tiempo de construcción con una firma criptográfica o atestaciones, como firma GPG o PGP, firmas Sigstore, proveniencia SLSA, o VSAs SLSA. Incluya los hashes criptográficos de cada activo en un manifiesto firmado o archivo de metadatos.

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

  Detalles:

  Se recomienda publicar esta información junto con la documentación técnica y de diseño del proyecto en un recurso públicamente visible como el repositorio de código fuente, sitio web del proyecto u otro canal.

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

  Detalles:

  Documente los participantes del proyecto y sus roles a través de artefactos tales como members.md, governance.md, maintainers.md, o archivo similar dentro del repositorio de código fuente del proyecto. Esto puede ser tan simple como incluir nombres o identificadores de cuenta en una lista de mantenedores, o más complejo dependiendo de la gobernanza del proyecto.

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

  Detalles:

  Documente los participantes del proyecto y sus roles a través de artefactos tales como members.md, governance.md, maintainers.md, o archivo similar dentro del repositorio de código fuente del proyecto.

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

  Detalles:

  Extienda el CONTRIBUTING.md o los contenidos de CONTRIBUTING/ en la documentación del proyecto para delinear los requisitos para contribuciones aceptables, incluyendo estándares de codificación, requisitos de pruebas y pautas de envío para contribuidores de código. Se recomienda que esta guía sea la fuente de verdad tanto para contribuidores como para aprobadores.

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

  Detalles:

  Incluya un DCO en el repositorio del proyecto, requiriendo que los contribuidores de código afirmen que están legalmente autorizados para confirmar las contribuciones asociadas en cada commit. Use una verificación de estado para asegurar que se haga la afirmación. Un CLA también satisface este requisito. Algunos sistemas de control de versiones, como GitHub, pueden incluir esto en los términos de servicio de la plataforma.

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

  Detalles:

  Configure el sistema de control de versiones del proyecto para requerir que todas las verificaciones de estado automatizadas pasen o requieran reconocimiento manual antes de que un commit pueda fusionarse en la rama principal. Se recomienda que cualquier verificación de estado opcional NO esté configurada como un requisito de pasar o fallar que los aprobadores puedan estar tentados a omitir.

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

  Detalles:

  Las pruebas automatizadas deben ejecutarse antes de cada fusión en la rama principal. El conjunto de pruebas debe ejecutarse en un pipeline de CI/CD y los resultados deben ser visibles para todos los contribuidores. El conjunto de pruebas debe ejecutarse en un entorno consistente y debe ejecutarse de manera que permita a los contribuidores ejecutar las pruebas localmente. Ejemplos de conjuntos de pruebas incluyen pruebas unitarias, pruebas de integración y pruebas de extremo a extremo.

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

  Detalles:

  Incluya diseños en la documentación del proyecto que expliquen las acciones y los actores. Los actores incluyen cualquier subsistema o entidad que pueda influir en otro segmento del sistema. Asegúrese de que esto se actualice para nuevas características o cambios importantes.

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

  Detalles:

  Documente todas las interfaces de software (APIs) de los activos de software liberados, explicando cómo los usuarios pueden interactuar con el software y qué datos se esperan o se producen. Asegúrese de que esto se actualice para nuevas funcionalidades o cambios incompatibles.

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

  Detalles:

  Realizar una evaluación de seguridad informa tanto a los miembros del proyecto como a los consumidores posteriores que el proyecto comprende qué problemas podrían surgir dentro del software. Comprender qué amenazas podrían materializarse ayuda al proyecto a gestionar y abordar el riesgo. Esta información es útil para los consumidores posteriores para demostrar la competencia y prácticas de seguridad del proyecto. Asegúrese de que esto se actualice para nuevas funcionalidades o cambios incompatibles.

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

  Detalles:

  Cree un archivo SECURITY.md en la raíz del directorio, describiendo la política del proyecto para la divulgación coordinada de vulnerabilidades. Incluya un método para reportar vulnerabilidades. Establezca expectativas sobre cómo el proyecto responderá y abordará los problemas reportados.

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

  Detalles:

  Proporcione un medio para que los investigadores de seguridad reporten vulnerabilidades de forma privada al proyecto. Esto puede ser una dirección de correo electrónico dedicada, un formulario web, herramientas especializadas del VCS, direcciones de correo electrónico para contactos de seguridad, u otros métodos.

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

  Detalles:

  Proporcione información sobre vulnerabilidades conocidas en un canal público predecible, como una entrada CVE, publicación de blog u otro medio. En la medida de lo posible, esta información debe incluir la(s) versión(es) afectada(s), cómo un consumidor puede determinar si es vulnerable, e instrucciones para la mitigación o remediación.

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

  Detalles:

  Configure los pipelines de CI/CD del proyecto para asignar los permisos más bajos disponibles a usuarios y servicios por defecto, elevando los permisos solo cuando sea necesario para tareas específicas. En algunos sistemas de control de versiones, esto puede ser posible a nivel organizacional o de repositorio. Si no es posible, establezca los permisos en el nivel superior del pipeline.

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

  Detalles:

  Asigne un identificador de versión único a cada activo de software producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Ejemplos incluyen SemVer, CalVer, o git commit id.

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

  Detalles:

  Documente cómo se gestionan y utilizan los secretos y credenciales dentro del proyecto. Esto debe incluir detalles sobre cómo se almacenan los secretos (por ejemplo, utilizando una herramienta de gestión de secretos), cómo se controla el acceso y cómo se rotan o actualizan los secretos. Asegúrese de que la información sensible no esté codificada directamente en el código fuente ni almacenada en sistemas de control de versiones.

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

  Detalles:

  Las instrucciones en el proyecto deben contener información sobre la tecnología utilizada, los comandos a ejecutar y la salida esperada. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

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

  Detalles:

  La identidad esperada puede estar en forma de IDs de clave utilizados para firmar, emisor e identidad de un certificado sigstore, u otras formas similares. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

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

  Detalles:

  Para comunicar el alcance y la duración del soporte para los activos de software lanzados del proyecto, el proyecto debe tener un archivo SUPPORT.md, una sección "Soporte" en SECURITY.md, u otra documentación que explique el ciclo de vida del soporte, incluyendo la duración esperada del soporte para cada lanzamiento, los tipos de soporte proporcionados (por ejemplo, corrección de errores, actualizaciones de seguridad), y cualquier política o procedimiento relevante para obtener soporte.

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

  Detalles:

  Para comunicar el alcance y la duración del soporte para correcciones de seguridad, el proyecto debe tener un SUPPORT.md u otra documentación que explique la política del proyecto para actualizaciones de seguridad.

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

  Detalles:

  Publique una política exigible en la documentación del proyecto que requiera que los colaboradores de código sean revisados y aprobados antes de otorgarles permisos elevados a recursos sensibles, como aprobación de fusiones o acceso a secretos. Se recomienda que la verificación incluya establecer un linaje justificable de identidad, como confirmar la asociación del colaborador con una organización confiable conocida.

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

  Detalles:

  Se recomienda generar automáticamente SBOMs en el momento de la compilación utilizando una herramienta que haya sido verificada para precisión. Esto permite a los usuarios ingerir estos datos en un enfoque estandarizado junto con otros proyectos en su entorno.

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

  Detalles:

  Cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento debe aplicar requisitos de seguridad según sea aplicable al estado e intención de la base de código respectiva. Además de seguir los requisitos correspondientes de la Línea Base OSPS, esto puede incluir requerir una revisión de seguridad, asegurar que esté libre de vulnerabilidades y asegurar que esté libre de problemas de seguridad conocidos.

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

  Detalles:

  Agregue una sección a la documentación de contribución que explique cómo ejecutar las pruebas localmente y cómo ejecutar las pruebas en el pipeline de CI/CD. La documentación debe explicar qué están probando las pruebas y cómo interpretar los resultados.

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

  Detalles:

  Agregue una sección a la documentación de contribución que explique la política para agregar o actualizar pruebas. La política debe explicar qué constituye un cambio importante y qué pruebas deben agregarse o actualizarse.

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

  Detalles:

  Configure el sistema de control de versiones del proyecto para requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos en la rama de lanzamiento o principal. Esto se puede lograr requiriendo que un pull request sea revisado y aprobado por al menos otro colaborador antes de que pueda fusionarse.

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

  Detalles:

  El modelado de amenazas es una actividad donde el proyecto examina la base de código, procesos asociados e infraestructura, interfaces, componentes clave y "piensa como un hacker" y hace una lluvia de ideas sobre cómo el sistema puede ser vulnerado o comprometido. Cada amenaza identificada se enumera para que el proyecto pueda pensar en cómo evitar proactivamente o cerrar cualquier brecha/vulnerabilidad que pueda surgir. Asegúrese de que esto se actualice para nuevas características o cambios importantes.

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

  Detalles:

  Establezca un feed VEX comunicando el estado de explotabilidad de vulnerabilidades conocidas, incluyendo detalles de evaluación o cualquier mitigación implementada que impida que el código vulnerable sea ejecutado.

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

  Detalles:

  Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Análisis de Composición de Software (SCA) relacionados con vulnerabilidades y licencias. Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

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

  Detalles:

  Documente una política en el proyecto para abordar los resultados aplicables del Análisis de Composición de Software antes de cualquier lanzamiento, y agregue verificaciones de estado que comprueben el cumplimiento de esa política antes del lanzamiento.

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

  Detalles:

  Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Análisis de Composición de Software en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

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

  Detalles:

  Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Pruebas de Seguridad de Aplicaciones Estáticas (SAST). Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

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

  Detalles:

  Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.