Este artículo fue coescrito por Mikey Strauss Víktor Kartashov.
Convierta los 10 principales riesgos de OWASP en controles automatizados y auditables
En los entornos DevOps modernos, las canalizaciones de CI/CD son la columna vertebral de la entrega de software. Sin embargo, una gran velocidad conlleva una mayor exposición. A medida que las organizaciones aceleran los lanzamientos, los atacantes atacan cada vez más las canalizaciones inseguras para inyectar código malicioso, exfiltrar información confidencial o comprometer la integridad de la cadena de suministro.
Para abordar esto, el marco de los 10 principales riesgos de seguridad de CI/CD de OWASP destaca las debilidades más comunes y críticas en los procesos de desarrollo. Seguridad del escribaHemos adoptado este marco para ayudar a las organizaciones a integrar la seguridad CI/CD directamente en sus flujos de trabajo a través de evidencia firmada, aplicación basada en iniciativas y políticas como código.
Por qué son importantes los riesgos de CI/CD de OWASP
Las herramientas de seguridad tradicionales tienen dificultades para seguir el ritmo de los flujos de trabajo modernos. Sin la aplicación y la visibilidad automatizadas, se filtran problemas comunes:
❌ Secretos codificados en las configuraciones de canalización
❌ Artefactos de construcción manipulados sin procedencia
❌ Imágenes de bases de datos inseguras extraídas de registros públicos
❌ Acceso a nivel de administrador sin 2FA ni controles de revisión
El marco de trabajo OWASP formaliza estos riesgos, proporcionando un lenguaje y una estructura compartidos para su remediación. En Scribe, lo utilizamos para definir iniciativas que verifican automáticamente la seguridad de sus pipelines de CI/CD, sin necesidad de realizar cambios importantes en su proceso de compilación.
La seguridad comienza con la evidencia firmada
Para validar que su canalización sea segura, recopilamos y firmamos criptográficamente evidencia como:
- Git SBOM y SBOM de imagen
Generado usando escriba-seguridad/acción-bombaEstos proporcionan visibilidad completa de lo que hay en su código y contenedores. - Procedencia de SLSA
Captura cómo, dónde y quién construyó tus artefactos. - Escaneos de organizaciones y repositorios de GitHub
Ejecutar a través de plataformas de acción para comprobar secretos, desviaciones de configuración y acceso mal configurado.
Toda esta evidencia está firmada, lo que garantiza la integridad y la trazabilidad, y se asigna a productos y versiones específicos para el seguimiento del ciclo de vida.
📌 Cubrimos este modelo basado en evidencia en nuestras publicaciones anteriores sobre Cumplimiento de SLSA Aplicación de la norma SP 800–190.
🔒 Aplicación de los controles de OWASP mediante políticas como código
En Scribe, mapeamos los 10 principales riesgos de CI/CD de OWASP en un iniciativa de política como código que se ejecuta directamente en su canalización de CI. Cada riesgo se representa como una regla configurable definida en un entorno local. owasp-top10-cicd.yaml archivo. Estas reglas se evalúan automáticamente durante la fase de verificación, lo que proporciona información práctica y orientación para la solución.
A continuación se muestran algunos de los controles clave incluidos:
- CICD-SEC-1 : Hacer cumplir las reglas de protección de sucursales
Evite cambios de código no autorizados restringiendo los envíos directos a ramas críticas como principal. - CICD-SEC-2 : Controles de gestión de identidad y acceso
Requiere autenticación multifactor (MFA) y limita los privilegios administrativos en tu proveedor de Git. - CICD-SEC-3 : Verificación de dependencia
Asegúrese de que todas las imágenes base y las dependencias de terceros se extraigan de registros aprobados y confiables. - CICD-SEC-4 : Prevención de la ejecución de tuberías envenenadas
Restrinja quién puede modificar los scripts de CI/CD para evitar introducir lógica maliciosa en sus flujos de trabajo. - CICD-SEC-6 : Control de la higiene de las credenciales
Escanee en busca de secretos codificados, tokens vencidos o credenciales filtradas y luego márquelos antes de publicarlos.
Cada uno de estos controles se puede personalizar según la tolerancia al riesgo, el entorno o los requisitos de cumplimiento de su organización. Al estar definido como código, su postura de seguridad se vuelve... auditable, versión controladay ejecutable mediante automatización.
✅ Pro consejo: Puede incluir o excluir reglas específicas, establecer umbrales de gravedad e incluso personalizar consejos de solución, directamente en su archivo de configuración de iniciativa.
Al incorporar estos controles a su canalización, pasa de revisiones ad hoc a aplicación de seguridad automatizada y verificable – un paso fundamental para proteger su cadena de suministro de software.
Acciones de GitHub: Integración de CI/CD en el mundo real
A continuación se muestra un ejemplo de flujo de trabajo que utiliza las acciones de Scribe para crear, recopilar evidencia, escanear la organización y verificar el cumplimiento con el marco de CI/CD OWASP Top 10:
nombre: OWASP CI/CD Secure Build en: push: ramas: - main env: NOMBRE_DE_PRODUCTO: my-app VERSIÓN_DE_PRODUCTO: v1.0 trabajos: compilación: se ejecuta en: ubuntu-latest salidas: nombre-de-imagen: ${{ steps.meta.outputs.image }} pasos: - usos: actions/checkout@v4 - usos: docker/setup-buildx-action@v3 - ejecución: echo "${{ secrets.REGISTRY_PASSWORD }}" | inicio de sesión de docker ${{ secrets.REGISTRY_URL }} -u ${{ secrets.REGISTRY_USER }} --password-stdin - id: meta usos: docker/build-push-action@v5 con: contexto: . push: verdadero etiquetas: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} - usos: scribe-security/action-bom@master con: objetivo: 'git:.' clave de producto: ${{ env.PRODUCT_NAME }} versión de producto: ${{ env.PRODUCT_VERSION }} formato: attest - usos: scribe-security/action-bom@master con: destino: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} imagen base: Dockerfile clave de producto: ${{ env.PRODUCT_NAME }} versión de producto: ${{ env.PRODUCT_VERSION }} formato: attest - usos: scribe-security/action-verify@master con: destino: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} clave de producto: ${{ env.PRODUCT_NAME }} versión de producto: ${{ env.PRODUCT_VERSION }} iniciativa: slsa.l2@v2 procedencia: verdadero formato: attest embellecer: verdadero org-scan: se ejecuta en: ubuntu-latest pasos: - usos: scribe-security/action-platforms@master con: comando: discover plataforma: github sign: true attest-default: sigstore argumentos: >- --token ${{ secrets.GITHUB_PAT }} --organization.mapping ${{ github.repository_owner }}::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --repository.mapping $(basename ${{ github.repository }})::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --scope.workflow.past_days 1 --scope.branch ${{ github.ref_name }} --hook trivy_iac_and_secrets_sarif verificar: se ejecuta en: ubuntu-latest necesita: [compilación, escaneo de organización] pasos: - usos: scribe-security/action-verify@master con: iniciativa: owasp-top10-cicd.yaml clave de producto: ${{ env.PRODUCT_NAME }} versión de producto: ${{ env.PRODUCT_VERSION }} formato: attest all-evidence: true embellecer: true
Cumplimiento continuo en acción
Este flujo de trabajo genera una certificación verificable que muestra qué riesgos de OWASP se aprueban o no en su pipeline. Cada infracción se puede rastrear a evidencia específica (SBOM, registros de flujo de trabajo y configuraciones de la organización), lo que permite a los equipos solucionar problemas con rapidez y seguridad.
¿Quiere ver cómo se ve esto en la práctica? Aquí tiene un ejemplo del resultado de un análisis de uno de nuestros procesos internos:
Vista de resumen
Vista de violación
Vista de la evidencia
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
