Lo que los desarrolladores frontales deben saber sobre los SBOM en JavaScript

Principales conclusiones

• Las aplicaciones JavaScript suelen incluir cientos de dependencias ocultas, tanto directas como transitivas.
• Los SBOM le ofrecen una visibilidad completa de su código base, exponiendo las vulnerabilidades y garantizando la transparencia.
• Herramientas como Syft y CycloneDX simplifican la generación de SBOM, ayudándole a reforzar la seguridad y mantener la conformidad.

Tu aplicación JavaScript es una caja negra de dependencias. Si abres node_modules, puede que encuentres miles de paquetes que no sabías que tenías, algunos tan crípticos como ovnis en una pantalla de radar. En una época en la que se intensifican los ataques a la cadena de suministro, esto no solo es espeluznante, sino peligroso.

Introduzca SBOMs (Software Bill of Materials): su carta estelar para navegar por la galaxia de las dependencias de JavaScript. En este artículo, explicaremos qué son los SBOM, por qué los desarrolladores frontend no pueden ignorarlos y cómo herramientas como CycloneDX y Syft te permiten mapear tu ecosistema, integrar la seguridad en tu flujo de trabajo y detectar vulnerabilidades antes de que se estrellen.

Encuentros cercanos del tipo JavaScript

Cuando consideramos el software como un todo, tenemos varias piezas que hacen que todo encaje. Hay paquetes, licencias, personas, procesos, etc., que encajan como las piezas de un puzle...la mayoría de las veces.

Las dependencias del software pueden parecer tan extrañas como un OVNI (Objeto Volador No Identificado) o un FANI (Fenómeno Aéreo No Identificado): a veces explicables, a menudo desconcertantes y siempre con la posibilidad de un encuentro sorpresa.

Puede haber valores atípicos en el código que usted sepa que están ahí y, en un abrir y cerrar de ojos, su software puede verse comprometido. Aquí es donde entran en escena los SBOM.

Puedes pensarlo así: instalas un paquete, ese paquete instala otro paquete, y entonces tu nave nodriza y TODAS sus naves hijas son destruidas.

Esta película lo resume todo.

¿Cuántas dependencias tiene su aplicación?

Adivina: ¿tu aplicación tiene 20 dependencias? 200? ¿O el valor de una pequeña galaxia, cerca de mil?

Si ejecutas npm ls en tu terminal, obtendrás una lista de dependencias.

¿Por qué no listar TODAS las dependencias? Podemos, puede sobrecargar el terminal ya que los árboles de dependencias pueden ser grandes, pero es posible.

Al listar las dependencias de esta forma no sólo se mostrarán las directas, sino también las transitivas.

Dos formas de dependencia

Cuando miramos las dependencias de nuestro proyecto, nos enfrentamos a dos tipos: una es la dependencia directa. La que puedes ver si abres tu archivo package.json, el árbol de dependencias directas.

Por ejemplo, next es una dependencia directa porque la necesitas para construir una aplicación Next.

JSON

"dependencies": {

"react": "^19.0.0",

"react-dom": "^19.0.0",

"next": "15.3.4"

}

Luego tenemos las dependencias transitivas. Estas son las dependencias de las dependencias que usted tiene que cavar profundo para encontrar. Por lo general, en un archivo package.json dentro de la carpeta node_modules DE una carpeta de paquetes.

En este ejemplo, @next/env es una dependencia transitiva de next.

JSON

"dependencies": {

"@next/env": "15.3.4"

}

¿Qué es un SBOM?

Un SBOM es esencialmente el manifiesto de tu proyecto: un inventario legible por máquina que detalla cada componente, dependencia y relación. Piense en ello como la lista de ingredientes de su código base, o el manifiesto de vuelo que dice exactamente quién está a bordo. Un SBOM enumera todas las dependencias y versiones de un proyecto.

A continuación, un extracto de Tahir Balarabe en Medium. Esta explicación lo resume perfectamente.

"Una SBOM, o lista de materiales de software, es una lista detallada y legible por máquina de todos los componentes de una pieza de software, incluidas las dependencias, los metadatos y las relaciones entre componentes."

• https://medium.com/@tahirbalarabe2/why-every-modern-software-needs-a-software-bill-of-materials-sbom-for-security-04a4fec312c8

Puede que te estés preguntando: "¿Por qué necesitamos un SBOM?". Hay un montón de razones por las que necesitamos un SBOM o SBOMs cuando estamos produciendo o consumiendo software. Una de ellas es la transparencia. Debemos saber qué contiene nuestro producto. Enviar un producto u ofrecer un producto inseguro no beneficia a nadie; acabará provocando problemas en el futuro.

La transparencia cuando se trata de lo que hay en el árbol de dependencias ayuda a mantener la seguridad y la conformidad, que también son dos razones muy importantes. Saber qué hay en tu producto es una cosa, pero estar seguro y cumplir la normativa es otra.

Tipos de SBOM

Cuando hablamos de varios SBOM para nuestro software, tenemos 6 tipos diferentes. Todos estos tipos corresponden a distintas partes del ciclo de vida del desarrollo de software (SLDC).

• Diseño SBOM
• Fuente SBOM
• Construir SBOM
• SBOM analizado
• SBOM desplegado
• SBOM en tiempo de ejecución

Para obtener más información sobre las definiciones de estos SBOM, consulte el PDF Types of Software Bill of Materials (SBOM) de la CISA (Cybersecurity & Infrastructure Security Agency).

Una cosa que hay que tener en cuenta al hablar de los SBOM es que no se trata de un archivo de paquete ni de un archivo de bloqueo: es más completo. Un SBOM también proporciona una lista completa y estandarizada de todas las cosas dentro de su proyecto: componentes, metadatos, etc.

El gran problema de Frontend

Si estás leyendo esto y has instalado algo en el frontend usando npm, lo más probable es que te hayas encontrado con el problema de escribir a través de la memoria muscular porque lo has hecho 100 veces antes. A veces puede que no estés prestando atención y simplemente instales lo que crees que necesitas. Puede que ni siquiera copies y pegues directamente del sitio del proveedor o del registro de npm. Esto trae muchos problemas; estamos hablando de Typosquatting.

El typosquatting también se conoce como secuestro de URL. Se trata de un tipo de ataque en el que un atacante registra un dominio o dominios con variaciones ligeramente diferentes de errores ortográficos para engañar a los usuarios para que consulten su sitio, a menudo malicioso. Esto también se traslada a la gestión de paquetes. Los atacantes también publican paquetes maliciosos y los escriben mal, igual que los dominios. Un desarrollador puede cometer accidentalmente un error tipográfico e instalar un paquete malicioso en lugar del correcto.

Un ejemplo sería el siguiente:

npm installexpress vs. npm install expres

Puedes ver que la segunda versión es la versión incorrecta de express y podría ser potencialmente dañina.

¿Por qué son importantes los SBOM?

Hay varias razones por las que tener un SBOM es extremadamente importante:

• Visibilidad de los componentes
• Gestión de vulnerabilidades
• Seguridad de la cadena de suministro
• Colaboración y gestión de parches
• Cumplimiento de la normativa

Tener visibilidad de nuestros componentes es crítico, especialmente cuando se trata de dependencias transitivas. También queremos poder gestionar nuestras vulnerabilidades en función de lo que tenemos instalado. Y no pases por alto el factor humano: compartir las SBOM genera confianza en el cliente, demostrando que tu cadena de suministro de software es transparente y segura.

Como profesionales de la web y el software, si estamos creando software que va a ser utilizado por otros, queremos asegurarnos de tener una relación sólida con nuestros clientes. Asegurarnos de que los SBOM están a disposición de nuestros clientes es fundamental.

Instalación de una herramienta para generar una SBOM

Hay diferentes maneras de instalar varias herramientas para generar un SBOM. En este post, vamos a utilizar Syft de Anchore. A continuación se presentan algunos comandos para instalar Syft en su máquina.

La forma recomendada es utilizar el rizo:

curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin

También puede instalar el paquete con Brew:

brew install syft

También existe una versión para Windows que puede instalarse a través de Chocolatey:

choco install syft -y

Microsoft también fabrica una herramienta para generar SBOM utilizando Winget:

winget install Microsoft.SbomTool

Una vez que tenemos Syft instalado, podemos pasar a generar un SBOM en nuestro proyecto.

Generación de SBOM

Existen dos formatos populares para generar un SBOM: SPDX y CycloneDX. En los siguientes ejemplos, estamos utilizando SPDX para formatear nuestro SBOM. También estamos generando un SBOM en un proyecto Angular, específicamente v19.

Una vez que estés en tu proyecto, ejecuta el comando de abajo para generar el SBOM. Es legible por máquina, pero lo arreglaremos con el segundo comando que ejecutaremos. Verás que hay dos banderas al final del comando, -source-name y -source-version. Sin incluirlas en el comando, la terminal te gritará. Es una buena práctica incluirlas.

syft packages dir:. -o json > sbom.json --source-name "my-js-project" --source-version "1.0"

Ahora, para generar una versión de la SBOM que puede ser leído por un ser humano. Puede ejecutar un comando llamado jq para pretty-print el SBOM para que pueda ir a través y ver lo que se creó.

jq . sbom.json > sbom-pretty.json

Cuando instalas nuevos paquetes, es una buena práctica generar un nuevo SBOM para poder documentar el paquete que instalas. A continuación se muestra un vídeo de la instalación del paquete Lucide para Angular y la regeneración manual del SBOM para ver reflejado el nuevo paquete.

Esto también puede hacerse utilizando una acción de GitHub. Cuando usted empuja a principal, dev, o una rama de liberación, se desencadena un flujo de trabajo para generar un nuevo artefacto SBOM en formato JSON, que se almacena en GitHub. Usted decide qué hacer con ese archivo.

Reflexiones finales

Un SBOM ya no es opcional: es una parte fundamental del desarrollo de software moderno. No sólo indica lo que está instalado, sino que ofrece un mapa vivo de las dependencias directas y transitivas. También ayuda en la gestión de vulnerabilidades y el cumplimiento de normativas.

La transparencia es primordial, y para muchas organizaciones un SBOM es una forma de demostrar su compromiso con la visibilidad. TuxCare, por ejemplo, proporciona automáticamente a sus usuarios un SBOM como parte de su servicio Endless Lifecycle Support (ELS) for Applications, con información detallada sobre cómo se crea, verifica y distribuye cada paquete. Así es como TuxCare permite a los desarrolladores que utilizan su parcheo ampliado para productos de software de código abierto al final de su vida útil garantizar la transparencia y la responsabilidad en sus ecosistemas de software.

Así que la próxima vez que abra su proyecto, genere un SBOM, páselo por un escáner de vulnerabilidades y vea exactamente qué paquetes podrían albergar exploits conocidos. Es una de las formas más sencillas e inteligentes de mejorar la seguridad de tu frontend.