Configurare l'analisi del codice
È possibile configurare il modo in cui GitHub analizza il codice nel progetto per individuare vulnerabilità ed errori. Quando si sceglie una configurazione personalizzata, si risparmia tempo e si decide la frequenza di analisi del codice migliore per il progetto. In questa unità si apprenderanno i concetti di base della configurazione dell'analisi del codice. Si apprenderà anche come configurare la frequenza delle analisi e pianificarle in base alle esigenze di sviluppo e del repository.
Come illustrato nelle unità precedenti, è possibile eseguire l'analisi del codice in GitHub, usando GitHub Actions o dal sistema di integrazione continua. Se si seleziona l'opzione advanced setup in GitHub, viene generato un file del flusso di lavoro personalizzabile di cui è possibile eseguire il commit direttamente nel repository. Non è in genere necessario modificare questo flusso di lavoro. Se necessario, è tuttavia possibile personalizzare alcune delle impostazioni.
È ad esempio possibile modificare il flusso di lavoro di analisi di CodeQL di GitHub per specificare la frequenza di analisi, i linguaggi o le directory da analizzare e gli elementi cercati nel codice dall'analisi del codice di CodeQL. Potrebbe anche essere necessario modificare il flusso di lavoro di analisi di CodeQL se si usa un set specifico di comandi per compilare il codice. L'analisi di CodeQL è solo un tipo di analisi del codice che è possibile eseguire in GitHub. GitHub Marketplace contiene diversi altri flussi di lavoro di analisi del codice.
Passaggio dall'impostazione predefinita alla configurazione avanzata dell'analisi del codice
Se è già disponibile una configurazione del repository per l'analisi del codice usando il metodo di configurazione predefinito, è possibile passare all'utilizzo della configurazione avanzata nelle impostazioni. Passare alla sezione Analisi codice in Impostazioni > sicurezza avanzata e quindi selezionare l'icona a tre puntini di overflow (...). Nell'elenco a discesa selezionare Passa ad avanzate. Seguire quindi le istruzioni per disabilitare CodeQL e riabilitarlo con il file del flusso di lavoro generato dall'installazione avanzata.
Modificare il flusso di lavoro di analisi del codice
GitHub salva i file del flusso di lavoro nella directory .github/workflows del repository. È possibile trovare un flusso di lavoro aggiunto cercando il relativo nome file. Per impostazione predefinita, ad esempio, il file del flusso di lavoro per l'analisi del codice di CodeQL è denominato codeql-analysis.yml.
Seguire questa procedura per modificare un file del flusso di lavoro:
- Per aprire l'editor del flusso di lavoro, selezionare l'icona di Modifica nell'angolo superiore destro della visualizzazione file.
Apportare le modifiche.
Dopo aver modificato il file, seleziona Conferma modifiche e compila il modulo di Conferma modifiche. È possibile scegliere di eseguire il commit direttamente nel ramo corrente oppure creare un nuovo ramo e avviare una richiesta pull.
Esaminare le sezioni seguenti per scoprire alcune opzioni di configurazione comuni per l'analisi del codice.
Configurare la frequenza
Una modifica comune al file del flusso di lavoro consiste nel regolare la frequenza con cui viene eseguita l'analisi del codice. È possibile configurare il flusso di lavoro di analisi di CodeQL per analizzare il codice in base a una pianificazione o quando si verificano eventi specifici in un repository. È anche possibile modificare il file del flusso di lavoro per analizzare il codice quando un utente esegue il push di una modifica e ogni volta che viene creata una richiesta pull. La regolazione di questa frequenza impedisce agli sviluppatori di introdurre nuovi errori e vulnerabilità nel codice. L'analisi del codice in base a una pianificazione indica le vulnerabilità e gli errori più recenti che GitHub, i ricercatori della sicurezza e la community individuano, anche quando gli sviluppatori non gestiscono attivamente il repository.
Scansione alla pressione
Per impostazione predefinita, il flusso di lavoro di analisi di CodeQL usa l'evento on:push per attivare un'analisi del codice per ogni push nel ramo predefinito del repository e in tutti i rami protetti. Affinché l'analisi del codice venga attivata in un ramo specificato, il flusso di lavoro deve esistere in tale ramo. Se si esegue la scansione con il comando push, i risultati vengono visualizzati nella scheda Sicurezza del repository.
Inoltre, quando un'analisi on:push restituisce un risultato di cui è possibile eseguire il mapping a una richiesta pull aperta, questi avvisi vengono visualizzati automaticamente nella richiesta pull nella stessa posizione degli altri avvisi delle richieste pull. Gli avvisi vengono identificati confrontando l'analisi esistente del capo del ramo con l'analisi per il ramo di destinazione.
Analisi per ogni richiesta pull
Il flusso di lavoro di analisi di CodeQL predefinito usa l'evento pull_request per attivare un'analisi del codice sulle richieste pull destinate al ramo predefinito. Se una richiesta pull proviene da un fork privato, l'evento pull_request viene attivato solo se è stata selezionata l'opzione per l'esecuzione di flussi di lavoro da richieste pull di fork nelle impostazioni del repository. Se si analizzano le richieste pull, i risultati vengono visualizzati come avvisi in un controllo delle richieste pull.
Se si usa il trigger pull_request, configurato per analizzare il commit di merge della richiesta pull anziché il commit head, si ottengono risultati più efficienti e accurati rispetto all'analisi dell'intestazione del ramo per ogni push. Se tuttavia si usa un sistema CI/CD che non può essere configurato per attivare le richieste pull, è comunque possibile usare il trigger on:push in modo che l'analisi del codice esegua il mapping dei risultati alle richieste pull aperte nel ramo e aggiunga gli avvisi come annotazioni in una richiesta pull.
Definire i livelli di gravità che causano un fallimento del controllo della pull request
Per impostazione predefinita, solo gli avvisi con il livello di gravità Error o con il livello di gravità della sicurezza Critical oppure High provocano un errore di controllo della richiesta pull.
Questi errori non bloccano l'esecuzione dell'analisi del codice, ma possono bloccare l'unione a seconda delle regole del repository. È possibile visualizzare i dettagli degli errori delle richieste pull nella scheda Avvisi di analisi del codice in Sicurezza.
È possibile configurare, nelle impostazioni del repository oppure tramite i ruleset del repository che usano la regola Richiedi i risultati dell’analisi del codice, quali livelli di gravità causano il fallimento dei controlli delle pull request. Entrambi i meccanismi funzionano, ma i set di regole sono il metodo di configurazione moderno e preferito.
- Su GitHub.com, naviga alla pagina principale del repository. Sotto il nome del repository selezionare Settings.
- Nella barra laterale sinistra selezionare Sicurezza avanzata.
- Nella sezione Code scanning sotto Protection rules usare il menu a discesa per selezionare il livello di gravità per cui si vuole attivare un errore di controllo della richiesta pull.
Esaminare e chiudere gli avvisi di analisi del codice in modo responsabile
La correzione del codice è il modo migliore per risolvere un avviso di analisi del codice. Tuttavia, alcuni avvisi potrebbero non richiedere una modifica del codice. Ad esempio, l'avviso può essere un falso positivo, viene visualizzato solo nel codice di test o rappresenta un rischio che il team ha deciso di non correggere.
Ignorare gli avvisi solo dopo aver esaminato i dettagli dell'avviso e aver confermato il motivo. Quando si ignora un avviso, GitHub registra il motivo di chiusura, rimuove l'avviso dal conteggio degli avvisi corrente, lo sposta nell'elenco chiuso e impedisce la generazione dello stesso avviso nelle analisi future. Il licenziamento si applica a tutte le filiali.
Scegliere attentamente il motivo di chiusura perché diventa parte del record di sicurezza per il repository. È anche possibile aggiungere un commento di rifiuto per spiegare la decisione. Questo commento viene aggiunto alla sequenza temporale degli avvisi e può supportare future verifiche di controllo, report e conformità.
Usare i commenti per acquisire dettagli, ad esempio:
Perché l'avviso non necessita di una modifica del codice
Chi ha esaminato la decisione
Indica se la decisione è temporanea o permanente
Qualsiasi controllo di compensazione o lavoro di completamento
Per una governance più solida, le organizzazioni possono usare l'archiviazione delegata degli avvisi per controllare chi è autorizzato ad archiviare gli avvisi di scansione del codice. Questo aiuta a impedire agli sviluppatori di chiudere i problemi di sicurezza senza una revisione e crea un processo di triage più responsabile.
Evitare analisi non necessarie delle richieste pull
È possibile che si voglia evitare l'attivazione di un'analisi del codice su richieste pull specifiche destinate al ramo predefinito, indipendentemente dai file modificati. È possibile configurare questa impostazione specificando on:pull_request:paths-ignore o on:pull_request:paths nel flusso di lavoro di analisi del codice. Se ad esempio le uniche modifiche apportate a una richiesta pull sono relative ai file con le estensioni di file .md o .txt, è possibile usare la matrice seguente paths-ignore.
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
paths-ignore:
- '**/*.md'
- '**/*.txt'
Regolare l'orario della scansione
Se si usa il flusso di lavoro di analisi di CodeQL predefinito, il flusso di lavoro analizza il codice nel repository una volta alla settimana in un giorno e a un orario generati in modo casuale, oltre alle analisi attivate dagli eventi. Per modificare questa pianificazione, modificare il valore cron nel flusso di lavoro.
L'esempio seguente mostra un flusso di lavoro di analisi di CodeQL per un repository con un ramo predefinito denominato main e un ramo protetto denominato protected:
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
schedule:
- cron: '20 14 * * 1'
Questo flusso di lavoro analizza:
Ogni push nel ramo predefinito e nel ramo protetto
Ogni richiesta pull nel ramo predefinito
Il ramo predefinito ogni lunedì alle 14:20 (UTC)
Usa i suggerimenti Autofix di Copilot
GitHub Copilot Autofix aiuta gli sviluppatori a risolvere gli avvisi della scansione del codice suggerendo modifiche mirate al codice. Autofix usa le informazioni dell'avviso, della base di codice e della pull request per generare una possibile correzione. Non è necessario un abbonamento GitHub Copilot separato per utilizzare Copilot Autofix. È disponibile per i repository pubblici in GitHub.com e per i repository di proprietà dell'organizzazione con GitHub Sicurezza del codice abilitata.
I suggerimenti di correzione automatica non sono correzioni automatiche. Vengono proposte modifiche che devono essere esaminate, testate e approvate come qualsiasi altra modifica del codice.
Quando si esamina un suggerimento di Autofix:
Leggere l'avviso e comprendere il problema di sicurezza.
Esaminare le modifiche al codice suggerite.
Verificare che la correzione indirizzi l'avviso senza modificare il comportamento previsto.
Eseguire i test del progetto ed eventuali controlli di sicurezza necessari.
Modificare il suggerimento, se necessario.
Esegui il commit della correzione alla pull request.
Conferma che l'avviso di analisi del codice sia stato risolto dopo che i controlli sono stati eseguiti nuovamente.
Se un suggerimento di Autofix non è appropriato, rifiuta il suggerimento anziché applicarlo. Se l'avviso stesso non deve essere risolto, ignorare l'avviso con il motivo corretto e un commento chiaro.