Implementación de herramientas de seguridad de código abierto en tu pipeline CI/CD
Asegurar tu pipeline de Integración Continua y Despliegue Continuo (CI/CD) ya no es opcional: es esencial. Esta guía es tu recurso de referencia para construir, implementar y optimizar flujos de trabajo de CI/CD seguros. Ya seas desarrollador, ingeniero DevOps o profesional de seguridad, proporcionamos información sobre las herramientas de código abierto y la orientación que necesitas para modelar la seguridad en cada etapa de tu pipeline. Desde proteger el código y las compilaciones hasta monitorear los entornos posteriores al despliegue, nuestro hub capacita a los equipos para integrar la seguridad de manera fluida en sus flujos de trabajo sin sacrificar velocidad ni agilidad. Explora, aprende y transforma tus procesos de CI/CD en una fortaleza de innovación y resiliencia.
Por qué esta guía
Esta guía ayuda a los ingenieros DevOps a construir pipelines de CI/CD que cumplan con las normas de seguridad, mapeando nuevas herramientas de automatización de código abierto a los marcos de seguridad en evolución. A medida que los estándares de seguridad cambian, las actualizaciones en los pipelines son esenciales para garantizar un desarrollo de software más seguro. Esta guía explora la intersección entre las herramientas de seguridad y el pipeline CI/CD, identificando las principales prácticas de seguridad, herramientas y estrategias que se alinean con marcos aceptados, como el Secure Software Development Framework y el NIST Cybersecurity Framework. Esta guía alinea las tareas definidas por los marcos con herramientas de código abierto para lograrlas.
Esta Guía de Ciberseguridad para CI/CD se ha segmentado en tres capítulos principales:
- CI/CD Code and Prebuild – esta sección incluye herramientas de seguridad para los primeros puntos del flujo de trabajo CI/CD.
- CI/CD Build and Deploy – esta sección cubre las herramientas de seguridad tanto para la etapa de compilación como para la de despliegue, sin importar dónde se realice el despliegue (pruebas o producción).
- CI/CD Post Deploy – la seguridad no termina después de que los binarios han sido desplegados. Esta sección cubre la gestión continua de vulnerabilidades y las pruebas de seguridad de aplicaciones dinámicas (DAST).
Para obtener más información sobre marcos de seguridad o políticas públicas de seguridad, visita las páginas de OpenSSF Public Policy o del EU Cybersecurity Resilience Act.
También puedes aprender sobre el OpenSSF Open Source Manifesto para ayudar en este recorrido.
Objetivos de cumplimiento
Las políticas y prácticas de cumplimiento se están definiendo tanto en los sectores público como privado. Específicamente, la Orden Ejecutiva de EE. UU. (EO) sobre la mejora de la ciberseguridad nacional y el EU Cyber Resilience Act (CRA) buscan establecer cómo gestionar amenazas y vulnerabilidades mediante marcos estandarizados de requisitos de ciberseguridad. Estos marcos cubren todo el proceso de desarrollo de software, desde el diseño hasta la monitorización continua de los activos de software en producción.
La inclusión de herramientas de seguridad en el pipeline de Integración Continua y Despliegue Continuo (CI/CD) es un área crucial donde las políticas y prácticas pueden implementarse y automatizarse. Con el ritmo acelerado de desarrollo y despliegue en los entornos modernos de DevOps, la seguridad debe integrarse de manera fluida en cada fase del pipeline para proteger aplicaciones y datos de vulnerabilidades y ataques. Este es el nuevo rol del equipo DevOps. Esta guía está diseñada para ayudar a los equipos DevOps a navegar fácilmente por los nuevos marcos y comprender las herramientas necesarias para cumplir con los objetivos de cumplimiento establecidos.
Aviso legal
Esta Guía de Ciberseguridad para CI/CD está destinada a servir como un punto de referencia. Se recomienda encarecidamente a los usuarios revisar estas recomendaciones para que se ajusten a los requisitos específicos de seguridad de su proyecto y a los estándares de su organización. Al usar esta guía, aceptas hacerlo bajo tu propio riesgo y criterio. La Continuous Delivery Foundation y la Linux Foundation no serán responsables de ningún daño directo, indirecto, incidental, especial, ejemplar o consecuente (incluyendo, pero no limitado a, la adquisición de bienes o servicios de reemplazo; pérdida de uso, datos o ganancias; o interrupción del negocio), sin importar la causa y bajo cualquier teoría de responsabilidad, ya sea contractual, responsabilidad estricta o por agravio (incluyendo negligencia u otra), que surja de cualquier forma del uso de esta guía, incluso si se ha advertido sobre la posibilidad de tales daños.
1 - Fase 1: Código y Preconstrucción
Cumplimiento de seguridad para Código y Preconstrucción
Fase 1 - Código y Preconstrucción
Integrar la seguridad en cada etapa del Ciclo de Vida del Desarrollo de Software (SDLC) es más crítico que nunca. La fase de código y preconstrucción es fundamental para crear aplicaciones seguras, confiables y de alto rendimiento. No abordar las vulnerabilidades de manera temprana puede derivar en correcciones costosas, filtraciones de datos y daños a la reputación a largo plazo.
Esta sección proporciona una guía completa de las herramientas de seguridad esenciales que los desarrolladores y los equipos de DevOps deben usar durante la fase de código y preconstrucción para garantizar que las vulnerabilidades se identifiquen y mitiguen antes de que puedan causar daño. Desde Pruebas de Seguridad de Aplicaciones Estáticas (SAST) hasta el escaneo de dependencias y pipelines de CI/CD seguros, las herramientas adecuadas pueden ayudarte a adoptar un enfoque proactivo de la seguridad del software mientras se mantiene la velocidad de desarrollo. A continuación, se presentan las pautas de los frameworks de la industria con las herramientas open source sugeridas necesarias para alcanzar los objetivos de cumplimiento. Por ejemplo:
– Garantizar la integridad y procedencia del código fuente
– Prevenir el acceso no autorizado a repositorios y pipelines
– Detectar patrones de código inseguro de manera temprana - shift left
– Identificar dependencias open-source vulnerables
– Generar SBOMs lo antes posible
– Establecer trazabilidad desde commit → artifact → deployment
Actividades Clave de Seguridad de la Fase 1
El cumplimiento en los pasos de Código y Preconstrucción incluye:
|
|
| ACTIVIDAD |
PROPÓSITO |
| Control de Acceso a Repositorios |
Prevenir cambios de código no autorizados |
| Firma de Commits |
Establecer la procedencia del software |
| Protección de Ramas |
Aplicar revisiones de pares y políticas |
| SAST |
Detectar patrones de código inseguro |
| Escaneo de Dependencias |
Identificar librerías vulnerables |
| Generación de SBOM |
Crear visibilidad temprana de los componentes |
A continuación, se presentan las pautas de los frameworks de la industria con las herramientas open source sugeridas para alcanzar los objetivos de cumplimiento.
1.1 - 1.0 Tareas de la Fase 1 del Marco de Desarrollo de Software Seguro
Tareas de la Fase 1 del Marco de Desarrollo de Software Seguro relacionadas con Código y Prebuild
1.0 Cumpliendo las Tareas de Código y Prebuild del Marco de Desarrollo de Software Seguro
Este capítulo se centra específicamente en herramientas y prácticas de DevSecOps relacionadas con las acciones de Código y Prebuild del pipeline CI/CD para cumplir las tareas definidas por el Marco de Desarrollo de Software Seguro.
El Marco de Desarrollo de Software Seguro, desarrollado por el Instituto Nacional de Estándares y Tecnología (NIST), proporciona un enfoque integral para garantizar la seguridad en todo el proceso de desarrollo de software, desde el diseño inicial hasta el despliegue y mantenimiento. El marco describe prácticas y directrices clave que las organizaciones pueden implementar para asegurar su ciclo de vida de desarrollo de software (SDLC), con un énfasis especial en integrar la seguridad en los procesos automatizados.
|
|
| 1.1 Preparar la Organización (PO) |
Las organizaciones deben asegurar que su personal, procesos y tecnología estén preparados para realizar desarrollo de software seguro a nivel organizacional. Muchas organizaciones encontrarán que algunas prácticas de PO también aplican a subconjuntos de su desarrollo de software, como grupos de desarrollo individuales o proyectos. |
| 1.2 Proteger el Software (PS) |
Las organizaciones deben proteger todos los componentes de su software frente a manipulaciones y accesos no autorizados. |
| 1.3 Producir Software Bien Asegurado (PW) |
Las organizaciones deben producir software bien asegurado con el mínimo de vulnerabilidades de seguridad en sus versiones. |
| 1.4 Responder a Vulnerabilidades (RV) |
Las organizaciones deben identificar vulnerabilidades residuales en sus versiones de software y responder de manera adecuada para abordarlas y prevenir que ocurran vulnerabilidades similares en el futuro. |
1.1.1 - 1.1 Preparar la Organización (PO)
1.1 Tareas de la Fase 1: Preparar la Organización (PO)
1.1 Preparar la Organización (PO) para las Tareas de Código y Preconstrucción
Las organizaciones deben asegurarse de que su personal, procesos y tecnología estén preparados para llevar a cabo un desarrollo de software seguro a nivel organizacional. Muchas organizaciones encontrarán que algunas prácticas de PO también son aplicables a subconjuntos de su desarrollo de software, como grupos de desarrollo individuales o proyectos.
PO.2 Implementar Roles y Responsabilidades
Asegúrate de que todas las personas, tanto dentro como fuera de la organización, involucradas en el SDLC estén preparadas para desempeñar sus roles y responsabilidades relacionados con el SDLC a lo largo de todo el ciclo de vida.
| Tareas |
Herramientas |
|
PO.2.1:
Crear nuevos roles y modificar las responsabilidades de los roles existentes según sea necesario para abarcar todas las partes del SDLC. Revisar y mantener periódicamente los roles y responsabilidades definidos, actualizándolos según se requiera.
Designar un grupo de individuos como propietarios del código para cada proyecto y revisar la lista anualmente.
|
GitHub CODEOWNERS
GitHub CODEOWNERS es una función del repositorio que permite a los equipos definir formalmente quién es responsable de qué partes del código y quién debe revisar los cambios antes de que se fusionen.
|
|
GitLab CODEOWNERS
GitLab CODEOWNERS es una función del repositorio que permite a los equipos definir formalmente quién es responsable de qué partes del código y quién debe revisar los cambios antes de que se fusionen.
|
PO.3 Implementar Cadenas de Herramientas de Soporte
Usa la automatización para reducir el esfuerzo humano y mejorar la precisión, reproducibilidad, usabilidad y exhaustividad de las prácticas de seguridad a lo largo del SDLC, además de proporcionar una forma de documentar y demostrar el uso de estas prácticas. Las cadenas de herramientas y las herramientas pueden usarse en diferentes niveles de la organización, como a nivel organizacional o específico de un proyecto, y pueden abordar una parte particular del SDLC, como un pipeline de construcción.
| Tareas |
Herramientas |
PO.3.1:
Especificar qué herramientas o tipos de herramientas deben o deberían incluirse en cada cadena de herramientas para mitigar los riesgos identificados, así como cómo se deben integrar entre sí los componentes de la cadena de herramientas.
Usar fábricas de software y/o plantillas de software para estandarizar la cadena de herramientas.
PO.3.2:
Seguir las prácticas de seguridad recomendadas para desplegar, operar y mantener herramientas y cadenas de herramientas.
Usar configuración basada en código para las cadenas de herramientas (por ejemplo, pipelines-as-code, toolchains-as-code).
PO.3.3:
Configurar las herramientas para generar artefactos que evidencien su soporte a las prácticas de desarrollo de software seguro definidas por la organización.
Usar herramientas existentes (por ejemplo, seguimiento de workflows, seguimiento de incidencias, mapeo de flujo de valor) para crear un historial de auditoría de las acciones relacionadas con el desarrollo seguro que se realizan con fines de mejora continua. Registrar aprobaciones, rechazos y solicitudes de excepciones de chequeos de seguridad como parte del sistema de workflow y seguimiento.
|
Backstage Software Templates
Backstage Software Templates es un mecanismo de scaffolding y estandarización que ayuda a los equipos a crear nuevos servicios, pipelines e infraestructura de manera consistente y conforme. Permite a los equipos de plataforma definir rutas óptimas para crear componentes de software. Una plantilla captura buenas prácticas, herramientas requeridas y estándares organizacionales, generando automáticamente repositorios, configuraciones y documentación.
|
|
Konflux-ci software factory for Tekton
La fábrica de software Konflux para Tekton es un sistema CI seguro y estandarizado que se apoya en Tekton para convertir pipelines en una fábrica confiable de la cadena de suministro de software. Konflux añade una capa que garantiza cómo deben ejecutarse los pipelines para que sus resultados sean confiables. Implementa el framework in-toto.
|
|
CDF CDEvents
CDEvents es una especificación común para eventos de entrega continua, permitiendo interoperabilidad en todo el ecosistema de producción de software.
|
|
Jenkins Jenkinsfile
Un Jenkinsfile de Jenkins es una definición declarativa o scriptada de un pipeline CI/CD, escrita como código y almacenada en un repositorio de origen. Describe cómo se construye, prueba, escanea, empaqueta y despliega el software. Al residir junto al código de la aplicación, permite pipelines-as-code—automatización versionada, revisable y auditable.
|
|
GitHub Actions (.github/workflows)
El directorio .github/workflows de GitHub Actions es el lugar central donde se define la automatización CI/CD como código para un repositorio GitHub. Contiene archivos YAML que describen workflows, cuándo deben ejecutarse y qué jobs y pasos se realizan ante eventos del repositorio.
|
|
GitLab CI/CD (.gitlab-ci.yml)
El archivo .gitlab-ci.yml de GitLab CI/CD es la definición única y autorizada de un pipeline que indica cómo GitLab debe construir, probar, asegurar y desplegar una aplicación. Es un archivo YAML basado en pipelines-as-code ubicado en la raíz del repositorio, definiendo jobs, orden y condiciones cuando hay cambios de código.
|
|
Spinnaker Dinghy
Spinnaker Dinghy es un servicio de configuración como código que permite a los equipos definir y gestionar pipelines de despliegue de Spinnaker usando Git en lugar de la interfaz. Los pipelines se escriben como JSON o YAML y se sincronizan automáticamente al hacer commit.
|
|
Argo CD
Argo CD es una herramienta GitOps de entrega continua para Kubernetes que despliega automáticamente y mantiene las aplicaciones sincronizadas con lo declarado en Git. Trata a Git como la única fuente de verdad.
|
|
Tekton Pipelines-as-Code
Tekton Pipelines-as-Code es una forma basada en Git de definir y ejecutar pipelines Tekton CI/CD directamente desde pull requests, tratando los pipelines como artefactos de código de primera clase.
|
|
OpenTofu
OpenTofu es una herramienta open-source de Infrastructure as Code (IaC) usada para definir, provisionar y gestionar infraestructura cloud y on-prem mediante archivos de configuración declarativos.
|
|
Konflux-ci
Konflux es una plataforma CI open-source y cloud-native diseñada para producir artefactos de software confiables, reproducibles y verificables, priorizando integridad, procedencia y repetibilidad, ideal para entornos regulados y críticos.
Python:
pylock.toml
(preferido, estándar más reciente)
JavaScript:
Java / Kotlin / Groovy:
Maven,
Gradle
C# / .NET:
Archivos lock de NuGet
,
DotNet.ReproducibleBuilds
C++: Bazel
Rust: Cargo
Golang: Go reproducible builds
|
|
PHP Composer
Composer es el gestor de dependencias estándar para PHP, usado para declarar, instalar y gestionar librerías de terceros requeridas por una aplicación PHP. Permite definir qué paquetes requiere el proyecto y automáticamente resuelve, descarga e instala las versiones correctas, asegurando consistencia en todos los entornos.
|
|
SLSA Framework
El framework SLSA (Supply-chain Levels for Software Artifacts) es un marco de seguridad que define cómo construir software de forma verificable, resistente a manipulaciones y confiable.
|
|
GitHub Issues
GitHub Issues es un sistema integrado de seguimiento usado para gestionar trabajo, errores, solicitudes de funcionalidades y discusiones directamente en un repositorio GitHub.
|
|
GitLab work tracking
GitLab Work Tracking es el sistema integrado de GitLab para planificar, rastrear y gestionar trabajo—desde ideas y requerimientos hasta código, correcciones de seguridad y entrega.
|
|
Bugzilla
Bugzilla es un sistema open-source de seguimiento de errores y gestión de incidencias usado para reportar, rastrear y gestionar defectos de software y solicitudes de mejora durante todo el ciclo de desarrollo.
|
|
Redmine
Redmine es una herramienta open-source de gestión de proyectos y seguimiento de incidencias usada por equipos de software para planificar trabajo, rastrear bugs y tareas, y gestionar proyectos en el tiempo.
|
|
Mantis Bug Tracker
Mantis Bug Tracker (o MantisBT) es un sistema open-source basado en web para seguimiento de errores e incidencias, diseñado para ser simple, rápido y ligero.
|
|
Trac
Trac es un sistema open-source basado en web de gestión de proyectos y seguimiento de incidencias que integra tickets, wiki y navegación de código. Es conocido por ser ligero, centrado en texto y amigable para desarrolladores.
|
|
in-toto framework
in-toto es un framework open-source para asegurar la cadena de suministro de software registrando y verificando criptográficamente cada paso de cómo se construye, prueba y libera el software.
|
PO.4 Definir y Usar Criterios para Chequeos de Seguridad del Software
Ayuda a asegurar que el software resultante del SDLC cumpla con las expectativas de la organización definiendo y utilizando criterios para verificar la seguridad del software durante el desarrollo.
| Tareas |
Herramientas |
PO.4.1:
Definir criterios para los chequeos de seguridad del software y darles seguimiento durante todo el SDLC.
Agregar criterios de seguridad del software a los chequeos existentes (por ejemplo, la Definición de Hecho en metodologías ágiles del SDLC).
PO.4.2:
Implementar procesos, mecanismos, etc., para recopilar y proteger la información necesaria en apoyo de los criterios.
Recopilar registros de auditoría de los repositorios de código.
PO.4.3:
Implementar procesos, mecanismos, etc., para recopilar y proteger la información necesaria en apoyo de los criterios.
Permitir solo a personal autorizado el acceso a la información recopilada, y prevenir cualquier alteración o eliminación de la información. Gestionar cuidadosamente la lista de propietarios de repositorios y de la organización que tienen la capacidad de ver registros de auditoría, eliminar organizaciones y eliminar repositorios de código, y revisar la lista anualmente.
|
Plantillas de Issues de GitHub
Las Plantillas de Issues de GitHub son formularios y guías predefinidos que aparecen cuando alguien crea un nuevo issue en un repositorio. Ayudan a los equipos a recopilar información consistente y de alta calidad para errores, solicitudes de funcionalidades, problemas de seguridad o preguntas.
|
|
Plantillas de Descripción de GitLab
Las Plantillas de Descripción de GitLab son plantillas Markdown predefinidas que se completan automáticamente en el campo de descripción cuando alguien crea un Issue, Merge Request (MR) o Epic en GitLab.
|
|
GitHub
Registros de Auditoría
|
|
GitLab
Registros de Auditoría
|
|
GitHub
|
|
GitLab
|
PO.5 Implementar y Mantener Entornos Seguros para el Desarrollo de Software
Asegúrese de que todos los componentes de los entornos para el desarrollo de software estén fuertemente protegidos contra amenazas internas y externas para prevenir compromisos de los entornos o del software que se desarrolla o mantiene en ellos. Ejemplos de entornos para el desarrollo de software incluyen entornos de desarrollo, compilación, prueba y distribución.
| Tareas |
Herramientas |
|
PO.5.1:
Separar y proteger cada entorno involucrado en el desarrollo de software.
Requerir autenticación multifactor, claves SSH, commits firmados y aprobaciones de cambios de código para los repositorios de código a nivel de organización.
|
Configuraciones de Organización en GitHub
|
|
GitLab
|
Nota: Configurar de manera segura los repositorios de código y los servidores CI/CD – este es un tema complejo, fuera del alcance de este documento. Configurar de manera segura los endpoints de desarrollo (por ejemplo, laptops de los desarrolladores) – este es un tema complejo, fuera del alcance de este documento.
1.1.2 - 1.2 Proteger el Software (PS)
Fase 1 de tareas de 1.2 Proteger el Software (PS)
1.2 Tareas de Proteger el Software (PS) para Código y Precompilación
Las organizaciones deben proteger todos los componentes de su software contra la manipulación y el acceso no autorizado.
Ayuda a prevenir cambios no autorizados en el código, tanto inadvertidos como intencionales, que podrían eludir o anular las características de seguridad previstas del software.
Para el código que no está destinado a ser accesible públicamente, esto ayuda a evitar el robo del software y puede dificultar o alargar el tiempo que los atacantes necesitan para encontrar vulnerabilidades en él.
| Tareas |
Herramientas |
|
PS.1.1:
Almacenar todas las formas de código – incluyendo código fuente, código ejecutable y configuración-como-código – basándose en el principio de menor privilegio para que solo el personal, herramientas, servicios, etc. autorizados tengan acceso.
Almacenar todo el código fuente y la configuración-como-código en un repositorio de código, y restringir el acceso según la naturaleza del código. Por ejemplo, el código abierto destinado al acceso público puede requerir protección de integridad y disponibilidad; otro código puede también necesitar protección de confidencialidad.
|
GitHub Proporciona un repositorio centralizado de código fuente con control de acceso, auditoría y cumplimiento de flujos de trabajo, apoyando prácticas SSDF para la gestión segura de código y control de cambios.
|
|
GitLab Ofrece control de versiones integrado, CI/CD y flujos de trabajo de seguridad que permiten gobernanza, trazabilidad y procesos de desarrollo seguros alineados con SSDF.
|
|
Bitbucket Apoya SSDF gestionando el código fuente con acceso basado en roles, opciones de integridad de commits y flujos de revisión obligatorios.
|
|
SourceForge Aloja y distribuye proyectos de código abierto con control de versiones y gestión de releases, apoyando requisitos SSDF para procedencia y transparencia del código.
|
|
Subversion Proporciona control de versiones centralizado permitiendo prácticas SSDF para seguimiento de cambios, auditoría y acceso controlado al código fuente.
|
|
Git Permite historial inmutable, trazabilidad y flujos de desarrollo distribuidos, fundamentales para la integridad y responsabilidad del código en SSDF.
|
|
GitBucket Ofrece hosting de repositorios Git con control de acceso y funciones de colaboración que apoyan la gobernanza segura de SSDF.
|
|
Gitea Proporciona repositorios Git ligeros y autoalojados que cumplen con los requisitos SSDF de gestión controlada del código y auditabilidad.
|
|
gittuf Refuerza el cumplimiento de SSDF aplicando políticas criptográficas y metadatos de confianza verificables sobre repositorios y flujos de trabajo Git.
|
|
GitHub Signing Commits Garantiza la integridad del código alineada con SSDF verificando criptográficamente la identidad de los autores de los commits.
|
|
Sigstore Permite la verificación de artefactos y commits alineada con SSDF mediante firmas criptográficas auditable y registros de transparencia sin claves.
|
|
Github CODEOWNERS Aplica la separación de roles y responsabilidad SSDF exigiendo que los propietarios designados revisen y aprueben los cambios de código.
|
|
GitHub Code Review Apoya el desarrollo seguro SSDF haciendo cumplir revisiones por pares, comprobaciones de políticas y puertas de aprobación antes de integrar código.
|
|
Gitlab CODEOWNERS Implementa la asignación de responsabilidades SSDF enviando automáticamente los cambios a los revisores responsables.
|
|
Gitlab Code Review Guidelines Establece estándares de revisión alineados con SSDF que reducen defectos y riesgos de seguridad antes de fusionar el código.
|
PS.2 Proporcionar un Mecanismo para Verificar la Integridad del Software Lanzado
Ayuda a los adquirentes de software a asegurarse de que el software que adquieren sea legítimo y no haya sido manipulado.
| Tareas |
Herramientas |
|
PS.2.1:
Hacer que la información de verificación de integridad del software esté disponible para los adquirentes de software.
Publicar hashes criptográficos de los archivos de lanzamiento en un sitio web seguro.
|
Apache Infrastructure Signing Releases Apoya SSDF asegurando que los lanzamientos de software de Apache estén firmados criptográficamente y sean verificables, estableciendo un origen confiable y protegiendo contra artefactos de distribución manipulados.
|
|
OpenPGP Proporciona mecanismos criptográficos alineados con SSDF para firmar y verificar código y artefactos, garantizando autenticidad, integridad y no repudio.
|
|
The GNU Privacy Guard Implementa los estándares OpenPGP para habilitar prácticas SSDF al firmar código fuente, commits y lanzamientos con identidad verificable del desarrollador.
|
|
Let's Encrypt Apoya la entrega segura alineada con SSDF al emitir certificados TLS gratuitos y automáticos que protegen los canales de distribución de software y los servicios del desarrollador contra interceptaciones y manipulaciones.
|
|
EJBCA Community Permite cumplir con SSDF proporcionando una PKI de código abierto para gestionar certificados usados para autenticar desarrolladores, sistemas y artefactos de software.
|
|
Dogtag Certificate System Apoya los requisitos de confianza e identidad de SSDF al emitir y gestionar certificados digitales para la firma segura de software y la autenticación de infraestructura.
|
|
OpenXPKI Proporciona gestión del ciclo de vida de certificados alineada con SSDF para establecer, auditar y aplicar confianza en las canalizaciones de desarrollo y liberación de software.
|
|
Step-CA Habilita la automatización de identidad criptográfica según SSDF mediante la emisión de certificados de corta duración para desarrolladores, sistemas CI/CD y flujos de trabajo de firma de software.
|
PS.3 Archivar y Proteger Cada Versión de Software
Conservar las versiones de software para ayudar a identificar, analizar y eliminar vulnerabilidades descubiertas en el software después de su lanzamiento.
| Tareas |
Herramientas |
PS.3.1:
Archivar de manera segura los archivos necesarios y los datos de soporte (por ejemplo, información de verificación de integridad, datos de procedencia) que se deben conservar para cada versión de software.
Almacenar los archivos de la versión, imágenes asociadas, etc., en repositorios siguiendo la política establecida por la organización. Permitir acceso de solo lectura al personal necesario y ningún acceso a otras personas.
PS.3.2:
Recopilar, proteger, mantener y compartir datos de procedencia de todos los componentes de cada versión de software (por ejemplo, en un Software Bill of Materials (SBOM)).
Hacer que los datos de procedencia estén disponibles para los adquirentes de software de acuerdo con las políticas de la organización, preferiblemente usando formatos estandarizados.
|
Permisos de Acceso en GitHub Aplica control de acceso basado en roles según SSDF restringiendo quién puede ver, modificar o administrar los repositorios de código fuente.
|
|
Roles y Permisos de GitLab Soporta la gobernanza SSDF definiendo roles granulares que aplican el principio de mínimo privilegio y separación de funciones a lo largo del SDLC.
|
|
Roles de Repositorio en GitHub para una Organización Implementa controles organizacionales SSDF estandarizando los niveles de permisos entre equipos y repositorios.
|
|
Roles y Permisos de GitLab Implementa controles organizacionales SSDF estandarizando los niveles de permisos entre equipos y repositorios.
|
|
Ortelius Extiende los controles SSDF más allá del código fuente al aplicar acceso, trazabilidad y responsabilidad sobre software desplegado, SBOMs y metadatos del entorno en vivo mediante un gemelo digital centrado en despliegue.
|
|
Generador AI SBOM Soporta SSDF generando y manteniendo automáticamente SBOMs precisos que mejoran la visibilidad de componentes y la trazabilidad de vulnerabilidades en todo el SDLC.
|
|
CycloneDX Permite la transparencia de componentes alineada con SSDF proporcionando un formato de SBOM estandarizado optimizado para seguridad, integridad y análisis de riesgos.
|
|
Herramientas y Utilidades de Etiquetado SWID Apoyan las prácticas SSDF identificando de forma única los componentes de software instalados para permitir inventario de activos, rastreo de procedencia y correlación de vulnerabilidades.
|
|
SPDX Proporciona un estándar compatible con SSDF para documentar componentes de software, licencias y relaciones, apoyando la transparencia y cumplimiento en la cadena de suministro.
|
|
bomctl Soporta el consumo de SBOMs SSDF validando, consultando y gestionando SBOMs a lo largo de los flujos de trabajo de construcción y liberación.
|
|
OWASP Dependency-Check Permite la detección de vulnerabilidades SSDF identificando CVEs conocidos en dependencias de terceros durante el desarrollo y la construcción.
|
|
Dependency-Track Soporta la gestión de riesgos SSDF analizando continuamente SBOMs para monitorear vulnerabilidades de componentes y cumplimiento de políticas.
|
|
Clair Contribuye a SSDF escaneando imágenes de contenedores para detectar vulnerabilidades conocidas antes del despliegue.
|
|
Grype Soporta prácticas de construcción segura SSDF detectando vulnerabilidades conocidas en imágenes de contenedores y sistemas de archivos usando datos de SBOM.
|
|
Ortelius Extiende SSDF más allá del tiempo de construcción correlacionando y agregando SBOMs, vulnerabilidades y metadatos de despliegue para identificar qué entornos en vivo están realmente en riesgo.
|
|
Protobom Soporta la interoperabilidad SSDF proporcionando bibliotecas y herramientas reutilizables para generar y transformar SBOMs entre formatos.
|
|
Syft Permite el descubrimiento de componentes SSDF generando SBOMs a partir de código fuente, contenedores y artefactos en ejecución.
|
|
Hoppr Soporta el intercambio y descubrimiento de SBOMs SSDF permitiendo la distribución segura y recuperación de artefactos SBOM.
|
|
Tern Contribuye a la transparencia SSDF analizando imágenes de contenedores para producir inventarios detallados de componentes y SBOMs.
|
|
Trivy Soporta el desarrollo seguro SSDF escaneando vulnerabilidades, configuraciones incorrectas y secretos expuestos en código y artefactos.
|
|
aoss-verifier Permite la validación de cumplimiento SSDF verificando la integridad y autenticidad de artefactos de código abierto.
|
|
Sigstore Soporta la procedencia SSDF permitiendo la firma criptográficamente verificable de artefactos y SBOMs con registros de transparencia.
|
|
Protocolo TLSNotary Contribuye a la confianza SSDF proporcionando prueba criptográfica de integridad de datos para metadatos de seguridad y dependencias obtenidos externamente.
|
|
GitHub Actions Permite la automatización SSDF integrando controles de seguridad, generación de SBOMs y cumplimiento de políticas directamente en los flujos de trabajo de CI.
|
|
GitLab CI/CD Soporta pipelines seguras SSDF integrando controles de construcción, prueba, escaneo y liberación dentro de un sistema CI/CD gobernado.
|
|
Jenkins Servidor de automatización totalmente open-source, bajo licencia MIT, con un ecosistema extensible de plugins, ampliamente usado para implementar controles de seguridad CI/CD alineados a SSDF.
|
|
Updatecli Soporta la remediación SSDF automatizando actualizaciones de dependencias, configuraciones y políticas de manera controlada y auditable.
|
|
Renovate Permite el mantenimiento seguro SSDF actualizando automáticamente dependencias vulnerables mientras se preservan los controles de revisión y aprobación.
|
1.1.3 - 1.3 Producir Software Bien Asegurado (PW)
1.3 Producir Software Bien Asegurado (PW) durante las tareas de código y precompilación
1.3 Producir Software Bien Asegurado (PW) — Tareas de Código y Precompilación
Las organizaciones deben producir software bien asegurado con vulnerabilidades de seguridad mínimas en sus versiones.
PW.1
Diseñar el Software para Cumplir con los Requisitos de Seguridad y Mitigar Riesgos de Seguridad: Identificar y evaluar los requisitos de seguridad del software; determinar qué riesgos de seguridad es probable que enfrente el software durante su operación y cómo el diseño y la arquitectura del software deben mitigar esos riesgos; y justificar cualquier caso en el que un análisis basado en riesgos indique que los requisitos de seguridad deben flexibilizarse o eximirse. Abordar los requisitos y riesgos de seguridad durante el diseño del software (secure by design) es clave para mejorar la seguridad del software y también ayuda a mejorar la eficiencia del desarrollo.
| Tareas |
Herramientas |
|
PW.1.1:
Usar formas de modelado de riesgos —como modelado de amenazas, modelado de ataques o mapeo de superficie de ataque— para ayudar a evaluar el riesgo de seguridad del software.
PW.1.2:
Rastrear y mantener los requisitos de seguridad, los riesgos y las decisiones de diseño del software.
PW.1.3:
Cuando sea apropiado, incorporar soporte para el uso de funciones y servicios de seguridad estandarizados (por ejemplo, permitir que el software se integre con sistemas existentes de gestión de registros, gestión de identidades, control de acceso y gestión de vulnerabilidades) en lugar de crear implementaciones propietarias de funciones y servicios de seguridad.
|
OWASP Threat Dragon
Se utiliza antes de programar para documentar los componentes del sistema, los flujos de datos y los límites de confianza, y luego enumerar amenazas y requisitos.
|
|
OWASP Amass
Ayuda a definir los requisitos de seguridad al identificar dependencias externas conocidas, APIs o servicios con los que el código interactuará, lo que informa el modelado de amenazas y el diseño seguro.
|
|
CAIRIS
Ayuda a los equipos de seguridad y a los desarrolladores a capturar, gestionar y rastrear los requisitos de seguridad desde el diseño inicial hasta el desarrollo, asegurando la alineación de seguridad en la fase prebuild.
|
|
Threagile
Permite el “modelado de amenazas como código” en la fase prebuild, de modo que los requisitos de seguridad puedan automatizarse y controlarse en versión junto con el código de la aplicación.
|
|
Open-Needs
Centraliza y estructura los requisitos de seguridad para que estén disponibles para el modelado de amenazas, las revisiones de diseño y la validación temprana.
|
|
rmtoo
Útil en la fase de diseño y planificación para mantener una lista estructurada de requisitos de seguridad y vincularlos con casos de prueba, modelos de amenazas o módulos de código, asegurando que la seguridad se aborde antes de programar.
|
|
OpenRMF® OSS
En la fase prebuild, puede definir los requisitos de seguridad exactos derivados del RMF que debe cumplir la base de código, incluyendo las líneas base de controles, y vincularlos con elementos de diseño o tareas de desarrollo.
|
PW.2
Revisar el Diseño del Software para Verificar el Cumplimiento de los Requisitos de Seguridad y la Información de Riesgos: Ayuda a garantizar que el software cumpla con los requisitos de seguridad y aborde de manera satisfactoria la información de riesgos identificada.
| Tareas |
Herramientas |
|
PW.2.1:
Contar con (1) una persona calificada que no haya participado en el diseño y/o (2) procesos automatizados en la cadena de herramientas que revisen el diseño del software para confirmar y asegurar que cumple con todos los requisitos de seguridad y aborda satisfactoriamente la información de riesgos identificada.
|
OWASP Dependency-Check
Analiza las dependencias del proyecto (directas y transitivas) contra la National Vulnerability Database (NVD) y otras fuentes para detectar vulnerabilidades conocidas (CVEs). Ayuda a confirmar si un componente cumple con los requisitos de seguridad antes de su inclusión.
|
|
Dependabot
Herramienta automatizada de monitoreo y actualización de dependencias integrada con GitHub. Detecta dependencias vulnerables y crea pull requests para actualizarlas, asegurando que solo se usen versiones seguras.
|
|
OpenRMF
Gestiona artefactos de cumplimiento del Risk Management Framework (RMF), incluyendo controles NIST 800-53. Puede usarse para confirmar que los componentes de software seleccionados cumplen con las bases de control de seguridad antes de su aprobación.
|
|
ESLint
Linter de JavaScript/TypeScript que aplica estándares de codificación segura y señala patrones inseguros antes de que lleguen a producción. Ayuda a validar que los componentes de código personalizados cumplan con los requisitos de codificación segura.
|
|
LGTM
Plataforma de análisis automatizado de código para identificar vulnerabilidades y problemas de calidad en múltiples lenguajes. Confirma que los componentes de código cumplen con las políticas de seguridad antes de su integración.
|
|
Grype
Escáner de vulnerabilidades de código abierto para imágenes de contenedores y sistemas de archivos. Garantiza que los componentes containerizados cumplan con los requisitos de vulnerabilidad y cumplimiento antes del despliegue.
|
|
Clair
Análisis estático de vulnerabilidades para imágenes de contenedores. Se integra en CI/CD para detectar vulnerabilidades en imágenes base y capas antes de su promoción.
|
|
Trivy
Escáner de vulnerabilidades integral para imágenes de contenedores, sistemas de archivos y repositorios Git. Valida que los componentes seleccionados no tengan vulnerabilidades conocidas ni configuraciones inseguras.
|
|
Checkov
Análisis estático de Infrastructure as Code (IaC) para detectar configuraciones de seguridad incorrectas (Terraform, Kubernetes, CloudFormation). Garantiza que los componentes de IaC cumplan con las bases de seguridad definidas antes de su uso.
|
|
Terrascan
Escáner de políticas como código para Terraform, Kubernetes, Docker y otros frameworks IaC. Confirma que los componentes de infraestructura cumplan con los requisitos de seguridad y cumplimiento.
|
|
Gerrit
Herramienta web de revisión de código. Aunque no es un escáner de vulnerabilidades, aplica revisiones humanas y flujos de aprobación que pueden incluir listas de verificación de validación de requisitos de seguridad antes de aprobar un componente.
|
PW.4
Reutilizar software existente y bien asegurado cuando sea factible en lugar de duplicar funcionalidades: Reducir los costos de desarrollo de software, acelerar el desarrollo y disminuir la probabilidad de introducir vulnerabilidades adicionales reutilizando módulos y servicios de software cuya seguridad ya ha sido verificada. Esto es especialmente importante para software que implementa funcionalidades de seguridad, como módulos y protocolos criptográficos.
| Tareas |
Herramientas |
PW.4.1:
Adquirir y mantener componentes de software bien asegurados (por ejemplo, bibliotecas, módulos, middleware, frameworks) de desarrolladores comerciales, de código abierto y de terceros para su uso en el software de la organización.
PW.4.2:
Crear y mantener componentes de software bien asegurados internamente siguiendo los procesos del SDLC para cubrir necesidades internas que no puedan ser satisfechas mejor mediante componentes de terceros.
PW.4.4:
Verificar que los componentes de software adquiridos, ya sean comerciales, de código abierto o de otros terceros, cumplan con los requisitos definidos por la organización a lo largo de todo su ciclo de vida.
|
|
CycloneDX
Generado durante build/prebuild para validar los datos de los componentes contra criterios de aceptación definidos.
|
|
SPDX
Usado para verificar que todos los componentes cumplen con los requisitos de licencias y seguridad antes de su integración.
|
|
ArtifactHub
Garantiza que solo se obtengan paquetes verificados, firmados y conformes a políticas para los builds.
|
|
JFrog Artifactory OSS
Actúa como fuente controlada para componentes que cumplen con estándares de seguridad definidos.
|
|
Sonatype Nexus OSS
Evita el uso de componentes que no cumplen con los requisitos de seguridad o políticas.
|
|
Harbor
Aplica reglas para que solo imágenes escaneadas, firmadas y conformes a políticas sean almacenadas y utilizadas en builds.
|
|
GitLab Signing
Aplica la política de commits firmados en merge requests antes de aceptar código.
|
|
GitHub CodeQL
Ejecuta consultas de seguridad predefinidas en CI para verificar el código antes de su integración.
|
|
AquaSec Trivy
Aplica criterios de aceptación de seguridad (por ejemplo, sin CVEs críticas) antes de promover componentes.
|
|
Dependabot
Crea PRs para garantizar que se usen versiones seguras definidas por política.
|
|
Allstar
Garantiza que los repositorios cumplan con criterios de configuración antes de permitir merges.
|
|
OWASP SAMM
Proporciona un marco para definir prácticas de aseguramiento de seguridad y objetivos de madurez. Ayuda a establecer criterios para procesos de desarrollo seguro, incluyendo prebuild.
|
|
OWASP ASVS
Define requisitos detallados de verificación de seguridad para aplicaciones. Puede usarse como referencia para pruebas de seguridad automatizadas y manuales en prebuild.
|
|
OWASP Defectdojo
Plataforma de gestión de vulnerabilidades y orquestación de pruebas de seguridad. Centraliza resultados de escáneres y asegura que los problemas se rastreen según criterios de aceptación.
|
|
OWASP Dependency-Check
Escanea dependencias del proyecto buscando vulnerabilidades conocidas (CVEs) y falla builds si no cumplen criterios.
|
|
Git
VCS que soporta firma de commits y hooks para aplicar prebuild checks (linting, escaneos de seguridad).
|
|
Gitea
Servicio Git ligero y autohospedado con aplicación de políticas de repositorio (p. ej., commits firmados, revisiones requeridas).
|
|
GitLab (Community Edition)
Plataforma Git con integración CI/CD para ejecutar controles de seguridad antes de mergear.
|
|
Visual Studio Code
Soporta extensiones para linting, escaneo de vulnerabilidades y enforcement de firma de código pre-commit.
|
|
Eclipse
IDE Java con plugins para análisis estático, escaneo de dependencias y enforcement de reglas de codificación segura.
|
|
IntelliJ IDEA (Community Edition)
IDE Java con plugins para análisis estático, codificación segura y generación de SBOM.
|
|
JUnit
Framework de pruebas unitarias Java; puede integrarse con suites de pruebas de seguridad.
|
|
NUnit
Framework de pruebas .NET; soporta integración con tests de validación de seguridad.
|
|
Pytest
Framework de pruebas Python; puede ejecutar tests basados en reglas de seguridad como parte de CI.
|
|
Selenium
Herramienta de pruebas automatizadas de navegador; puede validar comportamientos seguros (p. ej., flujos de autenticación).
|
|
Playwright
Pruebas end-to-end de navegador con soporte para escenarios centrados en seguridad.
|
|
OWASP ZAP
Herramienta DAST para encontrar problemas de seguridad en aplicaciones en ejecución durante fases de prueba.
|
|
TestNG
Framework de pruebas para Java; se integra con automatización de seguridad.
|
|
Cucumber
Framework de pruebas BDD; permite definir tests de aceptación de seguridad en lenguaje natural.
|
|
Aqua Trivy
Escanea contenedores, sistemas de archivos y repositorios en busca de vulnerabilidades y errores de configuración.
|
|
Clair
Escaneo estático de vulnerabilidades en imágenes de contenedor antes del despliegue.
|
|
Grype
Escáner de vulnerabilidades para contenedores y sistemas de archivos.
|
|
Bandit for Python
Analizador estático específico de Python para problemas de seguridad comunes.
|
|
Semgrep
Análisis estático multi-lenguaje usando reglas de seguridad personalizadas o predefinidas.
|
|
Brakeman
Analizador estático específico de Rails para vulnerabilidades de seguridad.
|
|
Gitleaks
Detecta secretos hardcoded en repositorios Git antes del commit o en CI.
|
|
TruffleHog
Detecta secretos e información sensible en el historial y commits del código.
|
|
Sigstore
Framework open-source para firmar artefactos de software (commits, contenedores) usando pruebas criptográficas.
|
|
OWASP Dependency-Check
Escanea dependencias del proyecto (directas y transitivas) buscando CVEs conocidas usando NVD y otras fuentes. Puede aplicar criterios de “no vulnerabilidades críticas/altas” antes de aprobar el build.
|
|
OSS Review Toolkit (ORT)
Garantiza que los componentes seleccionados cumplan criterios de licencias y seguridad antes de integrarse a la línea principal.
|
|
FOSSA (Community Edition)
Puede bloquear merges o builds que violen reglas de licencias o contengan vulnerabilidades conocidas.
|
|
ScanCode Toolkit
Asegura que los criterios de licencias se cumplan antes de aceptar componentes en el build.
|
|
Tern
Proporciona inventario de componentes para validar contra criterios de aceptación predefinidos.
|
|
Open Policy Agent (OPA)
Aplica políticas de seguridad, cumplimiento y configuración durante gates de CI/CD antes del release.
|
PW.5
Crear Código Fuente Siguiendo Prácticas de Codificación Segura: Reducir el número de vulnerabilidades de seguridad en el software y disminuir los costos de desarrollo asegurando que el código fuente se cree siguiendo prácticas de codificación segura, cumpliendo o superando los criterios de severidad de vulnerabilidades definidos por la organización.
| Tareas |
Herramientas |
|
PW.5.1:
Seguir todas las prácticas de codificación segura apropiadas para los lenguajes de desarrollo y el entorno, a fin de cumplir con los requisitos de seguridad de la organización.
|
Semgrep
Integrado en CI para escanear el código modificado y bloquear merges si las reglas de seguridad fallan; también puede ejecutarse localmente para verificaciones previas al commit.
|
|
Bandit para Python
Se ejecuta en prebuild o pipelines de CI para detectar problemas de seguridad de alta severidad en código Python.
|
|
FindBugs
Analiza código Java antes del empaquetado para identificar vulnerabilidades y malas prácticas de codificación.
|
|
SpotBugs
Integrado en CI/CD para detectar vulnerabilidades en Java antes del lanzamiento.
|
|
SonarQube
Se ejecuta en pipelines CI/CD para señalar problemas de seguridad antes de los merges, aplicando quality gates.
|
|
OWASP ZAP
Se ejecuta en entornos de prueba antes de producción para identificar problemas de seguridad en tiempo de ejecución.
|
|
Arachni
Escanea instancias de staging/test para detectar vulnerabilidades explotables antes del despliegue.
|
|
OWASP Dependency-Check
Previene builds que incluyan componentes con vulnerabilidades que superen los umbrales de severidad definidos.
|
PW.6
Configurar los Procesos de Compilación, Intérprete y Construcción para Mejorar la Seguridad de los Ejecutables: Reducir el número de vulnerabilidades de seguridad en el software y disminuir los costos de desarrollo al detectar y eliminar vulnerabilidades durante la compilación o construcción, antes de las pruebas y el despliegue.
| Tareas |
Herramientas |
PW.6.1:
Usar compiladores, intérpretes y herramientas de construcción que incluyan funcionalidades para mejorar la seguridad de los ejecutables.
PW.6.2:
Definir qué funcionalidades de compilador, intérprete y herramientas de construcción se deben aplicar y configurarlas según los estándares de seguridad aprobados.
|
|
Sigstore Cosign
Firma y verifica la integridad y autenticidad del código fuente y las dependencias precompiladas antes de la compilación.
|
|
GnuPG (GPG)
Verifica las firmas criptográficas de archivos fuente y dependencias antes de la construcción.
|
|
OSS Review Toolkit (ORT)
Audita y escanea las dependencias en busca de vulnerabilidades de seguridad y problemas de licencias antes de incluirlas en la construcción.
|
|
Meson
Sistema de construcción integrado en CI/CD para aplicar configuraciones de seguridad y cumplimiento durante la compilación.
|
|
Tern
Analiza capas de imágenes de contenedores para identificar componentes de código abierto, licencias y posibles vulnerabilidades antes de usarlas en las construcciones.
|
|
ScanCode Toolkit
Detecta licencias, derechos de autor y paquetes en el código fuente antes de la construcción para garantizar cumplimiento y seguridad.
|
|
Grype
Escanea código fuente e imágenes de contenedores en busca de vulnerabilidades conocidas antes de incluirlas en la construcción.
|
|
Syft
Genera SBOMs a partir del código fuente y dependencias antes de la construcción para documentar y verificar los componentes.
|
PW.7
Revisar y Analizar Código Legible por Humanos para Identificar Vulnerabilidades y Verificar el Cumplimiento de Seguridad: Identificar vulnerabilidades en el código para que puedan ser corregidas antes del lanzamiento, previniendo su explotación. Los métodos automatizados reducen el esfuerzo y los recursos necesarios para detectar problemas. El código legible por humanos incluye código fuente, scripts y cualquier otra forma que la organización reconozca como legible por humanos.
| Tareas |
Herramientas |
PW.7.1:
Determinar si se debe utilizar revisión de código (una persona examina directamente el código para encontrar problemas) y/o análisis de código (se usan herramientas para encontrar problemas en el código, ya sea de forma totalmente automatizada o en conjunto con una persona), según lo defina la organización.
PW.7.2:
Realizar la revisión de código y/o el análisis de código de acuerdo con los estándares de codificación segura de la organización, registrando y clasificando todos los problemas detectados y las recomendaciones de remediación en el flujo de trabajo del equipo de desarrollo o en el sistema de seguimiento de incidencias.
|
|
OWASP Dependency-Check
Escanea las dependencias del proyecto (por ejemplo, Maven, npm, Python) contra la NVD para CVEs conocidas antes de la compilación, permitiendo la remediación temprana de librerías vulnerables.
|
|
OWASP ZAP
Principalmente una herramienta de pruebas de seguridad de aplicaciones dinámicas (DAST), pero en precompilación no se usa generalmente; puede ejecutarse contra compilaciones locales para detectar fallas tempranas en tiempo de ejecución. Aplicabilidad limitada a PW.7 precompilación.
|
|
SonarQube
Realiza SAST y revisa la calidad del código para múltiples lenguajes, detectando vulnerabilidades, errores y malos olores en el código antes de la compilación o integración.
|
|
Retire.js
Escanea código JavaScript y manifiestos de paquetes en busca de librerías vulnerables conocidas antes del empaquetado.
|
|
Fossa Community Edition
Realiza escaneo de dependencias para problemas de licencias y vulnerabilidades antes de la compilación. La versión comercial SaaS es propietaria.
|
|
Semgrep
Herramienta SAST ligera y personalizable. Utiliza reglas para detectar problemas de seguridad y patrones inseguros en el código fuente antes de la compilación.
|
|
Bandit para Python
Escanea código Python en busca de problemas de seguridad comunes antes de la compilación (por ejemplo, uso inseguro de funciones, contraseñas codificadas).
|
|
Checkmarx KICS
Herramienta de análisis estático para IaC (Terraform, YAML de Kubernetes, etc.) para encontrar configuraciones incorrectas antes del despliegue.
|
|
Cppcheck para C++
Análisis estático para código C/C++ para detectar comportamientos indefinidos, problemas de memoria y vulnerabilidades comunes antes de la compilación.
|
|
FindSecBugs
Plugin para SpotBugs que detecta vulnerabilidades específicas de Java antes de la compilación.
|
|
GitHub CodeQL
Realiza análisis profundo del código usando un lenguaje de consultas para detectar vulnerabilidades antes de la compilación. Excelente para SAST automatizado en pipelines de CI.
|
|
PMD
Escanea Java, Apex, JavaScript, XML y otros códigos en busca de errores, código no utilizado y posibles problemas de seguridad antes de la compilación.
|
|
SpotBugs
Análisis estático para bytecode Java; detecta patrones de errores y posibles vulnerabilidades precompilación (cuando se ejecuta sobre archivos de clase compilados en CI antes del empaquetado).
|
|
Danger JC
Automatiza las revisiones de pull requests — aplica las pautas de seguridad/contribución y previene que patrones inseguros se fusionen al código antes de la compilación.
|
PW.8
Probar el Código Ejecutable para Identificar Vulnerabilidades y Verificar el Cumplimiento de los Requisitos de Seguridad: Ayuda a identificar vulnerabilidades para que puedan corregirse antes de que el software sea liberado, previniendo su explotación. El uso de métodos automatizados reduce el esfuerzo y los recursos necesarios para detectar vulnerabilidades, y mejora la trazabilidad y la repetibilidad. El código ejecutable incluye binarios, bytecode ejecutable directamente, código fuente y cualquier otra forma de código que la organización considere ejecutable.
| Tareas |
Herramientas |
PW.8.1:
Determinar si se debe realizar pruebas de código ejecutable para encontrar vulnerabilidades no identificadas por revisiones, análisis o pruebas previas y, de ser así, qué tipos de pruebas deben utilizarse.
PW.8.2:
Delimitar el alcance de las pruebas, diseñarlas, ejecutarlas y documentar los resultados, incluyendo el registro y la clasificación de todos los problemas descubiertos y las recomendaciones de remediación en el flujo de trabajo del equipo de desarrollo o en el sistema de seguimiento de incidencias.
|
|
Semgrep
Motor SAST que analiza el código fuente contra reglas de seguridad antes de la compilación, detectando vulnerabilidades tempranamente.
|
|
Bandit (Python)
Análisis estático para código Python para encontrar problemas de seguridad comunes antes del empaquetado.
|
|
FindSecBugs
Plugin de seguridad para SpotBugs para detectar vulnerabilidades en código Java/Scala/Groovy antes de la compilación.
|
|
Cppcheck
Análisis estático para C/C++ para detectar fallos de seguridad antes de generar los artefactos de compilación.
|
|
PMD
Análisis estático basado en reglas para Java, Apex, JavaScript y XML para detectar vulnerabilidades y problemas de codificación.
|
|
SpotBugs
Detección de errores y vulnerabilidades en código Java antes de generar la salida de compilación.
|
|
GitHub CodeQL
Análisis semántico de código para encontrar vulnerabilidades antes de la compilación.
|
|
OWASP Dependency-Check
Herramienta SCA que identifica dependencias vulnerables en los manifiestos antes del empaquetado.
|
|
Retire.js
Analiza dependencias de JavaScript y Node.js para detectar vulnerabilidades conocidas antes de la liberación.
|
|
Grype
Herramienta SSCA para escanear dependencias de código fuente y imágenes base antes de la compilación para detectar CVEs.
|
|
Syft
Genera SBOMs desde código fuente antes de la compilación para verificar el inventario de componentes.
|
|
Checkmarx KICS
Analiza archivos de Infrastructure-as-Code (Terraform, Kubernetes YAML, etc.) para detectar configuraciones incorrectas antes del despliegue.
|
|
Gitleaks
Busca secretos en el código y en el historial de Git antes de la compilación.
|
|
TruffleHog
Busca secretos e información sensible en el código y en el historial de Git antes de la compilación.
|
PW.9
Configurar el Software para que Tenga Configuraciones Seguras por Defecto: Ayuda a mejorar la seguridad del software en el momento de la instalación para reducir la probabilidad de que se despliegue con configuraciones de seguridad débiles, lo que aumentaría el riesgo de compromiso.
| Tareas |
Herramientas |
PW.9.1:
Definir una línea base segura determinando cómo configurar cada ajuste que tenga efecto en la seguridad o cualquier ajuste relacionado con la seguridad, de modo que la configuración predeterminada sea segura y no debilite las funciones de seguridad proporcionadas por la plataforma, la infraestructura de red o los servicios.
PW.9.2:
Implementar los ajustes predeterminados (o grupos de ajustes predeterminados, si es aplicable) y documentar cada configuración para los administradores de software.
|
|
KICS (Checkmarx)
Detecta configuraciones incorrectas y valores predeterminados inseguros en archivos de IaC antes de la compilación.
|
|
Open Policy Agent (OPA)
Motor de políticas como código para aplicar reglas de configuración segura en pipelines previos a la compilación.
|
|
Yamllint
Valida archivos de configuración YAML, asegurando la corrección de su estructura antes de realizar más verificaciones de seguridad.
|
1.1.4 - 1.4 Responder a Vulnerabilidades
1.4 Responder a Vulnerabilidades (RV) en Código y Pasos Prebuild de CI/CD
1.4 Responder a Vulnerabilidades (RV) para Tareas de Código y Prebuild
Responder a Vulnerabilidades (RV): Las organizaciones deben identificar vulnerabilidades residuales en sus lanzamientos de software y responder de manera adecuada para abordar esas vulnerabilidades y prevenir que ocurran similares en el futuro.
RV.1
Identificar y Confirmar Vulnerabilidades de Forma Continua: Ayuda a garantizar que las vulnerabilidades se identifiquen más rápido para poder remediarlas de acuerdo con el riesgo, reduciendo la ventana de oportunidad para los atacantes.
Para cumplir con SSDF RV.1 en un contexto de código y prebuild usando herramientas de código abierto, el enfoque se centra en detectar y remediar vulnerabilidades antes de que se construya cualquier artefacto, de modo que las correcciones ocurran en PRs de código/manifest, no después del empaquetado.
| Tareas |
Herramientas |
RV.1.1:Recopilar información de adquirientes de software, usuarios y fuentes públicas sobre posibles vulnerabilidades en el software y componentes de terceros que utiliza, e investigar todos los informes creíbles.
RV.1.2: Revisar, analizar y/o probar el código del software para identificar o confirmar la presencia de vulnerabilidades previamente no detectadas.
RV.1.3:
Definir una política que aborde la divulgación y remediación de vulnerabilidades, e implementar los roles, responsabilidades y procesos necesarios para respaldar dicha política.
|
|
OSV-Scanner
Escanea árboles de código y archivos manifest/lock contra OSV para detectar vulnerabilidades conocidas tempranamente en el desarrollo.
|
|
Ortelius Evidence Store
Sincroniza continuamente versiones de Software Bill of Material de artefactos construidos a OSV.dev, reportando vulnerabilidades descubiertas después del build.
|
|
Semgrep
SAST basado en reglas en PRs/CI para vulnerabilidades previamente no detectadas. Herramienta de análisis estático usada para buscar en el código, encontrar errores y aplicar estándares de código en varias etapas del ciclo de desarrollo (editor, commit e integración continua - CI).
|
|
OWASP Dependency Check
SCA para múltiples ecosistemas; corre en CI, genera salida SARIF/HTML. Coincidencia de dependencias basada en CVE para retroalimentación en tiempo de código.
|
|
Trivy
Escanea archivos fuente/lockfiles e IaC antes de construir. SCA todo-en-uno + comprobaciones de configuración incorrecta de IaC pre-build.
|
|
Syft
Genera SBOMs (CycloneDX/SPDX) directamente desde el código fuente. Datos de composición/procedencia para apoyar el descubrimiento de RV.1.
|
|
Grype
Escanea directorios de código o Software Bill of Materials (de Syft) en busca de vulnerabilidades. Coincidencia precisa mediante SBOM + integración flexible en CI.
|
|
SonarQube Community
Los desarrolladores pueden inspeccionar continuamente la calidad del código para detectar errores, "code smells" y vulnerabilidades de seguridad sin ejecutar el código.
|
|
CodeQL
Desarrollado por GitHub, permite a desarrolladores e investigadores de seguridad analizar bases de código para vulnerabilidades, errores y otros problemas de calidad de código.
|
|
Bandit (Python)
Herramienta de análisis estático diseñada para identificar vulnerabilidades de seguridad comunes en código Python.
|
|
Brakeman (Rails)
Escáner de vulnerabilidades específicamente diseñado para aplicaciones Ruby on Rails.
|
|
FindSecBugs (Java)
Herramienta de análisis estático para aplicaciones Java, usada para identificar posibles vulnerabilidades de seguridad en el código.
|
|
Gitleaks
Previene secretos codificados directamente en el código y archivos de configuración.
|
|
Conftest
Utilidad para escribir pruebas sobre datos de configuración estructurados.
|
|
Hoppr
Kit de utilidades SBOM / cadena de suministro: procesamiento de SBOM y movimiento de “materiales” de la cadena de suministro alineados a la recopilación/mantenimiento/compartición de procedencia.
|
RV.2
Evaluar, Priorizar y Remediar Vulnerabilidades: Ayuda a garantizar que las vulnerabilidades se remediarán de acuerdo con el riesgo para reducir la ventana de oportunidad para los atacantes.
Para cumplir con SSDF RV.2 en un contexto de código y prebuild usando herramientas de código abierto, el enfoque se centra en:
-
Registrar cada vulnerabilidad
-
Analizar el riesgo (explotabilidad e impacto)
-
Elegir respuestas, publicar avisos y entregar remediaciones mediante mecanismos confiables; incluir mitigaciones temporales cuando sea necesario.
| Tareas |
Herramientas |
RV.2.1:
Analizar cada vulnerabilidad para recopilar información suficiente sobre el riesgo y planificar su remediación u otra respuesta al riesgo.
RV.2.2:
Planificar e implementar respuestas al riesgo para las vulnerabilidades.
|
|
GUAC
Agrega SBOMs, atestaciones y vulnerabilidades para entender el impacto y priorizar correcciones.
|
|
Renovate
Automatiza actualizaciones de dependencias y PRs de parches con políticas conscientes del riesgo.
|
|
OWASP DefectDojo
Ingesta resultados de escáneres (Semgrep/Grype/Trivy/etc.) para deduplicación, severidad, propiedad y flujo de trabajo. Triage central de vulnerabilidades y seguimiento de riesgo vinculado a repos.
|
|
Ortelius Evidence Store
Muestra el impacto de cada vulnerabilidad a través de entornos en vivo.
|
|
Vulns
Escáner de vulnerabilidades sin agente que analiza paquetes instalados y los mapea a datos CVE con puntuación CVSS. Proporciona severidad, explotabilidad y recomendaciones de remediación; puede integrarse en flujos de parches.
|
|
Dependency-Track
Plataforma de análisis de componentes basada en SBOM de forma continua. Enriquece vulnerabilidades con metadatos (severidad, explotabilidad, impacto de políticas).
|
|
VEX
VEX cierra la brecha entre identificar vulnerabilidades potenciales (SBOM) y determinar su riesgo real en un entorno específico. Permite priorizar esfuerzos de remediación enfocándose en vulnerabilidades realmente explotables que requieren atención inmediata.
|
RV.3
Analizar Vulnerabilidades para Identificar Sus Causas Raíz: Ayuda a reducir la frecuencia de vulnerabilidades en el futuro.
Para cumplir con SSDF RV.3 en un contexto de código y prebuild usando herramientas de código abierto, el enfoque se centra en:
-
Identificar vulnerabilidades en código fuente y manifiestos de dependencias antes de construir, usando generación de SBOM, SCA y SAST
-
Confirmar hallazgos eliminando falsos positivos y documentando evidencia mínima para remediación
-
Aplicar barreras tempranas como fijación de versiones, listas de denegación y escaneo de secretos para bloquear riesgos conocidos
-
Normalizar, deduplicar y priorizar hallazgos según severidad, explotabilidad y contexto de uso
-
Aplicar controles basados en políticas en PRs para bloquear vulnerabilidades de alto riesgo y automatizar actualizaciones seguras de dependencias
-
Asignar propiedad, exigir disposición para cada hallazgo y gobernar excepciones con exenciones temporales o registros VEX
| Tareas |
Herramientas |
RV.3.1:
Analizar las vulnerabilidades identificadas para determinar sus causas raíz.
RV.3.2:
Analizar las causas raíz a lo largo del tiempo para identificar patrones, como prácticas de codificación segura que no se siguen de manera consistente.
RV.3.3:
Revisar el software para vulnerabilidades similares para erradicar una clase de vulnerabilidades y corregirlas proactivamente en lugar de esperar informes externos.
RV.3.4:
Revisar el proceso SDLC y actualizarlo si corresponde para prevenir (o reducir la probabilidad de) que la causa raíz reaparezca en actualizaciones del software o en nuevo software creado.
|
|
SpotBugs + FindSecBugs
Mantiene un conjunto de reglas de “barrera” para problemas históricos. Proporciona erradicación de patrones a través de módulos.
|
|
Semgrep
Codifica RCAs como reglas (p. ej., prohibir APIs inseguras, aplicar sanitizadores) y ejecuta en PRs. Detecta la clase de error que causó el incidente.
|
|
OpenSSF Scorecard
Monitorea señales de higiene de repositorio (protección de rama, fijación de dependencias, fuzzing, etc.) e incorpora mejoras en el SDLC. Controles preventivos alineados a temas de causas raíz.
|
|
Codeql
Consulta bases de código para rastrear el origen de vulnerabilidades (p. ej., encontrar todos los puntos de inyección).
|
|
SonarQube Community
Identifica violaciones de reglas de calidad/seguridad del código que pueden indicar problemas sistémicos de codificación.
|
|
DefectDojo
Agrega resultados de escáneres para que los patrones en tipos de vulnerabilidad sean más fáciles de detectar.
|
|
Dependency-Track
Rastrea componentes vulnerables y muestra problemas recurrentes relacionados con dependencias.
|
|
Grype
Escáner de vulnerabilidades para imágenes de contenedores y sistemas de archivos.
|
|
Syft
Correlaciona SBOMs a través de versiones para identificar problemas repetidos de dependencias.
|
|
Bandit (Python)
Escáner de seguridad específico de lenguaje para identificar el mismo fallo en múltiples archivos.
|
|
Brakeman (Rails)
Detecta prácticas de codificación insegura repetidas en aplicaciones Rails.
|
|
pre-commit
Aplica hooks de calidad/seguridad de código antes de los commits.
|
|
Husky
Automatización de hooks Git para proyectos JavaScript/TypeScript para hacer cumplir comprobaciones.
|
|
Checkov
Previene configuraciones incorrectas al integrarse en los flujos de trabajo existentes de los desarrolladores.
|
|
tfsec
Agrega barreras en IaC para prevenir configuraciones inseguras en el momento del commit.
|
|
kics
Detecta vulnerabilidades de seguridad, problemas de cumplimiento y configuraciones incorrectas de infraestructura.
|
2 - Fase 2: Compilar y Desplegar
Cumplimiento de seguridad en las fases de compilación y despliegue
Fase 2 - Compilar y Desplegar
A medida que el software avanza desde el desarrollo hasta producción, las etapas de compilación y despliegue juegan un papel crucial en mantener la integridad, seguridad y procedencia de tu aplicación. La Fase 2 cubre los controles y prácticas de seguridad aplicados durante las etapas de compilación y despliegue del pipeline de CI/CD. Estos controles aseguran que los artefactos de software sean creados, verificados y liberados de manera confiable, repetible y bajo políticas establecidas antes de llegar a los entornos de ejecución. La Fase 2 se enfoca en prevenir que artefactos comprometidos o no conformes sean desplegados, estableciendo confianza en la cadena de suministro de software antes de que este llegue a entornos en producción.
Específicamente, la Fase 2 incluye:
– Asegurar los entornos de compilación y los runners de CI para prevenir manipulaciones
– Compilaciones reproducibles y verificables
– Integridad de los artefactos, firma y seguimiento de procedencia
– Análisis de vulnerabilidades y configuraciones durante la compilación
– Aplicación de políticas de seguridad y cumplimiento durante la compilación
– Creación y validación segura de imágenes de contenedores
– Flujos de despliegue controlados con puertas automáticas y aprobaciones
– Registro de metadatos de despliegue necesarios para visibilidad post-despliegue
Actividades clave de seguridad en la Fase 2
El cumplimiento en los pasos de Compilación y Despliegue incluye:
|
|
| Compilaciones Reproducibles y Determinísticas |
Garantizar que los artefactos de software puedan ser verificados y reproducidos de forma independiente para prevenir manipulaciones. |
| Detección Automática de Amenazas y Aplicación de Cumplimiento |
Integrar análisis de seguridad continuo para detectar configuraciones incorrectas, vulnerabilidades y dependencias no autorizadas antes del despliegue. |
| Despliegues con Políticas Enforzadas |
Aplicar políticas de seguridad verificables asegurando que solo software conforme y certificado llegue a producción. |
| Entornos de Ejecución Confiables (TEEs) |
Asegurar los entornos de compilación contra manipulaciones usando entornos de ejecución respaldados por hardware. |
| Atestación Criptográfica |
Utilizar firmas digitales y pruebas criptográficas para verificar la autenticidad e integridad de compilaciones y despliegues. |
A continuación, se presentan las directrices de marcos de referencia de la industria con herramientas open source sugeridas necesarias para lograr los objetivos de cumplimiento.
2.1 - 2.0 Tareas de la Fase 2 del Marco de Desarrollo de Software Seguro
2.0 Marco de Desarrollo de Software Seguro y pasos de CI/CD en Build/Deploy
2.0 Cumpliendo las Tareas de Compilación y Despliegue del Marco de Desarrollo de Software Seguro
Este capítulo se enfoca específicamente en las herramientas y prácticas de DevSecOps relacionadas con las acciones de Compilar y Desplegar en el pipeline de CI/CD para cumplir las tareas definidas por el Marco de Desarrollo de Software Seguro.
El Marco de Desarrollo de Software Seguro, desarrollado por el Instituto Nacional de Estándares y Tecnología (NIST), proporciona un enfoque integral para garantizar la seguridad a lo largo del proceso de desarrollo de software, desde el diseño inicial hasta el despliegue y mantenimiento. El marco describe prácticas y directrices clave que las organizaciones pueden implementar para asegurar su ciclo de vida de desarrollo de software (SDLC), con un énfasis particular en integrar la seguridad en los procesos automatizados.
|
|
| 2.1 Preparar la Organización (PO) |
Las organizaciones deben asegurarse de que su personal, procesos y tecnología estén preparados para realizar desarrollo de software seguro a nivel organizacional. Muchas organizaciones encontrarán que algunas prácticas de PO también son aplicables a subconjuntos de su desarrollo de software, como grupos de desarrollo individuales o proyectos específicos. |
| 2.2 Proteger el Software (PS) |
Las organizaciones deben proteger todos los componentes de su software contra manipulaciones y accesos no autorizados. |
| 2.3 Producir Software Bien Asegurado (PW) |
Las organizaciones deben producir software seguro con vulnerabilidades mínimas en sus versiones. |
| 2.4 Responder a Vulnerabilidades (RV) |
Las organizaciones deben identificar vulnerabilidades residuales en sus versiones de software y responder adecuadamente para abordarlas y prevenir que ocurran vulnerabilidades similares en el futuro. |
2.1.1 - 2.1 Preparar la Organización (PO)
2.1 Preparar la Organización (PO) para los pasos de CI/CD de Build y Deploy
2.1 Preparar la Organización (PO) - Tareas de Build y Deploy
Las organizaciones deben asegurarse de que su personal, procesos y tecnología estén preparados para realizar desarrollo de software seguro a nivel organizacional. Muchas organizaciones encontrarán que algunas prácticas de PO también son aplicables a subconjuntos de su desarrollo de software, como grupos de desarrollo individuales o proyectos.
PO.1
Definir Requisitos de Seguridad para el Desarrollo de Software: Asegurar que los requisitos de seguridad para el desarrollo de software sean conocidos en todo momento, de manera que puedan ser considerados a lo largo del SDLC y se minimice la duplicación de esfuerzos, ya que la información de los requisitos puede recopilarse una sola vez y compartirse. Esto incluye requisitos de fuentes internas (por ejemplo, las políticas de la organización, objetivos de negocio y estrategia de gestión de riesgos) y fuentes externas (por ejemplo, leyes y regulaciones aplicables).
Para cumplir con SSDF PO.1 en un contexto de Build y Deploy usando herramientas de código abierto, el enfoque se desplaza de solo definir a:
-
Aplicar políticas de seguridad sobre dependencias, código y configuraciones.
-
Verificar el cumplimiento con las bases de seguridad establecidas antes del despliegue.
-
Asegurar que los artefactos cumplan con los requisitos de seguridad del DoD, NIST u organizacionales.
| Tareas |
Herramientas |
PO.1.1:
Identificar y documentar todos los requisitos de seguridad para las infraestructuras y procesos de desarrollo de software de la organización, y mantener dichos requisitos a lo largo del tiempo.
PO.1.2:
Identificar y documentar todos los requisitos de seguridad que el software desarrollado por la organización debe cumplir, y mantener dichos requisitos a lo largo del tiempo.
|
|
Open Policy Agent
Motor de políticas de propósito general usando Rego para aplicar políticas en servicios, CI/CD e infraestructura.
|
|
Conftest
Usa el lenguaje Rego de OPA para probar manifests de Kubernetes, Terraform y Dockerfiles contra requisitos de seguridad predefinidos.
|
|
InSpec
Prueba infraestructuras y aplicaciones desplegadas contra frameworks de cumplimiento (por ejemplo, CIS Benchmarks, NIST 800-53).
|
|
Kyverno
Motor de políticas nativo de Kubernetes para aplicar configuraciones seguras en el momento del despliegue.
|
|
Checkov
Escanea Infraestructura como Código (IaC) durante la compilación para asegurar el cumplimiento de los requisitos de seguridad antes del despliegue.
|
|
Trivy
Escanea imágenes de contenedores, IaC y SBOMs para vulnerabilidades y configuraciones incorrectas antes del despliegue.
|
|
Clair
Análisis estático de imágenes de contenedores para asegurar que cumplan con los requisitos de seguridad antes de enviarlas al registro.
|
|
Grype
Escaneo de vulnerabilidades en imágenes de contenedores y sistemas de archivos para validar artefactos contra políticas antes del despliegue.
|
|
Sigstore Cosign
Firmar y verificar imágenes de contenedores y otros artefactos de compilación para asegurar su integridad y procedencia.
|
|
Conforma
Verifica de forma segura artefactos de la cadena de suministro y aplica políticas sobre cómo fueron construidos y probados. Construido con Sigstore y Open Policy Agent, puede verificar el cumplimiento de procedencia SLSA con políticas extensibles.
|
PO.2
Implementar Roles y Responsabilidades: Asegurar que todas las personas, dentro y fuera de la organización, involucradas en el SDLC estén preparadas para desempeñar sus roles y responsabilidades relacionadas con el SDLC durante todo el ciclo de vida del desarrollo de software.
Para cumplir con SSDF PO.2 en un contexto de Build y Deploy usando herramientas de código abierto, el enfoque se traslada a:
-
Aplicar control de acceso basado en roles (RBAC) para limitar quién puede iniciar compilaciones, aprobar cambios y desplegar.
-
Proporcionar registros de auditoría y trazabilidad de las acciones para garantizar responsabilidad.
-
Asegurar que los cambios de código y despliegues sean revisados por personal autorizado.
| Tareas |
Herramientas |
PO.2.1:
Crear nuevos roles y modificar responsabilidades de los roles existentes según sea necesario para abarcar todas las partes del SDLC. Revisar y mantener periódicamente los roles y responsabilidades definidos, actualizándolos según se requiera.
PO.2.2:
Proporcionar formación basada en roles para todo el personal con responsabilidades que contribuyan al desarrollo seguro. Revisar periódicamente la competencia del personal y la formación basada en roles, y actualizar la formación según sea necesario.
PO.2.3:
Obtener el compromiso de la alta dirección o del funcionario autorizado con el desarrollo seguro y comunicar ese compromiso a todos los involucrados en roles y responsabilidades relacionadas con el desarrollo.
|
|
Keycloak
Gestión de identidad y acceso de código abierto para aplicar RBAC en pipelines de CI/CD y herramientas de despliegue.
|
|
Dex
Proveedor federado de OpenID Connect para integrar identidades de desarrolladores en sistemas de build y deploy con control de acceso basado en roles.
|
|
Vault by HashiCorp
Gestiona y controla de manera segura el acceso a secretos según roles definidos durante builds y despliegues.
|
|
Argo CD
Herramienta de despliegue GitOps con RBAC para controlar quién puede sincronizar, aprobar o revertir despliegues.
|
|
Jenkins with Role Strategy Plugin
Agrega RBAC detallado a pipelines de Jenkins, limitando acciones de build y deploy a roles autorizados.
|
|
Tekton Pipelines
CI/CD nativo de Kubernetes con RBAC de Kubernetes para controlar permisos de ejecución de pipelines.
|
|
Flux CD
Herramienta GitOps que aplica RBAC para workflows de despliegue y requiere aprobaciones para cambios.
|
|
Kubernetes RBAC
Control de acceso incorporado para restringir quién puede desplegar, modificar o eliminar cargas de trabajo.
|
|
Gitea
Servicio Git autoalojado con roles de usuario y permisos de repositorio para aplicar flujos de trabajo de aprobación y revisión.
|
|
Auditbeat
Proporciona registro de auditoría para acciones de build y deploy, ayudando a rastrear el cumplimiento de las responsabilidades asignadas.
|
PO.3
Implementar Cadenas de Herramientas de Soporte: Utilizar automatización para reducir el esfuerzo humano y mejorar la precisión, reproducibilidad, usabilidad y exhaustividad de las prácticas de seguridad a lo largo del SDLC, así como proporcionar una forma de documentar y demostrar el uso de estas prácticas. Las cadenas de herramientas y herramientas pueden utilizarse en diferentes niveles de la organización, como a nivel organizacional o específico de proyecto, y pueden abordar una parte particular del SDLC, como un pipeline de build.
Para cumplir con SSDF PO.3 en un contexto de Build y Deploy usando herramientas de código abierto, el enfoque se centra en:
-
Asegurar que las herramientas de build y despliegue estén configuradas de forma segura y se mantengan actualizadas.
-
Proteger contra ataques a la cadena de suministro que apunten al pipeline de CI/CD.
-
Verificar la integridad de herramientas y artefactos antes de su uso.
-
Controlar y monitorear el acceso a las cadenas de herramientas.
| Tareas |
Herramientas |
PO.3.1:
Especificar qué herramientas o tipos de herramientas deben o deberían incluirse en cada cadena de herramientas para mitigar los riesgos identificados, así como cómo se deben integrar entre sí los componentes de la cadena de herramientas.
PO.3.2:
Seguir las prácticas de seguridad recomendadas para desplegar, operar y mantener herramientas y cadenas de herramientas.
PO.3.3:
Configurar las herramientas para generar artefactos que respalden las prácticas de desarrollo de software seguro definidas por la organización.
|
|
Sigstore Cosign
Firma y verifica artefactos de build para evitar el despliegue de software manipulado.
|
|
Marco SLSA + slsa-verifier
Garantiza la procedencia del build y verifica la integridad de los artefactos antes del despliegue.
|
|
Gitleaks
Escanea repositorios y pipelines de build en busca de secretos antes de la ejecución del build.
|
|
Argo CD
Herramienta de despliegue GitOps con RBAC para controlar quién puede sincronizar, aprobar o revertir despliegues.
|
|
Trivy
Escanea contenedores de herramientas CI/CD y sus dependencias en busca de vulnerabilidades.
|
|
Syft
Genera SBOMs de artefactos de build para rastrear los componentes usados en la cadena de herramientas.
|
|
Builds herméticos con Konflux-ci
Builds con dependencias fijadas y predescargadas en entornos aislados para habilitar builds reproducibles y verificables.
|
|
Hermeto
Pre-descarga dependencias para builds herméticos, genera SBOMs y asegura builds de contenedores aislados de red con checksums verificables.
|
|
Clair
Analiza imágenes de contenedores usados en builds/despliegues para detectar vulnerabilidades.
|
|
Vault de HashiCorp
Protege secretos usados por herramientas de build/despliegue, asegurando que no se expongan en los pipelines.
|
|
Open Policy Agent (OPA)
Aplica políticas como código en workflows de CI/CD y despliegue usando Rego para prevenir acciones inseguras.
|
|
Fábrica de software Konflux-ci para Tekton
Implementa el framework In-toto usando pipelines como código.
|
|
Auditbeat
Monitorea y registra la actividad de la cadena de herramientas CI/CD para garantizar integridad y cumplimiento.
|
PO.4
Define and Use Criteria for Software Security Checks: Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.
Para cumplir con SSDF PO.4 en un contexto de Build y Deploy usando herramientas de código abierto, el enfoque se centra en:
-
Aplicar prácticas consistentes de pruebas y validación de seguridad antes del lanzamiento.
-
Automatizar las verificaciones de seguridad en los pipelines de CI/CD.
-
Utilizar procesos estandarizados para verificar, firmar y rastrear artefactos.
-
Integrar controles de seguridad para que ningún artefacto inseguro sea desplegado.
| Tareas |
Herramientas |
PO.4.1:
Definir criterios para las verificaciones de seguridad del software y hacer seguimiento a lo largo del SDLC.
PO.4.2:
Implementar procesos, mecanismos, etc., para recopilar y proteger la información necesaria en apoyo de los criterios.
|
|
OWASP Dependency-Check
Automatiza el escaneo de dependencias de código abierto en los builds para aplicar una detección consistente de vulnerabilidades.
|
|
Semgrep
Análisis estático integrado en los builds para asegurar verificaciones consistentes de seguridad del código antes del despliegue.
|
|
Bandit (para Python)
Linter de seguridad para Python en pipelines de build para mantener verificaciones consistentes por lenguaje.
|
|
Trivy
Escaneo consistente de vulnerabilidades e IaC antes del despliegue.
|
|
Grype
Mantiene escaneos de vulnerabilidades consistentes para todos los artefactos de build.
|
|
InSpec
Automatiza verificaciones de cumplimiento antes del despliegue para asegurar que las prácticas coincidan con los estándares organizacionales.
|
|
Sigstore Cosign
Estandariza la firma y verificación de artefactos para que solo builds confiables sean desplegados.
|
|
Open Policy Agent (OPA)
Aplica políticas de despliegue a nivel organizacional en todos los entornos.
|
|
DefectDojo
Centraliza y estandariza el seguimiento de vulnerabilidades y flujos de remediación en todos los builds.
|
PO.5
Implementar y Mantener Entornos Seguros para el Desarrollo de Software: Asegúrese de que todos los componentes de los entornos de desarrollo de software estén fuertemente protegidos contra amenazas internas y externas, para evitar compromisos de los entornos o del software que se desarrolla o mantiene en ellos. Ejemplos de entornos de desarrollo incluyen entornos de desarrollo, build, prueba y distribución.
Para cumplir con SSDF PO.5 en un contexto de Build y Deploy usando herramientas de código abierto, el enfoque se centra en:
Proteger la infraestructura de CI/CD contra amenazas internas y externas.
Endurecer servidores de build, registros de contenedores y sistemas de despliegue.
Asegurar que los entornos de build y despliegue estén parchados, monitoreados y con control de acceso.
Prevenir código malicioso o manipulación en la cadena de suministro de software.
| Tareas |
Herramientas |
PO.5.1:
Separar y proteger cada entorno involucrado en el desarrollo de software.
PO.5.2:
Asegurar y reforzar los endpoints de desarrollo (i.e., endpoints para diseñadores de software, desarrolladores, testers, builders, etc.) para realizar tareas de desarrollo utilizando un enfoque basado en riesgos.
|
|
Jenkins Configuration as Code + Role Strategy Plugin
Protege los servidores de build de Jenkins con configuraciones codificadas y RBAC para limitar el acceso a trabajos críticos de build.
|
|
Tekton Pipelines
Framework CI/CD nativo de Kubernetes con control de acceso basado en roles (RBAC).
|
|
Argo CD
Despliegue GitOps con RBAC y verificación de commits firmados para despliegues a producción.
|
|
Vault by HashiCorp
Protege secretos en entornos de build y despliegue, previniendo fugas en los pipelines.
|
|
Sigstore Cosign
Firma artefactos de build y los verifica antes del despliegue para asegurar que no fueron manipulados.
|
|
In-toto
Proporciona seguridad de extremo a extremo en la cadena de suministro de software, asegurando que cada paso del build/despliegue esté firmado y verificado.
|
|
InSpec
Ejecuta escaneos de cumplimiento continuo en servidores de desarrollo y build; aplica benchmarks CIS/NIST.
|
|
SLSA + slsa-verifier
Verifica la procedencia del build, asegurando que los artefactos provienen de un entorno de build confiable y no comprometido.
|
|
Trivy
Escanea contenedores e infraestructura de build/despliegue en busca de vulnerabilidades y configuraciones incorrectas.
|
|
Falco
Seguridad en tiempo de ejecución para entornos de build y despliegue, detectando comportamientos maliciosos o actividad no autorizada.
|
|
Auditbeat
Monitorea servidores de build y despliegue para cambios en la integridad de archivos, accesos no autorizados y eventos de seguridad.
|
|
Kyverno
Aplica políticas de seguridad de Kubernetes en los entornos de despliegue (ej., no permitir pods privilegiados).
|
2.1.2 - 2.2 Proteger el Software (PS)
2.2 Proteger el Software (PS) para pasos de Build y Deploy CI/CD
2.2 Proteger el Software (PS) en Tareas de Build y Deploy
Proteger el Software (PS): Las organizaciones deben proteger todos los componentes de su software contra manipulaciones y accesos no autorizados.
PS.1
Proteger Todas las Formas de Código de Accesos y Manipulaciones No Autorizadas: Ayuda a prevenir cambios no autorizados en el código, tanto inadvertidos como intencionales, que podrían eludir o anular las características de seguridad previstas del software. Para el código que no está destinado a ser accesible públicamente, esto ayuda a prevenir el robo del software y puede dificultar o retrasar que los atacantes encuentren vulnerabilidades en el software.
Para cumplir con SSDF PS.1 en un contexto de build y deploy usando herramientas de código abierto, el enfoque se desplaza de solo definir a:
-
Asegurar la propia pipeline CI/CD: garantizar que solo procesos confiables y autenticados puedan producir outputs de build.
-
Proteger los inputs de código fuente y dependencias, bloquear versiones, usar checksums y prevenir la inyección de código malicioso en el proceso de build.
-
Firmar artefactos y registrar su procedencia, generando metadatos criptográficamente verificables que prueben qué se construyó, desde qué fuente y por quién.
-
Aplicar builds reproducibles para que cualquier manipulación genere una discrepancia en hash/firma.
-
Restringir el acceso al sistema de build y aplicar permisos basados en roles, MFA y principio de menor privilegio para los servidores de build.
| Tareas |
Herramientas |
PS.1.1:
Almacenar todas las formas de código, incluyendo código fuente, código ejecutable y configuración-como-código, basándose en el principio de menor privilegio para que solo el personal, herramientas, servicios, etc., autorizados tengan acceso.
|
|
cosign Sigstore
Firmar los resultados de construcción (binarios, contenedores, SBOMs) y crear atestaciones; verificar en CI antes de la promoción.
|
|
Git commits/tags firmados
Requerir commits/tags firmados y rechazar los no firmados en CI para evitar que código no autorizado entre en las construcciones.
|
|
Sigstore Fulcio + Rekor
Emitir certificados de corta duración (Fulcio) y registrar firmas/atestaciones en un registro de transparencia (Rekor) para detectar/seguir manipulaciones.
|
|
Procedencia SLSA (generadores + verificador)
Emitir y firmar la procedencia de la construcción; verificar quién/qué/dónde se construyó el artefacto antes de enviarlo.
|
|
In-toto
Definir un diseño de cadena de suministro y verificar los materiales/productos de cada paso para asegurar que nada fue manipulado a lo largo de la canalización.
|
|
Tekton Chains
Firmar automáticamente los resultados de tareas (imágenes, archivos) en pipelines de Tekton y almacenar atestaciones (por ejemplo, en Rekor).
|
|
Notation (CNCF Notary v2)
Firmar artefactos OCI (imágenes, Helm charts) durante la construcción para verificación posterior en registros y clusters.
|
|
Nix
Bloquear insumos y hacer las construcciones determinísticas para que los cambios no autorizados sean detectables mediante discrepancia de hash/procedencia.
|
|
Bazel
Bloquear insumos y hacer las construcciones determinísticas para que los cambios no autorizados sean detectables mediante discrepancia de hash/procedencia.
|
|
Grafeas
Persistir firmas, SBOMs y metadatos de políticas para auditar la integridad de las construcciones a través de los servicios.
|
|
Harbor
Aplicar confianza de contenido, cuentas de robots y políticas sobre quién puede subir/descargar; requerir artefactos firmados antes de la liberación.
|
|
Sigstore Policy Controller
Controlador de admisión que bloquea imágenes no firmadas o firmadas incorrectamente; aplica políticas de clave/issuer/sujeto.
|
|
Kyverno
Políticas de Kubernetes que requieren firmas de imágenes, fijan por digest y prohíben etiquetas mutables en despliegues.
|
|
OPA Gatekeeper
Control de admisión para despliegues con políticas personalizadas (por ejemplo, “solo imágenes firmadas de registros/namespaces aprobados”).
|
|
Ratify
Verifica firmas/atestaciones OCI (Cosign/Notation) en tiempo de admisión y bloquea todo lo que falle la verificación.
|
|
Connaisseur
Controlador de admisión de Kubernetes dedicado a verificar las firmas de imágenes de contenedores antes de su programación.
|
|
Sigstore Cosign
Verificar firmas/atestaciones como puerta de liberación en su pipeline de CD antes de aplicar los manifests.
|
PS.2
Proporcionar un Mecanismo para Verificar la Integridad del Software: Ayuda a los adquirentes de software a asegurarse de que el software que reciben es legítimo y no ha sido manipulado. Hacer que la información de verificación de integridad esté disponible para los adquirentes de software.
Para cumplir con SSDF PS.2 en un contexto de build y deploy usando herramientas open-source, el enfoque se centra en:
-
Generar artefactos de integridad para cada release
-
Vincular artefactos con el código fuente versionado
-
Publicar materiales de verificación
-
Requerir chequeos de integridad como puerta de release
-
Exponer datos de verificación a los consumidores
-
Control de admisión basado en integridad
| Tasks |
Tools |
PS.2.1:
Poner la información de verificación de integridad del software a disposición de los adquirentes de software.
|
|
Cosign Sigstore
Firmar binarios, imágenes de contenedores, SBOMs y atestaciones durante la construcción; soporta firmas sin clave.
|
|
Git signed commits/tags
Firmar etiquetas de liberación para vincular criptográficamente el código fuente con el artefacto construido.
|
|
Sigstore Fulcio + Rekor
Fulcio emite certificados de firma efímeros; Rekor registra todas las firmas en un registro de transparencia a prueba de manipulaciones para verificación posterior.
|
|
SLSA provenance (generators + verifier)
Genera automáticamente metadatos de procedencia describiendo el origen, insumos y proceso de construcción. Valida los archivos de procedencia para asegurar la integridad del artefacto antes de su distribución.
|
|
In-toto
Define un diseño verificable de la cadena de suministro de software; crea metadatos de enlace que prueban cada paso de la construcción.
|
|
Grafeas
Almacena metadatos (firmas, checksums, SBOMs) para que puedan ser consultados para verificación.
|
|
GNU Coreutils / sha256sum
Crear y publicar checksums de artefactos de liberación para que los receptores puedan verificar manual o automáticamente la integridad.
|
|
Harbor
Aplicar confianza de contenido; asegurar que solo se almacenen y distribuyan imágenes firmadas, con políticas sobre quién puede subir/descargar; requerir artefactos firmados antes de la liberación.
|
|
Sigstore Policy Controller
Controlador de admisión de Kubernetes que aplica políticas de firma/procedencia antes del despliegue. Bloquea imágenes no firmadas o firmadas incorrectamente; aplica políticas de clave/issuer/sujeto.
|
|
Kyverno
Políticas de Kubernetes que requieren firmas de imágenes, fijan por digest y prohíben etiquetas mutables en despliegues. Valida firmas y digests de imágenes de contenedor antes de desplegarlas.
|
|
OPA Gatekeeper
Control de admisión personalizado para aplicar integridad de artefactos y políticas de firmantes confiables.
|
|
Ratify
Framework de verificación plugable para registros/imágenes OCI; funciona con Cosign, Notation, in-toto.
|
|
Connaisseur
Controlador de admisión de Kubernetes dedicado a la verificación de firmas y políticas de confianza de imágenes.
|
|
Notation
Firma artefactos OCI (contenedores, Helm charts) y los verifica antes de instalar o desplegar.
|
|
Sigstore Cosign
Se usa en pipelines de CD o hooks de admisión para verificar que firmas y atestaciones coincidan con claves/políticas confiables antes de la promoción.
|
PS.3
Archivar y Proteger Cada Versión de Software: Conservar las versiones de software para ayudar a identificar, analizar y eliminar vulnerabilidades descubiertas después de su liberación.
Para cumplir con SSDF PS.3 en un contexto de construcción y despliegue usando herramientas de código abierto, el enfoque se centra en:
-
Construcción: El énfasis está en capturar, almacenar y asegurar cada versión oficial (código fuente, binarios, SBOM, firmas, procedencia) en un almacenamiento inmutable y versionado.
-
Despliegue: El énfasis está en asegurar que solo se utilicen en producción aquellas versiones archivadas y protegidas, aplicando inmutabilidad, fijación por digest y verificación de firmas/procedencia como mecanismos de cumplimiento.
| Tareas |
Herramientas |
PS.3.1:
Archivar de manera segura los archivos necesarios y los datos de soporte (por ejemplo, información de verificación de integridad, datos de procedencia) que se deben conservar para cada liberación de software.
PS.3.2:
Recopilar, proteger, mantener y compartir los datos de procedencia de todos los componentes de cada liberación de software (por ejemplo, en una lista de materiales de software [SBOM]).
|
|
Git (Etiquetado de Liberación)
Crear etiquetas firmadas e inmutables para cada liberación; preserva el snapshot del código fuente para auditoría.
|
|
Git LFS
Almacenar artefactos binarios grandes junto con el código fuente, asegurando la integridad.
|
|
Nexus Repository OSS
Hospedar y versionar artefactos de liberación (JARs, binarios, contenedores) con control de acceso basado en roles y validación de checksums.
|
|
JFrog Artifactory OSS
Archivar resultados de construcción en un repositorio controlado y versionado; soporta checksums y políticas de retención.
|
|
Harbor
Almacenar imágenes de contenedores con escaneo de vulnerabilidades, RBAC y confianza de contenido firmado para preservar la integridad de la liberación. Aplicar etiquetas inmutables y evitar sobrescrituras para que los artefactos desplegados siempre se puedan rastrear hasta la copia archivada.
|
|
OSS Review Toolkit
(ORT) Archivar SBOMs, archivos de licencia y reportes de vulnerabilidades junto con la liberación para cumplimiento y auditoría.
|
|
Sigstore Cosign
Firmar artefactos de liberación antes de archivarlos para que la integridad pueda ser verificada posteriormente.
|
|
Kyverno
Aplicar imágenes con digest fijo para asegurar que los despliegues siempre coincidan con las versiones archivadas.
|
|
OPA Gatekeeper
Aplicación de políticas para garantizar que solo se desplieguen artefactos archivados y aprobados.
|
|
Ratify
Verifica firmas y atestaciones de artefactos contra los metadatos de liberaciones archivadas antes del despliegue.
|
|
Connaisseur
Controlador de admisión que asegura que solo se desplieguen imágenes firmadas del conjunto archivado.
|
|
Backblaze B2 / Rclone (Integración OSS)
Archivado a largo plazo de versiones de artefactos desplegados para recuperación o investigación.
|
|
SLSA Provenance + Rekor
Conservar la procedencia de construcción en un registro de transparencia para que las liberaciones desplegadas puedan ser verificadas cruzadamente con los originales archivados.
|
|
rebuilderd
rebuilderd verifica de manera independiente que los paquetes binarios puedan reproducirse desde el código fuente, lo que es un mecanismo sólido para la integridad de componentes de terceros y para preservar/verificar la evidencia de integridad de la liberación.
|
|
TestifySec
El enfoque de TestifySec es la verificación de evidencia, atestaciones y políticas en torno a las construcciones; su herramienta Witness se usa para crear y verificar atestaciones y aplicar políticas, es decir, generación de procedencia + verificación de políticas.
|
2.1.3 - 2.3 Producir Software Bien Asegurado (PW)
2.3 Producir Software Bien Asegurado (PW) en los pasos de Build y Deploy de CI/CD
2.3 Producir Software Bien Asegurado (PW) para las Tareas de Build y Deploy
Las organizaciones deben producir software bien asegurado con mínimas vulnerabilidades de seguridad en sus versiones.
PW.1
Diseñar Software para Cumplir Requisitos de Seguridad y Mitigar Riesgos de Seguridad: Identificar y evaluar los requisitos de seguridad del software; determinar qué riesgos de seguridad es probable que enfrente el software durante su operación y cómo el diseño y la arquitectura del software deberían mitigar esos riesgos; y justificar cualquier caso en el que el análisis basado en riesgos indique que los requisitos de seguridad deberían relajarse o omitirse. Abordar los requisitos y riesgos de seguridad durante el diseño del software (seguro por diseño) es clave para mejorar la seguridad del software y también contribuye a aumentar la eficiencia del desarrollo.
Para cumplir con SSDF PW.1 en un contexto de construcción y despliegue usando herramientas de código abierto, el enfoque se centra en:
-
Incrustar controles de seguridad directamente en el proceso de construcción
-
Validar que los resultados de la construcción (binarios, contenedores, paquetes) estén reforzados y libres de debilidades conocidas a nivel de diseño
-
Preservar la trazabilidad desde los requisitos de diseño hasta los artefactos desplegados
| Tareas |
Herramientas |
PW.1.1:
Usar formas de modelado de riesgos, como modelado de amenazas, modelado de ataques o mapeo de superficie de ataque para ayudar a evaluar el riesgo de seguridad del software.
PW.1.2:Rastrear y mantener los requisitos de seguridad, riesgos y decisiones de diseño del software.
PW.1.3:
Cuando sea apropiado, integrar soporte para el uso de funciones y servicios de seguridad estandarizados (por ejemplo, permitir que el software se integre con sistemas existentes de gestión de registros, gestión de identidades, control de acceso y gestión de vulnerabilidades) en lugar de crear implementaciones propietarias de funciones y servicios de seguridad.
|
|
Semgrep
Evita que código inseguro sea empaquetado y desplegado.
|
|
Trivy
Asegura que los artefactos desplegados cumplan con configuraciones base seguras.
|
|
Zap (Zed Attack Proxy)
Aplica listas de componentes aprobados y configuraciones base de seguridad antes del despliegue.
|
|
Syft
Genera SBOMs para aplicaciones desplegadas para monitoreo continuo.
|
|
OWASP Dependency-Track
Aplica listas de componentes aprobados y configuraciones base de seguridad antes del despliegue.
|
|
Grype
Escaneo de vulnerabilidades enfocado en artefactos desplegados.
|
|
Nix
Garantiza que los artefactos de construcción coincidan exactamente con el diseño aprobado de seguridad, sin desviaciones ni diferencias ambientales.
|
|
GNU Guix
Asegura que todos los artefactos desplegados se construyan desde un entorno trazable y verificable que cumpla con las bases de seguridad del diseño.
|
|
Bazel
Aplica reglas de construcción seguras, evita cambios no autorizados y produce resultados idénticos en todos los agentes de construcción.
|
|
Reproducible Builds Framework
Fortalece la seguridad de la cadena de suministro al detectar modificaciones no autorizadas entre el código fuente y el despliegue.
|
|
Apko (Chainguard)
Implementa principios de diseño seguro como superficie de ataque mínima y selección verificada de dependencias.
|
|
Sigstore(Cosign,Fulcio, Rekor)
Asegura que los artefactos provengan de un proceso de construcción confiable y verificado y que no hayan sido alterados.
|
|
Notary
Proporciona garantía criptográfica de que los artefactos desplegados son auténticos y no han sido manipulados.
|
|
In-Toto
Aplica integridad y responsabilidad en toda la canalización de construcción y despliegue.
|
|
The Update Framework (TUF)
Protege la integridad de los canales de despliegue y distribución de actualizaciones.
|
|
OpenSSL
Genera y gestiona claves para firmar artefactos de construcción. Implementa TLS/SSL para comunicación segura entre agentes de construcción y repositorios de artefactos.
|
|
GnuPG
Firma el código fuente, commits y resultados de construcción y verifica las firmas antes de desplegar artefactos.
|
|
Bouncy Castle
Incorpora firma y verificación criptográfica en pipelines de construcción Java/.NET.
|
|
Keylime
Valida que los entornos de despliegue cumplan los requisitos de integridad basados en hardware antes del despliegue.
|
|
Ethereum Attestation Service (EAS)
Publica atestaciones criptográficas de procedencia de construcción o aprobaciones de despliegue y proporciona un registro de auditoría descentralizado e inalterable de los datos de confianza de los artefactos.
|
|
Kyverno
Aplica políticas de diseño de despliegue seguro (por ejemplo, imágenes base aprobadas, configuraciones no permitidas).
|
|
OPA
Aplica los requisitos de diseño de seguridad en tiempo de construcción (por ejemplo, aprobación de dependencias, umbrales de CVE). Aplica políticas consistentes desde la construcción hasta el tiempo de ejecución.
|
|
SPIFFE/SPIRE
Asegura que las cargas de trabajo desplegadas cumplan con los requisitos de seguridad para autenticación mutua y confianza cero, y vincula la identidad de la carga de trabajo con la procedencia en tiempo de construcción para garantizar la integridad del despliegue.
|
|
Hermeto
Pre-descarga dependencias para construcciones herméticas, genera SBOMs y asegura construcciones reproducibles con seguimiento explícito de dependencias y checksums verificables.
|
|
OWASP Threat Dragon
Incorpora modelos de amenazas en CI/CD, asegurando que los requisitos de seguridad estén vinculados a los componentes arquitectónicos antes de la construcción. (Cumple PW.1.1 y PW.1.2)
|
|
OWASP Amass
Ayuda a refinar los requisitos de seguridad relacionados con la exposición de la red y el inventario de activos. (Cumple PW.1.1)
|
|
CAIRIS
Integra los requisitos de seguridad en los modelos del sistema, que luego pueden ser validados en la construcción y despliegue. (Cumple PW.1.1)
|
|
Threagile
Incorpora modelos de amenazas en CI/CD, asegurando que los requisitos de seguridad estén vinculados a los componentes arquitectónicos antes de la construcción. (Cumple PW.1.1)
|
|
Open-Needs
Herramienta de gestión de requisitos para definir, rastrear y validar requisitos de seguridad. Documenta los requisitos de seguridad y los vincula a commits y resultados de construcción. (Cumple PW.1.1 y PW.1.2)
|
|
rmtoo
Herramienta de gestión de requisitos usando texto plano y control de versiones para trazabilidad. Soporta trazabilidad desde el diseño hasta la construcción, asegurando que los requisitos se reflejen en los artefactos finales. (Cumple PW.1.2)
|
|
OpenRMF® OSS
Herramienta de marco de trabajo de cumplimiento y gestión de riesgos de código abierto para rastrear controles RMF (NIST 800-37). Los requisitos de seguridad se mapean a controles de cumplimiento formales que pueden verificarse en artefactos de construcción y despliegue. (Cumple PW.1.2)
|
PW.2
Revisar el Diseño del Software para Verificar Cumplimiento con los Requisitos de Seguridad y la Información de Riesgos: Ayuda a garantizar que el software cumpla con los requisitos de seguridad y aborde satisfactoriamente la información de riesgos identificada.
Para satisfacer SSDF PW.2 en un contexto de construcción y despliegue usando herramientas de código abierto, se enfoca en:
-
Validar las decisiones de arquitectura de seguridad antes del despliegue
-
Revisar las configuraciones de IaC y CI/CD para asegurar que cumplan con las bases de seguridad
-
Aplicar automáticamente reglas de diseño en los pipelines de construcción
-
Detectar configuraciones incorrectas y brechas de seguridad antes del lanzamiento
| Tareas |
Herramientas |
PW.2.1:
Contar con (1) una persona calificada (o personas) que no haya participado en el diseño y/o (2) procesos automatizados en la cadena de herramientas que revisen el diseño del software para confirmar y asegurar que cumple con todos los requisitos de seguridad y aborda satisfactoriamente la información de riesgos identificada.
|
|
OPA
Control automatizado de cumplimiento de diseño en CI/CD
|
|
Kyverno
Valida que las configuraciones de despliegue coincidan con la arquitectura de seguridad aprobada.
|
|
Checkov
Aplica reglas de segmentación de red, requisitos de cifrado y configuraciones seguras por defecto.
|
|
KICS (Keeping Infrastructure as Code Secure)
Agrega automatización de revisión de IaC al proceso de construcción.
|
|
Semgrep
Revisión automatizada de código para asegurar alineación con los requisitos de diseño de seguridad.
|
|
Trivy (Escaneo de Configuración)
Verificación de cumplimiento de configuraciones antes del despliegue.
|
|
ThreatSpec
Garantiza que los requisitos de diseño impulsados por el modelo de amenazas estén implementados.
|
|
Cartography
Verificación de arquitectura post-construcción/pre-despliegue. Detecta desviaciones respecto a la arquitectura prevista.
|
|
kube-score
Revisa los manifiestos de Kubernetes para cumplimiento de diseño antes del despliegue. Asegura que la configuración de seguridad de los pods coincida con los diseños aprobados.
|
|
Dependabot
PRs automatizados de actualización de dependencias con alertas de vulnerabilidades. Ayuda a verificar que las dependencias cumplan los requisitos de seguridad (p. ej., sin CVEs conocidos, versiones mínimas).
|
|
OpenRMF
Herramienta de seguimiento del Marco de Gestión de Riesgos. Puede mapear los requisitos de seguridad a nivel de diseño a controles NIST 800-53 y verificar que dichos controles estén implementados en las configuraciones de construcción.
|
|
ESLint
Se ejecuta en pipelines CI/CD o como pre-commit hook para bloquear merges si el código viola las reglas de seguridad o arquitectura aprobadas antes de la construcción.
|
|
Grype
Escáner de vulnerabilidades basado en SBOM para imágenes/sistemas de archivos. Verifica que las dependencias en la construcción cumplan con las bases de seguridad y estén libres de componentes no permitidos.
|
|
Clair
Análisis estático de vulnerabilidades para imágenes de contenedor. Confirma que las imágenes finales cumplan con los requisitos de seguridad de diseño antes del despliegue.
|
|
Terrascan
Escaneo de IaC y aplicación de políticas (basado en OPA). Aplica el diseño de seguridad aprobado en configuraciones de Terraform, Kubernetes, Docker y AWS CloudFormation antes del despliegue.
|
|
Gerrit
Herramienta de flujo de trabajo para revisión y aprobación de código. Garantiza revisión humana contra los requisitos de diseño y seguridad antes de fusionar a las ramas de lanzamiento.
|
PW.4
Reutilizar software existente, bien asegurado, cuando sea factible en lugar de duplicar funcionalidades: Reduce los costos de desarrollo de software, acelera el desarrollo y disminuye la probabilidad de introducir vulnerabilidades de seguridad adicionales al reutilizar módulos y servicios de software que ya han sido verificados en cuanto a su postura de seguridad. Esto es particularmente importante para software que implementa funcionalidades de seguridad, como módulos y protocolos criptográficos.
Nota: PW.3 se movió a PW.4
Para cumplir con SSDF PW.4 en un contexto de build y deploy usando herramientas de código abierto, el enfoque se desplaza a:
-
Incorporar valores predeterminados seguros en el código de la aplicación, contenedores y manifiestos de despliegue
-
Eliminar funciones inseguras, obsoletas o innecesarias de los artefactos de build
-
Aplicar automáticamente configuraciones de seguridad base durante el despliegue
-
Hacer cumplir estándares de hardening antes del lanzamiento
| Tareas |
Herramientas |
PW.4.1:
Adquirir y mantener componentes de software bien asegurados (por ejemplo, bibliotecas de software, módulos, middleware, frameworks) de desarrolladores comerciales, de código abierto y otros terceros para su uso en el software de la organización.
PW.4.2:
Crear y mantener componentes de software bien asegurados internamente siguiendo procesos SDLC para satisfacer necesidades internas de desarrollo de software que no pueden ser mejor atendidas por componentes de software de terceros.
PW.4.4:
Verificar que los componentes de software comerciales, de código abierto y de terceros cumplan con los requisitos definidos por la organización durante todo su ciclo de vida.
|
|
Kyverno
Garantiza que los manifiestos cumplan con los valores predeterminados seguros antes del despliegue.
|
|
OPA
Valida que las configuraciones predeterminadas cumplan con los requisitos de seguridad.
|
|
Checkovn
Detecta y bloquea valores predeterminados inseguros en Terraform, Helm o CloudFormation antes del lanzamiento.
|
|
KICS (Keeping Infrastructure as Code Secure)
Valida los valores predeterminados fortalecidos en la provisión de infraestructura en la nube.
|
|
Trivy
Verificación automatizada de cumplimiento de configuraciones durante CI/CD.
|
|
CIS-CAT Lite
Automatiza pruebas de cumplimiento para valores predeterminados seguros.
|
|
DevSec Hardening Framework
Incorpora valores predeterminados fortalecidos en imágenes de contenedor o VM antes del lanzamiento.
|
|
kube-score
Validación previa al despliegue de valores predeterminados seguros en manifiestos.
|
|
OpenSCAP
Garantiza que las imágenes del sistema operativo desplegadas cumplan con los valores predeterminados fortalecidos.
|
|
CycloneDX
Formato SBOM para documentar componentes/configuraciones exactas en el build final; ayuda a verificar que los valores predeterminados seguros estén presentes.
|
|
SPDX
Estándar SBOM para registrar todos los componentes, licencias y procedencia; puede confirmar la inclusión de dependencias fortalecidas.
|
|
ArtifactHub
Catálogo de Helm charts, operadores OLM, etc., verificados; puede hacer cumplir el uso de paquetes seguros por defecto.
|
|
JFrog Artifactory OSS
Gestor de repositorios para almacenar artefactos firmados y verificados con controles de acceso.
|
|
Sonartype Nexus OSS
Hospeda artefactos y hace cumplir comprobaciones de políticas antes de su promoción.
|
|
Harbor
Registro OCI con escaneo de vulnerabilidades, firma de contenido y aplicación de políticas para imágenes.
|
|
GitLab Signing
Firma de commits/tags en GitLab CE para verificar procedencia.
|
|
GitHub CodeQL
Detecta patrones de código que violan los requisitos de seguridad.
|
|
AquaSec Trivy
Escanea imágenes de contenedores, IaC y configuraciones para valores predeterminados inseguros.
|
|
Allstar
App de GitHub que aplica políticas de seguridad en repositorios.
|
|
OWASP SAMM
Modelo de madurez de seguridad para guiar prácticas de valores predeterminados seguros.
|
|
OWASP ASVS
Requisitos de seguridad de aplicaciones para verificar valores predeterminados seguros.
|
|
OWASP Defectdojo
Rastreo central de vulnerabilidades; garantiza que los problemas encontrados en builds se solucionen antes del lanzamiento.
|
|
OWASP Dependency-Check
Detecta dependencias conocidas vulnerables en los builds.
|
|
Gitea
Servicio Git autohospedado con soporte de firma y políticas.
|
|
GitLab (Community Edition)
Plataforma Git con firma, escaneo e integración de políticas CI/CD.
|
|
Pytest
Pruebas automatizadas para confirmar que los valores predeterminados funcionen.
|
|
Selenium
Automatización de pruebas funcionales/UI para verificar configuraciones seguras.
|
|
Playwright
Automatización de pruebas funcionales/UI para verificar configuraciones seguras.
|
|
OWASP ZAP
Escáner DAST para verificar que los valores predeterminados de la aplicación no sean explotables.
|
|
TestNG
Framework de pruebas Java para comprobaciones de seguridad/funcionales.
|
|
Cucumber
Framework BDD para verificar requisitos funcionales y de seguridad.
|
|
Clair
Escáner de vulnerabilidades de imágenes para registros OCI.
|
|
Grype
Escáner de vulnerabilidades basado en SBOM para builds e imágenes.
|
|
Bandit para Python
Detecta patrones de código y valores predeterminados inseguros en Python.
|
|
Semgrep
Encuentra patrones que violan políticas en el código.
|
|
Brakeman
Detecta problemas de seguridad y valores predeterminados específicos de Rails.
|
|
Gitleaks
Detecta secretos en el código (previene exposición de credenciales predeterminadas).
|
|
TruffleHog
Encuentra secretos en repositorios/historial para evitar valores predeterminados inseguros.
|
|
OWASP Dependency-Check
Detecta dependencias conocidas vulnerables en los builds.
|
|
OSS Review Toolkit (ORT)
Automatiza verificaciones de licencias/seguridad; bloquea componentes no conformes.
|
|
FOSSA (Community Edition)
Escaneo de licencias/dependencias; garantiza cumplimiento con políticas predeterminadas.
|
|
ScanCode Toolkit
Detecta licencias, derechos de autor y metadatos de seguridad en los artefactos.
|
|
Tern
Inspección de imágenes de contenedor para detalles de dependencias/componentes.
|
|
Open Policy Agent (OPA)
Política como código para build & deploy; bloquea valores predeterminados inseguros en configuraciones/manifiestos.
|
|
rebuilderd
rebuilderd verifica de manera independiente que los paquetes binarios puedan reproducirse desde la fuente, lo que es un mecanismo sólido para la integridad/validación de componentes de terceros y para preservar/verificar evidencia de integridad de lanzamientos.
|
PW.5
Crear Código Fuente Siguiendo Prácticas de Codificación Segura: Disminuir el número de vulnerabilidades de seguridad en el software y reducir costos minimizando las vulnerabilidades introducidas durante la creación del código fuente que cumplan o superen los criterios de severidad de vulnerabilidades definidos por la organización.
Para cumplir con SSDF PW.5 en un contexto de construcción y despliegue utilizando herramientas de código abierto, el enfoque se desplaza a:
-
Los artefactos de software se almacenan en repositorios seguros y controlados.
-
Solo se almacenan y despliegan compilaciones aprobadas y verificadas.
-
El acceso a los repositorios está restringido y es auditable.
-
Se aplican verificaciones de procedencia e integridad antes de que los artefactos sean aceptados o desplegados.
| Tareas |
Herramientas |
PW.5.1:
Sigue todas las prácticas de codificación segura que sean apropiadas para los lenguajes de desarrollo y el entorno para cumplir con los requisitos de la organización.
|
|
Artifactory Community Edition
Funciona como el repositorio central de artefactos confiable.
|
|
Nexus Repository OSS
Funciona como el repositorio central de artefactos confiable.
|
|
Harbor
Funciona como el repositorio central de artefactos confiable.
|
|
Sigstore(Cosign,Fulcio, Rekor)
Garantiza que el contenido del repositorio sea auténtico y no haya sido alterado.
|
|
Clair
Asegura que los artefactos almacenados cumplan los requisitos de vulnerabilidad antes del despliegue.
|
|
In-Toto
Aplica verificaciones de procedencia al ingresar artefactos al repositorio.
|
|
The Update Framework (TUF)
Protege contra la manipulación del repositorio y de las actualizaciones.
|
|
Notary (v2)
Controla la entrada en la cadena de suministro y el almacenamiento interno de artefactos.
|
|
Tekton Chains
Relaciona los artefactos del repositorio con pipelines de compilación seguros.
|
|
Semgrep
Se ejecuta como parte de la pipeline CI para escanear automáticamente el código en busca de fallas de seguridad, violaciones de políticas y patrones inseguros antes de construir los artefactos. Soporta reglas como código para aplicar políticas de compilación segura.
|
|
Bandit para Python
Analizador estático enfocado en Python que revisa funciones inseguras, criptografía débil y problemas de seguridad comunes antes del empaquetado o despliegue.
|
|
FindBugs
Análisis estático legado de Java; puede usarse para señalar patrones de código inseguros conocidos antes de la compilación. Ha sido reemplazado por SpotBugs.
|
|
SpotBugs
Reemplazo moderno de FindBugs. Escáner de bytecode de Java para aplicar prácticas de código seguro antes de compilar los artefactos finales.
|
|
SonarQube
Plataforma SAST completa; puede integrarse en CI/CD para aplicar gates de calidad, deteniendo compilaciones que incumplan reglas de seguridad.
|
|
OWASP ZAP
Se ejecuta contra aplicaciones construidas/etapas en entornos previos al despliegue para detectar vulnerabilidades explotables, asegurando que no se promueva ninguna versión insegura.
|
|
Arachni
Escáner de vulnerabilidades de aplicaciones web que puede formar parte de la etapa de QA de la compilación para asegurar que el lanzamiento sea seguro.
|
|
OWASP Dependency-Check
Escanea dependencias conocidas como vulnerables en la compilación, bloqueando versiones inseguras para su despliegue.
|
PW.6
Configurar los Procesos de Compilación, Intérprete y Construcción para Mejorar la Seguridad de los Ejecutables: Disminuir la cantidad de vulnerabilidades de seguridad en el software y reducir costos al eliminar vulnerabilidades antes de que ocurran las pruebas.
Para cumplir con SSDF PW.6 en un contexto de compilación y despliegue usando herramientas de código abierto, el enfoque se centra en hacer que las pruebas de seguridad sean continuas y automáticas, de modo que cada build y cada candidato a despliegue se evalúe frente a un estándar de seguridad, con evidencia capturada para auditoría y puertas de liberación:
| Tareas |
Herramientas |
PW.6.1:
Usar compiladores, intérpretes y herramientas de construcción que ofrezcan funciones para mejorar la seguridad de los ejecutables.
PW.6.2:
Determinar qué funciones de compilador, intérprete y herramientas de construcción deben usarse y cómo deben configurarse, luego implementar y usar las configuraciones aprobadas.
|
|
Semgrep
SAST rápido basado en reglas con integración CI.
|
|
SonarQube Community
Calidad general de código + reglas básicas de seguridad.
|
|
Bandit
Linters SAST para Python.
|
|
Gosec
Linters SAST para Go.
|
|
Brakeman
Linters SAST para Rails.
|
|
FindSecBugs
Linters SAST para Java.
|
|
Trivy
Escaneo de vulnerabilidades en imágenes/sistemas de archivos contra SBOMs.
|
|
Grype
Escaneo de vulnerabilidades en imágenes/sistemas de archivos contra SBOMs.
|
|
Syft
Genera SBOMs (SPDX/CycloneDX) durante la construcción.
|
|
OWASP Dependency Track
Monitoreo continuo de SBOM y alertas post-build.
|
|
Gitleaks
Bloquea commits/builds que contengan secretos; ejecutarse en CI y como pre-commit hooks.
|
|
Reproducible Builds
Proporciona métodos, guías y herramientas de apoyo para builds deterministas, asegurando integridad y verificabilidad de los outputs de fuente a binario.
|
|
Bazel
Sistema de construcción con ejecución hermética (sandbox) y seguimiento explícito de dependencias, previniendo dependencias ocultas o no verificadas.
|
|
Meson
Sistema de construcción de alta velocidad y determinista que soporta reproducibilidad y configuración estricta como código.
|
|
Apache Maven
Aplica resolución controlada de dependencias y soporta builds reproducibles para proyectos Java y basados en JVM.
|
|
Yocto Project
Crea entornos de build reproducibles y controlados para imágenes Linux embebidas, previniendo desviaciones ambientales.
|
|
AOSP Build System
Usa toolchains preconstruidos y entornos sandbox para builds Android seguros y reproducibles.
|
|
Hermeto
Herramienta CLI para pre-descarga de dependencias, soporta builds herméticos, genera SBOMs y asegura builds de contenedores aislados de red con gestión reproducible de dependencias.
|
|
Hoppr
Kit de utilidades SBOM / cadena de suministro—procesamiento de SBOM y movimiento de “materiales” de la cadena de suministro alineado a la recolección/mantenimiento/compartición de la procedencia.
|
PW.7
Revisar y/o Analizar Código Legible por Humanos para Identificar Vulnerabilidades y Verificar Cumplimiento con los Requisitos de Seguridad: Ayuda a identificar vulnerabilidades para que puedan corregirse antes de que el software sea liberado y evitar su explotación. Usar métodos automatizados reduce el esfuerzo y los recursos necesarios para detectar vulnerabilidades. El código legible por humanos incluye código fuente, scripts y cualquier otra forma de código que la organización considere legible por humanos.
Para cumplir con SSDF PW.7 en un contexto de build y deploy usando herramientas de código abierto, el enfoque se centra en:
-
Ejecutar escaneos automatizados de código en CI
-
Asegurar que los requisitos de revisión manual o por pares se cumplan antes de fusionar a las ramas de release
-
Verificar que el código cumpla con las políticas de seguridad definidas anteriormente en PW.1 y validadas en PW.2, capturando evidencia de auditoría de que la revisión se completó antes de promover los artefactos de build
| Tareas |
Herramientas |
PW.7.1:
Determinar si se debe utilizar revisión de código (una persona revisa directamente el código para encontrar problemas) y/o análisis de código (se utilizan herramientas para encontrar problemas en el código, ya sea de manera completamente automatizada o en conjunto con una persona), según lo definido por la organización.
PW.7.2:
Realizar la revisión y/o análisis de código basándose en los estándares de codificación segura de la organización, y registrar y clasificar todos los problemas detectados y las recomendaciones de corrección en el flujo de trabajo del equipo de desarrollo o en el sistema de seguimiento de incidencias.
|
|
Semgrep
Se ejecuta automáticamente en CI antes de construir el artefacto de despliegue.
|
|
SonarQube Community Edition
Se integra con CI/CD para garantizar código limpio antes del release.
|
|
CodeQL
Detecta inyecciones SQL, XSS o patrones de deserialización insegura en la base de código.
|
|
GitLeaks
Protege contra la filtración de secretos en los artefactos desplegados.
|
|
GitHub y GitLab
Requiere dos revisores para cualquier cambio en módulos críticos de seguridad.
|
|
DefectDojo
Proporciona un registro verificable de auditoría para la finalización de la revisión de seguridad.
|
|
Sigstore Cosign
Proporciona un registro verificable de auditoría para la finalización de la revisión de seguridad.
|
|
OWASP Dependency-Check
Escanea continuamente las dependencias en cada build para nuevos CVEs. Puede ejecutarse en cada commit o de forma nocturna en CI/CD.
|
|
OWASP ZAP
Puede automatizarse en CI/CD para re-probar entornos de staging en busca de vulnerabilidades a medida que se despliega nuevo código.
|
|
Retire.js
Enfocado en bibliotecas JavaScript; detecta vulnerabilidades recién divulgadas en paquetes frontend/back-end durante los builds.
|
|
Fossa
Escanea dependencias en busca de vulnerabilidades y problemas de licencias, integrándose con los builds para capturar nuevos hallazgos.
|
|
Bandit para Python
Se ejecuta en CI/CD para proyectos Python para detectar problemas de seguridad recién introducidos.
|
|
Checkmarx KICS
Detección de vulnerabilidades conocidas – Compara componentes y configuraciones de IaC contra buenas prácticas de seguridad y marcos de cumplimiento conocidos (CIS Benchmarks, NIST, PCI-DSS).
|
|
Cppcheck para C++
Re-escanea código C/C++ después de cada build para asegurar que no se introdujeron nuevos problemas.
|
|
FindSecBugs
Extensión de SpotBugs que detecta fallas de seguridad en bytecode Java continuamente durante el ciclo de build.
|
|
GitHub CodeQL
Realiza consultas de seguridad continuas en el código con cada pull request o escaneo programado.
|
|
PMD
Ejecuta revisiones de calidad de código y reglas de seguridad en cada commit/build.
|
|
SpotBugs
Análisis estático de Java integrado en la pipeline de build para detección continua de vulnerabilidades.
|
|
Danger JS
Automatiza reglas de revisión de PR relacionadas con seguridad, evitando que código inseguro se fusione.
|
PW.8
Probar Código Ejecutable para Identificar Vulnerabilidades y Verificar el Cumplimiento con los Requisitos de Seguridad: Ayuda a identificar vulnerabilidades para que puedan ser corregidas antes de que el software sea liberado, con el fin de prevenir su explotación. El uso de métodos automatizados reduce el esfuerzo y los recursos necesarios para detectar vulnerabilidades y mejora la trazabilidad y la repetibilidad. El código ejecutable incluye binarios, bytecode ejecutado directamente, código fuente y cualquier otra forma de código que la organización considere ejecutable.
Para cumplir con SSDF PW.8 en un contexto post-despliegue usando herramientas de código abierto, el enfoque se centra en:
-
Ejecutar pruebas de seguridad contra el artefacto final en entornos de staging o pre-despliegue
-
Validar la configuración en tiempo de ejecución, dependencias y permisos del artefacto
-
Asegurar el cumplimiento con las bases de seguridad a nivel ejecutable
-
Capturar evidencia de los resultados de las pruebas de los artefactos para los gates de cumplimiento
| Tareas |
Herramientas |
PW.8.1:
Determinar si se debe realizar pruebas de código ejecutable para encontrar vulnerabilidades no identificadas por revisiones, análisis o pruebas previas y, de ser así, qué tipos de pruebas deben utilizarse.
PW.8.2:
Definir el alcance de las pruebas, diseñarlas, ejecutarlas y documentar los resultados, incluyendo el registro y la clasificación de todos los problemas encontrados y las remediaciones recomendadas en el flujo de trabajo del equipo de desarrollo o en el sistema de seguimiento de incidencias.
|
|
Trivy
Ejecutar como un paso de CI después de construir la imagen, antes de subir al registro
|
|
Grype
Confirma que el ejecutable final cumple con los umbrales de vulnerabilidad.
|
|
Syft
Alimenta SBOM en herramientas SCA como Dependency-Track para monitoreo continuo
|
|
OpenSCAP
Asegura que el artefacto final cumpla con los requisitos de configuración segura.
|
|
CIS-CAT Lite
Paso de aplicación de línea base antes de la promoción a producción.
|
|
Zap (Zed Attack Proxy)
Pruebas de seguridad en tiempo de ejecución antes del lanzamiento.
|
|
In-toto + Sigstore Cosign Attestations
Proporciona evidencia verificable para cumplimiento y auditorías.
|
PW.9
Configurar el Software para Tener Configuraciones Seguras por Defecto: Ayuda a mejorar la seguridad del software en el momento de la instalación para reducir la probabilidad de que se despliegue con configuraciones de seguridad débiles, exponiéndolo a un mayor riesgo de compromiso.
Para cumplir con SSDF PW.9 en un contexto de compilación y despliegue usando herramientas de código abierto, el enfoque se centra en:
-
Incrustar configuraciones seguras en imágenes de contenedor, binarios e IaC
-
Eliminar funciones inseguras o no utilizadas antes de empaquetar
-
Aplicar líneas base de seguridad (CIS, STIG, NIST) en el proceso de compilación
-
Validar esos valores por defecto como parte de CI/CD
-
Evitar que valores por defecto inseguros lleguen a los candidatos de lanzamiento
| Tareas |
Herramientas |
PW.9.1:
Definir una línea base segura determinando cómo configurar cada ajuste que tenga un efecto sobre la seguridad o un ajuste relacionado con seguridad, de manera que los valores predeterminados sean seguros y no debiliten las funciones de seguridad proporcionadas por la plataforma, infraestructura de red o servicios.
PW.9.2:
Implementar los valores predeterminados (o grupos de valores predeterminados, si aplica), y documentar cada ajuste para los administradores de software.
|
|
DevSec Hardening Framework
Automatiza el endurecimiento de la línea base durante la creación de imágenes.
|
|
Chainguard Apko
Produce imágenes de contenedor seguras por defecto.
|
|
Trivy
Punto de control en CI para bloquear valores predeterminados inseguros antes de ser compilados/desplegados.
|
|
Checkov
Evita que los valores predeterminados inseguros de IaC lleguen al despliegue.
|
|
KICS
Evita que los valores predeterminados inseguros de IaC lleguen al despliegue.
|
|
OpenSCAP
Genera evidencia de cumplimiento antes de la promoción de artefactos.
|
|
Sigstore Cosign + In-Toto
Asegura que solo se puedan desplegar artefactos endurecidos y verificados.
|
|
CIS-CAT Lite
Verifica que los valores predeterminados endurecidos cumplan con los requisitos de CIS antes del lanzamiento.
|
|
Kyverno
Aplicación de políticas para manifiestos y configuraciones durante la compilación.
|
|
OPA Conftest
Codifica valores predeterminados seguros como políticas aplicables en CI/CD.
|
2.1.4 - 2.4 Responder a Vulnerabilidades (RV)
2.4 Responder a Vulnerabilidades (RV) en los pasos de Build y Deploy CI/CD
2.4 Responder a Vulnerabilidades (RV) para Tareas de Build y Deploy
Responder a Vulnerabilidades (RV): Las organizaciones deben identificar las vulnerabilidades residuales en sus versiones de software y responder adecuadamente para abordar dichas vulnerabilidades y prevenir que ocurran vulnerabilidades similares en el futuro.
RV.1
Identificar y Confirmar Vulnerabilidades de Forma Continua: Ayuda a garantizar que las vulnerabilidades se identifiquen más rápidamente para que puedan ser remediadas de manera más ágil de acuerdo con el riesgo, reduciendo la ventana de oportunidad para los atacantes.
Para cumplir con SSDF RV.1 en un contexto de compilación y despliegue utilizando herramientas de código abierto, el enfoque se centra en recopilar continuamente información sobre vulnerabilidades (VDP + fuentes públicas), monitorear componentes y confirmar problemas en todas las versiones compatibles.
| Tareas |
Herramientas |
RV.1.1:
Recopilar información de adquirentes de software, usuarios y fuentes públicas sobre posibles vulnerabilidades en el software y componentes de terceros que utiliza, e investigar todos los reportes creíbles.
RV.1.2:
Revisar, analizar y/o probar el código del software para identificar o confirmar la presencia de vulnerabilidades previamente no detectadas.
RV.1.3:
Tener una política que aborde la divulgación y remediación de vulnerabilidades, e implementar los roles, responsabilidades y procesos necesarios para respaldar esa política.
|
|
OSV-Scanner
Escanea continuamente manifiestos/locks contra OSV; excelente para confirmar nuevas divulgaciones en todas las versiones soportadas.
|
|
Ortelius
Sincroniza continuamente las versiones del Software Bill of Material de los artefactos construidos con OSV.dev, reportando vulnerabilidades descubiertas después de la compilación.
|
|
Base de Datos de Vulnerabilidades OSV
Consulta la base de datos de vulnerabilidades OSV.dev para CVEs de paquetes de código abierto.
|
|
Grype
Escanea imágenes de contenedores y SBOMs en busca de vulnerabilidades conocidas.
|
|
Vulners CLI/API
Agrega múltiples fuentes públicas de vulnerabilidades.
|
|
cve-bin-tool
Verifica binarios instalados en busca de CVEs conocidos.
|
|
Semgrep
SAST para múltiples lenguajes; reglas personalizables. Ejecutar al hacer merge en la rama principal.
|
|
Bandit
Lint de seguridad para Python. Agregar a la etapa de construcción de proyectos Python.
|
|
SonarQube Community Edition
SAST y controles de calidad. Ejecutar en el paso de construcción; bloquear despliegue si se encuentran problemas de alta severidad.
|
|
OWASP ZAP
DAST; escaneo pasivo rápido en la aplicación de staging desplegada.
|
|
Política de Seguridad GitHub
Ubicación pública para reporteros.
|
|
Plantillas Disclose.io
Programa de Divulgación de Vulnerabilidades.
|
|
Guía de Divulgación de Vulnerabilidades OpenSSF
Manual para implementar la divulgación.
|
RV.2
Evaluar, Priorizar y Remediar Vulnerabilidades: Ayuda a garantizar que las vulnerabilidades se remedien de acuerdo con el riesgo, reduciendo la ventana de oportunidad para los atacantes.
Para cumplir con SSDF RV.2 en un contexto de compilación y despliegue usando herramientas de código abierto, el enfoque se centra en:
-
Registrar cada vulnerabilidad
-
Analizar el riesgo (explotabilidad e impacto)
-
Elegir respuestas, publicar avisos y entregar remediaciones mediante mecanismos confiables; incluir mitigaciones temporales cuando sea necesario.
| Tareas |
Herramientas |
RV.2.1:
Analizar cada vulnerabilidad para recopilar información suficiente sobre el riesgo y planificar su remediación u otra respuesta al riesgo.
RV.2.2:
Planificar e implementar respuestas al riesgo para las vulnerabilidades.
|
|
GUAC
Agrega SBOMs, certificaciones y vulnerabilidades para entender el alcance y priorizar correcciones.
|
|
Renovate
Automatiza actualizaciones de dependencias/PRs de parches con políticas conscientes del riesgo.
|
|
Ortelius
Muestra el alcance de cada vulnerabilidad en los entornos en vivo.
|
|
DefectDojo
Centraliza vulnerabilidades de herramientas SAST/DAST/SCA; agrega puntuación de riesgo.
|
|
OWASP Dependency-Track
Seguimiento de vulnerabilidades basado en SBOM, incluye puntuación CVSS y metadatos.
|
|
EPSS (Exploit Prediction Scoring System)
Evalúa la probabilidad de explotación para CVEs (priorización basada en riesgo).
|
|
Vulners API
Proporciona enlaces de explotación, PoCs y contexto adicional por CVE.
|
|
Calculadora CVSS (FIRST)
Puntuación de impacto estandarizada para respaldar decisiones de triaje.
|
|
Sigstore / Cosign
Firma builds remediadas antes de desplegar (mecanismo de entrega confiable).
|
|
OWASP ModSecurity CRS
Reglas WAF temporales para mitigar vulnerabilidades web sin parchear.
|
|
Falco
Detección y mitigación en tiempo de ejecución para problemas de contenedores/Kubernetes sin parchear.
|
RV.3
Analizar Vulnerabilidades para Identificar sus Causas Raíz: Ayuda a reducir la frecuencia de vulnerabilidades en el futuro.
Para cumplir con SSDF RV.3 en un contexto de construcción y despliegue usando herramientas de código abierto, el enfoque se centra en:
| Tareas |
Herramientas |
RV.3.1:
Analizar las vulnerabilidades identificadas para determinar sus causas raíz.
RV.3.2:
Analizar las causas raíz a lo largo del tiempo para identificar patrones, como la falta de seguimiento consistente de una práctica de codificación segura específica.
RV.3.3:
Revisar el software para detectar vulnerabilidades similares, eliminar una clase de vulnerabilidades y corregirlas proactivamente en lugar de esperar informes externos.
RV.3.4:
Revisar el proceso SDLC y actualizarlo si es apropiado para prevenir (o reducir la probabilidad de) que la causa raíz se repita en actualizaciones del software o en nuevo software creado.
|
|
Semgreps
Escribir reglas específicas de la organización para detectar patrones de causa raíz; escanear repositorios para eliminar clases de errores.
|
|
CodeQL
Consultas profundas de código para identificar los constructos de codificación precisos que conducen a vulnerabilidades.
|
|
SonarQube CE
Proporciona trazas de problemas, violaciones de reglas y puntos críticos, incluidos indicadores de causa raíz.
|
|
DefectDojo
Realiza seguimiento de vulnerabilidades y metadatos, permite adjuntar notas de causa raíz por cada problema.
|
|
Dependency-Track
Seguimiento a largo plazo de componentes vulnerables para identificar problemas recurrentes de dependencias.
|
|
Grafeas
API de metadatos para seguimiento de eventos de seguridad a través de builds/lanzamientos.
|
|
cwe-checker
Detecta patrones de debilidad (CWEs) en binarios, útil para artefactos compilados.
|
|
Joern
Plataforma de análisis de código de código abierto para buscar patrones de errores a gran escala.
|
|
OpenSAMM (Modelo de Madurez de Aseguramiento de Software OWASP)
Marco para mejorar las prácticas de ciclo de vida de desarrollo seguro.
|
|
OpenSSF Scorecards
Automatiza revisiones de seguridad de repositorios (protección de ramas, fijación de dependencias, endurecimiento de CI).
|
|
OSCAL (NIST)
Estándar para documentar cumplimiento y mejoras de seguridad en el SDLC.
|
|
Allstar (por OpenSSF)
Aplica políticas de seguridad en organizaciones/repositorios de GitHub.
|
3 - Fase 3: Post-Despliegue
Cumplimiento de Seguridad para Post-Despliegue
Fase 3 - Post-Despliegue
La Fase 3, Post-Despliegue, extiende la ciberseguridad de CI/CD más allá del despliegue hacia sistemas en producción activos. Mientras que las fases anteriores se enfocan en prevenir que las vulnerabilidades ingresen al pipeline, la Fase 3 asume que el riesgo continúa después del lanzamiento. Nuevas vulnerabilidades se divulgan diariamente, las configuraciones pueden desviarse y los actores maliciosos atacan directamente los entornos de producción.
El enfoque principal de la Fase 3 es la visibilidad continua, la detección y respuesta post-despliegue de vulnerabilidades en sistemas activos. Garantiza que las organizaciones puedan identificar qué sistemas en ejecución se ven afectados cuando surgen nuevas vulnerabilidades, detectar comportamientos maliciosos o anómalos en tiempo de ejecución y responder rápidamente para minimizar el impacto operativo y de seguridad. La Fase 3 establece un bucle de retroalimentación que conecta la realidad de producción con los equipos de desarrollo y seguridad, permitiendo la mejora continua a lo largo del ciclo de entrega de software. Dentro del alcance de esta fase se incluyen:
– Detección continua de vulnerabilidades para aplicaciones, servicios, contenedores e infraestructura desplegada
– Monitoreo de seguridad en tiempo de ejecución y post-despliegue
– Pruebas de Seguridad Dinámica de Aplicaciones (DAST) sobre sistemas en ejecución
– Integración de feeds de inteligencia de vulnerabilidades y alertas
– Detección de incidentes, alertas y flujos de trabajo de respuesta
– Medición del desempeño de seguridad (por ejemplo, MTTD, MTTR)
– Mecanismos de retroalimentación que informan la remediación y el desarrollo futuro
Actividades Clave de Seguridad en Fase 3
El cumplimiento de los pasos Post-Despliegue incluye:
|
|
| ACTIVIDAD |
PROPÓSITO |
| Detección de anomalías en tiempo de ejecución |
Detectar ataques en producción |
| Escaneo DAST |
Encontrar vulnerabilidades en tiempo de ejecución |
| Integración de feeds de vulnerabilidades |
Actualizar continuamente los datos CVE |
| Alertas y Respuesta |
Clasificar y responder |
A continuación, se presentan las directrices de marcos de referencia de la industria con herramientas de código abierto sugeridas para lograr los objetivos de cumplimiento.
Marcos de Referencia de la Industria
Se presentan las directrices de marcos de referencia de la industria con herramientas de código abierto sugeridas para alcanzar los objetivos de cumplimiento.
3.1 - 3.0 Marco de Desarrollo de Software Seguro Fase 3 - Tareas
3.0 Pasos Post-Despliegue de CI/CD del Marco de Desarrollo de Software Seguro
3.0 Cumpliendo las Tareas Post-Despliegue del Marco de Desarrollo de Software Seguro
Este capítulo se enfoca específicamente en las herramientas y prácticas DevSecOps relacionadas con las acciones Post-Despliegue del pipeline CI/CD para cumplir las tareas definidas por el Marco de Desarrollo de Software Seguro.
El Marco de Desarrollo de Software Seguro, desarrollado por el Instituto Nacional de Estándares y Tecnología (NIST), proporciona un enfoque integral para garantizar la seguridad a lo largo del proceso de desarrollo de software, desde el diseño inicial hasta el despliegue y mantenimiento. El marco describe prácticas y directrices clave que las organizaciones pueden implementar para asegurar su ciclo de vida de desarrollo de software (SDLC), con un énfasis particular en integrar la seguridad en los procesos automatizados.
|
|
| 3.1 Preparar la Organización (PO) |
Las organizaciones deben asegurarse de que su personal, procesos y tecnología estén preparados para llevar a cabo un desarrollo de software seguro a nivel organizacional. Muchas organizaciones encontrarán que algunas prácticas de PO también son aplicables a subconjuntos de su desarrollo de software, como grupos o proyectos individuales. |
| 3.2 Proteger el Software (PS) |
Las organizaciones deben proteger todos los componentes de su software contra manipulaciones y accesos no autorizados. |
| 3.3 Producir Software Bien Asegurado (PW) |
Las organizaciones deben producir software bien asegurado con un mínimo de vulnerabilidades de seguridad en sus versiones. |
| 3.4 Responder a Vulnerabilidades (RV) |
Las organizaciones deben identificar vulnerabilidades residuales en sus versiones de software y responder apropiadamente para abordar esas vulnerabilidades y prevenir que ocurran vulnerabilidades similares en el futuro. |
3.1.1 - 3.1 Preparar la Organización (PO)
3.1 Preparar la Organización (PO) Pasos Post Despliegue CI/CD
3.1 Preparar la Organización (PO) Tareas Post Despliegue
Las organizaciones deben asegurar que sus personas, procesos y tecnología estén preparadas para realizar desarrollo de software seguro a nivel organizacional. Muchas organizaciones encontrarán que algunas prácticas PO también son aplicables a subconjuntos de su desarrollo de software, como grupos de desarrollo individuales o proyectos.
PO.1
Definir Requisitos de Seguridad para el Desarrollo de Software: Asegurar que los requisitos de seguridad para el desarrollo de software sean conocidos en todo momento para que puedan ser considerados durante todo el SDLC y minimizar la duplicación de esfuerzos, ya que la información de los requisitos puede recopilarse una vez y compartirse. Esto incluye requisitos de fuentes internas (p. ej., políticas de la organización, objetivos de negocio y estrategia de gestión de riesgos) y fuentes externas (p. ej., leyes y regulaciones aplicables).
Para cumplir con SSDF PO.1 en un contexto post-despliegue usando herramientas de código abierto, el enfoque se desplaza de solo definir a:
- Mantener y aplicar las tareas PO en sistemas en producción.
- Hacer que los requisitos de las tareas sean visibles y trazables en todos los entornos desplegados.
- Auditar y actualizar métodos y procedimientos a medida que cambian las políticas internas y externas.
| Tareas |
Herramientas |
PO.1.1:
Identificar y documentar todos los requisitos de seguridad para las infraestructuras y procesos de desarrollo de software de la organización, y mantener dichos requisitos a lo largo del tiempo.
PO.1.2:
Identificar y documentar todos los requisitos de seguridad que el software desarrollado por la organización debe cumplir, y mantener dichos requisitos a lo largo del tiempo.
|
|
Open Policy Agent
Soporta definiciones de políticas de seguridad como código y las aplica en pipelines, CI/CD y en tiempo de ejecución. Aplica políticas en tiempo de ejecución mediante integraciones con Kubernetes, Terraform y plataformas CI/CD.
|
|
InspecLog
Audita periódicamente los entornos desplegados contra estándares de seguridad internos y externos.
|
|
Ortelius Evidence Store
Asocia y versiona metadatos de requisitos de seguridad por servicio y despliegue, habilitando visibilidad continua.
|
|
DefectDojo
Relaciona hallazgos de seguridad con controles de políticas específicas o marcos regulatorios.
|
PO.2
Implementar Roles y Responsabilidades: Asegurar que todos, dentro y fuera de la organización, involucrados en el SDLC estén preparados para desempeñar sus roles y responsabilidades relacionadas con el SDLC durante todo el ciclo de vida.
Para cumplir con SSDF PO.2 en un contexto post-despliegue usando herramientas de código abierto, el enfoque se desplaza a:
- Definir y asignar roles para quienes son responsables de la remediación y configuraciones en tiempo de ejecución.
- Mantener evidencia de qué se desplegó, quién lo desplegó y el impacto sobre todos los activos de software.
- Asegurar la seguridad y gestión de parches con acciones restringidas post-despliegue.
| Tareas |
Herramientas |
PO.2.1:Crear nuevos roles y modificar responsabilidades de roles existentes según sea necesario para abarcar todas las partes del SDLC. Revisar y mantener periódicamente los roles y responsabilidades definidos, actualizándolos según sea necesario.
PO.2.2:
Proporcionar capacitación basada en roles para todo el personal con responsabilidades que contribuyan al desarrollo seguro. Revisar periódicamente la competencia del personal y la capacitación basada en roles, y actualizar la formación según sea necesario.
PO.2.3:
Obtener el compromiso de la alta dirección o autoridad autorizante para el desarrollo seguro, y comunicar ese compromiso a todos los roles y responsabilidades relacionados con el desarrollo.
|
|
Git
Rastrea autoría y revisores de código, etiqueta releases y documenta quién los disparó.
|
|
Ortelius Evidence Store
Asocia servicios desplegados con individuos o equipos responsables, manteniendo un historial de cambios, despliegues y roles.
|
|
Backstage
Lista propietarios de servicios, equipos on-call y rutas de escalamiento, haciendo transparente la responsabilidad post-despliegue en toda la organización.
|
|
DefectDojo
Rastrea hallazgos de seguridad y asigna responsabilidades de resolución.
|
|
Kubernetes RBAC / OPA Gatekeeper
Aplica políticas de acceso y límites de roles en entornos de ejecución.
|
|
ArgoCD
Garantiza que solo los commits/despliegues autorizados afecten producción y registra cada promoción y rollback.
|
|
Falco
Detecta actividad no autorizada en tiempo de ejecución.
|
|
Prometheus + Alertmanager
Alertas basadas en propiedad/roles.
|
PO.3
Implementar Cadenas de Herramientas de Soporte: Usar automatización para reducir el esfuerzo humano y mejorar la precisión, reproducibilidad, usabilidad y cobertura de las prácticas de seguridad durante todo el SDLC, así como proporcionar una forma de documentar y demostrar el uso de estas prácticas. Las cadenas de herramientas y herramientas pueden usarse en distintos niveles de la organización, como a nivel organizacional o por proyecto, y pueden abordar partes específicas del SDLC, como un pipeline de compilación.
Para cumplir con SSDF PO.3 en un contexto post-despliegue usando herramientas de código abierto, el enfoque se desplaza a:
- Asegurar que las cadenas de herramientas soporten detección de vulnerabilidades, seguimiento de SBOMs, cumplimiento y aplicación de políticas para funcionar después del despliegue.
- Mantener la seguridad, actualización e integración de las herramientas de automatización en el entorno en vivo.
- Mantener evidencia de que los outputs de la cadena de herramientas (e.g., SBOMs, reportes de escaneo) siguen siendo confiables y actuales.
| Tareas |
Herramientas |
PO.3.1:
Especificar qué herramientas o tipos de herramientas deben incluirse en cada cadena de herramientas para mitigar riesgos identificados, así como cómo se integrarán los componentes entre sí.
PO.3.2:
Seguir prácticas de seguridad recomendadas para desplegar, operar y mantener herramientas y cadenas de herramientas.
PO.3.3:
Configurar herramientas para generar artefactos que respalden las prácticas de desarrollo seguro definidas por la organización.
|
|
OWASP Dependency Track
Monitorea continuamente SBOMs para CVEs recién divulgados en el software desplegado.
|
|
Ortelius Evidence Store
Mantiene un registro histórico de software desplegado, componentes y sus SBOMs; vincula con propietarios para responsabilidad.
|
|
Syft
Genera SBOMs de imágenes de contenedores o sistemas de archivos desplegados bajo demanda.
|
|
Trivy
Escaneo de vulnerabilidades post-despliegue en contenedores, sistemas de archivos y paquetes; también genera SBOMs.
|
|
Clair
Escaneo continuo de registries de contenedores para vulnerabilidades.
|
|
Grype
Escáner rápido de vulnerabilidades para imágenes de contenedores y sistemas de archivos.
|
|
In-Toto
Valida que los artefactos desplegados coincidan con las certificaciones criptográficas del proceso de construcción.
|
|
Sigstore Cosign
Verifica firmas de artefactos desplegados; asegura que coincidan con builds aprobados.
|
|
Sigstore Rekor
Proporciona un registro público e inmutable para firmas y datos de procedencia.
|
|
Open Policy Agent
Aplica políticas de seguridad y cumplimiento en sistemas desplegados (e.g., clusters de Kubernetes).
|
|
Inspec
Audita la infraestructura y aplicaciones desplegadas contra líneas base de seguridad y requisitos de cumplimiento.
|
|
The Hive
Plataforma de respuesta a incidentes para eventos de seguridad post-despliegue.
|
|
Konflux-ci software factory for Tekton
Implementa el framework In-toto usando pipelines-as-code para validación de seguridad de la cadena de suministro.
|
|
DefectDojo
Rastrea vulnerabilidades y asigna tareas de remediación; integra con escáneres para actualizaciones continuas.
|
PO.4
Definir y Usar Criterios para Revisiones de Seguridad del Software: Ayuda a garantizar que el software resultante del SDLC cumpla con las expectativas de la organización al definir y usar criterios para verificar la seguridad del software durante el desarrollo.
Para cumplir con SSDF PO.4 en un contexto post-despliegue usando herramientas de código abierto, el enfoque se desplaza a:
-
Asegurarse de que los datos de seguridad continúen recopilándose después del lanzamiento.
-
Que los logs, SBOMs y resultados de escaneos se conserven y sean resistentes a manipulaciones.
-
Proteger los datos para evitar accesos o modificaciones no autorizadas.
-
Que los datos sean recuperables para auditorías, investigaciones y verificaciones de cumplimiento.
| Tareas |
Herramientas |
PO.4.1:
Definir criterios para revisiones de seguridad del software y darles seguimiento durante todo el SDLC.
PO.4.2:
Implementar procesos, mecanismos, etc., para recopilar y proteger la información necesaria en apoyo de los criterios.
|
|
Falco
Detección de seguridad en tiempo de ejecución para contenedores y hosts; genera logs de eventos para comportamientos sospechosos.
|
|
AuditD
Captura eventos de seguridad a nivel de sistema en Linux.
|
|
OSQuery
Telemetría de endpoints y monitoreo de configuración.
|
|
Prometheus y Loki
Recopila y almacena métricas y logs en un formato consultable.
|
|
Ortelius Evidence Store
Mantiene SBOMs versionadas vinculadas a cada despliegue.
|
|
Syft
Genera SBOMs a partir de artefactos desplegados para monitoreo continuo.
|
|
OpenSCAP
Recopila y almacena datos de escaneos de cumplimiento.
|
|
Wazuh SIEM
SIEM con registro de auditoría, detección de amenazas y monitoreo de cumplimiento.
|
|
Grype
Detecta vulnerabilidades CVE en imágenes y sistemas de archivos desplegados.
|
|
In-Toto
Valida que los artefactos desplegados coincidan con las certificaciones criptográficas del proceso de construcción.
|
|
Sigstore Rekor
Proporciona un registro público e inmutable para firmas y datos de procedencia.
|
|
Inspec
Audita infraestructura y aplicaciones desplegadas contra estándares de seguridad y cumplimiento.
|
|
Trivy
Escaneo continuo de vulnerabilidades y generación de SBOM para sistemas en ejecución.
|
|
DefectDojo
Almacena y organiza resultados de escaneos de seguridad; integra con Trivy, Grype y Dependency-Track.
|
PO.5
Implementar y Mantener Entornos Seguros para el Desarrollo de Software: Asegurar que todos los componentes de los entornos de desarrollo estén fuertemente protegidos contra amenazas internas y externas para prevenir compromisos del entorno o del software desarrollado o mantenido en ellos. Ejemplos de entornos incluyen desarrollo, construcción, prueba y distribución.
Para cumplir con SSDF PO.5 en un contexto post-despliegue usando herramientas de código abierto, el enfoque se desplaza a:
-
Los requisitos de seguridad de la infraestructura de desarrollo siguen siendo relevantes y aplicables después del lanzamiento del software.
-
Los entornos de construcción, despliegue y monitoreo permanecen endurecidos y conformes.
-
Se valida continuamente que la infraestructura de desarrollo no se haya desviado de su línea base segura.
| Tareas |
Herramientas |
PO.5.1:
Separar y proteger cada entorno involucrado en el desarrollo de software.
PO.5.2:
Proteger y reforzar los endpoints de desarrollo (diseñadores, desarrolladores, testers, constructores, etc.) para realizar tareas relacionadas con el desarrollo usando un enfoque basado en riesgos.
|
|
Inspec
Ejecuta escaneos de cumplimiento continuos en servidores de desarrollo y construcción; aplica benchmarks CIS/NIST.
|
|
OpenSCAP
Verifica la infraestructura contra estándares de seguridad definidos.
|
|
OSQuery
Monitorea nodos de construcción y despliegue en busca de cambios no autorizados.
|
|
Kube-bench
Valida que clusters de Kubernetes para construcción/pruebas cumplan benchmarks CIS.
|
|
Open Policy Agent - GateKeeper
Aplica reglas para la configuración de infraestructura (Kubernetes, Terraform, CI/CD).
|
|
Kyverno
Aplicación de políticas nativas de Kubernetes para la seguridad del cluster.
|
|
Jenkins
Endurece pipelines CI/CD con controles de acceso y logs de auditoría.
|
|
Nexus Repository OSS
Almacena artefactos de construcción de forma segura post-despliegue; aplica controles de acceso.
|
|
Harbor
Registro de contenedores con escaneo de vulnerabilidades y RBAC incorporados.
|
|
Wazuh SIEM
Ingesta logs de seguridad de infraestructura y alerta sobre violaciones.
|
|
Falco
Detecta actividad no autorizada en clusters o nodos de construcción/despliegue.
|
|
Prometheus + Alertmanager
Monitorea métricas de seguridad y genera notificaciones ante incidentes.
|
|
In-Toto
Valida que los artefactos desplegados coincidan con las certificaciones criptográficas del proceso de construcción.
|
|
Sigstore Rekor
Mantiene un registro inmutable y a prueba de manipulaciones de archivos de configuración firmados.
|
3.1.2 - 3.2 Proteger el Software (PS)
3.2 Proteger el Software (PS) Pasos Post Deploy CI/CD
3.2 Proteger el Software (PS) para Tareas Post Deploy
Proteger el Software (PS): Las organizaciones deben proteger todos los componentes de su
software contra manipulaciones y accesos no autorizados.
PS.1
Proteger Todas las Formas de Código contra Accesos No Autorizados y Manipulación : Ayuda a prevenir cambios no autorizados en el código, tanto inadvertidos como intencionales, que podrían eludir o anular las características de seguridad previstas del software. Para el código que no está destinado a ser accesible públicamente, esto ayuda a prevenir el robo del software y puede dificultar o retrasar que los atacantes encuentren vulnerabilidades en el software.
Para cumplir con SSDF PS.1 en un contexto post-despliegue usando herramientas open-source, el enfoque se desplaza de solo definir a:
-
Proteger los artefactos desplegados (binarios, contenedores, scripts, configuraciones) para que no sean alterados en producción
-
Asegurar que la integridad del código post-despliegue sea verificable en cualquier momento
-
Mantener almacenamiento, transporte y recuperación de código y artefactos seguros
-
Mantener un registro de auditoría para todas las modificaciones y accesos
| Tareas |
Herramientas |
PS.1.1:
Almacenar todas las formas de código incluyendo código fuente, código ejecutable y configuración como código según el principio de menor privilegio, de modo que solo personal, herramientas o servicios autorizados tengan acceso.
|
Cosign Sigstore
Firmar y verificar imágenes de contenedores, binarios y otros artefactos.
|
|
Rekor Sigstore
Registro público inmutable para firmas y metadatos.
|
|
In-Toto
Verificación de cadena de suministro de extremo a extremo para asegurar que los artefactos desplegados provienen de fuentes confiables.
|
|
Gnu Privacy GuardG
Firmar y verificar cualquier tipo de archivo, incluyendo tarballs y archivos de configuración.
|
|
Harbor
Registro de contenedores con escaneo de vulnerabilidades integrado, firma de contenido y RBAC.
|
|
Sonatype Nexus OSS
Repositorio seguro de artefactos con controles de acceso.
|
|
JFrog Artifactory OSS
Gestión de repositorios binarios con permisos granulares.
|
|
Tripwire OSS
Monitorea el sistema de archivos para detectar cambios no autorizados.
|
|
AIDE (Advanced Intrusion Detection Environment)
Crea una línea base de archivos y detecta alteraciones.
|
|
Falco
Detecta actividad sospechosa en entornos de Kubernetes o contenedores, incluyendo cambios de archivos.
|
|
Kubernetes RBAC + OPA Gatekeeper
Aplica políticas basadas en roles para el despliegue de imágenes de contenedores.
|
|
Keycloak
Autenticación/autorización centralizada para registros de artefactos y sistemas CI/CD.
|
|
Wazuh
Plataforma SIEM que monitorea registros de acceso y alerta sobre anomalías.
|
|
Ortelius Evidence Store
Rastrea qué versión de un servicio se despliega dónde y la vincula con su SBOM firmado.
|
|
Syft
Genera SBOMs para artefactos desplegados para verificación posterior.
|
|
OWASP Dependency-Track
Monitorea componentes en artefactos desplegados frente a feeds de CVE.
|
PS.2
Proporcionar un Mecanismo para Verificar la Integridad del Software: Ayuda a los adquirentes de software a asegurarse de que el software que adquieren es legítimo y no ha sido manipulado. Hacer que la información de verificación de integridad del software esté disponible para los adquirentes.
Para cumplir con SSDF PS.2 en un contexto post-despliegue usando herramientas open-source, el enfoque se desplaza a:
-
Mantener copias exactas de cada artefacto de lanzamiento (binarios, contenedores, configuraciones, SBOMs)
-
Registrar y publicar datos de verificación criptográfica (firmas, hashes, certificaciones)
-
Asegurar que los adquirentes puedan confirmar que lo que tienen coincide con la versión oficial y confiable
| Tareas |
Herramientas |
PS.2.1:
Hacer que la información de verificación de integridad del software esté disponible para los adquirentes.
|
Harbor
Registro de contenedores con políticas de retención de imágenes, RBAC y confianza de contenido.
|
|
Sonatype Nexus OSS
Repositorio de artefactos para almacenar binarios y dependencias.
|
|
JFrog Artifactory OSS
Gestión de binarios con retención y control de acceso.
|
|
GitHub
Etiquetar y almacenar binarios de lanzamiento, SBOMs y checksums.
|
|
Sigstore cosign
Firmar y verificar imágenes de contenedores, SBOMs y otros artefactos.
|
|
Sigstore Rekor
Registro de transparencia inmutable para todos los artefactos y metadatos firmados.
|
|
Gnu Privacy Guard
Firmar y verificar tarballs, binarios o archivos SBOM.
|
|
In-Toto
Proporcionar verificación de procedencia de construcción de extremo a extremo.
|
|
Ortelius
Mapea servicios desplegados a versiones específicas y sus SBOMs.
|
|
Syft
Genera SBOMs a partir de artefactos desplegados.
|
|
Hoppr
Kit de utilidades SBOM / cadena de suministro: procesamiento de SBOM y movimiento de “materiales” de la cadena de suministro alineados a recolección/mantenimiento/compartición de procedencia.
|
|
OWASP Dependency-Track
Monitorea continuamente SBOMs para nuevos CVEs en versiones preservadas.
|
|
AIDE (Advanced Intrusion Detection Environment)
Comprobador de integridad del sistema de archivos para detectar cambios en artefactos almacenados.
|
|
Tripwire OSS
Establecer línea base y monitorear directorios de lanzamiento almacenados para modificaciones.
|
|
Wazuh
SIEM que audita la actividad del repositorio de artefactos.
|
|
AuditD
Auditoría a nivel Linux para accesos a archivos de lanzamiento preservados.
|
|
Kubernetes RBAC / Keycloak
Restringir quién puede subir o modificar artefactos en los registros.
|
PS.3
Archivar y Proteger Cada Lanzamiento de Software: Preservar los lanzamientos de software para ayudar a identificar, analizar y eliminar vulnerabilidades descubiertas en el software después de su liberación.
Para cumplir con SSDF PS.3 en un contexto post-despliegue usando herramientas open-source, el enfoque se desplaza a:
-
Mantener un registro a prueba de manipulaciones de cada componente de software en cada lanzamiento
-
Asegurar que los datos de procedencia permanezcan accesibles para auditorías, investigaciones y respuesta a vulnerabilidades
-
Permitir a adquirentes y usuarios finales verificar de manera independiente el origen e integridad de cada componente
| Tareas |
Herramientas |
PS.3.1:
Archivar de manera segura los archivos y datos de soporte necesarios (por ejemplo, información de verificación de integridad, datos de procedencia) para retenerlos para cada lanzamiento de software.
PS.3.2:
Recopilar, proteger, mantener y compartir los datos de procedencia de todos los componentes de cada lanzamiento de software (por ejemplo, en un bill of materials -SBOM).
|
Syft
Genera SBOMs desde contenedores, VMs o sistemas de archivos desplegados (formatos SPDX & CycloneDX).
|
|
Trivy
Crear SBOMs y escanear vulnerabilidades en sistemas desplegados.
|
|
In-Toto
Registrar pasos de construcción y metadatos de la cadena de suministro como archivos “link” firmados.
|
|
Cosign Attest
Capturar procedencia de construcción y despliegue como certificaciones firmadas.
|
|
Gnu Privacy Guard
Firmar SBOMs y metadatos para distribución offline o privada.
|
|
Rekor
Almacenar firmas y certificaciones en un registro público e inmutable.
|
|
Tripwire OSS
Detectar cambios no autorizados en archivos de procedencia almacenados localmente.
|
|
AIDE (Advanced Intrusion Detection Environment)
Detectar cambios no autorizados en archivos de procedencia almacenados localmente.
|
|
Ortelius Evidence Store
Versionar y rastrear servicios desplegados y sus SBOMs; vincularlos a entornos y lanzamientos. Acceso API/UI para compartir historial de SBOM y componentes de lanzamientos específicos.
|
|
Dependency Track
Monitorear continuamente SBOMs preservados para nuevos CVEs.
|
|
Harbor
Adjuntar SBOMs y firmas a imágenes de contenedores en un registro.
|
|
CycloneDX BOM Portal (OSS)
Alojar y validar SBOMs en una interfaz web accesible.
|
|
Hoppr
Kit de utilidades SBOM / cadena de suministro—procesamiento de SBOM y movimiento de “materiales” de la cadena de suministro alineados a recolección/mantenimiento/compartición de procedencia.
|
3.1.3 - 3.3 Producir Software Bien Asegurado (PW)
3.3 Producir Software Bien Asegurado (PW) en los pasos de CI/CD posteriores al despliegue
3.3 Producir Software Bien Asegurado (PW) para tareas posteriores al despliegue
Las organizaciones deben producir software bien asegurado con vulnerabilidades de seguridad mínimas en sus versiones.
PW.1
Diseñar el software para cumplir con los requisitos de seguridad y mitigar los riesgos de seguridad: Identificar y evaluar los requisitos de seguridad del software; determinar qué riesgos de seguridad es probable que enfrente el software durante su operación y cómo el diseño y la arquitectura del software deben mitigar esos riesgos; y justificar cualquier caso en el que el análisis basado en riesgos indique que los requisitos de seguridad deben relajarse o eximirse. Abordar los requisitos y riesgos de seguridad durante el diseño del software (seguro por diseño) es clave para mejorar la seguridad del software y también ayuda a mejorar la eficiencia del desarrollo.
Para cumplir con SSDF PW.1 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Mantener un registro a prueba de manipulaciones de cada componente de software en cada versión
-
Garantizar que los datos de procedencia permanezcan accesibles para auditorías, investigaciones y respuesta a vulnerabilidades
-
Permitir que adquirentes y usuarios posteriores verifiquen de manera independiente el origen y la integridad de cada componente
| Tareas |
Herramientas |
PW.1.1:
Usar formas de modelado de riesgos, como modelado de amenazas, modelado de ataques o mapeo de superficie de ataque, para ayudar a evaluar el riesgo de seguridad del software.
PW.1.2:
Rastrear y mantener los requisitos de seguridad, riesgos y decisiones de diseño del software.
PW.1.3:
Cuando sea apropiado, incorporar soporte para usar funciones y servicios de seguridad estandarizados (por ejemplo, permitir que el software se integre con sistemas existentes de gestión de logs, gestión de identidad, control de acceso y gestión de vulnerabilidades) en lugar de crear implementaciones propietarias de funciones y servicios de seguridad.
|
|
Semgrep
Análisis estático y dinámico que puede ejecutarse contra bases de código desplegadas en entornos espejo de staging para detectar patrones inseguros.
|
|
Wapiti
Escáner de seguridad de aplicaciones web para aplicaciones desplegadas.
|
|
Zap (Zed Attack Proxy)
Pruebas activas y pasivas de aplicaciones en vivo para detectar vulnerabilidades.
|
|
Inspec
Valida que las aplicaciones desplegadas cumplan con estándares de codificación segura.
|
|
Ortelius
Sincronización cada 10 minutos con OSV.dev para detectar nuevas vulnerabilidades en artefactos desplegados.
|
|
OpenSCAP
Escanea sistemas para verificar cumplimiento con líneas base relacionadas con codificación segura.
|
|
Falco
Registro y monitoreo: detecta comportamiento inseguro en tiempo de ejecución (por ejemplo, llamadas al sistema inseguras).
|
|
Wazuh
Monitorea logs de la aplicación y del sistema operativo para eventos relacionados con seguridad.
|
|
AuditD
Captura llamadas de sistema de bajo nivel relacionadas con la ejecución de código.
|
|
Syft
Genera SBOMs para aplicaciones desplegadas con monitoreo continuo.
|
|
Hoppr
Hoppr es un kit de utilidades de SBOM / cadena de suministro: el procesamiento y movimiento de “materiales” de la cadena de suministro se alinea con la recolección, mantenimiento y compartición de procedencia.
|
|
OWASP Dependency-Track
Rastrea continuamente SBOMs para detectar nuevas vulnerabilidades
|
|
Trivy
Escanea contenedores/sistemas de archivos desplegados para CVEs conocidas en código y dependencias.
|
|
Grype
Escaneo enfocado de vulnerabilidades para artefactos desplegados.
|
PW.2
Revisar el diseño del software para verificar el cumplimiento con los requisitos de seguridad y la información de riesgos: Ayudar a garantizar que el software cumpla con los requisitos de seguridad y aborde satisfactoriamente la información de riesgos identificada.
Para cumplir con SSDF PW.2 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Verificación continua de que el código desplegado (fuente o binario) no ha sido manipulado.
-
Evaluación continua de vulnerabilidades en aplicaciones y componentes desplegados.
-
Disparadores de revisión de código posteriores a la liberación cuando se detecta una vulnerabilidad o incidente.
-
Evidencia auditable de que el software desplegado coincide con el código aprobado y revisado.
| Tareas |
Herramientas |
PW.2.1:
Tener (1) una persona calificada (o personas) que no hayan estado involucradas con el diseño y/o (2) procesos automatizados instanciados en la cadena de herramientas que revisen el diseño del software para confirmar y hacer cumplir que cumple con todos los requisitos de seguridad y aborda satisfactoriamente la información de riesgos identificada.
|
|
Sigstore Cosign
Verifica que los contenedores y binarios desplegados hayan sido firmados en tiempo de compilación.
|
|
Rekor
Almacena datos de verificación y attestations en un log evidente ante manipulaciones.
|
|
In-Toto
Garantiza que el código desplegado coincida con los pasos revisados del pipeline de build.
|
|
Tripwire OSS
Monitorea archivos desplegados para detectar cambios no autorizados.
|
|
Semgrep
Revisa código desplegado en espejo para detectar problemas de seguridad o violaciones de políticas.
|
|
GitHub CodeQL
Consultas avanzadas de código para detectar patrones de vulnerabilidad.
|
|
Wapiti
Escaneo de vulnerabilidades web contra endpoints desplegados.
|
|
Ortelius
Rastrea vulnerabilidades en endpoints en vivo para tiempos de remediación rápidos.
|
|
Zap (Zed Attack Proxy)
Pruebas DAST automatizadas y manuales para aplicaciones en vivo.
|
|
Nikto
Escaneo de vulnerabilidades enfocado en servidores.
|
|
OpenSCAP
Mapea resultados a líneas base de cumplimiento.
|
|
DefectDojo
Rastrea vulnerabilidades encontradas durante revisiones posteriores al despliegue y las vincula con la remediación.
|
PW.4
Reutilizar software existente y bien asegurado cuando sea factible en lugar de duplicar funcionalidad: Reducir los costos del desarrollo de software, acelerar el desarrollo y disminuir la probabilidad de introducir vulnerabilidades de seguridad adicionales en el software reutilizando módulos y servicios de software cuya postura de seguridad ya haya sido verificada. Esto es particularmente importante para software que implementa funcionalidades de seguridad, como módulos y protocolos criptográficos.
Nota: PW.3 fue movido a PW.4
Para cumplir con SSDF PW.4 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
La detección de vulnerabilidades se ejecuta continuamente en entornos de producción o equivalentes a producción.
-
Los resultados se triagean y asignan rápidamente.
-
Existe una ruta automatizada o semiautomatizada hacia la remediación (por ejemplo, parcheo, reconstrucción de imágenes o actualización de componentes).
-
Toda la actividad es auditable y está vinculada a los artefactos de liberación.
| Tareas |
Herramientas |
PW.4.1:
Adquirir y mantener componentes de software bien asegurados (por ejemplo, bibliotecas, módulos, middleware, frameworks) de proveedores comerciales, de código abierto y otros desarrolladores externos para ser utilizados por el software de la organización.
PW.4.2:
Crear y mantener componentes de software bien asegurados internamente siguiendo procesos SDLC para cubrir necesidades comunes de desarrollo interno que no puedan satisfacerse mejor con componentes de terceros.
PW.4.4:
Verificar que los componentes de software comerciales, de código abierto y todos los demás componentes de terceros adquiridos cumplan con los requisitos definidos por la organización durante todo su ciclo de vida.
|
|
Git
Almacena reportes de vulnerabilidades firmados y metadatos de commits de parches.
|
|
Rekor
Registra de forma inmutable resultados de escaneo, remediaciones y firmas.
|
|
Ortelius
La auditoría y retención de evidencia rastrea qué entornos están ejecutando qué versión, permitiendo el redespliegue dirigido de builds parchados.
|
|
Trivy
Escanea contenedores en ejecución, sistemas de archivos y clústeres Kubernetes; también genera SBOMs.
|
|
Grype
Escaneo de vulnerabilidades impulsado por SBOM para imágenes y directorios.
|
|
Clair
Monitorea registros de contenedores para detectar imágenes vulnerables.
|
|
OpenVAS / Greenbone
Escaneo de vulnerabilidades de red y hosts.
|
|
Syft
Genera SBOMs desde entornos desplegados.
|
|
OWASP Dependency-Track
Monitorea SBOMs para detectar nuevos CVEs y violaciones de políticas.
|
|
Vulnix
Escaneo de vulnerabilidades basado en Nix a partir de entradas SBOM.
|
|
Kyverno
Controlador de admisión nativo de Kubernetes que aplica umbrales de vulnerabilidad.
|
|
Falco
Detecta anomalías en tiempo de ejecución que pueden indicar explotación.
|
|
Nikto
Escaneo de vulnerabilidades enfocado en servidores.
|
|
Keel
Automatiza redespliegues de contenedores cuando se publica una nueva imagen.
|
|
Kured
Reinicios automatizados de nodos Kubernetes para parcheo del kernel.
|
|
DefectDojo
Centraliza datos de vulnerabilidades provenientes de escáneres; asigna tareas de remediación y rastrea SLAs.
|
|
The Hive
Respuesta a incidentes y coordinación para eventos urgentes de vulnerabilidades.
|
PW.5
Crear código fuente adhiriéndose a prácticas de codificación segura: Disminuir la cantidad de vulnerabilidades de seguridad en el software y reducir costos minimizando las vulnerabilidades introducidas durante la creación del código fuente que cumplan o superen los criterios de severidad de vulnerabilidad definidos por la organización.
Para cumplir con SSDF PW.5 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Verificación continua de la integridad, el cumplimiento y la postura de seguridad del software desplegado.
-
Validaciones continuas para asegurar que el software en ejecución siga cumpliendo los requisitos de seguridad que tenía al momento de la liberación.
-
Detección de drift, nuevas vulnerabilidades introducidas y cambios de configuración.
-
Mantenimiento de evidencia verificable de estas validaciones a lo largo del tiempo.
| Tareas |
Herramientas |
PW.5.1:
Seguir todas las prácticas de codificación segura apropiadas para los lenguajes de desarrollo y el entorno, con el fin de cumplir los requisitos de la organización.
|
|
Trivy
Escaneos continuos de contenedores desplegados, sistemas de archivos y clústeres Kubernetes.
|
|
Grype
Detecta CVEs en SBOMs o imágenes desplegadas.
|
|
Clair
Escaneo continuo de vulnerabilidades para imágenes en registros.
|
|
Syft
Genera SBOMs desde sistemas en ejecución para monitoreo continuo.
|
|
Inspec
Define y ejecuta validaciones de cumplimiento (CIS, NIST, políticas específicas de la organización) contra entornos desplegados.
|
|
OpenSCAP
Evalúa sistemas en ejecución contra líneas base de seguridad.
|
|
Kube-bench
Valida despliegues de Kubernetes contra benchmarks CIS.
|
|
Kube-hunter
Identifica posibles rutas de ataque en clústeres Kubernetes desplegados.
|
|
Falco
Detecta cambios en tiempo de ejecución en archivos, procesos y comportamiento de red.
|
|
AIDE
Monitoreo de integridad de archivos para asegurar que binarios/configuraciones no sean alterados.
|
|
osquery
Consulta el estado del sistema para detectar cambios de configuración no autorizados.
|
|
Open Policy Agent
Aplica políticas continuas de cumplimiento en tiempo de ejecución.
|
|
Kyverno
Motor de políticas nativo de Kubernetes para prevenir actualizaciones inseguras.
|
|
DefectDojo
Centraliza resultados de verificación y rastrea problemas a lo largo del tiempo.
|
|
Rekor
Almacena reportes de verificación firmados en un registro a prueba de manipulaciones.
|
PW.6
Configurar los procesos de compilación, intérprete y build para mejorar la seguridad del ejecutable: Disminuir la cantidad de vulnerabilidades de seguridad en el software y reducir costos eliminando vulnerabilidades antes de que ocurran las pruebas.
Para cumplir con SSDF PW.6 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Ejecutar escaneos programados sobre contenedores en ejecución, máquinas virtuales y registros; integrarlos con monitoreo de SBOM
-
Mantener SBOMs para el software desplegado; monitorear nuevos CVEs.
-
Puntuar hallazgos (CVSS, EPSS); priorizar correcciones según severidad y explotabilidad.
-
Reconstruir/redesplegar automáticamente cuando haya imágenes parchadas disponibles.
| Tareas |
Herramientas |
PW.6.1:
Usar compiladores, intérpretes y herramientas de build que ofrezcan funcionalidades para mejorar la seguridad del ejecutable.
PW.6.2:
Determinar qué funcionalidades de compiladores, intérpretes y herramientas de build deben usarse y cómo debe configurarse cada una, luego implementar y usar las configuraciones aprobadas.
|
|
Trivy
Trivy ejecuta escaneos semanales sobre todas las imágenes de contenedores y hosts de producción → los resultados son firmados y registrados en Rekor.
|
|
Syft
Regenera SBOMs para artefactos desplegados y marca nuevos CVEs.
|
|
DefectDojo
Puntuación CVSS + asignación de SLA a los responsables.
|
|
Keel
Reconstrucción/redespliegue automático cuando haya imágenes parchadas disponibles.
|
|
Kured
Reinicios automatizados de nodos Kubernetes para parcheo del kernel.
|
|
Argo Rollouts
Usa despliegues canary/escalonados para versiones parchadas.
|
|
OpenVAS
Ejecuta escaneos programados en contenedores en ejecución, máquinas virtuales y registros; se integra con monitoreo de SBOM.
|
|
Rekor
Almacena registros firmados de detección, triage, corrección y verificación.
|
PW.7
Revisar y/o analizar código legible por humanos para identificar vulnerabilidades y verificar el cumplimiento con los requisitos de seguridad: Ayudar a identificar vulnerabilidades para que puedan corregirse antes de que el software sea liberado y así prevenir su explotación. El uso de métodos automatizados reduce el esfuerzo y los recursos necesarios para detectar vulnerabilidades. El código legible por humanos incluye código fuente, scripts y cualquier otra forma de código que la organización considere legible por humanos.
Para cumplir con SSDF PW.7 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Mantener un registro que demuestre que la versión desplegada pasó por el proceso requerido por la organización de revisión de código y/o análisis automatizado.
-
Garantizar que todos los parches de emergencia/hotfix enviados después del despliegue también sean revisados o analizados, incluso si se hace después de la liberación.
-
Mantener evidencia lista para auditoría.
| Tareas |
Herramientas |
PW.7.1:
Determinar si debe utilizarse revisión de código (una persona observa directamente el código para encontrar problemas) y/o análisis de código (se usan herramientas para encontrar problemas en el código, ya sea de forma totalmente automatizada o en conjunto con una persona), según lo definido por la organización.
PW.7.2:
Realizar la revisión de código y/o el análisis de código con base en los estándares de codificación segura de la organización, y registrar y triagear todos los problemas descubiertos y las remediaciones recomendadas en el flujo de trabajo del equipo de desarrollo o en el sistema de seguimiento de issues.
|
|
Semgrep
Ejecuta SAST contra el código exacto vinculado a los binarios desplegados; incluye escaneo de dependencias.
|
|
GitHub CodeQL
Vuelve a ejecutar el análisis de código en espejos de producción.
|
|
DefectDojo
Mantiene registros inmutables de todas las revisiones, aprobaciones y ejecuciones de análisis automatizado.
|
|
Rekor
Commits firmados, historial de ramas protegidas y resultados de escaneo.
|
PW.8
Probar código ejecutable para identificar vulnerabilidades y verificar el cumplimiento con los requisitos de seguridad: Ayudar a identificar vulnerabilidades para que puedan ser corregidas antes de que el software sea liberado con el fin de prevenir su explotación. El uso de métodos automatizados reduce el esfuerzo y los recursos necesarios para detectar vulnerabilidades y mejora la trazabilidad y la repetibilidad. El código ejecutable incluye binarios, bytecode ejecutado directamente y código fuente,
y cualquier otra forma de código que la organización considere ejecutable.
Para cumplir con SSDF PW.8 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Probar continuamente los ejecutables desplegados para detectar vulnerabilidades
-
Verificar el cumplimiento con los requisitos de seguridad
-
Retroalimentar los hallazgos al desarrollo
| Tareas |
Herramientas |
PW.8.1:
Determinar si debe realizarse pruebas de código ejecutable para encontrar vulnerabilidades no identificadas por revisiones, análisis o pruebas previas y, de ser así, qué tipos de pruebas deben utilizarse.
PW.8.2:
Definir el alcance de las pruebas, diseñarlas, ejecutarlas y documentar los resultados, incluyendo el registro y triage de todos los problemas descubiertos y las remediaciones recomendadas en el flujo de trabajo del equipo de desarrollo o en el sistema de seguimiento de issues.
|
|
Trivy
Escanea contenedores y sistemas de archivos desplegados para detectar CVEs conocidas en código y dependencias.
|
|
Grype
Escaneo enfocado de vulnerabilidades para artefactos desplegados.
|
|
Ortelius
Sincronización cada 10 minutos con OSV.dev para detección de nuevas vulnerabilidades en artefactos desplegados.
|
|
OpenVAS / Greenbone
Escaneo de vulnerabilidades de red y hosts.
|
|
Inspec
Mapea resultados de escaneo a estándares de seguridad (NIST, CIS, OWASP ASVS).
|
|
OpenSCAP
Resultados de escaneo de cumplimiento, perfiles base, documentación de excepciones.
|
|
Wapiti
DAST, fuzzing y monitoreo en tiempo de ejecución para detectar comportamiento inseguro.
|
|
Zap (Zed Attack Proxy)
Reportes de DAST y fuzzing.
|
PW.9
Configurar el software para que tenga configuraciones seguras por defecto: Ayudar a mejorar la seguridad del software en el momento de la instalación para reducir la probabilidad de que el software sea desplegado con configuraciones de seguridad débiles, poniéndolo en mayor riesgo de compromiso.
Para cumplir con SSDF PW.9 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Verificar el software y la infraestructura desplegados contra la línea base de configuración segura de la organización (por ejemplo, NIST 800-53, CIS Benchmarks, DISA STIGs).
-
Usar policy-as-code y herramientas de gestión de configuración para mantener los sistemas desplegados en cumplimiento.
-
Integrar validaciones de configuración dentro del monitoreo en tiempo de ejecución
| Tareas |
Herramientas |
PW.9.1:
Definir una línea base segura determinando cómo configurar cada ajuste que tenga efecto en la seguridad o que sea un ajuste relacionado con seguridad, de modo que la configuración por defecto sea segura y no debilite las funciones de seguridad proporcionadas por la plataforma, la infraestructura de red o los servicios.
PW.9.2:
Implementar las configuraciones por defecto (o grupos de configuraciones por defecto, si aplica) y documentar cada configuración para los administradores del software.
|
|
Ortelius
Monitorea continuamente drift en configuraciones de contenedores.
|
|
Inspec
Compara sistemas desplegados contra líneas base seguras de configuración (NIST, CIS, STIG).
|
|
OpenSCAP
Compara sistemas desplegados contra líneas base seguras de configuración (NIST, CIS, STIG).
|
|
Falco
Monitorea continuamente cambios de configuración; alerta o autorremedia desviaciones.
|
|
Wazuh
Logs de detección de drift y acciones de remediación.
|
|
Ansible
Policy-as-code y gestión de configuración para asegurar que todos los despliegues coincidan con la línea base.
|
|
Saltstack
Playbooks de configuración, logs de enforcement e historial de cambios de políticas.
|
|
Git
Almacena resultados de escaneo firmados y registros de detección de drift en sistemas evidentes ante manipulaciones.
|
3.1.4 - 3.4 Responder a Vulnerabilidades (RV)
3.4 Responder a Vulnerabilidades (RV) en los pasos CI/CD post-despliegue
3.4 Responder a Vulnerabilidades (RV) Tareas posteriores al despliegue
Responder a Vulnerabilidades (RV): Las organizaciones deben identificar vulnerabilidades residuales en sus versiones de software y responder de manera adecuada para abordarlas y prevenir que ocurran nuevamente en el futuro.
RV.1
Identificar y confirmar vulnerabilidades de forma continua: Ayudar a garantizar que las vulnerabilidades se identifiquen más rápidamente para que puedan ser remediadas con mayor rapidez de acuerdo con el riesgo, reduciendo la ventana de oportunidad para los atacantes.
Para cumplir con SSDF RV.1 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Escaneo continuo de entornos en vivo para detectar nuevas vulnerabilidades
-
Correlación de vulnerabilidades detectadas con componentes desplegados y datos SBOM
-
Validación de si las vulnerabilidades son explotables en el entorno específico
-
Priorización de la remediación según severidad, explotabilidad e impacto operativo
| Tareas |
Herramientas |
RV.1.1:
Recopilar información de adquirentes de software, usuarios y fuentes públicas sobre posibles vulnerabilidades en el software y componentes de terceros, e investigar todos los reportes creíbles.
RV.1.2:
Revisar, analizar y/o probar el código del software para identificar o confirmar la presencia de vulnerabilidades previamente no detectadas.
RV.1.3:
Contar con una política de divulgación y remediación de vulnerabilidades, e implementar los roles, responsabilidades y procesos necesarios para dar soporte a dicha política.
|
|
OWASP Dependency Track
Se integra con SBOMs en vivo para detectar y alertar vulnerabilidades después del despliegue.
|
|
Ortelius
Vincula las vulnerabilidades detectadas directamente con versiones desplegadas del servicio para trazabilidad.
|
|
DefectDojo
Centro de gestión de vulnerabilidades con métricas y seguimiento.
|
|
Trivy
Identifica vulnerabilidades en imágenes ya desplegadas en entornos Kubernetes o Docker.
|
|
Grype
Funciona con SBOMs generados por Syft para comprobar continuamente nuevos CVEs.
|
|
OpenSCAP
Proporciona escaneos programados de cumplimiento junto con escaneos de vulnerabilidades.
|
|
VEX (Vulnerability Exploitability eXchange) + OpenVEX
Ayuda a los equipos a priorizar la remediación filtrando vulnerabilidades no explotables.
|
|
Syft
Genera SBOMs en vivo para ser consumidos por herramientas como Dependency-Track o Grype.
|
|
Hoppr
Kit de herramientas de cadena de suministro y SBOM que permite gestionar y mover artefactos de procedencia.
|
RV.2
Evaluar, priorizar y remediar vulnerabilidades: Ayudar a garantizar que las vulnerabilidades sean remediadas de acuerdo con el riesgo para reducir la ventana de oportunidad para los atacantes.
Para cumplir con SSDF RV.2 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Determinar qué vulnerabilidades son más relevantes en el entorno desplegado
-
Usar explotabilidad, impacto de negocio y requisitos de cumplimiento para la priorización
-
Ejecutar acciones de remediación o mitigación de manera oportuna en entornos en vivo
-
Rastrear el estado de remediación hasta su cierre con registros auditables
| Tareas |
Herramientas |
RV.2.1:
Analizar cada vulnerabilidad para obtener suficiente información de riesgo para planificar su remediación u otra respuesta de riesgo.
RV.2.2:
Planificar e implementar respuestas de riesgo para vulnerabilidades.
|
|
DefectDojo
Centraliza la puntuación de riesgo, la gestión de flujos de trabajo y el seguimiento del progreso de remediación.
|
|
OWASP Dependency Track
Proporciona priorización de vulnerabilidades en tiempo real e integración con sistemas de seguimiento de issues.
|
|
Ortelius
Permite priorización y evaluación de impacto de vulnerabilidades según el entorno desplegado.
|
|
Jenkins + OPA (Open Policy Agent)
Aplicación de SLAs de remediación y automatización del despliegue de versiones corregidas.
|
|
Trivy + Grype
Escaneo continuo e integración con CI/CD para promover artefactos parcheados.
|
|
GitHub/GitLab Issues + bots de automatización
Asegura que ninguna vulnerabilidad quede sin una acción de remediación rastreada.
|
|
Kube-bench + Falco (seguridad en runtime)
Proporciona señales en tiempo real para priorizar correcciones de seguridad operativa.
|
RV.3
Analizar vulnerabilidades para identificar sus causas raíz: Ayudar a reducir la frecuencia de vulnerabilidades en el futuro.
Para cumplir con SSDF RV.3 en un contexto posterior al despliegue usando herramientas de código abierto, el enfoque cambia a:
-
Determinar si la vulnerabilidad se originó en el código, dependencias, procesos de build o configuraciones de despliegue
-
Documentar lecciones aprendidas para evitar recurrencias
-
Retroalimentar los resultados hacia los requisitos de seguridad, pipelines y capacitación de desarrolladores
| Tareas |
Herramientas |
RV.3.1:
Analizar las vulnerabilidades identificadas para determinar sus causas raíz.
RV.3.2:
Analizar las causas raíz a lo largo del tiempo para identificar patrones, como la falta de adopción consistente de prácticas seguras de codificación.
RV.3.3:
Revisar el software para vulnerabilidades similares y eliminar clases completas de vulnerabilidades de forma proactiva, en lugar de esperar reportes externos.
RV.3.4:
Revisar el proceso SDLC y actualizarlo si es necesario para evitar la recurrencia de la causa raíz en futuras versiones del software o en nuevo desarrollo.
|
|
Ortelius
Soporta análisis forense rastreando cuándo y dónde un componente vulnerable ingresó al sistema.
|
|
DefectDojo
Mantiene datos históricos para identificar tendencias en el origen de vulnerabilidades.
|
|
GitHub
Soporta trazabilidad forense y análisis de responsabilidad en la causa raíz.
|
|
Syft + OWASP Dependency Track
Permite análisis de diferencias de SBOM para investigaciones de causa raíz.
|
|
Semgrep
Ayuda a determinar si las vulnerabilidades provienen de problemas a nivel de código.
|
|
OpenSCAP
Permite mapear la causa raíz hacia debilidades de configuración del sistema.
|
|
Trivy + Grype
Proporciona contexto temporal para análisis de líneas de tiempo de la causa raíz.
|
|
osquery
Soporta inspección profunda durante análisis forense de vulnerabilidades.
|