La protección de su cadena de suministro de software comienza con el descubrimiento y la gobernanza de su "fábrica de software"
En el entorno de desarrollo de software actual, los equipos manejan activos descentralizados, como repositorios de código, procesos de compilación e imágenes de contenedores. Si bien este modelo distribuido ofrece flexibilidad y acelera la producción, también fragmenta los activos y complica la gobernanza y la supervisión de la seguridad, especialmente a medida que las aplicaciones nativas de la nube se vuelven más comunes.
Como resultado, los equipos de seguridad a menudo pierden tiempo valioso al rastrear a los propietarios de código para cargas de trabajo de producción huérfanas cuando surgen problemas de seguridad o cuando artefactos de software no autorizados llegan a producción. La cadena de suministro de software se ha convertido en una superficie de ataque crítica y es esencial recopilar señales de seguridad de manera temprana, desde el desarrollo hasta las etapas de compilación, para evitar puntos ciegos y garantizar que se monitoreen todos los activos a lo largo del ciclo de vida del desarrollo de software (SDLC).
Los equipos de DevSecOps suelen carecer de herramientas automatizadas para mapear continuamente este cambiante panorama de desarrollo, donde se introducen con frecuencia nuevas herramientas y rutas de código. La información suele permanecer aislada en varias plataformas, lo que dificulta el acceso por motivos de seguridad. Las plataformas y herramientas de desarrollo suelen variar a lo largo del desarrollo, la integración y la implementación a medida que el software avanza en las distintas etapas.
Si bien los proveedores de gestión de la postura de seguridad de aplicaciones (ASPM) y capacidad de observación agregan análisis de seguridad, a menudo no logran brindar una vista completa que conecte las rutas de código con la producción.
La presencia de activos obsoletos agrava el problema. Identificar qué repositorios siguen activos en producción puede ser una tarea abrumadora, en particular para las grandes organizaciones. Las fusiones y adquisiciones complican aún más la situación al agregar diversas plataformas y estándares de desarrollo.
Los equipos de DevSecOps a menudo recurren a procesos manuales (como completar manifiestos o etiquetar contenedores), que son tediosos, propensos a errores y a menudo se dejan de lado en favor de prioridades más urgentes.
Piense en ello como si estuviera defendiendo un campo de batalla en constante cambio, donde los equipos de seguridad necesitan un mapa preciso para proteger sus activos. Estos activos están en constante movimiento durante el desarrollo, y se deben identificar y proteger nuevos objetivos. Para abordar esto, se requiere un mecanismo de descubrimiento continuo para mapear los cambios a medida que ocurren.
Las mejores prácticas y marcos de trabajo respaldan este enfoque. Por ejemplo, el Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) exige que las organizaciones verifiquen la procedencia de los componentes de software y mantengan un inventario completo como parte de su proceso de autocertificación. Del mismo modo, el Marco de desarrollo de software seguro (SSDF) del NIST y para los Modelo de madurez de DevSecOps de OWASP (DSOMM) Destacar la importancia del descubrimiento y la visibilidad continuos.
En el resto de esta publicación, describiremos un plan para abordar estos desafíos y exploraremos cómo Scribe Security ayuda a las organizaciones a implementar estas capacidades de manera efectiva.
Plan de Scribe para un descubrimiento eficaz
Discovery genera un mapa modelado en un gráfico, que ofrece una vista de los activos, las relaciones y la situación de seguridad de su fábrica. Esto permite:
- Visibilidad completa y control de propiedad.
- Capacidades de consulta mejoradas.
- Monitoreo de KPIs y métricas de madurez de seguridad.
- Identificación y priorización más rápida de los factores de riesgo.
- Escaneo inicial
El análisis inicial tiene como objetivo crear un mapa de alto nivel de los activos, centrándose en identificar aquellos que requieren un análisis más profundo. Un análisis profundo completo puede llevar mucho tiempo y muchos activos, como los que no están vinculados a la producción o los que están obsoletos, pueden ser irrelevantes. Este análisis inicial generalmente recopila detalles básicos como nombres de repositorios, identificaciones y estadísticas de actividad, pero no incluye una lista completa de confirmaciones o contribuyentes.
Un método consiste en escanear de “derecha a izquierda”. Al acceder a los entornos de producción (por ejemplo, a través de la API de clúster de K8s), el escáner puede identificar imágenes de contenedores en ejecución (activos críticos que reflejan el valor comercial). A partir de ahí, el escaneo se remonta al registro de contenedores y a los repositorios relevantes. El escaneo normalmente se detiene aquí, ya que no suele haber una conexión directa entre el registro y el proceso de SDLC anterior.
Se pueden ejecutar escaneos complementarios de “izquierda a derecha”, identificando repositorios de código, canales de compilación y registros en diferentes etapas del SDLC (por ejemplo, desarrollo, integración, prueba).
El resultado es una lista priorizada de activos en todas las plataformas, lista para un análisis profundo para rastrear el linaje desde el código hasta la producción y evaluar la postura de seguridad del ciclo de vida del desarrollo de software. La priorización se basa en factores como la relevancia para la producción, el nivel de actividad y la actualidad. A veces, el conocimiento institucional de la importancia de los activos ayuda a guiar este proceso.
El análisis inicial se puede programar periódicamente o activarse por eventos como la inserción de código. Los análisis posteriores pueden aplicar criterios de selección automáticos, como el uso de globs para el análisis profundo de activos recién descubiertos.
- Análisis en profundidad
Una vez que se priorizan los activos relevantes, el análisis profundo recopila atributos detallados que establecen relaciones entre los activos, como los identificadores de rama, los identificadores de confirmación y de confirmador y los identificadores de ejecución de la canalización. La duración de este análisis puede variar según el alcance de los activos y los límites de velocidad de la API.
Al final de esta etapa, comienza a tomar forma un gráfico de relaciones de activos, con grupos de activos conectados en torno a repositorios de código (que contienen información de compilación) y entornos de ejecución (con activos de registro). Sin embargo, un linaje completo aún está incompleto, ya que los registros normalmente no almacenan información sobre los procesos que impulsaron los artefactos de compilación.
- Conectando los clusters
Una vez que se establece el inventario, el linaje se puede completar mediante la instrumentación de una herramienta CLI en el pipeline para capturar detalles de procedencia de la compilación o mediante el procesamiento de registros de CI. La instrumentación es el método más confiable, ya que registra atributos clave como los identificadores de repositorio de código, los identificadores de pipeline y ejecución y los identificadores de imagen. Vincula clústeres previamente aislados de manera efectiva y crea un linaje completo de extremo a extremo desde el código hasta la producción.
Un enfoque complementario es el procesamiento de registros de CI, que recupera atributos relevantes pero requiere más recursos y depende de los registros existentes. Si bien este método ofrece una implementación más rápida, la combinación de ambos enfoques produce los mejores resultados: instrumentar los canales críticos y usar el análisis de registros para los recién descubiertos, que luego se pueden evaluar para una instrumentación adicional.
Este enfoque de agrupamiento también considera la agregación de linajes separados en una estructura unificada para productos complejos, como aplicaciones web compuestas de múltiples componentes, como microservicios.
- Lista de materiales de software (SBOM)
Hasta este punto, el enfoque se ha centrado en conectar los activos de desarrollo entre plataformas, estableciendo un linaje claro desde el código hasta la producción para los activos relevantes. Ahora, la atención se desplaza hacia la composición de los artefactos de software en sí. En este paso, se genera un SBOM a partir de esos artefactos y sus repositorios de código asociados, y se agregan al inventario existente.
Al sintetizar un repositorio de código y SBOM de artefactos en un único SBOM, con lógica para correlacionar dependencias y excluir las irrelevantes (como bibliotecas de desarrollo y prueba), el resultado es un SBOM más preciso y completo que el que cualquiera de las fuentes podría proporcionar por sí sola.
- Postura de seguridad y KPI de DevSecOP
El mapeo continuo del inventario de activos y sus relaciones ofrece la mejor oportunidad para evaluar la situación de seguridad de estos activos. Los factores clave incluyen permisos de acceso para identidades humanas y no humanas, verificación de firma de código, dependencias riesgosas o vulnerables y configuraciones de seguridad en varias plataformas y cuentas.
Estos datos se pueden agregar en diferentes dimensiones para medir los KPI de los lanzamientos de productos, los tiempos de implementación hasta la producción y la madurez de DevSecOps. En concreto, permite a los equipos evaluar la adopción de controles de seguridad, como la firma de código y el cumplimiento de las configuraciones de seguridad, lo que ayuda a realizar un seguimiento del progreso y garantizar prácticas de seguridad sólidas.
- Visualización y consulta del gráfico de SDLC y de la cadena de suministro de software
Un beneficio clave del proceso de descubrimiento es la capacidad de visualizar el ciclo de vida del desarrollo de software y la cadena de suministro de software como un gráfico dinámico o un “mapa de batalla”. Esta visualización ofrece una visión integral de todo el ciclo de vida del desarrollo, lo que facilita el seguimiento de los activos y sus relaciones.
El verdadero poder proviene de la capacidad de consultar el gráfico, lo que permite a los equipos plantear preguntas críticas, como:
- “¿Qué componente no superó una comprobación de seguridad durante su compilación o implementación?”
- “¿Qué cargas de trabajo en producción están huérfanas?”
- “¿Quién realizó el cambio que introdujo una vulnerabilidad?”
- “¿Quién es el propietario del activo que necesita ser reparado?”
Consultar el linaje ayuda a los equipos a identificar la causa raíz de los problemas, lo que es una clara ventaja sobre la documentación manual. Los mapeos de propiedad mantenidos manualmente se vuelven obsoletos rápidamente, lo que a menudo lleva a los equipos de DevSecOps a realizar búsquedas ineficientes de las partes interesadas adecuadas. Por el contrario, un gráfico consultable garantiza que la propiedad y la responsabilidad estén siempre actualizadas, lo que reduce el tiempo perdido en el seguimiento de la responsabilidad del código o la infraestructura.
- Opciones de implementación para herramientas de detección
Las organizaciones tienen distintas necesidades en cuanto a la implementación de herramientas de detección, y ofrecer opciones de implementación flexibles es esencial para cumplir con los distintos requisitos de seguridad. Algunos equipos prefieren el acceso remoto a través de una plataforma SaaS, lo que simplifica la gestión y el escalamiento. Por otro lado, los equipos con protocolos de seguridad más estrictos pueden optar por la implementación de escáneres locales para mantener un control más estricto sobre las credenciales confidenciales, como los tokens de API de la plataforma de desarrollo. La elección entre SaaS y la implementación local depende de factores como la postura de seguridad de la organización, las necesidades de cumplimiento y el control sobre los datos.
Conclusión
Proteger la cadena de suministro de software es una batalla constante; ninguna organización debería emprenderla sin un mapa claro. Al implementar un proceso de detección sólido, obtiene una visibilidad integral de su ciclo de vida del desarrollo de software y de su cadena de suministro, lo que garantiza que se tenga en cuenta cada activo, desde el desarrollo hasta la producción. Con herramientas como el modelo de Scribe Security, puede crear un linaje conectado, generar SBOM precisos, evaluar su postura de seguridad y visualizar relaciones críticas dentro de su ecosistema de desarrollo. Este nivel de conocimiento permite a los equipos de DevSecOps identificar vulnerabilidades rápidamente, rastrear sus orígenes y mantener una comprensión actualizada de su panorama de software, algo esencial para mantenerse a la vanguardia en el acelerado y complejo entorno de desarrollo actual.
Escriba ofrece una solución integral para el descubrimiento y la gobernanza como un facilitador crítico para proteger su cadena de suministro de software:
- Escaneos iniciales y profundos – Identifica y prioriza activos como repositorios de código, canalizaciones e imágenes de contenedores en todos los entornos, creando un inventario de componentes relevantes.
- Linaje de extremo a extremo – Conecta clústeres de activos aislados mediante herramientas CLI y registros de CI, formando un linaje completo desde el código hasta la producción.
- Lista de materiales de software (SBOM) – Genera SBOM precisos sintetizando datos de artefactos y repositorios, excluyendo dependencias irrelevantes.
- Evaluación de la postura de seguridad – Evalúa continuamente los controles de acceso, las firmas de código y las dependencias vulnerables para medir los KPI de seguridad.
- Visualización y consulta – Visualiza todo el SDLC y permite realizar consultas para rastrear vulnerabilidades, cargas de trabajo huérfanas y propiedad de activos.
- Implementación flexible – Admite implementaciones tanto locales como SaaS para satisfacer distintas necesidades de seguridad y control sobre datos confidenciales.
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
