A l'hostil i sempre canviant món de la ciberseguretat, la història de la vulnerabilitat CVE-2024-6387 ens ofereix una lliçó crucial sobre la importància de la gestió del codi i la revisió constant de la seguretat. Aquesta vulnerabilitat, va ser identificada el 2006, i reintroduïda (imaginem que per error) al codi font d'OpenSSH el 2020, concepte que s'anomena “Regressió” (per això se'n diu una vulnerabilitat RegreSSHió), causant consternació entre els experts i usuaris per igual.
Com és possible que una fallada identificada fa gairebé dues dècades torni a sorgir en el programari modern?
Per entendre aquest fenomen, hem de considerar diversos factors clau a SSDLC (Secure Software Development Life Cicle):
Gestió del Codi i Control de Versions: El 2006, la vulnerabilitat va ser documentada i aplicada, però els sistemes de control de versions i la gestió del codi no sempre asseguren que els pegats siguin permanents. En algun moment entre la identificació original i 2020, el codi vulnerable va ser reintroduït, possiblement a causa de la fusió incorrecta de branques de codi o la reutilització de components antics que no es van actualitzar adequadament (no pensem malament, si us plau!!).
Desenvolupament de Programari i Cicle de Vida del Codi: A mesura que el programari evoluciona, el cicle de vida del codi implica nombroses actualitzacions, millores i correccions. En grans projectes, és fàcil que les modificacions passades es perdin al mar de canvis continus, especialment si no hi ha un seguiment rigorós i una documentació exhaustiva.
Cadena de subministrament / Dependències de llibreries de tercers: El desenvolupament modern sovint depèn de múltiples biblioteques i components de tercers. Si una vulnerabilitat es troba en un d'aquests components i no es gestiona correctament, pot ser reintroduïda en actualitzar o canviar dependències sense la diligència deguda.
Auditories i Revisions de Seguretat: Tot i que les auditories de seguretat són essencials, no sempre garanteixen la detecció de totes les vulnerabilitats, especialment si l'auditoria no se centra a revisar l'historial complet del codi. La reintroducció de CVE-2024-6387 subratlla la necessitat d'auditories exhaustives i contínues, així com de processos automatitzats que alertin sobre la reaparició de fallades conegudes.
Eines usades per auditar codi
Fa un temps en sessions de consultoria d'implantació de l'Esquema Nacional de Seguretat amb un client, vaig conèixer un parell d'eines d'anàlisi de codi que considero que són una meravella i un “MUST” a tots els equips de desenvolupament i que probablement haurien fet saltar les alarmes en algun dels múltiples Pull Requests que haurà patit el codi des del 2020.
SNYK
SNYK és una eina especialitzada en la seguretat del codi i les dependències. El seu enfocament principal és la detecció i correcció de vulnerabilitats en temps real, cosa que permet als desenvolupadors integrar la seguretat directament al seu flux de treball de desenvolupament.
Anàlisi de Dependències: SNYK escaneja les dependències del projecte i alerta sobre qualsevol vulnerabilitat coneguda, incloent-hi aquelles que podrien haver estat reintroduïdes accidentalment.
Monitorització Continu: Ofereix monitoratge continu, cosa que significa que fins i tot després de la integració inicial, SNYK seguirà analitzant el codi i les dependències a la recerca de noves vulnerabilitats.
Correcció Automàtica: Proposa solucions i actualitzacions de seguretat per a les vulnerabilitats detectades, ajudant els equips a resoldre problemes ràpidament.
SonarQube
SonarQube és una plataforma robusta per a la inspecció contínua de la qualitat del codi, que inclou anàlisis de seguretat, detecció de bugs, i avaluació de la qualitat del codi en general.
Detecció de Vulnerabilitats i Bugs: SonarQube pot identificar problemes de seguretat i bugs al codi, incloent patrons de vulnerabilitats que podrien reaparèixer.
Revisions de Codi Automatitzades: Ajuda a mantenir estàndards de codificació consistents mitjançant revisions automatitzades, cosa que redueix la probabilitat que el codi insegur sigui reintroduït.
Historial i Comparació de Codi: SonarQube manté un historial de les revisions de codi i permet comparar canvis, cosa que és crucial per identificar quan i com una vulnerabilitat reintroduïda podria haver passat.
Integració al Cicle de Vida del Desenvolupament
Per maximitzar l'eficàcia d'aquestes eines, és fonamental integrar-les al cicle de vida del desenvolupament de programari (SDLC). Aquí hi ha algunes pràctiques recomanades:
Integració Contínua (CI/CD): Integrar SNYK i SonarQube a les canonades de CI/CD per assegurar que el codi sigui analitzat automàticament a cada commit i build.
Gestió de Canvis i Passi a producció: Establir un procés robust i rigorós que requereixin l'aprovació de les anàlisis de seguretat abans de fusionar qualsevol nou codi.
Formació i Capacitació: Assegurar que els desenvolupadors estiguin capacitats per utilitzar aquestes eines i interpretar els resultats per prendre les accions correctives necessàries. NOTA: Us sorprendria la quantitat de desenvolupadors que audito que tenen coneixements Baixos o Nuls a Ciberseguretat... Com a mínim saber interpretar aquestes eines, és vital.
Conclusió final
Eines com SNYK i SonarQube són vitals per prevenir la reintroducció de vulnerabilitats com la CVE-2024-6387. En proporcionar anàlisi continua, detecció automàtica de vulnerabilitats i bugs, i solucions correctives, aquestes eines ajuden a mantenir la integritat i seguretat del codi al llarg del temps. Integrar eficaçment en el cicle de vida del desenvolupament de programari i assegurar que els equips estiguin ben entrenats en el seu ús és fonamental per crear i mantenir programari segur i d'alta qualitat.
