La cybersecurity in Italia continua a crescere, il mercato è arrivato a 2,78 miliardi di euro nel 2025, +12% rispetto al 2024. Nel primo semestre ci sono stati 2.755 attacchi gravi a livello globale, +36% rispetto al semestre precedente. Per chi sviluppa software, proteggere GitHub è diventato parte del modo in cui si scrive, si rivede e si rilascia il codice.
I punti deboli di GitHub sono evidenti a tutti, i team sono stanchi di fare i controlli a fine progetto. È arrivato il momento di cambiare approccio, di portare i controlli dentro le pull request, di automatizzare la scansione delle dipendenze, di ridurre i permessi dei token e i trattano i file di workflow come codice vero, non come semplici configurazioni. Il confronto tra diversi github security tools aiuta proprio a capire questa evoluzione: non basta più uno strumento per segnalare che qualcosa non va, serve un sistema che dica dove intervenire, quando farlo e con quale priorità.
Contenuti dell'articolo
La sicurezza entra nella pull request, non arriva a fine sprint
Per anni, molti team hanno trattato la security review come un passaggio separato. Prima si sviluppava, poi qualcuno controllava. Oggi questo modello regge sempre meno, soprattutto quando le release sono frequenti e le pipeline CI/CD spingono codice in produzione anche più volte al giorno.
La direzione più efficace è spostare i controlli nel punto in cui gli sviluppatori lavorano già: la pull request. Un controllo su una libreria vulnerabile, su una credenziale finita per errore in un commit o su un permesso troppo largo nel workflow diventa parte della revisione normale, non una sorpresa che arriva settimane dopo. Non si lavora più solo per evitare l’incidente, ma per accorgersene prima e contenerlo meglio.
Segreti e token sono diventati il punto più fragile dei workflow
Dentro GitHub non ci sono solo file sorgente. Ci sono chiavi API, token temporanei, variabili d’ambiente, permessi per pubblicare pacchetti, accessi al cloud e automazioni che possono fare molte cose in autonomia. È comodo, certo, ma aumenta la superficie da controllare.
Un errore molto comune è lasciare a un workflow più permessi del necessario. Il problema è che, se quel workflow viene abusato, il danno può uscire dal singolo repository e toccare ambienti molto più ampi.
Le pratiche che stanno prendendo piede sono semplici da capire:
- usare il privilegio minimo per ogni token
- evitare token personali quando non servono davvero
- bloccare le azioni di terze parti su versioni precise o commit SHA
- separare i workflow che fanno test da quelli che rilasciano in produzione
Le FAQ tecniche sulla sicurezza GitHub pubblicate in italiano insistono proprio su questi punti: token con permessi limitati, input validati e workflow trattati come parte della superficie d’attacco.
Dipendenze e supply chain spingono i team a guardare oltre il codice
Un’app moderna usa decine, a volte centinaia di componenti esterni. Pacchetti open source, container, action di terze parti, moduli IaC, librerie frontend e backend. Tutto accelera lo sviluppo, ma ogni pezzo aggiunge una dipendenza da conoscere.
È per questo che i team engineering non guardano più solo il codice scritto internamente. Guardano anche tutto ciò che entra nel progetto. Dependabot, Software Composition Analysis, secret scanning, controlli sui container e analisi IaC servono proprio a evitare che una vulnerabilità nota resti nascosta fino al deploy.
Il tema si lega anche alla normativa europea. Il Cyber Resilience Act, pubblicato nella Gazzetta Ufficiale dell’Unione Europea nel novembre 2024 ed entrato in vigore a dicembre 2024, ha reso molto più centrale la tracciabilità dei componenti software.
Meno alert e più priorità chiare per non bloccare gli sviluppatori
Se ogni scansione produce decine di alert poco chiari, il team smette di fidarsi dello strumento. Gli sviluppatori non hanno bisogno di dashboard infinite, hanno bisogno di sapere quale problema va risolto subito, quale può aspettare e quale non è davvero rilevante nel loro contesto.
È qui che si vede la differenza tra sicurezza “aggiunta” e sicurezza “integrata”. La prima rallenta, perché scarica sul team una lista grezza di problemi. La seconda filtra, ordina e porta il feedback dove serve.
Non a caso, testing e vulnerability management sono tra le aree prioritarie di spesa, insieme ai servizi gestiti. Non è difficile capire perché: le aziende vogliono controlli continui, ma non vogliono paralizzare i rilasci.
La direzione è semplice: workflow sicuri senza perdere velocità
La sicurezza dei workflow GitHub sta diventando più concreta. Meno documenti generici, più controlli. Meno riunioni dopo l’incidente, più segnali utili prima del merge.
Il punto non è trasformare ogni sviluppatore in un esperto di cybersecurity. Il punto è dare al team gli strumenti e le regole che consentono di fare la cosa giusta. Una pull request che mostra subito una dipendenza fragile, un workflow che fallisce: sono piccoli dettagli, ma messi insieme cambiano il livello di protezione in modo significativo.
Quindi, i team engineering più maturi non stanno scegliendo tra la velocità e la sicurezza. Stanno costruendo workflow in cui le due cose viaggiano insieme, nello stesso posto dove nasce il software: dentro GitHub.
