Mejores prácticas de seguridad de la cadena de suministro de software

La cadena de suministro de software se refiere a todo y a todos los que están conectados a su código de software de alguna manera durante el ciclo de vida de desarrollo. Cada pieza de software se compone de varios componentes. Además del código propietario escrito desde cero, el código también requiere infraestructura de software externa, servicios en la nube y sistemas operativos para funcionar correctamente. Los registros, los repositorios, las bases de código e incluso las personas que escribieron este software son parte de la cadena de suministro del software.

Cada nodo de esta compleja cadena es un punto potencial de vulnerabilidad que puede afectar el rendimiento y la seguridad de su software de alguna manera. La vulnerabilidad introducida en cualquier punto de esta cadena de dependencia tiene graves ramificaciones posteriores. Esto se debe a que la complejidad de la cadena de suministro de software enmascara los riesgos y hace que sea difícil predecirlos e identificarlos sin un marco estandarizado para asegurar la cadena de suministro. Por eso es importante que los desarrolladores y las organizaciones de productos Aprenda qué es la seguridad de la cadena de suministro de software.

La seguridad de la cadena de suministro de software se refiere al conjunto de prácticas estandarizadas implementadas para proteger su software de posibles vulnerabilidades a lo largo del ciclo de vida del desarrollo de software desde el punto de desarrollo de la aplicación y mediante la integración e implementación continuas (canal de CI/CD).

Es importante que los equipos de seguridad comprendan y sigan la lista de mejores prácticas de seguridad de la cadena de suministro de software para mantener segura la cadena de suministro de software de su organización. Esta publicación detalla las mejores prácticas de la cadena de suministro que debe conocer.

Mejores prácticas para proteger su cadena de suministro de software

Esta sección hace referencia a las prácticas estándar que los desarrolladores y las organizaciones de productos deben seguir para proteger su cadena de suministro de software. Puede utilizar estas pautas como marco básico para describir, evaluar y medir las prácticas de seguridad para su organización dentro de las diferentes etapas del ciclo de vida de su software. Estas mejores prácticas abarcan la fase de adquisición, desarrollo e implementación de la cadena de suministro de software para garantizar la integridad de su entorno de desarrollo, código fuente y producto final.

Adquirir componentes bien asegurados

La incorporación de componentes de terceros al software es una práctica estándar para los desarrolladores, ya que esto les permite aprovechar las capacidades API existentes para ofrecer las funcionalidades deseadas en lugar de crear desde cero. Los componentes de terceros pueden ser software comercial propietario o herramientas gratuitas de código abierto. Al adquirir cualquiera de estos componentes, es importante que considere la seguridad como uno de los criterios más importantes que debe cumplir el componente de software.

Para determinar la seguridad de componentes de terceros, es posible que necesite realizar análisis de seguridad avanzados, como análisis de composición segura, análisis de bases de datos de vulnerabilidades, evaluación de código fuente y análisis de evaluación de riesgos. El resultado de estas comprobaciones ayudará a determinar si este componente es seguro y debe permitirse para su producto.

Además, los componentes seleccionados deben monitorearse continuamente mediante un servicio automatizado de seguimiento de vulnerabilidades para identificar las vulnerabilidades lo antes posible y eliminarlas lo antes posible.

Cree componentes de software seguros internamente siguiendo prácticas de codificación seguras.

Aunque los componentes de software externos incorporados a su software son importantes, la seguridad y la integridad de los productos de software también dependen de las prácticas de codificación segura que siga internamente.

Cada organización necesita un marco integral del ciclo de vida de desarrollo de software que incorpore prácticas de codificación segura para garantizar que los artefactos creados cumplan con las pautas estipuladas.

Para empezar, la integridad de sus productos de software y los artefactos que construye internamente depende de la calidad de su equipo. Su equipo de desarrollo debe incluir expertos en desarrollo, control de calidad, profesionales de ciberseguridad e ingenieros de construcción con un buen conocimiento de las prácticas de seguridad estándar.

El equipo de gestión de productos también debe incluir arquitectos de seguridad, gerentes de productos y líderes de productos que trabajen para garantizar el cumplimiento de las políticas de desarrollo seguro. Algunas de las estrategias básicas para garantizar la creación interna de artefactos de software seguros incluyen:

• Generar documentos de diseño y arquitectura para cada artefacto.
• Creación de modelos de amenazas para productos de software.
• Definición e implementación de pruebas de seguridad.
• Establecer criterios de lanzamiento específicos para evaluar el producto.
• Establecer políticas de manejo de vulnerabilidades para cada producto.
• Documentar y publicar procedimientos de seguridad para cada versión de software.

 Utilice cadenas de herramientas de software de terceros seguras y bibliotecas de compatibilidad

Muchos entornos de desarrollo integrados (IDE) utilizados en el proceso de desarrollo de software son autónomos. Esto significa que le permiten realizar varios pasos dentro del proceso de desarrollo, como codificar, compilar, empaquetar y depurar código, todo desde la misma herramienta. Algunos IDE también tienen herramientas para conectar una fuente a un repositorio externo. Los IDE con esta función admiten múltiples lenguajes de compilación. Además de estas funciones principales, los desarrolladores pueden ampliar las capacidades del IDE que utilizan con complementos. Esta es una fuente potencial de vulnerabilidad para el entorno de desarrollo local, debido a la complejidad de fuentes no confiables como esta.

Para mantener seguro su entorno de desarrollo, todos los IDE y complementos que se utilizarán dentro del entorno deben ser auditados y aprobados previamente después de haber sido escaneados en busca de vulnerabilidades y validados.

Además de los complementos que amplían las capacidades de su entorno de compilación, otra categoría de herramientas de compilación de terceros que quizás necesite verificar en busca de vulnerabilidades son las cadenas de herramientas de software y las bibliotecas de compatibilidad. Estas herramientas del sistema operativo de terceros se instalan en el entorno de desarrollo para permitirle utilizar utilidades y comandos específicos exclusivos de ese sistema operativo. Por ejemplo, un entorno de desarrollo de Windows puede requerir algunos comandos del sistema operativo exclusivos del sistema operativo Linux durante el proceso de compilación para brindar compatibilidad entre ambos sistemas durante el proceso de producción.

De manera similar, las bibliotecas de conversión API también lo ayudan a crear un entorno de codificación común para dos sistemas operativos diferentes. Estas cadenas de herramientas API son herramientas comerciales y de código abierto y es necesario acceder a ellas para detectar vulnerabilidades antes de adoptarlas para su entorno de compilación y utilizarlas para su proyecto.

Mitigar la modificación o explotación del código fuente por parte de personas internas.

Según la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), una información privilegiada es cualquier persona con acceso autorizado o conocimiento de los recursos de una organización. Las personas que tienen o tuvieron acceso a sus instalaciones, redes, equipos y sistemas pueden potencialmente poner en peligro la integridad de su producto de software, ya sea intencionalmente o sin saberlo.

Como parte de los esfuerzos para proteger su software, debe asegurarse de que el proceso de desarrollo cuente con políticas para evitar la exposición intencional o no intencional a código malicioso en su código de producción por parte de personas internas, como personal comprometido, ingenieros mal capacitados o empleados inactivos. Algunas de las medidas que puede implementar para mitigar esto incluyen:

• Proceso de registro de código fuente equilibrado y autenticado
• Escaneo de seguridad automatizado en busca de vulnerabilidades
• Capacitación en desarrollo de software seguro
• Fortalecer el entorno de desarrollo
• Priorizar las revisiones de código

Almacene el código o los ejecutables y revise todos los cambios antes de su aprobación.

El control de versiones es una de las prácticas estándar que puede ayudar a mantener la integridad de su software. Como parte de su proceso de integración e implementación continua (canal de CI/CD), necesitará mantener un repositorio para almacenar su código y archivos ejecutables. Esto proporciona un historial de trabajo de su código para que pueda rastrear fácilmente lo que ha entrado en la pila de desarrollo hasta ese momento.

También necesitará un sistema de aprobación continua para revisar todos los cambios que se realizan en su software antes de que se aprueben. Esto es particularmente útil cuando se colabora con otros desarrolladores dentro de equipos. Solucionar problemas es más fácil en este caso, ya que puede identificar fácilmente los cambios a medida que se realizan y quién los realiza.

No importa cuán simple o complejo sea el software que está creando, un sistema de control de versiones o fuente hace que sea fácil ver y rastrear todos los cambios que se realizan en su código, rastrear el historial de versiones cuando sea necesario o incluso volver a una versión anterior de su código cuando sea necesario.

Crear y mantener un SBOM para cada paquete de software creado.

El Lista de materiales del software Es documentación vital que detalla todos los componentes de terceros incorporados en su producto de software. Un SBOM facilita la validación de todos los componentes aprobados de una pieza de software e identifica fácilmente cualquier vulnerabilidad o defecto. Para cada paquete de software que cree, también debe crear y mantener un SBOM para él.

Se puede preparar una lista de materiales de software en función de las especificaciones definidas en formatos estándar, como las etiquetas Software Package Data Exchange (SPDX), CycloneDX y Software Identification (SWID), según lo definido por Linux, OWASP y NIST, respectivamente.

Para cada producto de software que cree, los proveedores o propietarios de los componentes de terceros que utilice deben proporcionar una lista de materiales de software completa. Los entregables de su proyecto y los SBOM proporcionados por el proveedor también se pueden validar utilizando una herramienta de análisis de composición (SCA).

Incluso si el proveedor no proporciona un SBOM, el SBOM generado con la herramienta de análisis de composición de software aún puede proporcionar la información requerida para describir los componentes de terceros del software. El proceso de generando SBOM debe ser automatizado. Automatización SBOM es vital porque los proveedores y desarrolladores externos necesitan generar un nuevo SBOM cada vez que se modifica un software de terceros, y hacerlo manualmente no es práctico. El SBOM actualizado describirá cualquier mejora o cambio en el código del componente y su relación con el producto de software.

Endurecer el entorno de construcción

Una de las formas de garantizar la integridad de su software es reforzar el entorno de desarrollo contra posibles vulnerabilidades. Esto incluye tanto el entorno de desarrollo individual como el entorno de construcción de producción general.

Ya sea que su entorno de compilación esté alojado en la nube o en las instalaciones, debe configurarlo e implementar medidas para proteger el servidor y la red y, al mismo tiempo, controlar quién tiene acceso a qué. Realizar la debida diligencia para optimizar y proteger el entorno de compilación de esta manera garantizará la integridad de su código fuente y del producto final.

Proteger el proceso de compilación implica proteger todos los sistemas que utiliza durante el proceso de compilación de su producto. Esto incluye repositorios de código, servidores de firma, estaciones de trabajo de ingeniería, servidores de implementación, etc. Algunas de las medidas que puede implementar para proteger la infraestructura de su tubería de construcción incluyen:

Sistemas de bloqueo

Para proteger sus sistemas, debe limitar las operaciones del sistema a funciones específicas que el sistema debe realizar. Por ejemplo, su sistema de compilación solo debe usarse para operaciones de compilación y nada más.

Limite las actividades de la red externa y fuera de LAN

Tanto las actividades de red entrantes como salientes pueden exponer potencialmente su sistema a ataques. Debe bloquear todas las actividades externas y fuera de la LAN y limitar las conexiones externas a las URL necesarias.

Monitorear los sistemas para detectar fugas de datos.

Para garantizar la integridad del código fuente de su producto, debe configurar sus defensas de ciberseguridad para proteger su repositorio, estación de trabajo y otras partes de su entorno de compilación contra la filtración e infiltración de datos. Esto implica bloquear todo comportamiento malicioso, aislar aplicaciones y configurar sistemas de detección para detectar cualquier intrusión tan pronto como ocurra.

Configure su canal de control de versiones

La canalización de su código debe tener control de versión. Al realizar cambios en su producto, las actualizaciones deben realizarse en el código de configuración y no en los sistemas reales.

Autenticación de múltiples factores

Cada sistema que forme parte de su entorno de compilación debe configurarse con autenticación multifactor siempre que sea posible. También se deben implementar medidas de seguridad adicionales, como acceso basado en roles, privilegios mínimos, etc. La directriz del NIST también recomienda un sistema de autorización dual para todos los sistemas críticos o sensibles en su entorno de construcción.

Segregue su red de ingeniería

Solo se debe acceder a su sistema de compilación a través de una red de ingeniería aislada diferente del resto de la red de su organización. Cuando sea posible, la red de ingeniería debe estar fuera de línea.

Analizar cada vulnerabilidad para recopilar información suficiente para planificar su remediación.

Al desarrollar software, se deben implementar medidas para garantizar que su producto y todos sus componentes estén libres de vulnerabilidades conocidas de alto riesgo. De manera similar, cuando un cliente descubre o informa nuevas vulnerabilidades, debe responder al incidente de inmediato. En algunos casos, esto requerirá que actualice su sistema para mitigar los riesgos asociados con la vulnerabilidad recién descubierta.

Los proveedores de software deben contar con un proceso para aceptar actualizaciones o informes sobre posibles vulnerabilidades o defectos en sus productos, ya sea de investigadores externos o de clientes. También necesita tener un sistema automatizado que le notifique sobre las actualizaciones de vulnerabilidades anunciadas por organizaciones confiables como la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA).

Cada organización necesita una política interna de gestión de vulnerabilidades que cumpla con las directrices estándar. Las alertas sobre amenazas de alto riesgo deben evaluarse en función de la relación entre su producto y sus componentes que pueden haber sido afectados por la vulnerabilidad reportada. Su equipo de ingeniería también debe tener un sistema integral para revisar, diagnosticar y posiblemente resolver problemas.

Mantenimiento de componentes

Un producto de software y sus componentes nunca son estáticos. Debes tener en cuenta que los componentes de terceros integrados en tus productos pueden ser modificados o actualizados por parte del proveedor periódicamente. Debe monitorear estas modificaciones, especialmente cuando están relacionadas con vulnerabilidades y exposiciones comunes (CVE).

Una gran parte del mantenimiento de sus componentes de software es monitorear los mecanismos de informes CVE estándar y otros canales de soporte para determinar si las vulnerabilidades recientemente identificadas en un componente de terceros incorporado dentro de su producto afectan la integridad de sus propios sistemas y tomar las acciones apropiadas para mitigar los riesgos ( Si alguna).

Al seleccionar componentes de terceros para incluirlos en su producto, debe verificar el contrato para asegurarse de que el propietario del componente tenga políticas sobre cómo notificar a las organizaciones de productos sobre las actualizaciones de sus sistemas, la presencia de vulnerabilidades y el plazo para la vulnerabilidad. resolución, así como cualquier acción que pueda necesitar realizar por su parte para garantizar una seguridad óptima.