1.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 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 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 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. |
|
|
CDEvents es una especificación común para eventos de entrega continua, permitiendo interoperabilidad en todo el ecosistema de producción de software. |
|
|
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. |
|
|
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 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 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 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 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 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 |
|
|
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. |
|
|
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 es un sistema integrado de seguimiento usado para gestionar trabajo, errores, solicitudes de funcionalidades y discusiones directamente en un repositorio GitHub. |
|
|
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 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 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 (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 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 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 |
|
|
GitLab |
|
|
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.