Comprender los requisitos de seguridad de la cadena de suministro de software en la orden ejecutiva sobre ciberseguridad

La orden ejecutiva sobre ciberseguridad del presidente Biden de mayo de 2021 no debería sorprender a nadie que esté al corriente de los titulares del año anterior. La orden ejecutiva surge como respuesta del Gobierno Federal de EE. UU. frente a una larga lista de incidentes que comenzaron con el ataque a SolarWinds y terminaron con el reciente ataque de ransomware a Colonial Pipeline, el ataque conocido más importante contra una empresa de energía estadounidense.

Si tenemos en cuenta que muchos de los últimos ataques se relacionan con la cadena de suministro de software, no es sorpresa que la seguridad del software, en particular la seguridad de la cadena de suministro de software, sea un tema recurrente en la orden ejecutiva. El ahora reconocido ataque a SolarWinds afectó a una gran cantidad de agencias gubernamentales, que incluyen el Pentágono, el Departamento de Estado y el Departamento de Seguridad Nacional, junto con empresas privadas como Microsoft, Intel y Cisco, y puso de relieve la importancia de la seguridad de la cadena de suministro de software.

Los ataques a las cadenas de suministro de software no son nuevos. En Snyk, mencionamos que la composición y el desarrollo de software moderno es un eslabón débil y un posible canal de distribución de malware desde 2018. Sin embargo, cada vez son más populares entre atacantes debido a algunos cambios en la forma en que las aplicaciones de software se desarrollan actualmente. En la orden ejecutiva del presidente Biden, se reconocen estos cambios y se tiene como objetivo minimizar el riesgo que estos suponen al orientar al Departamento de Comercio de modo que cree estándares más estrictos para las empresas que venden software al Gobierno Federal.  

¿Qué son los ataques a las cadenas de suministro de software?

En un ataque a la cadena de suministro de software, se accede y modifica el software desde la compleja cadena de suministro de desarrollo de software para poder insertar código malicioso a fin de poner en riesgo a un objetivo posterior. El ataque a la cadena de suministro de software no es el fin último. Mediante un ataque de este tipo, se genera la oportunidad para que el atacante inserte malware o cree una puerta trasera para acceder en el futuro. Por ejemplo, en el ataque a SolarWinds, un grupo de hackers logró acceder a la red y la plataforma de supervisión de aplicaciones de SolarWinds, Orion, para distribuir actualizaciones maliciosas a miles de usuarios del software.

Los ataques a las cadenas de suministro de software son sumamente efectivos debido al modo en que se desarrolla el software moderno hoy en día. Al igual que ocurre con las cadenas de suministro industriales, las cadenas de suministro de software abarcan planificación, suministro de materiales, fabricación y comercio minorista. En lugar de materiales, una cadena de suministro de software incluye código, que puede ser propio, pero un segmento cada vez más importante proviene de proveedores, opciones comerciales o código abierto. Estas dependencias pueden utilizarse para inyectar código malicioso en el software. El código se utiliza para desarrollar el software y, en la cadena de suministro de software moderno, el desarrollo incluye una cantidad cada vez mayor de procesos que pueden explotarse para que la distribución de malware tenga éxito.

Requisitos federales de la seguridad de la cadena de suministro de software

La orden ejecutiva del presidente Biden exige la modernización de la ciberseguridad del Gobierno Federal, mejor comunicación y colaboración en lo que atañe a la ciberseguridad entre el Gobierno Federal y el sector privado, y una seguridad más estricta en lo que refiere al software adquirido por el Gobierno Federal. El riesgo que suponen los ataques a las cadenas de suministro de software se detalla claramente en la primera parte del Artículo 4 de la orden ejecutiva:

“Con frecuencia, el desarrollo de software comercial no es transparente, no tiene la capacidad de resistir ataques ni cuenta con los controles necesarios para evitar que actores maliciosos lo manipulen. Es urgente aplicar mecanismos más estrictos y predecibles para garantizar que los productos funcionen de forma segura y según lo previsto. En consecuencia, el Gobierno Federal debe actuar rápidamente para mejorar la seguridad y la integridad de la cadena de suministro de software...”.

Con el objetivo de proteger a las agencias gubernamentales de estos riesgos, la orden ejecutiva exige al NIST establecer prácticas recomendadas, pautas y criterios para desarrollar futuros estándares que las empresas proveedoras de software deban cumplir si desean vender software al Gobierno Federal.

SBOM: lista de materiales de software

Una pequeña parte del código que conforma un software se desarrolla desde cero de forma interna; sin embargo, la mayoría se obtiene de componentes de terceros o de código abierto. En la orden ejecutiva, se reconoce esta realidad y se plantea un requisito en lo que refiere a la SBOM\: la necesidad de mejorar la transparencia sobre lo que realmente está incluido en un programa de software para poder mitigar el riesgo de ataques a las cadenas de suministro de software.  

Entorno de desarrollo seguro

Quienes proveen software deberán certificar que el entorno de desarrollo es seguro. En la orden ejecutiva, se establece que el NIST debe plantear los criterios necesarios para que un entorno de desarrollo se considere seguro, que incluyen seguridad en los procesos de desarrollo, el cifrado de datos, las auditorías, la autenticación, y la gestión y supervisión de incidentes.

Procesos de desarrollo seguros

Además, quienes proveen software también deberán adherirse a prácticas de desarrollo seguro y deberán poder avalar las medidas tomadas. Esto implica emplear pruebas de seguridad automatizadas al comienzo y durante el desarrollo para garantizar la integridad del código y buscar y corregir vulnerabilidades. Estos “artefactos” que certifican el desarrollo de software y el empleo de las herramientas y los procesos utilizados deben estar disponibles si se necesitan.

Integridad del código abierto

En general, entre el 80 y el 90 % del código que conforma una aplicación proviene de código abierto. En la orden ejecutiva se reconoce esta realidad y se exige que las empresas proveedoras de software “garanticen y certifiquen la integridad y el origen del software de código abierto que se utiliza en cualquier sección del producto”.

Cómo mejorar la seguridad de la cadena de suministro de software

Para adherirse a las pautas del NIST, se debe fortalecer la cadena de suministro de software y, para ello, la seguridad de la aplicación debe ser más estricta. Snyk, al brindar una plataforma de seguridad para aplicaciones nativas de la nube y pensada para desarrolladores, respalda la gran mayoría de los requisitos que se detallan en la orden ejecutiva.

Cómo empoderar a los desarrolladores

Para que, como se determina en la orden ejecutiva, las prácticas de desarrollo seguro se implementen correctamente, los desarrolladores deben poder integrar la seguridad a su flujo de trabajo con facilidad. El desarrollo seguro debe comenzar por los desarrolladores, ya que son quienes deciden cómo se desarrolla una aplicación y, en última instancia, también son responsables de la integridad, la calidad y la seguridad del código. Los modelos de seguridad tradicionales (que se integran posteriormente al proceso de desarrollo y agregan discrepancias a flujos de trabajo poco intuitivos) ya no se eligen en un panorama de desarrollo acelerado como el de hoy en día.

La estrategia de Snyk consiste en empoderar a los desarrolladores con herramientas fáciles de usar para ellos e instrucciones adecuadas del equipo de seguridad. La plataforma de Snyk se diseñó para brindarles a los desarrolladores una herramienta que disfruten usar, que funcione como cualquier otra en su arsenal y que no retrase su trabajo.

Seguridad automatizada en el SDLC

Para garantizar la integridad del software desde un primer momento en el proceso de desarrollo de software, en la orden ejecutiva se exige la pronta implementación de pruebas de seguridad automatizadas “...que funcionarán con regularidad o, al menos, antes del lanzamiento de un producto, una versión o una actualización”. Los clientes de Snyk utilizan diversas opciones de las integraciones disponibles, además de la API de Snyk, para automatizar las pruebas de seguridad en todas las diferentes etapas del proceso de desarrollo de software. Esto comienza en el entorno de desarrollo local del desarrollador, continúa en los flujos de trabajo de Git, el proceso de compilación y finaliza en el entorno de producción. 

Cómo proteger TODO el código que conforma el software moderno

En la orden ejecutiva, se reconoce el hecho de que el código que conforma una aplicación ya no es el mismo que antes. En una cadena de suministro de software moderna, los materiales que se usan son código propio, paquetes de código abierto, contenedores y el código responsable de brindar la infraestructura en la nube (infraestructura como código).

Para que las organizaciones puedan gestionar y mitigar estos nuevos riesgos, debe adoptarse un enfoque de seguridad de aplicaciones más holístico. Los equipos de seguridad dedicados a las herramientas SAST (prueba de seguridad de aplicaciones estáticas) que protegen el código creado por los equipos de desarrollo ignoran los riesgos que supone el uso de contenedores y código abierto, y viceversa: las herramientas SCA (análisis de la composición de software) no brindan cobertura sobre el código propio. La plataforma de Snyk es una solución integral pensada para desarrolladores que permite a las organizaciones proteger todo el código que conforma el software moderno.

Certificación y elaboración de informes a nivel de componente

Como mencionamos más arriba, ser transparente ante el Gobierno Federal acerca de las medidas y los procesos implementados además de los materiales utilizados para desarrollar software (es decir, la SBOM) es crucial según los requisitos que se plantean en la orden ejecutiva. Snyk ofrece capacidades de elaboración de informes detallados que permiten visualizar y exportar una SBOM, además de otros tipos de informes. Los clientes de Snyk también utilizan la API para integrar de forma automática herramientas de gestión de vulnerabilidades y elaboración de informes de terceros a fin de supervisar continuamente la postura de cumplimiento y seguridad de la organización.

Qué nos depara el futuro

En la orden ejecutiva, se le exige al NIST que publique las pautas preliminares en seis meses y las pautas definitivas en un año.  Aunque los requisitos detallados en la orden ejecutiva están orientados a las empresas que prestan servicios al Gobierno Federal, es muy probable que los estándares lleguen poco a poco al sector privado y afecten a todo el mercado de software.

Sería prudente comenzar las planificaciones; primero, debe analizarse la orden ejecutiva en detalle e identificar las principales brechas existentes en la cadena de suministro de software.

No te pierdas nuestras noticias. En Snyk, haremos un seguimiento de las pautas que presenta el NIST y publicaremos información adicional en el blog. Además, participamos activamente en los esfuerzos del NIST por cumplir con la orden ejecutiva, en particular, en lo que refiere a las indicaciones sobre la SBOM a través de SBOM SIG.

Para obtener más información sobre cómo Snyk ayuda a las agencias gubernamentales a cumplir con los requisitos de la orden ejecutiva, escribe a snyk_federal@snyk.io o visita nuestra página web Snyk para el gobierno.