- Definición de seguridad de la cadena de suministro de software
- Ataques a las cadenas de suministro de software: ¿por qué son tan comunes?
- El SSDF (NIST 800-218) se ha finalizado y está en vigor
- SLSA es un marco que debes cumplir
- ¿Cómo asegurar su cadena de suministro de software?
- Validar la integridad del software es un desafío
- Garantía de código en todo el SDLC
- Seguridad de la cadena de suministro de software
- Automatización de la evaluación del cumplimiento de SLSA
- Scribe Security: un nuevo estándar de seguridad de la cadena de suministro de software
- ¿Cómo puede ayudar el escriba?
¿Qué es la seguridad de la cadena de suministro de software?
La cadena de suministro de software abarca todo lo que influye o desempeña un papel en un producto o aplicación durante todo su ciclo de vida de desarrollo de software (SDLC).
En los últimos años, los ataques a la cadena de suministro de software se están volviendo más frecuentes y más sofisticados. En su informe de 2022, Gartner establece lo siguiente: "Anticipar la expansión continua de la superficie de ataque empresarial y aumentar la inversión en procesos y herramientas para la detección y remediación de amenazas de identidad y la integridad de la cadena de suministro digital".
Es más importante que nunca proteger todos los componentes, actividades y prácticas de SDLC involucradas en la creación e implementación de software. Los equipos de desarrollo y los proveedores de software deben asegurarse de utilizar únicamente componentes de código libres de vulnerabilidades conocidas y encontrar formas de validar la integridad de su compilación, comprobando si hay manipulaciones no autorizadas.
- Definición de seguridad de la cadena de suministro de software
- Ataques a las cadenas de suministro de software: ¿por qué son tan comunes?
- El SSDF (NIST 800-218) se ha finalizado y está en vigor
- SLSA es un marco que debes cumplir
- ¿Cómo asegurar su cadena de suministro de software?
- Validar la integridad del software es un desafío
- Garantía de código en todo el SDLC
- Seguridad de la cadena de suministro de software
- Automatización de la evaluación del cumplimiento de SLSA
- Scribe Security: un nuevo estándar de seguridad de la cadena de suministro de software
- ¿Cómo puede ayudar el escriba?
Definición de seguridad de la cadena de suministro de software
La cadena de suministro de software se refiere a todo lo involucrado en el desarrollo de una aplicación a lo largo de todo el ciclo de vida de desarrollo de software (SDLC). La creación e implementación de software requiere asegurar las actividades, procesos y componentes de su cadena de suministro. Hay muchos factores a considerar en este sentido, incluido el código personalizado (componentes internos), las dependencias y bibliotecas de código abierto (componentes de terceros), las herramientas e infraestructura de DevOps que conforman el proceso de CI/CD y, finalmente, los desarrolladores y DevOps. equipos.
Es responsabilidad de las organizaciones realizar estas actividades de seguridad y proporcionar pruebas de sus esfuerzos de seguridad a los consumidores.
Ataques a las cadenas de suministro de software: ¿por qué son tan comunes?
Los canales de software modernos son entornos automatizados que dependen de una variedad de herramientas para la integración y entrega continuas. Un proyecto de software puede acabar incluyendo miles de dependencias de código abierto.
Los actores maliciosos pueden hacer pasar bibliotecas fraudulentas como legítimas explotando "defectos lógicos" en los administradores de paquetes de código abierto. Por ejemplo, los paquetes con malware pueden atribuirse a mantenedores confiables sin su conocimiento. Esta confianza fuera de lugar puede introducir vulnerabilidades ocultas y problemáticas en su código. Estas vulnerabilidades pueden proporcionar a los atacantes acceso a datos confidenciales o permitirles instalar malware y sistemas de control en toda la cadena de suministro.
El entorno de desarrollo moderno tiene sus propias vulnerabilidades, y una variedad de ataques a la cadena de suministro de software se dirigieron al proceso de CI/CD para insertar código malicioso en algún punto del proceso de desarrollo. También en este caso, una suposición de confianza cero es el enfoque adecuado para ganar confianza en el producto de software final: comprobar, verificar y validar cada paso de la cadena de desarrollo interno.
Los procesos de CI/CD actuales carecen de visibilidad y controles para proteger adecuadamente el proceso de desarrollo de software. También tienen dificultades para detectar la manipulación del código, lo que hace que este vector de ataque sea aún más atractivo.
El SSDF (NIST 800-218) se ha finalizado y está en vigor
El marco SSDF (NIST 800-218) requiere que los proveedores implementen prácticas de seguridad que cubran el ciclo de vida de desarrollo de software (SDLC). Promueve la transparencia y medidas resistentes a la manipulación en un esfuerzo por reducir las vulnerabilidades de seguridad y la interferencia maliciosa.
Específicamente, contiene pautas para un enfoque basado en evidencia para proteger el software en sí contra manipulaciones.
El SSDF tiene cuatro partes principales:
01 /
Preparar la Organización (PO):
Asegúrese de que las personas estén preparadas y que los procesos y la tecnología estén implementados para realizar un desarrollo de software seguro a nivel de organización y, en algunos casos, para grupos o proyectos de desarrollo individuales.
02 /
Proteger el software (PD):
Proteja todos los componentes del software de cualquier acceso no autorizado o manipulación.
03 /
Produzca software bien protegido (PW):
Produzca software bien protegido con vulnerabilidades de seguridad mínimas en sus versiones.
04 /
Responder a las vulnerabilidades (RV):
Identifique vulnerabilidades residuales en versiones de software, responda adecuadamente para abordar esas vulnerabilidades y evite que se produzcan vulnerabilidades similares en el futuro.
No debe referirse al SSDF como una lista de verificación, sino más bien como una guía para planificar e implementar un enfoque basado en riesgos y evidencia para desarrollar software seguro.
Las empresas deben tomar medidas para mejorar su postura de seguridad a fin de facilitar el cumplimiento de los cambios regulatorios emergentes.
SLSA es un marco que debes cumplir
Un marco originado en Google, llamado SLSA (Niveles de cadena de suministro para artefactos de software), proporciona pautas sobre cómo alcanzar cuatro niveles de protección de la cadena de suministro de software. El marco se centra en la integridad de la construcción de los artefactos con la intención de evitar la manipulación y asegurar los artefactos.
SLSA funciona de esta manera: implementa listas de verificación de controles de seguridad que debe implementar en su canalización, y estos controles están en subdominios como sistemas de control de fuente, sistemas de compilación y dependencias que incorpora a sus proyectos de software.
SLSA establece cuatro niveles de cumplimiento con el objetivo de llegar al nivel 4, que tendría el valor de seguridad más alto, pero tendría una lista de requisitos más larga.
El marco SLSA se basa en el concepto de procedencia. Un documento que representa una “cadena de evidencia” que denota el origen de los artefactos y el proceso de construcción. A medida que aumentan los niveles de SLSA, es necesario proteger mejor la evidencia en sí.
Debe considerar SLSA como un estándar de la industria, un nivel de protección y cumplimiento reconocible y acordado que debe cumplir.
¿Cómo asegurar su cadena de suministro de software?
Sin embargo, nos gustaría subrayar tres clases principales de controles de seguridad:
1. Asegure la configuración del ciclo de vida de su desarrollo de software
Las credenciales comprometidas, el control insuficiente de los permisos y los sistemas de compilación vulnerables crean superficies de ataque que afectan al productor de software. Los atacantes que explotan estas vulnerabilidades pueden robar secretos no seguros o alterar artefactos de software. Una variedad de soluciones comerciales y de código abierto de esta clase pueden proporcionar controles para mapear brechas en la postura de seguridad y remediarlas.
2. Evite depender de dependencias vulnerables o maliciosas
Invariablemente, se seguirán descubriendo nuevas vulnerabilidades en el software comercial y de código abierto. Los productores de software deben mitigar este riesgo actualizando los componentes vulnerables de código abierto, buscando vulnerabilidades autoinfligidas en su código propietario e informando a los consumidores de software sobre la lista de materiales del software (SBOM) y sus implicaciones asociadas. Estos consumidores, a su vez, pueden actuar en consecuencia.
Las cuentas de proyectos de código abierto secuestradas y los paquetes maliciosos que se hacen pasar por legítimos plantean riesgos adicionales, que afectan principalmente al robo de secretos de los oleoductos. La comunidad de código abierto y algunos proveedores comerciales están trabajando para solucionar este problema mediante una mejor reputación y la detección de comportamientos maliciosos.
3. Validar la integridad y la construcción segura de los artefactos de software.
La ciberseguridad requiere una defensa en profundidad. Los ataques pueden pasar desapercibidos cuando se utiliza el enfoque de protección tradicional de reducción de la superficie de ataque, detección y reputación. Más aún, hoy en día los consumidores de software intermedios tienen poca influencia sobre estos controles. Como máximo, pueden confiar en auditorías de seguridad puntuales, como el escaneo de códigos que proporciona una instantánea de la vulnerabilidad, de proveedores que no crean una confianza real en que el artefacto de software esté bien protegido y protegido durante el ciclo de vida de desarrollo.
Ahora está disponible una nueva clase emergente de controles que certifica continuamente la integridad de cada artefacto de software y el proceso de desarrollo seguro. Estas certificaciones no tienen buena reputación y pueden compartirse entre productores y consumidores intermedios que buscan validación. El no repudio se logra mediante métodos criptográficos y, por lo tanto, eleva significativamente el precio para cualquier atacante que se infiltre en la cadena de suministro.
Los expertos en el campo de la seguridad de la cadena de suministro de software consideran esencial este enfoque. Sin embargo, si bien existen algunos componentes básicos de código abierto para admitir esta clase de controles, sólo unos pocos proveedores pueden proporcionar una solución integrada.
Una solución completa de la cadena de suministro de software debe incluir:
La recopilación de pruebas y su firma como certificaciones de los procesos de desarrollo y construcción de software. Normalmente, esta evidencia son hashes de archivos con metadatos que se comparan entre pasos relevantes del proceso, eventos sobre pasos relacionados con la seguridad, como identidades de autores de código, revisiones de código, pruebas de seguridad automáticas, etc. También es necesario proporcionar una certificación sobre la situación de seguridad del proceso de construcción del productor de software en el momento en que se creó el artefacto de software.
Un almacén de atestación seguro que permite visibilidad y admite análisis como la validación de la integridad del código.
Un motor de políticas que mide estas certificaciones con respecto a una política definida por la organización o una política basada en estándares para la validación y demostración del cumplimiento.
Un centro para compartir información relacionada con la confianza entre productores o consumidores de software; esto podría ser inter o intraempresa).
Validar la integridad del software es un desafío
En teoría, comprobar la integridad del código debería ser fácil. Simplemente compare archivos, ¿verdad? En realidad, hay mucho que considerar. Para empezar, cada idioma compila archivos de manera diferente. Además, los archivos se utilizan de forma muy diferente según su finalidad. Algunos están destinados a cambiar, mientras que otros se eliminan y otros se crean durante el proceso de compilación.
A esto se suma el hecho de que las empresas no quieren ceder su código propietario entre sí.
Garantía de código en todo el SDLC
Scribe se propone proteger todo su SDLC continuamente. Con evidencia recopilada de varias partes del proceso de desarrollo y construcción, Scribe utiliza la firma digital para crear certificaciones infalsables.
Una vez firmada, cada pieza de evidencia se puede verificar posteriormente para garantizar que todos los procesos se llevaron a cabo según lo planeado y que no se produjeron alteraciones no planificadas.
Siguiendo las mejores prácticas establecidas en el SSDF, Scribe le permite emplear políticas de sentido común para aumentar su confianza durante todo el proceso de desarrollo. Políticas como exigir confirmaciones firmadas, 2FA para desarrolladores, revisión de código por dos personas, etc., ayudan a generar confianza en que cada pieza de software se produjo siguiendo la postura de seguridad correcta.
Recopilar toda esta evidencia en una sola ubicación, junto con un informe de integridad del código y un resumen de todas las políticas y certificaciones permite una mayor visibilidad y confianza en el proceso de desarrollo y los artefactos de software producidos al final y está alineado con las pautas SSDF vigentes. en la base de la nueva regulación cibernética.
Permitir que suscriptores selectos vean el cumplimiento del producto con los requisitos de políticas y los resultados de integridad ofrece a los usuarios una mayor visibilidad y confianza en sus procesos de desarrollo y el producto de software final.
El resultado final no es sólo detectar la manipulación del código o de la canalización, sino también la capacidad de dar fe de las pruebas y procedimientos de seguridad que tuvieron lugar durante el diseño y la construcción del software, así como la integridad del código fuente y los paquetes de código abierto. utilizado en su construcción.
Seguridad de la cadena de suministro de software
Automatización de la evaluación del cumplimiento de SLSA
La seguridad de las tuberías dinámicas debe medirse continuamente. SLSA (Niveles de cadena de suministro para artefactos de software) define cuatro niveles de protección de la cadena de suministro de software junto con pautas sobre cómo alcanzarlos.
Una evaluación de cumplimiento de SLSA se puede automatizar para cumplir con sus requisitos. Pero, ¿cómo debería proceder una organización para adquirir uno? ¿Existen mejores prácticas específicas que deba seguir?
Mire este video donde compartimos las mejores prácticas para implementar la automatización, utilizando herramientas de código abierto como Sigstore y OPA en escenarios del mundo real. Las mejores prácticas tanto conceptuales como técnicas arrojan luz sobre los detalles y los desafíos del mundo real al evaluar y automatizar el cumplimiento de SLSA.
| Antes de usar Escriba | Después de usar Escriba | |
|---|---|---|
| Centro de confianza: intercambio de información |
|
|
| SDLC seguro: política y cumplimiento |
|
|
| Detección de integridad y manipulación |
|
|
| Visibilidad |
|
|
| Postura de seguridad |
|
|
Scribe Security: un nuevo estándar de seguridad de la cadena de suministro de software
Realice un seguimiento de cada detalle y evento en el proceso de desarrollo de software, así como de la integridad de los componentes y artefactos del software.
Verificar que no se haya producido manipulación en ninguna y todas las partes del proceso de desarrollo de software.
Verificar la integridad de las herramientas CI/CD utilizadas para construir el código.
Confirmar la integridad del proceso de desarrollo, asegurando que los pasos relacionados con la seguridad se llevaron a cabo de acuerdo con la política de la organización y no se hayan omitido.
Al recopilar y firmar evidencia de todo lo que sucede con el código, en cada etapa del ciclo de vida de desarrollo, hace que sea más difícil para los atacantes alterar archivos, herramientas o el comportamiento esperado de su proceso de CI/CD.
AYUDA?
