Fins ara hem revisat codi i configuració propis. Però una aplicació moderna com BazarNube és, en la seva major part, codi d'altres: React, Express, desenes de paquets npm, Spring i les seves dependències transitives al mòdul Java. Cadascuna d'aquestes peces pot tenir vulnerabilitats conegudes (CVE) que un atacant explota sense tocar la teva lògica. Això és A06:2021 – Components Vulnerables i Desactualitzats (Vulnerable and Outdated Components).

És una categoria peculiar: rarament la "descobreixes" auditant el teu codi, perquè l'error és en una llibreria. Es combat amb procés: inventariar el que fas servir, saber quines versions tens, vigilar els CVE que les afecten i actualitzar a temps. Un sol paquet transitiu desactualitzat —d'aquells que ni sabies que tenies— pot ser la porta d'entrada. En aquesta lliçó apliquem l'anàlisi de composició de programari (SCA) que ja vam presentar al mòdul 2 (02-05, Dependency-Check) al package.json i al pom.xml de BazarNube.

Avís legal i ètic: els CVE i versions citats són il·lustratius. Practica l'anàlisi només sobre sistemes i dependències propis o amb autorització explícita.

1. Per què les dependències són un risc de primer nivell
2. Dependències directes i transitives
3. SCA: npm audit i OWASP Dependency-Check
4. El SBOM: inventari del que composes
5. Gestió de versions i actualització segura
6. Riscos de la cadena de subministrament (a alt nivell)
7. Errors comuns, exercicis i solucions

Quan es publica un CVE d'una llibreria popular, es fa públic l'error i, sovint, com explotar-lo. A partir d'aquell moment hi ha una cursa: els atacants escanegen internet buscant aplicacions que encara facin servir la versió vulnerable. Casos històrics (com el d'una llibreria de serialització o d'un framework web àmpliament fet servir) han provocat bretxes massives simplement perquè les víctimes no van actualitzar a temps.

Ho agreuja que:

• El codi de tercers sol ser la major part de l'aplicació.
• Moltes dependències són transitives (dependències de les teves dependències): ni saps que hi són.
• Actualitzar fa "por" (pot trencar alguna cosa), així que s'ajorna.

El teu package.json llista les dependències directes, però l'arbre real (a package-lock.json) inclou centenars de paquets transitius. La vulnerabilitat sol ser en un de transitiu que mai vas triar conscientment. Per això no n'hi ha prou amb "revisar el que vaig instal·lar": necessites eines que recorrin tot l'arbre.

El SCA (Software Composition Analysis) compara el teu arbre de dependències amb bases de dades de vulnerabilitats conegudes i et diu quines versions tens que són vulnerables.

npm audit recorre package-lock.json, assenyala la severitat i sovint ofereix npm audit fix per actualitzar automàticament a una versió apedaçada. Integra'l en CI: per exemple, fer fallar el build si hi ha vulnerabilitats altes o crítiques.

Ja el vam presentar a 02-05. Analitza el pom.xml (i .jar) contra la base de dades pública de vulnerabilitats (NVD) i informa dels CVE que afecten les teves dependències:

failBuildOnCVSS converteix la troballa en un error de build, forçant a atendre les vulnerabilitats greus abans de desplegar. Hi ha equivalents comercials i open source (Snyk, Trivy, Grype), però Dependency-Check és el projecte OWASP de referència.

Un SBOM (Software Bill of Materials) és la "llista d'ingredients" del teu programari: quins components i versions exactes el formen. És la base per respondre ràpid a un CVE nou: quan aparegui "vulnerabilitat crítica a la llibreria X versió Y", amb un SBOM saps a l'instant si BazarNube la fa servir i on.

Formats estàndard com CycloneDX o SPDX permeten intercanviar el SBOM amb clients i eines. Generar-lo en cada build i arxivar-lo et dóna traçabilitat: saps exactament què va compondre cada versió desplegada.

L'objectiu no és "estar sempre a l'última versió a qualsevol preu", sinó mantenir un procés controlat:

1. Fixa versions (lockfiles: package-lock.json, pom.xml amb versions concretes) per a builds reproduïbles.
2. Automatitza avisos d'actualització (Dependabot, Renovate) que obren PRs quan hi ha versions noves o pedaços de seguretat.
3. Prova abans d'actualitzar: una bona bateria de tests permet actualitzar amb confiança; sense tests, l'actualització fa por i s'ajorna (l'arrel del problema).
4. Prioritza per risc: primer els CVE de severitat alta/crítica i els que siguin explotables en el teu context.
5. Elimina el que no fas servir: cada dependència sobrant és superfície d'atac. Menys és més.

Més enllà de "fer servir versions amb CVE", existeix el risc que la mateixa dependència sigui maliciosa o manipulada: paquets amb noms semblants als legítims (typosquatting), comptes de mantenidors compromesos que publiquen versions amb portes del darrere, o dependències que "de sobte" canvien d'amo. Bones pràctiques a alt nivell:

• Verifica la integritat del que descarregues (els lockfiles guarden hashes; no els ignoris).
• Desconfia de dependències sense manteniment, amb molt pocs usos o d'origen dubtós.
• Restringeix d'on s'instal·len els paquets (registre intern/proxy).

La verificació d'integritat d'artefactes i del pipeline és tan important que té la seva pròpia categoria: A08 (Errors d'Integritat de Programari i Dades), que veurem a la lliçó 03-10. Aquí n'hi ha prou amb quedar-nos amb la idea que "components segurs" inclou també la seva procedència.

• Ignorar les dependències transitives. Allà hi ha la majoria dels CVE; fes servir SCA que recorri tot l'arbre.
• No integrar l'SCA en CI. Un audit manual que ningú executa no protegeix; automatitza'l i fes fallar el build.
• Actualitzar sense tests. Sense xarxa de seguretat, l'actualització s'ajorna eternament.
• Acumular dependències que no fas servir. Cadascuna és superfície; poda periòdicament.
• No tenir inventari (SBOM). Davant d'un CVE nou, trigaràs dies a saber si t'afecta.
• Confiar cegament en qualsevol paquet. Vigila procedència i manteniment (cadena de subministrament).
• Consell: defineix una política clara ("no despleguem amb CVE crític obert") i automatitza-la; converteix la seguretat de dependències en part del flux normal, no en una tasca heroica esporàdica.

Exercici 1. npm audit reporta una vulnerabilitat alta en un paquet que resulta ser transitiu d'una llibreria que sí que fas servir directament. La llibreria directa encara no ha publicat una versió que actualitzi aquella transitiva. Quines opcions tens?

Exercici 2. Per què un SBOM accelera la resposta quan es publica un CVE crític en una llibreria molt utilitzada?

Exercici 3. Un company proposa treure npm audit de CI "perquè de vegades falla el build per vulnerabilitats que no ens afecten". Quina alternativa millor proposaries?

Solució 1. Opcions, de més a menys preferible: (a) actualitzar la llibreria directa si publica un fix; (b) forçar la versió apedaçada de la transitiva mitjançant overrides (npm) o resolutions; (c) si no hi ha pedaç, avaluar el risc real (és explotable en el teu ús?), aplicar mitigacions i vigilar; (d) com a últim recurs, substituir la llibreria directa per una altra de mantinguda. Documenta la decisió al backlog.

Solució 2. Perquè el SBOM és un inventari exacte de components i versions desplegats: en lloc d'investigar manualment cada servei, busques la llibreria i versió afectades al SBOM i saps de seguida si i on estàs exposat, prioritzant l'apedaçament. Redueix el temps de resposta de dies a minuts.

Solució 3. No eliminar-lo, sinó calibrar-lo: fixar --audit-level=high (o critical) per no bloquejar per vulnerabilitats menors, i gestionar els falsos positius o els CVE no explotables mitjançant excepcions documentades i amb data de revisió (allowlist temporal), no desactivant la comprovació sencera. Així mantens la protecció sense fricció injustificada.

A06 no es resol amb una tècnica de codificació, sinó amb disciplina de procés: inventariar (SBOM), analitzar la composició (npm audit, Dependency-Check) de manera automàtica en CI, actualitzar amb una xarxa de tests, podar l'innecessari i vigilar la procedència. A BazarNube, integrar l'SCA en el pipeline converteix els CVE en tasques rutinàries del backlog en lloc d'incidents.

Entrada de backlog — A06: npm audit --audit-level=high en CI del front i l'API; Dependency-Check amb failBuildOnCVSS=7 al mòdul Java; Dependabot habilitat; SBOM CycloneDX generat per build; poda de dependències sense ús pendent.

Hem assegurat qui accedeix, què es protegeix, com s'injecta, com es dissenya, com es configura i quins components fem servir. Toca tornar a un control fonamental que vam deixar pendent en distingir-lo de l'autorització: l'autenticació. La lliçó següent és A07:2021 – Errors d'Identificació i Autenticació, amb el login i les sessions de BazarNube.