Proteggere i tuoi repository Git: buone pratiche e fonti non attendibili

Proteggere i tuoi repository Git significa più che mantenere il codice privato. Un repository può contenere segreti, hook eseguibili, rischi legati alla supply chain, cronologia sensibile e configurazioni che influenzano ogni sviluppatore che lo clona.

Buone pratiche di sicurezza Git ti aiutano a evitare credenziali trapelate, automazione non sicura e fiducia accidentale in codice proveniente da fonti sconosciute. Le basi sono semplici, ma devono essere applicate in modo coerente.

Proteggi i segreti prima che arrivino a Git

Il segreto più sicuro è quello che non entra mai nel repository. Chiavi API, chiavi private SSH, credenziali cloud, password di database, token e file .env dovrebbero rimanere completamente fuori da Git.

Aggiungi i file segreti locali a .gitignore:

.env
.env.*
*.pem
id_rsa
id_ed25519

Fai attenzione con .env.example. Quel file è spesso utile, ma dovrebbe contenere valori fittizi segnaposto:

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=sostituiscimi

Non incollare valori reali "solo per testare". La cronologia di Git ricorda le versioni precedenti anche dopo aver eliminato una riga in un commit successivo.

Se commetti accidentalmente un segreto, trattalo come esposto. Rimuovilo dall'albero corrente, ruota la credenziale nel servizio che l'ha emessa e poi decidi se è necessaria una pulizia della cronologia. Riscrivere la cronologia può aiutare a ridurre l'esposizione futura, ma non garantisce che il segreto non sia mai stato copiato.

I team dovrebbero anche utilizzare la scansione dei segreti. Molte piattaforme Git ospitate offrono scansione per pattern di token comuni. Strumenti di pre-commit locali possono cogliere errori prima, prima che un push raggiunga il server.

Per pattern operativi correlati, vedi padroneggiare le variabili d'ambiente per configurazione e segreti.

Blocca l'accesso e le modifiche ai rami

La sicurezza del repository inizia con il controllo degli accessi. Dai alle persone il minimo accesso di cui hanno bisogno. Qualcuno che revisiona solo codice probabilmente non ha bisogno di diritti di amministratore. Un account di servizio CI probabilmente non ha bisogno del permesso di riscrivere i rami.

Revisiona regolarmente queste impostazioni:

• Amministratori e proprietari del repository.
• Collaboratori con accesso in scrittura.
• Chiavi di deploy e utenti macchina.
• Token di accesso personale utilizzati dall'automazione.
• Webhook che ricevono eventi del repository.
• Regole di protezione dei rami.

I rami protetti sono uno dei controlli più utili. Per rami importanti come main, richiedi pull request, controlli di stato e revisione prima del merge. Disabilita i force push a meno che il tuo team non abbia una ragione molto specifica per permetterli.

I commit firmati o i tag firmati possono anche aiutare in ambienti a maggiore fiducia. Non rendono il codice sicuro da soli, ma possono dimostrare che un commit o un tag di rilascio è stato creato da una chiave che il tuo team riconosce.

Usa i tag con attenzione per i rilasci. Se un processo di deploy si fida dei tag, limita chi può crearli o spostarli. Un tag di rilascio spostato può confondere audit e deploy.

Fai attenzione con i repository non attendibili

Clonare codice da una fonte non attendibile è comune. Eseguirlo immediatamente è la parte rischiosa. Un repository Git può includere script di build, script di ciclo di vita dei pacchetti, Makefile, container, configurazione CI e istruzioni che eseguono codice sulla tua macchina.

Prima di eseguire qualsiasi cosa, ispeziona il repository:

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

Poi controlla i file ad alto rischio:

• Script shell come install.sh o bootstrap.sh.
• Script di pacchetto in package.json.
• File CI sotto .github/workflows/, .gitlab-ci.yml o percorsi simili.
• Dockerfile e file compose.
• Makefile.
• Manifest delle dipendenze specifici del linguaggio.

Non eseguire comandi di configurazione curl | bash da un README casuale. Se un progetto richiede un installer, scaricalo, leggilo ed eseguilo in un ambiente usa e getta se possibile.

Gli hook Git meritano una menzione speciale. Gli hook in .git/hooks/ non vengono normalmente trasferiti come hook attivi quando cloni un repository. Questo è positivo. Ma un repository può includere script che installano hook per te. Leggi quegli script prima di eseguirli perché gli hook possono eseguire durante commit, merge, rebase e push.

Per codice sconosciuto, usa l'isolamento. Una macchina virtuale temporanea, un contenitore o un ambiente di sviluppo bloccato riduce il raggio d'esplosione se uno script si comporta male. Non montare le tue chiavi SSH, credenziali cloud o kubeconfig di produzione in un ambiente utilizzato per codice non attendibile.

Mantieni la cronologia e i file del repository puliti

La sicurezza è più facile quando il repository è ordinato. File binari grandi, archivi generati, segreti venduti e vecchi dump di configurazione rendono la revisione più difficile e aumentano il rischio.

Usa .gitignore per i file locali e .gitattributes per le regole di gestione dei file. Per esempio:

*.sh text eol=lf
*.png binary
*.jpg binary

Se il tuo progetto ha bisogno di file grandi, considera se Git Large File Storage è appropriato. Git standard non è ideale per enormi artefatti di build o file multimediali. Memorizzarli direttamente può rallentare i clone e rendere più difficile la pulizia di file sensibili.

Revisiona le pull request per modifiche sensibili alla sicurezza, non solo logica applicativa. Fai attenzione a:

• Nuove credenziali o token.
• Nuove chiamate di rete negli script.
• Modifiche alla fonte delle dipendenze.
• Nuove autorizzazioni CI.
• Modifiche agli script di deploy.
• Modifiche ampie a .gitignore che nascondono file importanti.

Presta attenzione anche ai sottomoduli. Puntano a repository esterni e commit specifici. Se il tuo progetto li usa, revisiona attentamente gli URL e gli aggiornamenti dei sottomoduli.

Quando coinvolgere un professionista

Coinvolgi un ingegnere della sicurezza, un responsabile DevOps o un responsabile della gestione degli incidenti se un segreto è stato inviato a un repository pubblico, un ramo protetto è stato forzato inaspettatamente o un contributore sconosciuto ha modificato l'automazione CI o di deploy.

Dovresti anche chiedere aiuto se sospetti che la cronologia del repository sia stata manomessa. Preservare le prove può essere più importante che pulire rapidamente, specialmente in un ambiente aziendale.

Proteggere i repository Git si riduce a una fiducia disciplinata. Mantieni i segreti fuori, limita l'accesso, proteggi i rami importanti e ispeziona il codice non attendibile prima di eseguirlo. Queste abitudini prevengono la maggior parte dei problemi di sicurezza del repository prima che diventino incidenti.