GitHub: separare validazione iniziale e analisi settimanale
Scansioni settimanali in repository inattivi possono sembrare sviluppo attivo. Meno esecuzioni non significano automaticamente meno protezione.
Il 1° ottobre 2026 GitHub ha modificato l’avvio delle analisi pianificate di code scanning default setup e GitHub Code Quality. Distinguiamo fatti e proposte operative.
La validazione iniziale resta
Attivare il setup continua a eseguire una validazione con risultati. Le scansioni settimanali iniziano dopo un’analisi provocata da push o pull request. Conta la cronologia delle analisi, non l’attività Git precedente.
Code scanning e Code Quality condividono la valutazione dell’attività. Vale per Enterprise Cloud ed è previsto per Enterprise Server 3.24. GitHub non richiede modifiche alla configurazione.
Registrare setup e analisi separatamente
Proponiamo di annotare stato, ultimo evento, commit, ora del risultato e responsabile. L’attivazione da sola non prova un ciclo settimanale attivo.
Un archivio con sola validazione iniziale può essere registrato come configurato e verificato inizialmente. Aggiungi a parte la prova di analisi push o pull request. Sono note del team, non nuovi stati GitHub.
Meno esecuzioni non equivale a meno vulnerabilità
Non trasformare la diminuzione in un punteggio di sicurezza. Controlla validità dei risultati, risoluzione e collegamenti con servizi attivi.
Un repository inattivo può contenere sorgenti in produzione. Verifica copertura, dipendenze e responsabilità senza dedurre l’importanza dall’attività.
Iniziare con una revisione limitata
Confronta un repository mantenuto con un archivio. Leggi configurazione e cronologia distinguendo validazione da analisi push o pull request.
Non creare commit inutili o cambiare impostazioni validate per questa verifica. Registra ambiente e versione in caso di divergenze. Il diagramma descrive la revisione, non è una schermata del prodotto.