ISMS Copilot Docs

Come costruire una pipeline DevSecOps utilizzando l'AI

DevSecOps integra la sicurezza in ogni fase del ciclo di vita della consegna del software, invece di trattarla come un controllo finale prima del rilascio. Per…

Panoramica

DevSecOps integra la sicurezza in ogni fase del ciclo di vita della consegna del software, invece di trattarla come un controllo finale prima del rilascio. Per le organizzazioni soggette a ISO 27001, SOC 2, NIST CSF o altri framework di conformità, una pipeline DevSecOps ben progettata trasforma la conformità da un esercizio di audit periodico in un processo continuo di generazione di evidenze. La sicurezza "shift-left" rileva le vulnerabilità prima che raggiungano la produzione. I gate di conformità automatizzati forniscono evidenze pronte per l'audit ad ogni deployment. Il monitoraggio continuo mantiene la postura di sicurezza tra le valutazioni.

Questa guida mostra come utilizzare ISMS Copilot per progettare, costruire e rafforzare una pipeline DevSecOps che soddisfi i requisiti di conformità mantenendo produttivi i team di ingegneria.

A chi è rivolto

  • Ingegneri DevOps e platform che integrano controlli di sicurezza nelle pipeline CI/CD
  • Ingegneri della sicurezza responsabili della sicurezza delle applicazioni e dell'automazione della conformità
  • CISO e architetti della sicurezza che definiscono standard di sviluppo sicuro
  • Professionisti GRC che devono verificare che le pipeline tecniche soddisfino i requisiti dei controlli

Progettazione della pipeline DevSecOps

Una pipeline DevSecOps mappa le attività di sicurezza e conformità a ogni fase del ciclo di vita della consegna del software. Invece di aggiungere la sicurezza alla fine, si distribuiscono i controlli su sei fasi: pianificazione, codifica, build, test, deployment e monitoraggio.

Mappatura dei requisiti di conformità alle fasi della pipeline

Utilizza ISMS Copilot per generare una mappatura fase per fase che colleghi i tuoi obblighi di conformità ad attività concrete della pipeline:

Pipeline Stage

Security Activities

ISO 27001 Controls

SOC 2 Criteria

Plan

Threat modeling, requisiti di sicurezza, valutazione dei rischi

A.8.25 (Secure development lifecycle)

CC3.2, CC8.1

Code

Standard di codifica sicura, pre-commit hooks, revisione tra pari

A.8.26 (Application security requirements)

CC8.1

Build

SAST, SCA, controlli delle dipendenze, generazione SBOM

A.8.28 (Secure coding)

CC7.1, CC8.1

Test

DAST, scansione dei container, test di sicurezza di integrazione

A.8.27 (Secure system architecture)

CC7.1, CC7.2

Deploy

Gate di conformità, firma degli artifact, workflow di approvazione

A.8.25, A.8.32 (Change management)

CC8.1

Monitor

Protezione runtime, aggregazione dei log, rilevamento delle derive

A.8.15 (Logging), A.8.16 (Monitoring)

CC7.2, CC7.3

Chiedi a ISMS Copilot di personalizzare questa mappatura in base al tuo specifico stack tecnologico e ai requisiti di conformità:

Map our compliance requirements to a DevSecOps pipeline for [application type] using [CI/CD platform]. We need to satisfy [ISO 27001 / SOC 2 / NIST CSF]. For each pipeline stage (plan, code, build, test, deploy, monitor), identify:
- Specific security activities to implement
- Applicable compliance controls and how they're satisfied
- Recommended tools and integrations
- Evidence artifacts generated for audit

Our stack: [languages, frameworks, cloud provider, container orchestration].

Una pipeline ben mappata svolge un doppio compito: previene che difetti di sicurezza raggiungano la produzione e genera contemporaneamente le evidenze necessarie ai tuoi auditor. Ogni risultato di scansione, record di approvazione e alert di monitoraggio diventa un artefatto di audit.

Considerazioni sull'architettura

Quando progetti l'architettura della tua pipeline, considera queste decisioni rilevanti per la conformità:

  • Pipeline-as-code: Memorizza tutte le definizioni della pipeline nel controllo di versione (soddisfa A.8.32 gestione delle modifiche e fornisce una traccia di audit)
  • Ambienti di build immutabili: Utilizza runner e container effimeri per prevenire manomissioni (affronta l'integrità della supply chain)
  • Separazione dei compiti: Assicurati che gli sviluppatori non possano approvare i propri deployment in produzione (soddisfa SOC 2 CC6.1 e A.5.3 segregazione dei compiti)
  • Conservazione delle evidenze: Archivia i risultati delle scansioni, i log di approvazione e i record di deployment per il periodo di conservazione richiesto

Integrazione della scansione di sicurezza

Gli strumenti di scansione di sicurezza costituiscono la spina dorsale della tua pipeline DevSecOps. La sfida consiste nel selezionare e configurare la giusta combinazione di strumenti senza sopraffare gli sviluppatori con falsi positivi o rallentare la consegna.

Selezione degli strumenti di scansione giusti

Utilizza ISMS Copilot per valutare quali categorie di scansione si allineano alle tue esigenze di conformità e all'ambiente tecnico:

Recommend security scanning tools for our DevSecOps pipeline. Our environment:
- Languages: [e.g., Python, TypeScript, Go]
- Cloud: [e.g., AWS with EKS]
- CI/CD: [e.g., GitHub Actions]
- Compliance: [e.g., ISO 27001, SOC 2]

For each scanning category (SAST, DAST, SCA, container scanning, IaC scanning, secrets detection), recommend:
- Best-fit open source and commercial options
- Which compliance controls each addresses
- Integration approach with our CI/CD platform
- Expected false positive rates and tuning strategies

Categorie di scansione e mappatura della conformità

  • SAST (Static Application Security Testing): Analizza il codice sorgente per individuare vulnerabilità prima dell'esecuzione. Affronta ISO 27001 A.8.28 (codifica sicura) e la prevenzione OWASP Top 10. Strumenti: Semgrep, SonarQube, CodeQL, Checkmarx.
  • DAST (Dynamic Application Security Testing): Testa le applicazioni in esecuzione per individuare vulnerabilità sfruttabili. Soddisfa A.8.27 (architettura di sistema sicura e principi di ingegneria) convalidando il comportamento runtime. Strumenti: OWASP ZAP, Burp Suite, Nuclei.
  • SCA (Software Composition Analysis): Identifica vulnerabilità e rischi di licenza nelle dipendenze di terze parti. Critico per A.5.21 (gestione della sicurezza della catena di fornitura ICT) e per la generazione di Software Bills of Materials (SBOM). Strumenti: Snyk, Dependabot, Grype, OWASP Dependency-Check.
  • Container scanning: Rileva vulnerabilità nelle immagini dei container e convalida la configurazione. Supporta A.8.9 (gestione della configurazione) e la sicurezza runtime. Strumenti: Trivy, Grype, Anchore, Clair.
  • IaC scanning: Verifica i template di infrastruttura-as-code per individuare configurazioni errate prima del provisioning. Previene configurazioni errate nel cloud che violano A.8.9 e i benchmark CIS. Strumenti: Checkov, tfsec, KICS.
  • Secrets detection: Impedisce che credenziali, chiavi API e token entrino nel controllo di versione. Affronta direttamente A.5.33 (protezione dei record) e A.8.28. Strumenti: GitLeaks, TruffleHog, detect-secrets.

Configurazione delle soglie di scansione

Le scansioni sono efficaci solo se i loro risultati guidano le decisioni. Definisci soglie di gravità che si allineano con la tua propensione al rischio:

Create security scanning threshold policies for our CI/CD pipeline that align with [ISO 27001 / SOC 2] risk appetite. Define:
- Hard-fail thresholds by severity (critical, high, medium, low) for each scan type
- Grace periods for newly discovered vulnerabilities in existing dependencies
- Exception/waiver process with approval requirements and expiry dates
- Escalation paths when thresholds are breached
- Metrics to track threshold effectiveness over time

Output as both human-readable policy and CI/CD configuration snippets for [platform].

Inizia con soglie rigorose (zero critical, zero high) e adatta in base ai risultati reali. È meglio iniziare in modo rigoroso e allentare con giustificazione documentata piuttosto che iniziare in modo permissivo e cercare di stringere in seguito. Ogni eccezione dovrebbe essere tracciata con una data di scadenza e un responsabile del rischio.

Standard di codifica sicura

I framework di conformità richiedono pratiche di codifica sicura documentate, ma le linee guida generiche raramente si adattano allo stack tecnologico specifico e al profilo di rischio della tua organizzazione. Utilizza ISMS Copilot per generare standard di codifica che siano sia allineati alla conformità che praticamente utili per i tuoi sviluppatori.

Generazione di linee guida specifiche per l'organizzazione

I controlli ISO 27001 da A.8.25 a A.8.28 richiedono collettivamente un ciclo di vita di sviluppo sicuro con pratiche di codifica definite. Chiedi a ISMS Copilot di creare standard su misura per il tuo ambiente:

Generate secure coding standards for our engineering team. Context:
- Primary languages: [e.g., Python, TypeScript]
- Frameworks: [e.g., Django, React, FastAPI]
- Architecture: [e.g., microservices on Kubernetes]
- Compliance requirements: ISO 27001 A.8.25-A.8.28, OWASP Top 10

For each language/framework, provide:
- Input validation and output encoding rules
- Authentication and session management requirements
- Cryptographic standards (algorithms, key lengths, key management)
- Error handling and logging (what to log, what never to log)
- Dependency management policies (approved sources, update cadence, vulnerability SLAs)
- Code review security checklist

Format as a developer-facing reference document with code examples.

Mappatura dei controlli specifici per framework

Mappa i tuoi standard di codifica a specifici controlli di conformità in modo che gli auditor possano tracciare dai requisiti del framework alle pratiche implementate:

Coding Standard Area

ISO 27001 Control

OWASP Reference

Input validation

A.8.26 (Application security requirements)

A03:2021 Injection

Authentication implementation

A.8.5 (Secure authentication)

A07:2021 Identification and Authentication Failures

Cryptographic usage

A.8.24 (Use of cryptography)

A02:2021 Cryptographic Failures

Error handling and logging

A.8.15 (Logging), A.8.28 (Secure coding)

A09:2021 Security Logging and Monitoring Failures

Dependency management

A.5.21 (ICT supply chain security)

A06:2021 Vulnerable and Outdated Components

Access control logic

A.8.3 (Information access restriction)

A01:2021 Broken Access Control

Applicazione degli standard tramite automazione

Gli standard documentati funzionano solo se vengono applicati. Integra l'applicazione nella tua pipeline:

  • Pre-commit hooks: Esegui linter, formattatori e rilevamento dei segreti prima che il codice entri nel repository
  • Controlli delle pull request: Scansioni SAST automatizzate e checklist di revisione del codice focalizzate sulla sicurezza che bloccano il merge fino alla risoluzione
  • Regole SAST personalizzate: Codifica i tuoi standard specifici per l'organizzazione come regole Semgrep o CodeQL personalizzate
  • Integrazione della formazione degli sviluppatori: Collega i risultati delle scansioni alle linee guida interne di codifica in modo che gli sviluppatori imparino dagli errori

Gate di conformità automatizzati

I gate di conformità sono punti di controllo della pipeline che verificano che requisiti specifici siano soddisfatti prima che il codice passi alla fase successiva. A differenza dei workflow di approvazione manuali, i gate automatizzati forniscono un'applicazione coerente e generano evidenze senza colli di bottiglia umani.

Progettazione dei criteri dei gate

Utilizza ISMS Copilot per progettare gate di conformità che mappino direttamente ai tuoi requisiti di controllo:

Design automated compliance gates for our CI/CD pipeline deploying to production. Requirements:
- Framework: [ISO 27001 / SOC 2 / both]
- Pipeline: [GitHub Actions / GitLab CI / Jenkins / Azure DevOps]
- Environments: dev → staging → production

For each gate, define:
- Gate name and pipeline stage where it runs
- Pass/fail criteria with specific thresholds
- Compliance controls it satisfies (with control numbers)
- Evidence artifacts it generates
- Bypass/exception process with required approvals
- Notification and escalation on failure

Include gates for: security scanning results, code review completion, change approval, environment promotion criteria, and deployment verification.

Pattern di architettura dei gate

Struttura i tuoi gate su tre livelli:

Tier 1 -- Gate al momento della build (veloci, ad ogni commit):

  • Rilevamento dei segreti: fail immediato su qualsiasi segreto rilevato
  • SAST: fail su risultati di gravità critica e alta
  • SCA: fail su CVE critici o violazioni di licenza
  • Copertura dei test unitari: soglia minima (es. 80%)

Tier 2 -- Gate pre-deployment (approfonditi, prima di staging/produzione):

  • Completamento della scansione DAST senza risultati critici
  • Scansione dell'immagine del container che supera la soglia
  • Scansione di sicurezza IaC senza configurazioni errate di gravità alta
  • Approvazione da parte dei revisori di codice richiesti (separazione dei compiti)
  • Richiesta di modifica collegata e approvata nel sistema di gestione delle modifiche

Tier 3 -- Gate post-deployment (validazione, dopo il deployment):

  • Test di smoke e controlli di salute superati
  • Verifica delle intestazioni di sicurezza e della configurazione TLS
  • Conferma che il monitoraggio e gli alert sono attivi
  • Test di rollback o piano di rollback documentato

Ogni gate di conformità deve avere un processo di eccezione documentato. Quando un gate deve essere bypassato (ad esempio, per una hotfix di emergenza), richiedere una giustificazione scritta da parte di un responsabile della sicurezza o del CISO, impostare una data di scadenza per l'eccezione e creare un ticket di follow-up. Gli auditor verificheranno specificamente se i bypass sono tracciati e risolti. Questo soddisfa i requisiti di ISO 27001 A.8.32 (gestione delle modifiche) per le modifiche di emergenza.

Rafforzamento della sicurezza della CI/CD

La pipeline stessa è un obiettivo di alto valore. Un sistema CI/CD compromesso può iniettare codice malevolo in ogni deployment. Rafforzare l'infrastruttura della pipeline è importante quanto i controlli di sicurezza che vi vengono eseguiti.

Gestione dei segreti

Le credenziali, le chiavi API e i certificati utilizzati dalla tua pipeline devono essere gestiti con lo stesso rigore dei segreti di produzione:

  • Utilizza un gestore di segreti dedicato: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o GCP Secret Manager -- mai memorizzare segreti nei file di configurazione della pipeline o nelle variabili di ambiente che appaiono nei log
  • Iniezione a runtime: I segreti dovrebbero essere iniettati nell'ambiente di build al momento dell'esecuzione e mai scritti su disco o negli artifact di build
  • Rotazione regolare: Automatizza la rotazione delle credenziali con programmi definiti (massimo 90 giorni per gli account di servizio, secondo A.5.17)
  • Mascheramento nei log: Configura la tua piattaforma CI/CD per oscurare i valori dei segreti da tutti i log e output di build
  • Audit degli accessi: Registra ogni accesso ai segreti con chi, cosa, quando e da quale esecuzione della pipeline

Controlli di accesso alla pipeline

Applica il principio del privilegio minimo e la separazione dei compiti all'infrastruttura della tua pipeline:

  • RBAC per la configurazione della pipeline: Solo il personale autorizzato può modificare le definizioni della pipeline, i target di deployment e le soglie dei gate di sicurezza
  • Regole di protezione dei branch: Richiedi revisioni delle pull request, controlli di stato e commit firmati sui branch protetti
  • Regole di protezione degli ambienti: I deployment in produzione richiedono l'approvazione da parte di revisori designati che non siano gli autori del codice
  • Privilegio minimo per gli account di servizio: Gli account di servizio della pipeline dovrebbero avere solo i permessi necessari per la loro fase specifica
  • Registrazione degli audit: Registra tutte le modifiche alla configurazione della pipeline, le approvazioni manuali e gli override dei gate

Firma degli artifact e sicurezza della supply chain

Proteggi l'integrità dei tuoi artifact di build dalla sorgente al deployment:

  • Commit firmati: Richiedi la firma dei commit con GPG o SSH per verificare l'identità dell'autore (A.8.25, A.5.14)
  • Provenienza della build: Genera attestazioni di provenienza SLSA per documentare come ogni artifact è stato costruito
  • Firma delle immagini dei container: Firma le immagini con Cosign o Docker Content Trust prima di inviarle al registro
  • Generazione di SBOM: Produci Software Bills of Materials per ogni rilascio per soddisfare i requisiti di trasparenza della supply chain (A.5.21)
  • Deployment verificati: I controller di ammissione (OPA Gatekeeper, Kyverno) dovrebbero rifiutare artifact non firmati o non verificati
Design a supply chain security strategy for our CI/CD pipeline. We use [CI/CD platform] deploying [container images / serverless functions / VM images] to [cloud provider]. Include:
- Commit signing enforcement and verification
- Build provenance generation (SLSA framework level)
- Artifact signing workflow (tools, key management, verification points)
- SBOM generation and storage strategy
- Admission control policies for deployment targets
- Supply chain attack scenarios and mitigations
- Mapping to ISO 27001 A.5.21 (ICT supply chain), A.8.25 (secure development lifecycle), and NIST SSDF practices

Output as implementation guide with configuration examples.

Esempi di prompt

Utilizza questi prompt in ISMS Copilot per accelerare l'implementazione della tua pipeline DevSecOps. Sostituisci i segnaposto con i tuoi dettagli specifici.

Progettazione dell'architettura della pipeline

Design a DevSecOps pipeline architecture for a [microservices / monolithic] application built with [languages/frameworks], deployed to [AWS EKS / Azure AKS / GCP GKE] using [GitHub Actions / GitLab CI]. We need to satisfy ISO 27001:2022 Annex A controls A.8.25-A.8.28 and SOC 2 CC7-CC8.

Include: pipeline stages with security gates, tool recommendations for each scanning category (SAST, DAST, SCA, container, IaC, secrets), evidence collection points for audit, and estimated implementation timeline. Output as an architecture document with a pipeline diagram description.

Politica dei gate di conformità

Create a comprehensive compliance gate policy for our CI/CD pipeline. We deploy [application type] to production [frequency]. Define gate criteria for each pipeline stage with specific pass/fail thresholds, map each gate to ISO 27001 and SOC 2 controls, document the exception/bypass process for emergency deployments (who can approve, what must be documented, maximum exception duration), and specify evidence artifacts generated at each gate. Format as both a policy document and pipeline configuration for [CI/CD platform].

Integrazione della scansione di sicurezza

Create a security scanning integration plan for our [CI/CD platform] pipeline. Our codebase uses [languages] with [number] microservices deployed as containers to [Kubernetes / ECS / other].

For each scanning type (SAST, DAST, SCA, container scanning, IaC scanning, secrets detection): recommend specific tools, provide pipeline configuration snippets, define severity thresholds and failure criteria, estimate scan duration impact, and explain tuning strategies to reduce false positives below 10%. Map each scanning type to specific ISO 27001 Annex A controls.

Architettura di gestione dei segreti

Design a secrets management architecture for our DevSecOps pipeline on [cloud provider] using [CI/CD platform]. Current state: [describe current secrets handling]. Requirements: zero secrets in source code or pipeline logs, automated rotation for all service credentials, audit trail for every secret access, emergency revocation procedure, and compliance with ISO 27001 A.5.17 (authentication information) and A.8.24 (use of cryptography).

Include migration plan from current state, implementation steps, and monitoring/alerting for secret misuse.

Automazione delle evidenze di audit

Design an automated audit evidence collection system integrated into our DevSecOps pipeline. We need continuous evidence for [ISO 27001 / SOC 2 / both] covering secure development lifecycle controls.

For each pipeline stage, define: what evidence is generated (scan reports, approval records, deployment logs), storage location and retention period, integrity protection (immutability, checksums), how evidence maps to specific control requirements, and automated completeness checks that alert when evidence gaps are detected. Output as an evidence matrix with automation scripts for [CI/CD platform].

Checklist per il rafforzamento della pipeline

Generate a CI/CD pipeline security hardening checklist for [GitHub Actions / GitLab CI / Jenkins / Azure DevOps]. Cover: runner/agent security (ephemeral vs persistent, isolation), pipeline configuration access controls and RBAC, secrets injection and masking, build environment integrity, artifact signing and verification, audit logging configuration, network segmentation for build environments, and third-party action/plugin security review process.

For each item, indicate: priority (critical/high/medium), applicable ISO 27001 control, implementation effort, and verification method. Format as an actionable checklist our DevOps team can work through.

Risorse correlate

On this page