Proteja su cadena de suministro de software desde la compilación hasta el despliegue

Evite que las imágenes de contenedor no escaneadas, no firmadas o vulnerables lleguen a producción. Esta guía muestra cómo los controles de registro privado, el escaneo de vulnerabilidades, la firma de artefactos y las políticas de admisión de Kubernetes crean un flujo de trabajo ejecutable en toda la cadena de suministro de software. 
Empezar ahoraManaged Private Registry
Ilustración de nombres de dominio

Verifique cada componente de su pipeline

La seguridad de la cadena de suministro de software implica verificar continuamente cada dependencia, paquete y artefacto en un pipeline CI/CD. La confianza debe abarcar el código fuente, los paquetes públicos, la tecnología externa, los componentes de terceros, los elementos de compilación, los registros y la versión final. Una amenaza puede entrar a través de dependencias alteradas o procesos comprometidos. Empiece identificando cada componente orientado al cliente frente a un marco reconocido, como la guía del NIST o los principios SSCS. Los equipos pueden entonces aprender dónde faltan pruebas, aplicar prácticas de codificación segura y firmar los resultados con Cosign. Este enfoque basado en marcos le permite aplicar garantías a lo largo de toda la cadena en lugar de depender de un único punto de control. Cada parte puede rastrear qué entró en la compilación, cómo se manejó y qué pruebas respaldan el despliegue.
[object Object]

Construya la garantía de lanzamiento sobre controles verificables

Proyectos Private Harbor, políticas de Trivy, firma con Cosign y jurisdicción europea
Community@2x.png
Restrinja el acceso al registro
Cyber Security@2x.png
Bloquee las vulnerabilidades conocidas
Magnifying Glass Check@2x.png
Verifique el origen y la resiliencia

Proteja cada etapa expuesta a posibles ataques

¿Qué es la seguridad de la cadena de suministro en un entorno de contenedores moderno?

¿Qué es la seguridad de la cadena de suministro en un entorno de contenedores moderno? Esta protege la ruta desde el código fuente y las dependencias de terceros a través de los sistemas de compilación, el almacenamiento de imágenes y los puntos finales de despliegue. La seguridad de la cadena de suministro de software trata estos procesos como conectados, ya que un ataque en un extremo puede debilitar todos los controles posteriores.

Protección del repositorio de código fuente

Un repositorio de código fuente es un objetivo claro. Un atacante puede robar credenciales, alterar códigos, desactivar una regla de revisión o introducir una dependencia que parezca legítima. Las fuentes de descarga controladas, la revisión obligatoria por pares y las ramas protegidas forman la primera línea de defensa. Los equipos también deben bloquear las versiones de las dependencias y verificar las sumas de comprobación, las licencias y los orígenes, en lugar de aceptar entradas cambiantes para cada compilación. Estas comprobaciones reducen el riesgo de importar software malicioso o no autorizado de terceros.

Rutas de ataque a la infraestructura de compilación

La infraestructura de compilación presenta diferentes rutas de ataque. Los ejecutores comprometidos, los secretos expuestos o las imágenes base mutables pueden modificar un artefacto después de que los desarrolladores aprueben su código fuente. Aísle los procesos de compilación, utilice credenciales de corta duración y registre las entradas exactas. Este enfoque respalda la seguridad de las imágenes de contenedor al facilitar el rastreo de cambios de código inesperados.

Controles del registro al clúster

La ruta del registro al clúster necesita controles independientes. Un atacante podría reemplazar una imagen aprobada, reutilizar una etiqueta antigua o explotar permisos de despliegue excesivos. El acceso con privilegios mínimos restringe lo que cada identidad puede publicar o recuperar. Las referencias inmutables conectan los manifiestos con imágenes precisas, mientras que Kyverno puede rechazar versiones que carezcan de pruebas fiables o infrinjan los requisitos de seguridad.

Una gestión eficaz de la cadena de suministro de software comienza con un inventario. Registre las bibliotecas de terceros y de primera parte, las imágenes base, las licencias y las herramientas de compilación utilizadas por cada aplicación. Conecte cada lista de materiales de software (SBOM) con el proyecto, la confirmación y la ejecución del pipeline que produjo su artefacto. Esta relación ayuda a los equipos de ciberseguridad a identificar los servicios afectados cuando un componente sensible se ve comprometido. Elija una herramienta que exporte pruebas legibles por máquina y compare las versiones mediante automatización. El inventario debe desarrollarse junto con el software, en lugar de depender de un trabajo manual periódico. Asigne un contacto para los temas de dependencias, excepciones y remediación para que la responsabilidad siga estando clara.
Ejecute las pruebas de seguridad con la suficiente antelación para ofrecer a los desarrolladores resultados procesables. La automatización del pipeline puede examinar las dependencias de origen, las capas de contenedor y la configuración antes de la promoción. Defina los umbrales de escaneo de CVE según la exposición de la carga de trabajo y el impacto empresarial, y luego dirija los resultados fallidos al equipo responsable. Una comprobación fallida debería detener el progreso en lugar de generar una alerta no leída. Registre el problema, el paquete afectado, la gravedad y la respuesta aprobada. Esta evidencia ayuda a proteger la calidad de la versión a la vez que mantiene coherentes las decisiones de seguridad de la cadena de suministro de software en todas las aplicaciones.
La firma de imágenes demuestra qué proceso controlado aprobó un artefacto. Firme cada imagen mediante un resumen inmutable una vez superadas las pruebas requeridas y, a continuación, conserve la procedencia que identifica la revisión de origen, el creador y el flujo de trabajo. Evite firmar únicamente etiquetas mutables, ya que una etiqueta puede hacer referencia posteriormente a contenido diferente. Separe los permisos de firma del acceso general de los desarrolladores y del pipeline. La verificación debe utilizar identidades de confianza o claves públicas definidas por su organización. Un proceso de compilación comprometido no puede crear pruebas aceptables a menos que también cumpla la política de firma.
Un controlador de admisión de Kubernetes proporciona el punto de decisión final antes de que las cargas de trabajo entren en un clúster. Configúrelo para rechazar imágenes sin firmar, registros no aprobados, criterios de vulnerabilidad fallidos o procedencia faltante. Kyverno y OPA Gatekeeper pueden expresar estas condiciones como políticas controladas por versiones. Pruebe cada regla con cargas de trabajo representativas antes de su aplicación en producción. Comience en modo de auditoría para encontrar excepciones legítimas y, a continuación, ponga los controles maduros en modo de bloqueo. Mantenga una ruta de excepción autorizada con un propietario, un motivo y una fecha de expiración. El clúster puede entonces evaluar las pruebas de lanzamiento de forma coherente, incluso cuando un control anterior se omite o se configura incorrectamente.
Una gestión eficaz de la cadena de suministro de software comienza con un inventario. Registre las bibliotecas de terceros y de primera parte, las imágenes base, las licencias y las herramientas de compilación utilizadas por cada aplicación. Conecte cada lista de materiales de software (SBOM) con el proyecto, la confirmación y la ejecución del pipeline que produjo su artefacto. Esta relación ayuda a los equipos de ciberseguridad a identificar los servicios afectados cuando un componente sensible se ve comprometido. Elija una herramienta que exporte pruebas legibles por máquina y compare las versiones mediante automatización. El inventario debe desarrollarse junto con el software, en lugar de depender de un trabajo manual periódico. Asigne un contacto para los temas de dependencias, excepciones y remediación para que la responsabilidad siga estando clara.

Asigne la responsabilidad en cuatro prioridades de gobernanza

Código de confianza y gobernanza de proveedores

Un líder designado debe definir los criterios de confianza para las fuentes y los proveedores, con el apoyo de los recursos de contratación, ingeniería y seguridad. Utilice SLSA como guía para una mayor integridad de compilación y procedencia sin asumir un nivel de logro particular. Adapte las revisiones al tamaño de la organización y al riesgo de la cadena de suministro de software.

Aplicación de políticas e infraestructura conforme

Los propietarios de la seguridad y de la plataforma deben traducir las obligaciones de cumplimiento en una aplicación de políticas medible en todo el código, la nube y la infraestructura. Defina quién puede aprobar excepciones, qué pruebas deben aportar y cómo los controles cumplen los requisitos internos.

Documentación, auditorías y pruebas

Asigne un recurso responsable para mantener la documentación de las decisiones, las dependencias y los cambios de control. Las auditorías periódicas deben comprobar si los registros coinciden con la práctica operativa. Proporcione a los revisores suficiente apoyo para rastrear un problema hasta su propietario, la versión afectada y su resolución.

Preparación ante incidentes y responsabilidad de la corrección

Un líder de seguridad debe coordinar las funciones de respuesta antes de que un atacante las ponga a prueba. Mantenga un plan para abordar posibles problemas, que cubra la clasificación, la contención, la comunicación con las partes interesadas y la recuperación. Cada acción necesita un responsable, recursos de apoyo y plazos adecuados a la exposición al riesgo de la organización.

Opere Harbor a través de cuatro pilares de seguridad

Controle el acceso con precisión

Harbor admite RBAC a nivel de proyecto y de equipo para separar las cargas de trabajo y las responsabilidades de la empresa. Emita cuentas de robot con alcance limitado para las tareas de push y pull de CI/CD en lugar de compartir credenciales humanas generales. Asocie cada identidad a un único propósito, rote su secreto y elimine el acceso no utilizado. Esta práctica limita el impacto de la exposición de credenciales a la vez que asegura la publicación diaria.

Detecte componentes inseguros de forma continua

Combine comprobaciones continuas de Trivy con análisis de composición de software (SCA) y gestión de dependencias. Estas herramientas detectan vulnerabilidades conocidas, paquetes obsoletos e indicadores de código malicioso dentro de cada componente. Genere un informe claro para cada versión, incluyendo la gravedad, la localización y el estado de la corrección. Los equipos pueden entonces distinguir los hallazgos bloqueantes de las excepciones aceptadas y observar cuándo la nueva información afecta a los artefactos almacenados.

Conecte los flujos de trabajo de desarrollo

Integre la plataforma con GitLab CI, Tekton y otros flujos de trabajo de desarrollo aprobados. Mantenga las decisiones de política cerca del pipeline para que una comprobación fallida devuelva información útil antes de la promoción. Las referencias de gestión del código fuente (SCM) deben vincular cada artefacto con su confirmación, ejecución de compilación y propietario. Los equipos de DevSecOps disponen entonces de un registro coherente en lugar de pruebas separadas dispersas por los sistemas.

Prepare la respuesta operativa

Mantenga un plan de respuesta ante incidentes para credenciales comprometidas, imágenes inseguras y controles fallidos. Defina quién pausa la distribución, elimina una versión afectada, investiga el acceso y aprueba la recuperación. Las alertas necesitan un responsable y una ruta de respuesta esperada; generarlas por sí solas no reduce el riesgo. Realice ejercicios para confirmar que los equipos de seguridad y de plataforma pueden encontrar el informe pertinente, aislar el contenido y comunicar las decisiones. Este pilar operativo convierte la detección en una acción oportuna en toda la plataforma de entrega.

Preserve pruebas fiables para cada versión

La visibilidad de la versión depende de pruebas que muestren quién produjo un artefacto, de dónde procedía y cómo se probó. Genere y conserve los resultados de Trivy, los datos de la lista de materiales de software y las firmas para cada imagen y conjunto de gráficos de Helm. Esto permite a la organización identificar cada tipo de contenido e investigar un posible problema de seguridad. Integre las comprobaciones con GitLab CI para automatizar la respuesta a los desarrolladores antes de que el software entre en el entorno controlado. Las pruebas coherentes también apoyan la concienciación sobre seguridad al mostrar por qué falló una versión. Proteja las claves de firma de Cosign mediante OVHcloud Key Management Service, utilizando almacenamiento respaldado por HSM FIPS 140-2. La gestión centralizada de claves ayuda a garantizar que cada firma generada esté vinculada a material de clave controlado en lugar de a un secreto de pipeline expuesto.
[object Object]
Haga cumplir su política de lanzamiento de contenedores con OVHcloud
Cree una ruta controlada desde la salida de CI/CD hasta el despliegue en Kubernetes con Managed Private Registry y Managed Kubernetes Service. Evalúe cómo la validación del registro, la evidencia de lanzamiento y la aplicación en el clúster pueden detener imágenes no escaneadas, no firmadas o vulnerables antes de la producción. Descubra Managed Private Registry y, a continuación, evalúe la integración de Kubernetes para sus cargas de trabajo, modelo de políticas y responsabilidades operativas.
Explorar la ruta del registro