El mòdul anterior va acabar assenyalant una paraula que va aparèixer a les seves sis lliçons sense desenvolupar-se mai: verificar. El registre de riscos afirma que el port 5432 està exposat, el catàleg de controls promet un escaneig extern mensual que ningú no ha executat (C-10, «planificat») i el risc R-07 parla de «serveis oblidats» sense que ningú sàpiga quants n'hi ha avui. Aquesta lliçó converteix aquestes afirmacions en mesuraments: aprendràs a trobar què està exposat, decidir què s'arregla primer i demostrar que s'ha arreglat, amb eines de cost zero que caben al pressupost de Nimbus.

⚠️ Advertiment legal i d'autorització — llegeix-lo abans d'executar res

Tot el que hi ha en aquesta lliçó s'executa exclusivament sobre sistemes propis o amb autorització escrita, explícita i vigent.

• Escanejar ports o llançar un escàner de vulnerabilitats contra una màquina aliena sense autorització pot constituir delicte a Espanya (arts. 197 bis i 264 del Codi Penal). La curiositat no és una eximent.
• Al núvol has de complir a més la política de proves del proveïdor, i si el sistema l'opera un tercer —la consultora d'A-19, el proveïdor de correu, la passarel·la—, l'autorització ve de qui l'opera, no només de qui el contracta.

Tot el material treballa sobre el rang propi de Nimbus (10.20.0.0/16 a l'oficina, 10.30.0.0/16 al núvol) i el seu domini nimbusreservas.example. No hi ha exploits ni payloads: cada troballa va amb la seva correcció. (La interpretació penal concreta depèn del cas; davant d'una prova amb impacte sobre tercers, consulta assessoria jurídica.)

1. La gestió de vulnerabilitats com a procés continu
2. El mapa d'eines: què troba cada família
3. Descobriment de xarxa amb nmap
4. Escàner de vulnerabilitats: Greenbone/OpenVAS
5. Dependències i contenidors: pip-audit i trivy
6. Anàlisi estàtica de codi i escaneig de secrets
7. Priorització: CVSS, EPSS, KEV i exposició
8. Falsos positius, falsos negatius i validació
9. Integració al cicle i mètriques del procés
10. L'informe de vulnerabilitats

Gairebé totes les pimes que «fan gestió de vulnerabilitats» fan en realitat escaneig puntual: un cop l'any algú llança una eina, exporta un PDF de 300 pàgines i l'arxiva. Això no redueix el risc: genera un document. La diferència és un cicle tancat amb verificació.

Cinc regles separen el procés del teatre:

• El pas 0 no és opcional. Un escaneig sobre 12 màquines quan en tens 18 no troba res a les altres 6: la cobertura és la primera mètrica, no l'última.
• L'alimenten diverses eines, no una. Cap família no veu més del 30 % del problema.
• Prioritzar no és ordenar per CVSS. És la part que més valor aporta i la que gairebé ningú no fa bé (§7).
• Una troballa es tanca quan la nova passada d'escaneig ja no la troba, no quan algú diu que l'ha arreglada: aquesta és l'evidència auditable de 04-03. I el que no es corregeix es converteix en excepció amb caducitat (04-02), no en una fila que envelleix en silenci.

Precisió d'01-01: una versió d'OpenSSL amb CVE és una vulnerabilitat; que aquest servei escolti a Internet és l'exposició; el risc combina totes dues amb la criticitat de l'actiu. Una de crítica en una màquina apagada no és una urgència; una de mitjana a l'API pública que arriba a A-01 sí.

La columna important és «què no veu». L'IDOR que Nimbus va corregir amb WHERE tenant_id no el troba cap d'aquestes famílies: no és una versió antiga ni un patró evident, és una fallada d'autorització que exigeix entendre el negoci. Per això l'escaneig es complementa amb revisió de codi (05-05) i proves manuals (05-03), i per això cap escàner no pot signar que un sistema és segur.

nmap respon a la pregunta que Nimbus no sap contestar: què hi ha escoltant aquí fora i aquí dins?

Sortida real de l'escaneig extern:

Les troballes d'01-04, ara mesurades i amb data: 5432 accessible des d'Internet confirma R-03 (només el protegeix una contrasenya); 6379 amb Redis sense autenticació és R-07; 8000 és el python -m http.server oblidat durant 94 dies; i el contrast entre 22/tcp open a preproducció i filtered a producció demostra que a producció sí que hi ha una regla i a preproducció no. A-22 és avui el baula més feble de Nimbus.

Calen els dos punts de vista i mesuren coses diferents. L'extern (mensual automatitzat, control C-10) mesura la superfície que veu un atacant d'Internet, és a dir, l'exposició. L'intern (trimestral, des del bastió i des de la VLAN d'usuaris) mesura el que abasta qui ja és dins o un portàtil compromès, i per tant revela fallades de segmentació i moviment lateral: és el que hauria descobert, abans de l'incident, que des de la xarxa d'administració s'arribava a la zona de dades sense control intermedi (dia 1-4 de 02-06).

nmap diu què hi ha; l'escàner diu què li passa al que hi ha. Greenbone Community Edition (l'antic OpenVAS) és gratuït i suficient per a Nimbus. Només fa dues coses, i convé no atribuir-li màgia:

1. Comparar versions contra una base de vulnerabilitats. És ràpid i és la font de gairebé tots els falsos positius: les distribucions apliquen pedaços sense apujar el número visible (backporting).
2. Comprovacions actives: envia una petició i observa la resposta —si accepta TLS 1.0, si un tauler respon amb credencials per omissió—. Més lent i molt més fiable.

El config id és la plantilla d'escaneig (Full and fast equilibra cobertura i temps). Un escàner que s'ha de llançar a mà es llança dues vegades l'any: es programa o no existeix.

Troba molt més perquè deixa d'endevinar: sense credencials no veu una biblioteca vulnerable que no escolta en cap port, i la majoria de les vulnerabilitats del sistema són exactament això. Per a Nimbus: compte svc-scanner sense sudo, clau Ed25519 dedicada (03-06), origen restringit i rotació semestral.

Tres claus de lectura: QoD (Quality of Detection) és el camp més útil i el més ignorat —99 % amb comprovació activa és un fet, 30 % per banner és una hipòtesi, així que es comença per QoD alt i no per CVSS alt—; els 63 «Log» no són soroll, són inventari per a 01-04; i un informe sense troballes només significa que l'escàner no ha trobat res del que sap cercar: l'IDOR d'A-04 no hi apareixerà mai.

El 80 % del codi que executa l'API no el va escriure l'Iván: són dependències. És la superfície que més creix i la més barata de mesurar.

--requirement audita les dependències fixades del projecte (sense ella audites la màquina) i --strict falla també si alguna cosa no s'ha pogut analitzar: tractar un «no ho sé» com un «està bé» és l'arrel dels falsos negatius.

La de requests és la rellevant: l'API crida la passarel·la i el proveïdor de correu amb aquesta biblioteca. La de jinja2 només afecta plantilles del tauler intern. Mateixa severitat nominal, prioritat molt diferent.

--severity HIGH,CRITICAL filtra el soroll (una imatge base típica llança 300 troballes baixes, i incloure-les garanteix que no se'n miri cap); --ignore-unfixed amaga el que encara no té pedaç, i és l'opció més discutible —política de Nimbus: usar-la al CI per no bloquejar per una cosa irresoluble i no usar-la a l'informe mensual—; i --scanners vuln,secret,misconfig afegeix secrets a les capes i males pràctiques del Dockerfile: tres eines pel preu d'una.

Vulnerabilitat present ≠ vulnerabilitat explotable. perl-base és a la imatge perquè l'arrossega la base de Debian, però l'API no executa mai Perl: està present i no és abastable. Dos conceptes ho formalitzen:

• Abastabilitat: hi ha un camí d'execució des del codi de Nimbus fins a la funció vulnerable? Analitzar-ho descarta fins al 70 % de les troballes.
• VEX (Vulnerability Exploitability eXchange): document signat en què declares, per CVE i producte, si t'afecta (affected, not_affected, fixed, under_investigation) i per què.

Nimbus emet el seu VEX juntament amb l'SBOM de 04-04: quan una clínica pregunti per una CVE famosa, la resposta serà un document i no una trucada d'urgència. La resposta a una troballa no explotable no és ignorar-la, és documentar-la. I la via més eficaç per reduir-ne el nombre és canviar a una imatge base mínima o distroless (05-07), que elimina de cop el 80 % d'aquestes línies.

-ll limita a severitat mitjana o superior; --sarif produeix el format estàndard que GitHub mostra a la seva pestanya de seguretat. Troballa real al codi de Nimbus:

El SAST encerta aquí perquè verify=False és un patró textual inequívoc, i falla amb l'IDOR perquè saber que hi falta WHERE tenant_id exigeix entendre el model de dades. Regla: troba errors de patró, no errors de raonament. A 05-05 escriuràs una regla semgrep pròpia que sí que detecta el patró concret de Nimbus.

--log-opts="--all" és l'opció crítica: sense ella només mira l'arbre actual; amb ella recorre tots els commits i branques. Un secret esborrat l'endemà continua a l'historial i continua sent vàlid.

És el risc R-06 i l'escalada del dia 5 de 02-06. Correcció en aquest ordre: (1) rotar la credencial avui —està compromesa des del 2024 i esborrar el fitxer no la invalida; és el pas urgent i el que gairebé tothom posposa—; (2) moure-la al gestor de secrets (03-06); (3) reescriure l'historial amb git filter-repo, que és cosmètica comparada amb el pas 1; i (4) gitleaks com a hook de pre-commit i pas bloquejant del CI (control C-12).

Aquí el procés es guanya el sou. Un escaneig de Nimbus produeix ~180 troballes i la Lucía té 440 h/any per a tot. Ordenar per CVSS descendent és l'error més estès del sector.

El grup ambiental és el que converteix una llista genèrica en una llista teva, i l'únic que ningú no pot calcular per tu. S'hi sumen dos senyals externs:

• EPSS (FIRST): probabilitat que una CVE sigui explotada els propers 30 dies, de 0 a 1, actualitzada diàriament. Més del 90 % de les CVE tenen EPSS < 0,05; una minoria concentra gairebé tota l'explotació real.
• KEV (CISA): catàleg de vulnerabilitats amb explotació confirmada al món real. No és predicció, és un fet observat; la llista és curta i consultar-la és gratis.

Regla operativa de Nimbus: tot el que sigui a KEV i sigui accessible es tracta com a crític, tingui el CVSS que tingui. Una de 7.5 a KEV és més urgent que una de 9.8 amb EPSS 0,001.

Els terminis compten des del descobriment, no des de la publicació de la CVE. I si un P1 no arriba a termini no es reetiqueta a P2: s'obre una excepció signada (04-02). Rebaixar la prioritat perquè el quadre de comandament quedi verd és la forma més comuna de corrompre el procés.

El que revela el resultat: REDIS-SENSE-AUTH té el CVSS més alt (10.0) i cau al tercer lloc per viure en un actiu de criticitat 2; CVE-2026-1044 té 9.1 —més que la 1010, de 7.5— i queda l'última perquè ni és a KEV, ni és abastable, ni afecta un actiu crític. Ordenar per CVSS hauria posat la Lucía a treballar tres dies en les dues vulnerabilitats menys urgents. Avís honest: que A-22 tingui criticitat 2 és la classificació documentada, i l'inventari admet que està «a revisar». Si preproducció té còpia de dades reals, la seva criticitat és 5 i el Redis puja al primer lloc: revisar aquella cel·la és més rendible que qualsevol escaneig.

Validació d'una troballa, en ordre de cost: (1) comprovar la versió real del paquet (dpkg -l | grep nginx) resol el 60 % dels falsos positius d'infraestructura; (2) llegir l'avís de la distribució (USN d'Ubuntu, DSA de Debian), que diu si aquella versió ja està corregida; (3) comprovar l'abastabilitat; (4) reproduir de forma no destructiva només si persisteix el dubte —verificar que un port respon o que falta una capçalera, mai explotar en producció: aquesta conversa és de 05-03—; i (5) documentar la decisió, apta o no, perquè un fals positiu tancat sense registrar reapareix cada mes i costa el mateix cada vegada.

Un escàner no substitueix mai el criteri. No sap que A-01 conté historials que revelen informació de salut, ni que A-19 té accés permanent, ni que preproducció potser té dades reals, ni pot trobar una fallada d'autorització. Mesura versions i configuracions: el risc el posa el context, i el context el posa una persona. Això s'escriu a la declaració de limitacions de l'informe (§10).

L'últim és el més barat i el més infravalorat: comparar l'escaneig d'avui amb el d'ahir i avisar només del que és nou és el que hauria detectat el http.server el mateix dia, i no 94 dies després.

El principi de disseny: bloquejar el que és accionable i informar del que no ho és. Un pipeline que trenca el build per troballes que ningú no pot corregir acaba desactivat en dues setmanes, i llavors no protegeix de res. I el criteri de fallada el decideix Nimbus (ci/llindar.py), no una eina que canvia de versió: externalitzar-lo és cedir el govern del risc.

Estructura de l'informe mensual: resum executiu, abast i limitacions, metodologia i versions de les eines, troballes prioritzades, tendència, tancats i verificats, i annex tècnic. Les limitacions són el que protegeix honestament el lector: diuen què no es va escanejar i quines fallades aquestes eines no troben.

Els cinc elements que converteixen una troballa en accionable: evidència reproduïble, impacte de negoci i no només tècnic, correcció concreta amb esforç estimat, criteri de verificació explícit i un propietari amb nom. L'error més freqüent és lliurar el bolcat de l'eina: 300 pàgines sense prioritzar que garanteixen que no es corregeixi res, perquè ningú no sap per on començar.

• Escanejar un cop l'any i dir-ne gestió de vulnerabilitats. L'inventari canvia cada setmana; millor mensual, automatitzat i revisat.
• Ordenar per CVSS i començar per dalt. Sense exposició, EPSS/KEV i criticitat de l'actiu dedicaràs el temps al que menys importa. És l'error més car de la lliçó.
• Escanejar sense credencials «per no molestar». Perds entre el 70 i el 85 % de les troballes del sistema; l'escaneig autenticat és la millora individual més rendible.
• Oblidar preproducció. A-22 té avui més ports oberts que producció. L'atacant no distingeix entorns: distingeix portes.
• Bloquejar el CI amb llindars impossibles, o tancar troballes sense verificar. El primer acaba amb el pipeline desactivat; el segon converteix «tancat» en «algú va dir que sí». Vigila la taxa de reobertura.
• Consell: comença pel diferencial. Abans de muntar Greenbone, automatitza un nmap extern setmanal que compari amb l'anterior i desa sempre la sortida crua amb data (-oA, JSON, SARIF): és la teva sèrie històrica, i sense tendència no hi ha conversa amb direcció. Mitja hora de feina que hauria evitat dues de les quatre troballes d'01-04.
• Consell: si només recordes una regla, que sigui aquesta. Una CVE a KEV i exposada es tracta avui.

La Lucía llança el primer escaneig extern mensual i obté:

1. Què cal esbrinar sobre pruebas-2019 abans fins i tot de mirar les versions?
2. Ordena les accions de la primera setmana justificant l'ordre amb els criteris de §7.
3. Què li falta a aquest escaneig perquè el procés sigui complet?

Ordena i assigna termini segons la política de §7, justificant cada decisió:

Identifica almenys cinc problemes a la proposta de l'Iván i explica com es corregeix cadascun.

Exercici 1

(1) La primera pregunta no és tècnica, és d'inventari: què és pruebas-2019, qui el va posar, quines dades conté i encara cal? Aquest nom suggereix un entorn de fa set anys que ningú no manté i que no és a l'inventari d'01-04 ni a l'abast de cap aplicació de pedaços. Si ningú no ho sap, la correcció no és aplicar-hi pedaços: és apagar-lo després de confirmar que res no en depèn, conservant-ne una còpia. Apagar és la correcció més barata, més ràpida i més definitiva que existeix, i la que menys es considera.

(2) Ordre de la primera setmana:

1. MySQL 3306 exposat (P0, 24 h). És el patró de R-03 però pitjor: base de dades accessible des d'Internet en un host sense manteniment des del 2019, amb credencials probablement febles. Es tanca al tallafoc avui, abans d'investigar res.
2. Determinar si conté dades personals reals (P0, en paral·lel). Si en conté i feia anys que estava exposat, deixa de ser una troballa tècnica: és una possible bretxa amb obligacions del RGPD (06-03) i activació del pla de 04-05.
3. Apagar el host (P1, 7 dies) un cop confirmat que res no en depèn. Apache 2.4.29 acumula anys de CVE: aplicar-hi pedaços és invertir en una cosa que ha de desaparèixer.
4. Afegir-lo a l'inventari i revisar el DNS cercant més subdominis oblidats: que aparegués en un escaneig i no a l'inventari significa que la cobertura no era del 100 %.

(3) Què falta: l'escaneig només mira els ports habituals de noms que algú recordava. Falten l'enumeració de subdominis des de la zona DNS, un -p- mensual (el http.server del 8000 no surt a --top-ports 1000), escaneig UDP bàsic, escaneig intern des de la VLAN d'usuaris i des de la VPC per mesurar la segmentació, i les capes que nmap no cobreix: escàner autenticat, SCA, SAST i configuració cloud. nmap és el 15 % del procés.

Exercici 2

Observació transversal: els dos primers no requereixen pedaç, sinó un canvi de configuració i una rotació de credencial, tots dos gratuïts i de minuts. El més urgent gairebé mai no és el més car.

Exercici 3

1. workflow_dispatch com a únic disparador: només s'executa a mà, és a dir, gairebé mai. Falten pull_request, push a main i un schedule que capturi CVE noves sense canvis de codi.
2. checkout sense fetch-depth: 0: gitleaks només veu l'últim commit, així que els secrets de l'historial —el cas real de Nimbus— passen desapercebuts indefinidament.
3. trivy image nimbus/api:latest: escaneja una etiqueta que no és la imatge que aquest canvi construeix. Es valida una imatge i se'n desplega una altra; cal construir i escanejar per SHA del commit.
4. --exit-code 1 sense --severity: bloqueja amb qualsevol troballa, incloses les informatives i les que no tenen pedaç. Es desactivarà en dues setmanes.
5. pip-audit sense -r requirements.txt: audita l'entorn del runner, no el projecte; pot passar en verd amb dependències vulnerables.
6. No es publica cap resultat i no hi ha permissions explícites: sense SARIF ni artefactes no hi ha historial, tendència ni evidència per a 04-03, i el token opera amb més permisos dels necessaris, contra el mínim privilegi d'01-03.

La versió corregida és la de l'apartat 9, amb fetch-depth: 0, els tres disparadors, permissions acotades, llindar propi a ci/llindar.py, imatge etiquetada per SHA i publicació SARIF amb if: always().

Has convertit el «verificar» del mòdul 4 en un procés mesurable. Saps que la gestió de vulnerabilitats és un cicle —inventariar, descobrir, prioritzar, esmenar, verificar i informar— i no un PDF anual, i que el pas 0 mana: sense inventari no hi ha cobertura, i sense cobertura la resta de mètriques menteixen. Coneixes el mapa de les nou famílies d'eines i, sobretot, què no veu cap d'elles: l'IDOR de Nimbus no apareix en cap escàner, perquè aquestes eines detecten errors de patró i no errors de raonament.

Manegues nmap opció a opció i saps per què l'escaneig extern i l'intern mesuren coses diferents; amb ell has retrobat amb data i evidència les quatre troballes d'01-04. Saps què fa realment un escàner de vulnerabilitats, per què l'escaneig autenticat en troba entre cinc i deu vegades més, i a llegir un informe començant pel QoD. Amb pip-audit i trivy distingeixes vulnerabilitat present de vulnerabilitat explotable, amb l'abastabilitat i el document VEX com a forma correcta de dir «no ens afecta» sense perdre traçabilitat. Amb semgrep, bandit i gitleaks has tancat el verify=False i has trobat la credencial de PostgreSQL a l'historial, la correcció de la qual comença per rotar-la i no per esborrar el fitxer. I t'endus la part que separa un procés útil d'un full de càlcul inútil: prioritzar amb CVSS base/temporal/ambiental, EPSS com a probabilitat i KEV com a fet observat, la política de terminis P0-P4 i un càlcul que reordena la llista fins a deixar la CVE de 9.1 a l'últim lloc; validar falsos positius en cinc passos; integrar-ho tot en un pipeline que bloqueja el que és accionable i informa de la resta; i redactar una troballa accionable amb evidència, impacte de negoci, correcció estimada, verificació i propietari.

Però fixa't en el límit de tot l'anterior: aquest procés troba portes mal tancades; no veu ningú entrant-hi. Si demà un atacant fa servir la credencial de la consultora a les 22:14, cap escàner d'aquesta lliçó no se n'assabentarà: el port està legítimament obert i la credencial és vàlida. Aquest és el buit que va deixar vint dies de silenci a l'incident de 02-06 i que el catàleg de 04-03 reflecteix amb vuit controls detectius dels quals només dos estan implantats. A Tècniques de Monitoratge i Detecció (05-02) construïm per fi aquests controls: què registrar, on centralitzar-ho, com escriure deteccions que es disparin amb el que importa i callin amb el que no, i com reduir el temps de permanència de l'atacant de vint dies a un matí.