Quando mi trovo davanti a un cluster Kubernetes o a un workload che non conosco, una delle prime domande è: dove potrebbero esserci problemi di sicurezza?

Per rispondere ho preparato una skill basata su OWASP Kubernetes Top 10. Nel video mostro come l’ho costruita, come si installa e come la uso con GitHub Copilot per ottenere una prima revisione strutturata del cluster.

Una precisazione è importante: questa skill aiuta a orientare l’analisi, ma non sostituisce un audit professionale né strumenti specializzati per l’analisi statica e dinamica, la scansione delle immagini o i penetration test.

Da OWASP a una skill per coding agent

Tra i progetti OWASP ci sono le famose liste Top 10: raccolte di rischi comuni relative a una tecnologia o a un contesto specifico. La lista dedicata a Kubernetes raccoglie dieci aree di rischio e, per ciascuna, spiega cosa controllare e perché.

La documentazione è disponibile anche nel repository GitHub del progetto OWASP Kubernetes Top 10. Quando ho aperto la cartella del 2025 ho trovato un’introduzione, alcuni file di orientamento e un documento Markdown per ciascun rischio.

Quella struttura si prestava bene a diventare una skill. Lo standard Agent Skills prevede un file SKILL.md come punto d’ingresso e consente di affiancargli documenti di riferimento. In pratica, il coding agent può leggere prima le istruzioni essenziali e consultare gli approfondimenti solo quando servono.

È lo stesso principio della progressive disclosure: nel file principale metto il contesto e il processo, mentre nei riferimenti lascio le informazioni più dettagliate. Ne ho parlato anche nell’articolo sulle coding agent skills.

Come ho organizzato la skill

Nel mio repository ho creato una cartella dedicata a OWASP Kubernetes. La struttura comprende:

  • SKILL.md, con lo scopo della skill, i suoi limiti e il workflow da seguire;
  • una cartella references, con la documentazione relativa ai dieci rischi;
  • un template per rendere omogeneo il report finale.

Non mi sono inventato una nuova metodologia di sicurezza. Ho preso una ricerca già disponibile, l’ho organizzata in una forma che un coding agent sa consultare e ho aggiunto istruzioni operative per guidare la revisione.

Il workflow chiede all’agente di procedere per passi: capire cosa sta analizzando, confrontare configurazioni e workload con i riferimenti OWASP, raccogliere evidenze e produrre un report. Il formato del report è importante: senza una struttura precisa si rischia di ottenere una lista generica di raccomandazioni difficili da verificare.

Installazione e primo utilizzo

La skill è disponibile nel repository MFSoftwareEngineering/mfse-softwarefactory. Puoi consultarla come reference oppure installarla direttamente con:

npx skills add https://github.com/MFSoftwareEngineering/mfse-softwarefactory/tree/main/skills/owasp-kubernetes

Durante l’installazione basta selezionare OWASP Kubernetes e scegliere se installarla nel progetto corrente o nel profilo globale. Per questa prova l’ho installata a livello di progetto, così resta disponibile solo nella codebase su cui sto lavorando.

Dopo aver ricaricato le skill in Copilot, la richiamo con /OWASP Kubernetes e indico la cartella che contiene i manifest e i riferimenti Kubernetes. Nel mio caso la cartella si chiama k8s.

A questo punto l’agente può avviare la revisione seguendo il workflow definito nella skill. Non gli sto chiedendo semplicemente di “controllare la sicurezza”: gli sto dando una traccia, una fonte di riferimento e un formato con cui presentare i risultati.

Che cosa contiene il report

Nel caso mostrato nel video, la revisione non ha trovato problemi di gravità critical, ma ha evidenziato alcuni problemi high e altri rilievi con priorità inferiore.

Per ogni risultato il report indica:

  • il riferimento alla categoria OWASP;
  • la parte di configurazione o di workload coinvolta;
  • la motivazione per cui quella configurazione è rischiosa;
  • una remediation concreta;
  • la priorità con cui conviene intervenire.

Questa è la parte che trovo più utile. Dire che una configurazione è rischiosa serve a poco se non si spiega anche come correggerla e quale impatto può avere. Inoltre, un elenco ordinato per priorità è più facile da trasformare in attività: posso portare i singoli rilievi in una wiki, in un work item di Azure DevOps o nel sistema di ticketing che usa il team.

Un primo controllo, non l’ultima parola

Una skill come questa è utile per creare un punto di partenza ripetibile, soprattutto quando devi orientarti rapidamente in una codebase o in un insieme di manifest che non conosci. Può aiutarti a non dimenticare controlli importanti e a spiegare meglio i risultati al resto del team.

Non è però una certificazione di sicurezza. Un assessment completo deve considerare anche il contesto operativo, la configurazione effettiva del cluster, le immagini utilizzate, i secret, le policy di rete, l’identità e il comportamento a runtime. A seconda del caso servono scanner e verifiche specifiche, oltre alla revisione di una persona competente.

Se lavori con Azure Kubernetes Service, puoi affiancare questa analisi alle tecniche per mettere in sicurezza un cluster AKS. Per un quadro più ampio dell’integrazione della sicurezza nel lavoro quotidiano, c’è anche il mio articolo sulla sicurezza in ottica DevOps.

Conclusione

Il valore di questa skill non sta nell’aver riscritto la OWASP Top 10. Sta nell’aver trasformato una buona base di conoscenza in un processo che un coding agent può seguire e ripetere.

Puoi prendere la skill, adattarla alle policy della tua organizzazione, aggiungere i controlli che ti servono e usarla con il coding agent che preferisci. L’importante è mantenere chiari il perimetro dell’analisi e i limiti del risultato.

Se vuoi rendere più affidabile la sicurezza dei tuoi ambienti Kubernetes, trovi maggiori informazioni sui miei servizi Kubernetes.