Neotecnica

WWG ha realizzato il progetto attraverso quattro flussi di lavoro paralleli, strutturati per produrre sia una riduzione immediata del rischio sia una chiara roadmap per la modernizzazione a lungo termine.

WWG ha eseguito un audit completo su tutti e quattro i repository utilizzando una metodologia multi-strumento coerente. Ogni codebase è stata valutata per:

• Vulnerabilità di sicurezza: npm audit e osv-scanner hanno rilevato oltre 19 problemi nel frontend e nella libreria dei componenti, tra cui CVE ad alta gravità nelle dipendenze principali e una vulnerabilità ReDoS confermata che interessa tre repository distinti.

• Salute delle dipendenze: npm-check e depcheck hanno identificato pacchetti inutilizzati che si accumulavano come peso morto e decine di pacchetti obsoleti di una o più versioni principali.
• Qualità del codice: ESLint ha rilevato circa 9.000 problemi nel frontend React e oltre 4.000 nella libreria dei componenti, principalmente violazioni di no-undef, variabili inutilizzate e utilizzo di @typescript-eslint/no-explicit-any.
• Backend Java: l'analisi del codice sorgente con SonarQube ha identificato credenziali hardcoded, blocchi di eccezioni catch-all, SQL manuale, blocchi di codice commentati e classi di grandi dimensioni strettamente accoppiate come i principali rischi per la manutenibilità.

Ogni audit è stato consegnato come un report strutturato con una classificazione della gravità per area e una roadmap di risoluzione prioritaria.

WWG ha condotto un audit completo del flusso di lavoro Git di Neotecnica su tutti i repository, documentando i rischi dell'approccio attuale: branch principali non protetti, merge diretti da branch di funzionalità a lungo termine, assenza di revisione del codice basata sulle pull request e nessun gate CI prima della produzione.

Sono state valutate in dettaglio due strategie di branching alternative: GitHub Flow (ottimizzata per cicli di implementazione frequenti) e Trunk-Based Development (ottimizzata per ridurre al minimo i conflitti di merge tramite branch di breve durata e feature flag). Per la libreria di componenti React privata, la valutazione ha affrontato in particolare la sfida dei branch beta di lunga durata, che non si adattano perfettamente a nessuno dei due modelli standard. Insieme ai risultati dell'audit è stata fornita una raccomandazione di implementazione concreta, comprensiva di regole di protezione dei branch, modelli di pull request e checkpoint di integrazione CI.

WWG ha ristrutturato da zero i cluster Kubernetes di Neotecnica per garantire alta disponibilità e un supporto CI/CD moderno:

• Alta disponibilità con 3 nodi control plane e gruppi di nodi worker dedicati in base ai carichi di lavoro.
• Installazione e configurazione di Rancher come interfaccia utente per la gestione del cluster, che consente la visibilità dei carichi di lavoro e il controllo operativo senza la necessità di conoscere la riga di comando.
• Installazione di Jenkins con agenti nativi di Kubernetes: le pipeline vengono eseguite con pod effimeri, eliminando la necessità di agenti persistenti sulle VM.
• Implementazione di Nexus Artifact Repository per l'hosting di pacchetti NPM privati ​​(in sostituzione dei sottomoduli Git) e artefatti di build Maven.

Ciascuna delle quattro codebase operava con una configurazione di base diversa: set di regole ESLint diversi, gestori di pacchetti diversi, sistemi di build diversi. Standardizzare la metodologia di audit su tutte senza modificare le configurazioni esistenti ha richiesto un'attenta selezione degli strumenti e un'accurata interpretazione dei risultati. In particolare, distinguere i problemi di ESLint che erano artefatti di configurazione (ad esempio, regole che segnalavano pattern intenzionalmente dinamici) dal vero debito tecnico ha richiesto una revisione a livello di codice insieme all'output automatizzato.

Il repository della libreria dei componenti aveva sviluppato un modello di branching in cui un branch di funzionalità si era di fatto trasformato in un branch di versione beta di lunga durata. Né GitHub Flow né lo sviluppo basato sul trunk gestiscono questo modello in modo pulito fin da subito: GitHub Flow scoraggia i branch che durano più di una settimana e lo sviluppo basato sul trunk richiede flag di funzionalità per il lavoro non completato. L'audit Git di WWG ha affrontato specificamente questo problema, fornendo una raccomandazione ibrida che riconosceva le esigenze di versioning della libreria senza imporre un flusso di lavoro che avrebbe creato attrito per il team.

I tre repository principali di Neotecnica — un'applicazione React, una libreria NPM privata e un backend Java Maven — hanno requisiti CI/CD significativamente diversi. Un'app React richiede un flusso di lavoro standardizzato per i controlli di qualità e la distribuzione automatizzata. Una libreria NPM necessita di versioning automatizzato e di una gestione sicura degli artefatti per la distribuzione. Un backend Maven richiede un processo di build complesso, che include la containerizzazione e il deployment su un registro privato. WWG ha progettato pipeline di esempio per tutte e tre le tipologie, utilizzando le librerie condivise di Jenkins per estrarre la logica dei modelli riutilizzabile, riducendo le duplicazioni e garantendo al team di Neotecnica riferimenti operativi anziché linee guida astratte.

Sia il server Keycloak che il server OpenVPN erano attivi e in uso durante l'intervento. Le valutazioni e il rafforzamento della sicurezza secondo i benchmark CIS hanno richiesto l'individuazione delle raccomandazioni applicabili immediatamente e di quelle che necessitavano di finestre di manutenzione pianificate.