Portfolio e progetti Come costruire un portfolio in cybersecurity Guida pratica per iniziare: passi concreti e risorse utili. Indice Perché un portfolio conta davvero Prima dei progetti: basi e direzione Cosa includere (e cosa evitare) Progetti che funzionano davvero per un junior Write-up: la parte che ti distingue Formato e struttura del portfolio Come presentarlo ai recruiter Roadmap pratica Esempi di portfolio (mini-case) e come presentarli bene < av> Perché creare un portfolio in cybersecurity Un portfolio in cybersecurity è un “sostituto” credibile dell’esperienza quando sei junior. Non perché dimostri che sei già pronto a tutto, ma perché rende visibile il tuo approccio: come raccogli informazioni, come fai ipotesi, come le verifichi e come comunichi il risultato. Nei colloqui reali capita spesso che un recruiter apra un link e guardi due cose: chiarezza e concretezza. Un portfolio ben fatto ti aiuta anche internamente: ti costringe a scegliere un focus e a mettere ordine nello studio. E soprattutto ti evita l’errore più comune: accumulare corsi e certificati senza avere nulla da mostrare. Da dove iniziare: costruire basi solide Prima ancora dei progetti, serve un minimo di fondamenta: rete, sistemi, log, un po’ di scripting. Se non hai chiaro cosa significa “basi” in un contesto entry level, qui trovi una mappa pratica: competenze fondamentali per iniziare in cybersecurity. Una domanda frequente è: “che tipo di portfolio devo fare: blue team o pentest?”. Nella pratica, scegli in base a dove ti vedi nei prossimi 6–12 mesi. Se punti al SOC, lavora su log e triage. Se punti al web, lavora su OWASP e remediation. Se scegli a caso, il portfolio diventa incoerente. Se stai impostando tutto il percorso (non solo il portfolio) e vuoi un ordine ragionato dei passaggi, ti può essere utile anche: come entrare in cybersecurity in Italia nel 2026. Cosa includere in un portfolio cybersecurity (e cosa evitare) Un portfolio non è una vetrina di tool. È un insieme di prove che dimostrano competenze reali. La regola è semplice: ogni elemento deve rispondere a “cosa hai fatto, perché l’hai fatto e cosa hai imparato”. Se non riesci a spiegarlo in modo chiaro, meglio non inserirlo. Evita invece la “collezione” di cose scollegate: 20 repo vuote, screenshot senza contesto, oppure report copiati. Meglio 3 progetti solidi con write-up decenti che 30 link che nessuno riesce a leggere. Selezione: 3–5 progetti totali, non 15 “tentativi”. Coerenza: stesso ruolo target, stessi segnali (log/IR per SOC; vulnerabilità/fix per AppSec). Verificabilità: comandi, configurazioni, screenshot essenziali, dati di input (sanificati) e output. Confini chiari: cosa hai fatto tu, cosa è di un tutorial, cosa è stato adattato. Tipologie di progetti da inserire (quelli che reggono ai colloqui) Per un junior, i progetti più efficaci sono quelli replicabili e leggibili: un esercizio, un lab, un’analisi con una conclusione sensata. Non devi inventare exploit: devi dimostrare metodo e capacità di lavorare con dati reali (log, traffico, configurazioni). Se vuoi una lista già pronta di progetti “da CV” con criteri di presentazione (senza gonfiare il profilo), qui trovi esempi concreti: 5 progetti da inserire nel CV in cybersecurity junior. Progetti “da blue team” che funzionano bene Esempi tipici: analisi di log con un mini-report, configurazione di alert semplici, investigazione su un evento simulato, oppure un honeypot con spiegazione di cosa ha catturato. Se sai raccontare una timeline e motivare un’escalation, ti stai già avvicinando al lavoro reale. Progetti “da web/app” credibili per iniziare Anche qui basta poco, ma fatto bene: analisi di una vulnerabilità OWASP con riproduzione controllata, evidenza e proposta di fix. Non serve “rompere” siti: serve capire il problema e spiegare come lo ridurresti. Questo approccio è apprezzato perché mostra maturità e attenzione alla remediation. Write-up: la parte che ti distingue davvero Se c’è una cosa che fa emergere un junior, è la documentazione. Un write-up non deve essere un romanzo, ma deve essere chiaro: contesto, obiettivo, passaggi, osservazioni e cosa faresti dopo. Nei SOC reali si scrivono ticket e note: un portfolio con write-up buoni è un segnale fortissimo. Nella pratica, i write-up migliori sono quelli onesti: includono anche errori e correzioni. “Ho provato X, non ha funzionato per Y, allora ho fatto Z”. È molto più realistico di un testo perfetto ma sterile. Contesto e confini: ambiente (VM, lab, dataset), cosa è simulato e cosa è reale. Osservazioni prima degli strumenti: cosa hai visto nei log/traffico e cosa ti ha fatto sospettare. Decisioni motivate: perché hai scelto quel controllo o quel test, non solo “ho lanciato il tool”. Risultato leggibile: una conclusione netta (anche “inconclusivo”) + next step sensato. Formato e struttura del portfolio Puoi pubblicare su GitHub, GitHub Pages o anche una pagina semplice. Il formato conta meno della struttura: una home con chi sei e cosa stai cercando, una sezione progetti, e per ogni progetto: descrizione breve + link + write-up. Se un recruiter deve cercare informazioni, hai già perso attenzione. Molti sottovalutano una cosa: il portfolio deve essere “scansionabile” in 60 secondi. Titoli chiari, poche parole, link diretti. Il dettaglio lo metti nei singoli progetti, non nella home. Home: 3 righe (ruolo target, stack/lab, cosa stai cercando) + 3 progetti in evidenza. Progetti: una riga “cosa dimostra” + link al repo + link al write-up. Repo pulite: README utile, struttura coerente, niente cartelle “final_final2”. Screenshot pochi e con didascalia: servono a capire, non a fare volume. Come presentare il portfolio ai recruiter Non basta dire “ho un portfolio”: devi guidare lo sguardo. Nel CV e su LinkedIn, punta a 2–3 progetti chiave, con una riga di contesto ciascuno. Nei colloqui, scegli un progetto e raccontalo come un caso: problema, ipotesi, verifica, risultato. Questo è esattamente il tipo di ragionamento che si valuta in cybersecurity. Se stai scegliendo un percorso formativo e vuoi capire quanto “spinge” davvero sulla produzione di deliverable (lab, report, progetti verificabili), tieni questa checklist come riferimento: corso cybersecurity in Italia: come scegliere (2026). Checklist: il portfolio è pronto per essere visto? Hai 3–5 progetti massimo, coerenti con il ruolo target Ogni progetto ha un obiettivo chiaro e un write-up leggibile Hai indicato strumenti usati e cosa hai osservato (non solo “ho fatto una scansione”) I link funzionano e portano direttamente a repository o report La home spiega in 3 righe chi sei e cosa stai cercando Hai rimosso progetti vuoti, copie, o materiale senza contesto Roadmap pratica per costruire il portfolio Se devi partire da oggi, il modo migliore è fare poco ma con continuità: un progetto a settimana o ogni due settimane, con write-up breve e miglioramenti incrementali. Il portfolio cresce per accumulo di qualità, non per quantità. Step Cosa fare Output 1 Definire il ruolo target (SOC, web, cloud, ecc.) Focus chiaro del portfolio 2 Creare 2 progetti base + write-up essenziale Prime prove credibili 3 Aggiungere 1 progetto “caso studio” più completo Progetto da raccontare ai colloqui 4 Ottimizzare CV/LinkedIn e fare candidature mirate Portfolio usato davvero Esempi di portfolio (mini-case) e come presentarli bene Gli esempi che “funzionano” non sono quelli con più tool o più pagine: sono quelli dove, in pochi minuti, si capisce cosa hai fatto e cosa sai dimostrare. Qui sotto trovi mini-case tipici (blue team e web/app) con la struttura di presentazione che regge bene anche quando ti fanno domande. Mini-case 1 (SOC/Blue team): evento sospetto e triage basato su log Obiettivo: dimostrare che sai partire da segnali (log/alert), fare triage e arrivare a una conclusione operativa. In home (1 riga): “Triage di un alert: autenticazioni anomale + correlazione log e timeline dell’evento”. Nel write-up: sorgenti log (es. Windows Event, Sysmon o dataset), ipotesi iniziali, query/filtri usati, timeline, impatto stimato. Output che convince: una pagina “Executive summary” + “Technical notes” (anche breve) con indicatori e raccomandazioni. Errore comune da evitare: incollare schermate di dashboard senza spiegare cosa stai osservando e perché. Mini-case 2 (Blue team): hardening con verifica prima/dopo Obiettivo: dimostrare ragionamento difensivo e capacità di verificare una modifica, non solo applicarla. In home (1 riga): “Hardening di una VM: baseline, modifiche motivate, verifica e trade-off”. Nel write-up: baseline iniziale, controlli scelti, cosa rompe (se rompe), come misuri il miglioramento (porte, servizi, policy). Output che convince: tabella “prima/dopo” con 5–8 evidenze e una conclusione sui rischi residui. Errore comune da evitare: liste infinite di “best practice” non applicate o non verificabili. Mini-case 3 (Web/AppSec): vulnerabilità OWASP con riproduzione e remediation Obiettivo: dimostrare che non ti fermi al finding, ma sai ragionare su impatto e fix. In home (1 riga): “Analisi di una vulnerabilità OWASP: riproduzione controllata, evidenza e proposta di remediation”. Nel write-up: contesto (app lab), prerequisiti, passaggi minimi per riprodurre, evidenza, rischio, fix proposto e test di regressione. Output che convince: una sezione “Cosa cambierei nel codice/config” + “Come verificherei che è risolto”. Errore comune da evitare: descrivere solo il tool (scanner) senza dimostrare comprensione e controllo dei falsi positivi. Mini-case 4 (General): repository pulita + README che guida il recruiter Obiettivo: far sì che il progetto sia leggibile senza call di 30 minuti. README (suggerimento pratico): 6 blocchi: contesto, obiettivo, ambiente, cosa hai fatto, risultati, link al write-up. Segnale di maturità: una sezione breve “Limitazioni” (cosa non copre quel progetto) e “Next step”. Errore comune da evitare: README generici (“Questo progetto mostra la mia passione…”) senza dettagli verificabili. Se vuoi un punto di partenza più guidato per trasformare studio e lab in progetti presentabili, puoi partire da academycybersecurity.it e capire quali percorsi sono più adatti al tuo livello. Non serve costruire un portfolio “perfetto”: serve costruirne uno credibile, che racconti come lavori e come ragioni.
