Cuando tres agencias gubernamentales de EE. UU. se reúnen para “alentar firmemente” a los desarrolladores a adoptar ciertas prácticas, se debe prestar atención. La CISA, la NSA y la ODNI, en reconocimiento de la amenaza de los ciberpiratas y tras el ataque de SolarWinds, anunciaron que publicarán conjuntamente una colección de recomendaciones para proteger la cadena de suministro de software y evitar este tipo de vulnerabilidades en el futuro. . El anuncio dejó en claro que el propósito del documento es alentar a los desarrolladores a adoptar las mejores prácticas, afirmando que “Estos principios incluyen la planificación de requisitos de seguridad, el diseño de la arquitectura del software desde una perspectiva de seguridad, la adición de funciones de seguridad y el mantenimiento de la seguridad del software y la infraestructura subyacente."
Esta guía está organizada en una serie de tres partes y se publicará coincidiendo con el ciclo de vida de la cadena de suministro de software. Parte 1 de la serie., que se centra en recomendaciones para desarrolladores de software, se publicó en agosto de 2022. Las dos partes restantes se publicarán en un futuro próximo: la parte 2 se centrará en los proveedores de software y la parte 3 se centrará en los clientes que reciben el software. El objetivo final es que esta serie ayude a fomentar la comunicación entre estas tres partes interesadas clave y entre los profesionales de la ciberseguridad para facilitar una mayor resiliencia y mejorar en general. seguridad de la cadena de suministro de software.
Si bien no siempre está claro quién es la responsabilidad de garantizar la seguridad del software, independientemente de quién pueda tener la responsabilidad general en su organización específica, esto nueva guía deja muy claro que todos los desarrolladores deben familiarizarse con estas nuevas mejores prácticas y que todos tienen un papel en la seguridad de la cadena de suministro de software. O, si puedo ser más directo: Desarrolladores, ustedes desempeñan un papel fundamental a la hora de proteger la cadena de suministro de software de su organización. Y por esa razón, pensamos que podría resultarle útil leer un resumen (relativamente) breve de esta primera parte de la guía, solo para usted. Aquí viene.
La guía en pocas palabras:
Entre las extensas listas de amenazas potenciales a las que se hace referencia en esta guía práctica para desarrolladores, se han identificado algunas vulnerabilidades clave y usted debe asegurarse de abordarlas y prepararse para ellas:
- Funciones que no se han documentado adecuadamente o que implementan funciones riesgosas
- Cambios ocultos en los supuestos básicos de seguridad entre el momento de la evaluación de seguridad y la entrega del código
- Cambios corporativos para las partes interesadas de la cadena de suministro
- Prácticas de seguridad o codificación deficientes
Todos los gerentes de administración, finanzas y programas tienen la responsabilidad de abordar la seguridad de la cadena de suministro de software, pero la integridad de seguridad de la cadena de suministro de software A menudo depende de la vigilancia de los desarrolladores de software y de la concienciación entre todas las partes interesadas de la cadena de suministro. La parte 1 de la guía se centra en el papel de los desarrolladores y las amenazas inherentes a cada etapa del proceso de desarrollo, y ofrece recomendaciones para estrategias de mitigación que deberían convertirse en prácticas estándar.
Etapa #1: Criterios y gestión seguros del producto
El desarrollo seguro comienza con el reconocimiento de la importancia de la seguridad de la cadena de suministro de software por parte de todas las partes interesadas clave en los equipos de desarrollo y productos. Los escenarios de amenaza son comunes y pueden resultar claros para todos; el desafío es lograr que todos estén en sintonía con respecto a las políticas de mitigación que se han decidido. Estas políticas deben cubrir todo el proceso: el diseño y la arquitectura, el modelado de amenazas, la codificación, los planes de prueba de seguridad, los criterios de liberación y cómo gestionar las vulnerabilidades en el futuro. Parte de esto también incluye evaluar las capacidades de los equipos y garantizar que hayan recibido la capacitación adecuada para sus tareas y luego definir prácticas de documentación y revisiones periódicas de seguridad y evaluaciones de amenazas.
Etapa #2: Desarrollo de código seguro
Cuando se trata de desarrollo de código, las prácticas correctas para la codificación segura ya se han establecido en el SSDF. Esta es la razón por la que, en la medida en que el lenguaje de programación no haya sido predeterminado, las consideraciones de seguridad también deberían ser parte de esa decisión. La guía proporciona una guía útil para desarrolladores, que aborda una amplia gama de escenarios, como la inserción de código fuente dañino por parte de 'iniciados' (por ejemplo, desarrolladores), software de código abierto y las mejores prácticas para abordarlo. Cómo crear un entorno seguro para la codificación (incluidas configuraciones de compilación seguras y herramientas de software de terceros) y posteriormente probar la seguridad de un producto integrado. Dado que es probable que también surjan vulnerabilidades después de la entrega, también existen recomendaciones para abordar las vulnerabilidades informadas y garantizar que futuras extensiones de software externo no comprometan la integridad de la seguridad del producto.
Etapa 3: reforzar el entorno de construcción
Una vez que el código se ha desarrollado de forma segura, la seguridad de la cadena de suministro de software requiere que el entorno de construcción esté reforzado con los mismos estándares que el propio software. Comprometer el sistema de compilación es una forma atractiva de infiltrarse en el código, ya que llega en una etapa del proceso de desarrollo que, naturalmente, es menos examinada por los desarrolladores.
Etapa # 4: entrega de código
La última debilidad que aborda la guía cubre la etapa final de la cadena de suministro de software: la entrega de código. Incluso cuando el código se ha protegido adecuadamente hasta este punto, todavía hay dos vulnerabilidades clave en la cadena de suministro que deben mitigarse. La primera es la validación final del paquete, que puede explotarse, por ejemplo, exponiendo inadvertidamente metadatos, credenciales de desarrollador o el inventario de código abierto. El otro paso en el que a menudo se investigan las debilidades es el sistema de distribución, que podría verse comprometido por un ataque de intermediario que puede hacerse cargo de una o más etapas de la entrega.
Al aplicar estas prácticas de mitigación de riesgos a nivel de desarrollo de software, los proveedores de software pueden evitar debilidades que pueden conducir, por ejemplo, a la infiltración de actualizaciones, manipulación de firmas de código y “sorpresas” ocultas en el código fuente abierto.
No hay nada gratis: el coste oculto del software de terceros
Una de las claves Contribuyente a la velocidad del desarrollador. se ha convertido en la capacidad de incorporar eficazmente software de terceros. Esto ha hecho posible que los desarrolladores se centren, por ejemplo, en la innovación o la funcionalidad, mientras utilizan componentes ya preparados para la escalabilidad o las interfaces. Este mayor uso de software de terceros ha creado un desafío importante para la seguridad de la cadena de suministro de software. Además de realizar una evaluación de dicho código de acuerdo con los mismos estándares utilizados para evaluar el suyo propio, la guía sugiere escanear los binarios en busca de vulnerabilidades y evaluar los riesgos resultantes. Los resultados de esta evaluación deben influir en la decisión de utilizar o no un componente de software específico. La selección de un componente de software también debe tener en cuenta su origen; La incorporación de componentes de terceros en su código fuente es el comienzo de una relación larga y debe esforzarse por trabajar con socios en los que pueda confiar. La propiedad del código, las prácticas de codificación y las políticas de gestión de versiones son sólo algunos puntos a considerar al seleccionar una fuente confiable. Basta pensar en todas las futuras actualizaciones, lanzamientos y trabajos de mantenimiento de cada componente a medida que se descubren nuevas amenazas. El desafío será monitorear todos los cambios de terceros, evaluar las vulnerabilidades y responder en consecuencia, a veces bajo una gran presión de tiempo.
Aumente la seguridad de su cadena de suministro de software con un SBOM
Una práctica clave para garantizar la integridad a largo plazo de su cadena de suministro de software es mantener una actualización Lista de materiales del software (SBOM). El SBOM es un inventario detallado de los componentes de software que componen una solución determinada.
Esto le ahorrará tiempo y esfuerzo y, lo más importante, reducirá su exposición a amenazas continuas. Cada componente de software que se incorpore a su producto debe venir con su propio SBOM, que debe validarse y fusionarse en un único SBOM "maestro" para el producto. Si tiene intención de incorporar componentes que no vienen con un SBOM, deberá realizar su propio análisis utilizando herramientas de análisis de composición de software (SCA).
Cuanto más preciso y descriptivo sea el SBOM, más fácil será de mantener y consultar. Dada la vertiginosa velocidad a la que se actualizan los componentes de software, un SBOM bien estructurado pagará dividendos cuando llegue el momento de rastrear y registrar cada actualización, parche o lanzamiento. Aún más importante es que una vez que se descubre una amenaza a la seguridad, cada momento es crítico. Recuerde: Los seguridad de su cadena de suministro de software Siempre será tan fuerte como tu eslabón más débil. Cuando hay docenas de componentes de software en riesgo, agradecerá un SBOM que tenga todas las respuestas.
Para un flujo de trabajo eficiente, un SBOM útil debe incluir al menos estos tres componentes:
- Campos de información – Estos son los descriptores de los componentes que ha implementado. Ser capaz de identificar fácilmente qué componentes se han utilizado, incluso mucho después de que se haya completado el desarrollo, ayuda a monitorearlos de manera efectiva en busca de vulnerabilidades.
- Soporte de automatización – El seguimiento automático de los SBOM requiere que también estén identificados en uno de los formatos aceptados legibles por máquina.
- Prácticas y promesas – La gestión de un SBOM requiere una comprensión común de las prácticas de mantenimiento, como la frecuencia de las versiones, las dependencias, las incógnitas conocidas, la distribución y entrega, el control de acceso y cómo dar cabida a los errores.
Compartir el SBOM entre las partes interesadas de un producto específico (el desarrollador de software, el proveedor de software y el cliente) ayuda a promover la transparencia y la alineación, aumentando la capacidad de una cadena de suministro de software para defender el producto contra amenazas a la seguridad. Cabe señalar que, dadas todas las partes móviles de una cadena de suministro de software, mantener consistentemente un SBOM de este tipo (uno que pueda ser fácilmente referenciado, monitoreado y mantenido) es un desafío complejo.
Palabras finales: ¿Cómo puede llevar la seguridad de su cadena de suministro de software al siguiente nivel?
A medida que la seguridad de la cadena de suministro de software se vuelve cada vez más crucial, las organizaciones enfrentan repetidamente el desafío de generar una confianza transparente en el software que entregan o utilizan. Dado que se espera que crezca la adopción del SBOM como mejor práctica, contar con una herramienta que le permita superar este desafío es un paso clave para establecer la seguridad de la cadena de suministro de software. Es por eso que recientemente lanzamos el primer centro de seguridad basado en evidencia para productos de software, permitiendo a sus usuarios generar confianza en su software entre equipos y organizaciones. Esta plataforma fácil de usar ayudará a los equipos de desarrollo a mitigar los riesgos de la cadena de suministro de software al hacer que el SBOM sea accesible, fácil de usar y, lo más importante:Hacer que la seguridad de los productos de software sea transparente para los clientes, compradores y equipos de seguridad..
Si a usted, como desarrollador de software, le preocupan las amenazas a la seguridad de su cadena de suministro de software, le instamos a que prueba la plataforma; Es de uso gratuito, sin condiciones. Al implementar nuestro flujo de trabajo, podrá compartir sus SBOM en toda su cadena de suministro.
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
