• Cloud, Guide, Open Source, Sicurezza
• 2 Novembre 2026

All’interno della community abbiamo parlato ampiamente di Microsoft Sentinel, SIEM e SOAR di casa Redmond e di come esso possa aiutare le aziende a collezionare Log e rispondere in moto automatizzato ad Incidenti di sicurezza Informatica, a tal proposito vi lascio il link della community che vi permette di visualizzare tutti gli articoli inerenti a questa soluzione di Microsoft Microsoft Sentinel – ICT Power

Quest’oggi vorrei parlarvi di un’integrazione, che a mio avviso può aiutare le aziende a migliorare l’efficienza di questo strumento, a automatizzare attività oltre a migliorare la Governance dei processi dei reparti di CyberSecurity, ovvero l’integrazione tra Microsoft Sentinel e GitHub.

Microsoft stessa, al giorno d’oggi, raccomanda di utilizzare Repositories come prima scelta, in quanto offrono versioning, approvazioni, workflow e rollback per gestire le detection e per chi è Multitenant sono il modo più scalabile per gestirli, proprio per questo qual’ora vogliate approfondire il pensiero di Microsoft vi rimango al link ufficiale della documentazione Detection lifecycle management recommendations for Microsoft Sentinel | Microsoft Learn

Figura 1: Flusso di Lavoro tra Microsoft Sentinel e GitHub

Prima di darvi evidenza di come poter integrare i due ecosistemi, è necessario darvi evidenza di alcune terminologie e concetti chiave.

Concetti Chiave

Quanto costa questa soluzione?

La funzione Repositories di per se è gratuita, sono a pagamento i dati di cui viene eseguita Ingestion in Microsoft Sentinel, e se superate la soglia gratuita dovrete pagare anche i “minuti” della GitHub Actions.

Per un eventuale ambiente di demo, il consiglio che posso fornirvi è quello di configurare un Repo privato, un Workspace di Microsoft Sentinel con “pochi” logs (EntraID sign-in e Azure Activity), e un daily cap sul workspace per evitare sorprese, quest’ultimo si configura dal portale di Azure à Settings à Usage and estimated costs à Daily cap

Primo passaggio? Preparare il Repository di GitHub

Recatevi su GitHub eseguite la login con il vostro account, se non lo avete procedete alla creazione di un Account gratuito

Figura 2: Scegliamo di creare un nuovo Repo

Figura 3: Scegliamo un nome ed una descrizione per il Repo, e aggiungiamo un Readme impostandolo come privato

Figura 4: Repo creato correttamente

Una volta creato, sarà necessario impostare la struttura del repository che dovrà essere in questo modo:

sentinel-content/
├── AnalyticsRules/
├── AutomationRules/
├── CustomDetections/
├── HuntingQueries/
├── Parsers/
├── Playbooks/
├── Workbooks/
└── README.md

I nomi delle cartelle sono a vostra scelta, il deploy guarda il contenuto dei file e non il contenuto della cartella, la struttura impostata in questo modo vi permetterà di “orientarvi meglio”.

Nel mio caso ho chiesto a Claude Code di “costruire” per me il repository e questo è il risultato

Figura 5: Struttura Repo che Claude Code ha creato secondo le indicazioni che sono state fornite

Figura 6: Configurazione del Repository per permettere i Workflow

Figura 7: Serve allo smart deployment, che scrive un file di tracciamento nel repo

Ora è necessario avere almeno un file valido nel repo prima di collegarlo, e per farlo abbiamo due metodi:

• Esportare una Analytics Rule già presente
• Scrivere una Analytics Rule da zero

Nel mio caso procederò con la prima soluzione di cui vi darò evidenza passo passo.

Figura 8: Selezioniamo una o pio Analytics ed esportiamole

Figura 9: Download Json delle regole effettuato con successo

Figura 10: Ho fornito al file un nome parlante, consiglio un file per regola così il PR tocca una sola regola

Ora rechiamoci su GitHub e posizioniamo il file all’interno della cartella “AnalyticsRule”

Figura 11: Selezioniamo il file ed inseriamo un commento per il Commit

Nello stesso modo eseguiamo un Export di una regola di Automation, cambierà la cartella di destinazione di GitHub che diventerà “AutomationRules”

Figura 12: Download della regola di automazione

Figura 13: Commit anche della regola di automazione

Ora siete pronti per collegare il Repo a Microsoft Sentinel.

Ma ricapitoliamo cosa abbiamo fatto fino ad ora:

• Creato repo GitHub e relativa struttura
• Caricato nel repo Analytics Rule
• Caricato nel repo Automation Rule

Ora rechiamoci all’interno del portale di Microsoft Defender, nella sezione relativa a Microsoft Sentinel

Figura 14: Configuriamo il Repository di GitHub in Microsoft Sentinel

Figura 15: Autorizziamo il repository, dopo aver inserito nome descrizione

Figura 16: Il sistema ci chiede di autorizzare Azure Sentinel sul repo GitHub

Figura 17: Selezioniamo il repository che abbiamo creato in precedenza

Figura 18: Selezionate solo i Content Types che avete popolato, nel mio caso Analytycis/Automation Rules, potete aggiungere altro in un secondo momento

Cosa succede nel momento in cui clicchiamo Create?

Cosa succede dietro le quinte, in pochi secondi:

• In Entra ID nasce un’app registration chiamata Azure Sentinel Content Deployment App seguita da un ID tra parentesi, con permessi sul workspace
• Nel repo compare il file .github/workflows/sentinel-deploy-<id>.yml.
• Nei Settings > Secrets and variables > Actions del repo compaiono i secret che il workflow usa per autenticarsi. Non toccarli.
• Parte subito il primo deploy.

Limiti da sapere: massimo 5 connessioni per workspace, e non puoi creare due connessioni con lo stesso repo e lo stesso branch sullo stesso workspace.

Figura 19: Connessione Riuscita

Figura 20: Comparsa Workflows in GitHub

Figura 21: Secret Presenti all’interno del repo

Figura 22: Dalle Actions di GitHub il primo flusso ha funzionato correttamente

Come la soluzione ci aiuta nel lavoro di tutti i giorni?

Qui c’è il valore aggiunto di questa configurazione, ovvero tutte le regole collegate al repository si modificano solo nel repo, questo permette a chi lavora quotidianamente nel tuning della piattaforma di avere un unico punto di accesso, soprattutto quanto il repo risulta collegato a più istanze di Microsoft Sentinel.

Vediamo insieme cosa accade:

Figura 23: Regola attualmente configurata con ingestion_time() > ago(5m)

Ora modificheremo, direttamente da GitHub, la regola impostando il parametro a 2m

Figura 24: Modifica parametro e commit della change

Figura 25: Scegliamo di fare commit in un altro Branch, questo ci permetterà di vedere la modifica effettuata e dopo fare il merge in Main (sentinel prende le modifiche da li)

Figura 26: Modifiche evidenziate per verificare prima di effettuare il merge

Figura 27: Dopo la verifica effettuare il pull

Scelgo come metodo di merge “Squash and Marge” in quanto tutti i commit della PR diventano un solo commit su main, con il titolo della PR. Ogni modifica a una regola è una riga nella descrizione, e se serve un rollback lo fai su un unico commit. Per le detection è la scelta più pulita

Figura 28: Merge della modifica in Main

Figura 29: Automazione che stà “scrivendo” la modifica in Sentinel

Figura 30: Modifica riuscita

Figura 31: Modifica eseguita anche lato Microsoft Sentinel

E se avessimo commesso un errore e volessimo ripristinare la regola a prima della modifica?

Possiamo farlo direttamente dalla Pull Request

Figura 32: Pull Request Closed apriamola

Figura 33: Facciamo il Revert

Figura 34: Eseguiamo il commit del revert

Ora attendiamo l’automazione e verifichiamo in Microsoft Sentinel il revert della modifica

Figura 35: Revert Effettuato con successo

Se cancellata la regola direttamente da GitHub, questa non si cancella in automatico da Sentinel, ma dovrete procedere alla cancellazione manuale. Inoltre se qualcuno modifica una regola dal portale la modifica resta finché quel file non viene ridistribuito. Con lo smart deployment questo succede solo quando il file cambia nel repo: a quel punto la versione del repo sovrascrive quella del portale. Se la modifica fatta nel portale era giusta.

Per eventuali approfondimenti vi rimando alla documentazione Microsoft Manage custom content with repository connections – Microsoft Sentinel | Microsoft Learn

Invece per approfondimenti su quanto visto all’interno dell’articolo Deploy Custom Content from your Repository – Microsoft Sentinel | Microsoft Learn

Conclusioni

Collegare GitHub a Microsoft Sentinel trasforma le detection in codice, e il vantaggio più concreto è la tracciabilità. Ogni modifica ad una regola passa da un commit e da una pull request: si sa sempre chi l’ha fatta, quando, cosa è cambiato riga per riga e perché. Se una regola smette di funzionare, la storia del repository dice esattamente da quale modifica è partito il problema, e il rollback è un click. È un salto rispetto alla gestione dal portale, dove una soglia cambiata o una query modificata lasciano poche tracce leggibili. Con “Repositories” il repository diventa l’unica fonte di verità: le regole si modificano solo lì, e quello che arriva in Sentinel è sempre ciò che è stato approvato. A questo si aggiunge un’autenticazione pulita, tramite OIDC e managed identity, senza secret da custodire, e un costo praticamente nullo. Il consiglio è partire in piccolo: poche analytics rules, una pull request per ogni modifica, e solo dopo estendere l’approccio al resto dei contenuti.