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 dalla configurazione di analisi del codice predefinita a quella avanzata
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 e analisi del codice 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.
Analisi per ogni push
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. Gli errori delle richieste pull non interrompono un'analisi del codice, ma rappresentano un blocco durante il tentativo di unione del codice. È possibile trovare l'elenco degli errori delle richieste pull nella scheda degli avvisi di analisi del codice nella scheda Sicurezza del repository. Nelle impostazioni del repository è possibile modificare i livelli di gravità degli avvisi e i livelli di gravità della sicurezza che causano un errore di controllo della richiesta pull.
Su GitHub.com, naviga alla pagina principale del repository. Sotto il nome del repository selezionare Settings.
Nella barra laterale sinistra selezionare Code security and analysis.
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.
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)