Cos'è il Secure Development Lifecycle?
Il Secure Development Lifecycle (SDLC) — detto anche S-SDLC o Secure SDLC — è un insieme strutturato di processi, pratiche e controlli che integrano la sicurezza in ogni fase dello sviluppo di un prodotto software o hardware. L'obiettivo è semplice ma ambizioso: costruire prodotti sicuri fin dall'inizio, invece di cercare di "applicare" la sicurezza come un cerotto alla fine.
La differenza rispetto a un tradizionale processo di sviluppo è sostanziale: in uno SDLC convenzionale la sicurezza viene spesso affrontata solo nella fase di test, quando i costi di correzione sono già molto elevati. Nel Secure SDLC, invece, la sicurezza è un requisito trasversale che accompagna il prodotto dall'ideazione all'end-of-life.
Con l'entrata in vigore del Cyber Resilience Act (CRA), il Secure SDLC non è più una best practice opzionale: è diventato un requisito normativo per tutti i produttori di prodotti digitali nel mercato UE. Il CRA impone che la sicurezza sia "integrata by design e by default" nel processo di sviluppo — ed è esattamente ciò che un Secure SDLC garantisce.
Perché è importante per il CRA: Il Cyber Resilience Act richiede esplicitamente che i prodotti digitali siano sicuri fin dalla progettazione (Annex I, Parte I). Un SDLC ben strutturato è la risposta operativa a questo obbligo normativo. Senza di esso, la conformità CRA diventa impossibile da sostenere nel tempo.
Le Fasi del Secure SDLC
Un Secure SDLC si struttura tipicamente in sei fasi, ognuna delle quali include attività di sicurezza specifiche.
Requisiti (Requirements)
Definizione dei requisiti di sicurezza funzionali e non funzionali. Coinvolge la classificazione dei dati trattati, l'identificazione dei requisiti normativi applicabili (CRA, GDPR, ISO 27001) e la definizione degli obiettivi di sicurezza del prodotto.
Design & Architettura
Progettazione dell'architettura sicura del sistema, esecuzione del Threat Modeling, analisi delle superfici di attacco e definizione dei principi di security by design. È la fase più critica: le decisioni prese qui hanno impatto su tutto il ciclo di vita.
Implementazione (Development)
Scrittura del codice secondo secure coding standards, utilizzo di librerie verificate, code review di sicurezza e analisi statica (SAST) integrata nel workflow. I developer seguono linee guida per evitare le vulnerabilità più comuni (OWASP Top 10, CWE Top 25).
Verifica & Testing
Test di sicurezza approfonditi: analisi dinamica (DAST), Software Composition Analysis (SCA), penetration testing e fuzz testing. L'obiettivo è trovare e correggere le vulnerabilità prima del rilascio.
Deploy & Rilascio
Hardening dell'ambiente di produzione, configurazioni sicure di default (requisito CRA), gestione sicura dei secret, firma degli artefatti e generazione dell'SBOM obbligatorio per la conformità CRA.
Manutenzione & Response
Monitoraggio continuo, gestione delle patch, Coordinated Vulnerability Disclosure (CVD) — obbligatoria per CRA — e risposta agli incidenti. Il CRA impone aggiornamenti di sicurezza per almeno 5 anni dalla messa in commercio.
Le Terminologie Fondamentali dello SDLC
Il Secure SDLC è ricco di acronimi e termini tecnici. Ecco una guida completa alle terminologie più rilevanti, anche nell'ottica della conformità CRA.
Threat Modeling
Il Threat Modeling è un processo strutturato per identificare, analizzare e prioritizzare le minacce potenziali a un sistema. Si svolge durante la fase di design e risponde a quattro domande fondamentali: Su cosa stiamo lavorando? Cosa può andare storto? Cosa facciamo al riguardo? Abbiamo fatto un buon lavoro? Le metodologie principali sono STRIDE, PASTA e TARA. Il CRA richiede esplicitamente una cybersecurity risk assessment per ogni prodotto — il Threat Modeling è il modo più efficace per soddisfare questo obbligo.
Risk Analysis (Analisi del Rischio)
La Risk Analysis è il processo di identificazione, stima e valutazione dei rischi di sicurezza di un prodotto. La formula di base è Rischio = Probabilità × Impatto. Guida le decisioni di prioritizzazione nell'SDLC. Metodologie comuni: CVSS, DREAD, ISO/IEC 27005. È strettamente legata al Threat Modeling: il Threat Modeling identifica le minacce, la Risk Analysis le quantifica e le prioritizza.
Security Architecture Review
La Security Architecture Review (SAR) è un'analisi dell'architettura di un sistema per verificare che i controlli di sicurezza siano adeguati e correttamente posizionati. Include la revisione dei flussi di dati, dei trust boundary, delle interfacce esterne, dei meccanismi di autenticazione, della crittografia e delle dipendenze software. È fondamentale per identificare debolezze strutturali — come trust boundary non chiari tra componenti hardware e software — che i test funzionali non rileverebbero.
Secure Coding Standards
I Secure Coding Standards sono regole e best practice per scrivere codice sicuro. Referenze principali: OWASP Secure Coding Practices, CWE/SANS Top 25, linee guida specifiche per linguaggio (CERT C/C++, etc.). Coprono: validazione degli input, gestione sicura della memoria, prevenzione dell'injection, crittografia corretta, autenticazione robusta e gestione sicura delle credenziali. Il CRA richiede che i prodotti non abbiano vulnerabilità sfruttabili note — i Secure Coding Standards sono il primo livello di difesa.
Security Code Review
La Security Code Review è l'analisi del codice sorgente focalizzata sull'identificazione di vulnerabilità di sicurezza. A differenza della normale code review, si concentra su: injection flaws, gestione errata di autenticazione/autorizzazione, esposizione di dati sensibili, vulnerabilità crittografiche, race condition e logiche di business insicure. Può essere manuale (da security engineer) o semi-automatizzata con tool SAST. Particolarmente efficace per vulnerabilità logiche complesse.
SAST — Static Application Security Testing
Il SAST analizza il codice sorgente, bytecode o binari senza eseguire l'applicazione, cercando pattern di codice vulnerabili. Si integra nell'IDE o nella CI/CD pipeline ("shift left security"). Rileva vulnerabilità comuni: SQL injection, XSS, path traversal, hardcoded secrets. Esempi: Semgrep, Checkmarx, Veracode, SonarQube, CodeQL. Il principale limite è il tasso di falsi positivi, che richiede un processo di triage.
DAST — Dynamic Application Security Testing
Il DAST analizza un'applicazione mentre è in esecuzione, simulando gli attacchi di un attaccante esterno (black-box testing). Cerca vulnerabilità runtime: autenticazione debole, endpoint non protetti, configurazioni errate, problemi di sessione. Esempi: OWASP ZAP, Burp Suite, Nikto. È complementare al SAST: il SAST trova bug nel codice, il DAST trova vulnerabilità nel comportamento runtime.
SCA — Software Composition Analysis
La SCA identifica e gestisce le dipendenze open source e di terze parti di un prodotto, rilevando componenti con vulnerabilità note (CVE). Con il crescente uso di librerie open source, l'SCA è essenziale — in molti prodotti oltre il 70% del codice è di terze parti. Tool: Snyk, Black Duck, Dependabot, OWASP Dependency-Check. La SCA è anche il fondamento per la generazione degli SBOM, obbligatori per il CRA.
IAST — Interactive Application Security Testing
L'IAST combina elementi di SAST e DAST: analizza l'applicazione dall'interno durante l'esecuzione, tramite un agent strumentato che monitora il comportamento del codice in tempo reale durante i test funzionali. Ha visibilità completa sul flusso di dati interno e rileva vulnerabilità con alta precisione e pochi falsi positivi. Particolarmente efficace per applicazioni web e API. Esempi: Contrast Security, Seeker.
Penetration Testing (Pentest)
Il Penetration Testing è un attacco simulato e autorizzato condotto da esperti di sicurezza per scoprire vulnerabilità reali sfruttabili. A differenza dei tool automatici, il pentest identifica vulnerabilità logiche complesse e valuta il reale impatto di un compromesso. Modalità: black-box, grey-box, white-box. Il CRA richiede valutazioni di sicurezza periodiche per i prodotti in Classe I e superiori. Il pentest è lo strumento più efficace per validare la postura di sicurezza prima del rilascio.
SecDevOps / DevSecOps
DevSecOps è l'integrazione della sicurezza nelle pratiche DevOps, trasformandola da un gate finale a una responsabilità condivisa tra development, security e operations. Il principio fondamentale è lo "shift left": portare i controlli di sicurezza il più presto possibile nel ciclo di sviluppo. In pratica: tool di sicurezza nell'IDE, SAST/SCA nella CI pipeline, DAST nella CD pipeline, IaC scanning, vulnerability management automatizzato e policy as code. DevSecOps è il modo operativo per implementare un Secure SDLC su larga scala.
CI/CD Pipeline Security
La CI/CD Pipeline Security protegge la pipeline di build e deployment da attacchi e integra test di sicurezza automatizzati nel flusso di sviluppo. Include: gestione sicura dei secret (no credenziali hardcoded), firma crittografica degli artefatti (supply chain integrity), policy di accesso minimo ai sistemi CI/CD, e security gates che bloccano il deploy in presenza di vulnerabilità critiche. Attacchi come il SolarWinds compromise hanno dimostrato quanto la pipeline CI/CD sia un vettore critico.
SBOM — Software Bill of Materials
Lo SBOM è un inventario formale di tutti i componenti software di un prodotto: librerie di terze parti, dipendenze open source, strumenti di build e firmware. Permette di rispondere rapidamente a: "Siamo vulnerabili a questa CVE? Quali prodotti usano questa libreria?" I formati standard sono SPDX e CycloneDX. Il Cyber Resilience Act rende obbligatorio il mantenimento di un SBOM aggiornato per tutti i produttori soggetti al regolamento — rendendolo uno degli elementi centrali della conformità CRA.
Vulnerability Management
Il Vulnerability Management è il processo continuo di identificazione, classificazione, prioritizzazione, remediation e monitoraggio delle vulnerabilità di un prodotto. Le fasi principali: Discovery → Assessment → Prioritization → Remediation → Verification → Reporting. Il CRA impone processi formali di Vulnerability Management: i produttori devono gestire le vulnerabilità sfruttate attivamente con notifiche ad ENISA entro 24 ore dalla scoperta.
CVD — Coordinated Vulnerability Disclosure
La Coordinated Vulnerability Disclosure è il processo attraverso cui chi scopre una vulnerabilità la comunica al produttore in modo privato, fornendo tempo per sviluppare una patch prima della divulgazione pubblica. Include: canale di reporting dedicato, SLA di risposta chiari (tipicamente 7 giorni per conferma, 90 giorni per remediation), eventuale Bug Bounty program e CVE assignment. Il CRA rende la CVD obbligatoria per tutti i produttori, con l'obbligo di notificare ad ENISA le vulnerabilità attivamente sfruttate entro 24 ore.
Security Awareness & Training
La Security Awareness & Training è il programma di formazione continua per sviluppatori e team tecnici su tematiche di sicurezza. Un developer con buone competenze di sicurezza introduce meno vulnerabilità e le identifica prima. I programmi efficaci combinano formazione teorica (secure coding, OWASP Top 10, crittografia), training pratico (lab, CTF interni, code review guidate) e aggiornamenti continui. Nei Secure SDLC maturi, la formazione è spesso un prerequisito per ottenere il ruolo di Security Champion all'interno dei team.
SDLC e Conformità al Cyber Resilience Act
Il CRA non definisce un framework SDLC specifico, ma i suoi requisiti si mappano direttamente sulle pratiche di un Secure SDLC:
- Security by Design (Annex I, Part I, §1): Threat Modeling e Security Architecture Review nelle fasi di design
- Configurazioni sicure di default (§2): No password predefinite, superficie di attacco minimizzata — garantito da Secure Coding e hardening
- Nessuna vulnerabilità sfruttabile nota (§1e): SAST, DAST, SCA, Penetration Testing sistematici
- SBOM obbligatorio (Annex I, Part II, §1): SCA automatizzata e generazione SBOM nella pipeline CI/CD
- CVD obbligatoria (Art. 13, §6): Policy CVD pubblica con canale di reporting e SLA definiti
- Notifica vulnerabilità (Art. 14): Processo formale di Vulnerability Management con escalation path verso ENISA
- Aggiornamenti di sicurezza per 5 anni: Vulnerability Management e patch management sostenibili nel tempo
Un Secure SDLC ben implementato non è in conflitto con la conformità CRA: è esattamente il percorso operativo che porta alla conformità in modo organico e sostenibile.
Come Possiamo Aiutarti
Implementare un Secure SDLC conforme al CRA — o migliorare i processi esistenti — richiede competenza tecnica e normativa combinata. Sapere cosa fare non basta: bisogna sapere come farlo nella specifica realtà di prodotto e organizzazione.
Il team di CRA.tips supporta i produttori in ogni fase: dalla Gap Analysis CRA iniziale alla progettazione dello SDLC, dall'implementazione DevSecOps all'integrazione degli SBOM, fino alla documentazione tecnica e alla preparazione per la marcatura CE. Contattaci per una valutazione personalizzata.
What Is the Secure Development Lifecycle?
The Secure Development Lifecycle (SDLC) — also called S-SDLC or Secure SDLC — is a structured set of processes, practices, and controls that embed security into every phase of software or hardware product development. The goal is simple but ambitious: build secure products from the start, rather than applying security as an afterthought.
The difference from a traditional development process is substantial: in a conventional SDLC, security is often addressed only in the testing phase, when fix costs are already very high. In the Secure SDLC, security is a cross-cutting requirement that accompanies the product from inception to end-of-life.
With the Cyber Resilience Act (CRA) in force, the Secure SDLC is no longer an optional best practice: it is a regulatory requirement for all digital product manufacturers in the EU. The CRA mandates that security be "integrated by design and by default" into the development process — which is exactly what a Secure SDLC delivers.
Why it matters for CRA: The Cyber Resilience Act explicitly requires that digital products be secure from the design phase (Annex I, Part I). A well-structured SDLC is the operational response to this regulatory obligation. Without it, CRA compliance becomes impossible to sustain over time.
The Phases of the Secure SDLC
A Secure SDLC typically consists of six phases, each with specific security activities.
Requirements
Definition of functional and non-functional security requirements. Involves classifying data handled, identifying applicable regulatory requirements (CRA, GDPR, ISO 27001), and defining the product's security objectives.
Design & Architecture
Designing the secure system architecture, performing Threat Modeling, analyzing attack surfaces, and defining security-by-design principles. The most critical phase: decisions made here impact the entire lifecycle.
Implementation (Development)
Writing code per secure coding standards, using verified libraries, performing security code reviews, and integrating SAST into the development workflow. Developers follow guidelines to avoid OWASP Top 10 and CWE Top 25 vulnerabilities.
Verification & Testing
In-depth security testing: DAST, SCA, penetration testing, and fuzz testing. The goal is to find and fix vulnerabilities before release — a direct CRA requirement under Annex I.
Deployment & Release
Hardening the production environment, secure default configurations (CRA requirement), secret management, artifact signing, and SBOM generation — mandatory under the CRA.
Maintenance & Response
Continuous monitoring, patch management, Coordinated Vulnerability Disclosure (CVD — mandatory under CRA), and incident response. The CRA mandates security updates for at least 5 years from market placement.
Key SDLC Terminology
The Secure SDLC is full of acronyms and technical terms. Here is a complete guide to the most relevant terminology, including its connection to CRA requirements.
Threat Modeling
Threat Modeling is a structured process for identifying, analyzing, and prioritizing potential threats to a system before it is built. It answers four questions: What are we building? What can go wrong? What do we do about it? Did we do a good job? Key methodologies: STRIDE, PASTA, TARA. The CRA explicitly requires a cybersecurity risk assessment for each product — Threat Modeling is the most effective way to fulfil this obligation.
Risk Analysis
Risk Analysis identifies, estimates, and evaluates the security risks of a product. Core formula: Risk = Probability × Impact. It drives prioritization in the SDLC. Key methodologies: CVSS, DREAD, ISO/IEC 27005. Closely linked to Threat Modeling: Threat Modeling identifies threats; Risk Analysis quantifies and prioritizes them.
Security Architecture Review
A Security Architecture Review (SAR) analyzes a system's architecture to verify that security controls are adequate and correctly positioned. It reviews data flows, trust boundaries, external interfaces, authentication mechanisms, cryptography, and software dependencies. Essential for identifying structural weaknesses — such as unclear trust boundaries between hardware and software components — that functional testing would miss.
Secure Coding Standards
Rules and best practices for writing secure code. Key references: OWASP Secure Coding Practices, CWE/SANS Top 25, language-specific guidelines (CERT C/C++, etc.). Cover: input validation, secure memory management, injection prevention, proper cryptography, robust authentication. The CRA requires products to have no known exploitable vulnerabilities — Secure Coding Standards are the first line of defense.
Security Code Review
Security Code Review is source code analysis focused specifically on identifying security vulnerabilities. Unlike a standard code review, it targets: injection flaws, authentication/authorization mishandling, sensitive data exposure, cryptographic vulnerabilities, race conditions, and insecure business logic. Can be manual (security engineer) or semi-automated with SAST tools. Particularly effective for complex logical vulnerabilities.
SAST — Static Application Security Testing
SAST analyzes source code, bytecode, or binaries without executing the application, searching for vulnerable code patterns. Integrates into the IDE or CI/CD pipeline ("shift left security"). Detects: SQL injection, XSS, path traversal, hardcoded secrets. Examples: Semgrep, Checkmarx, Veracode, SonarQube, CodeQL. Main limitation: false positive rate requires a triage process.
DAST — Dynamic Application Security Testing
DAST analyzes an application while running, simulating attacks from an external attacker (black-box). Finds runtime vulnerabilities: weak authentication, unprotected endpoints, misconfigurations, session issues. Examples: OWASP ZAP, Burp Suite, Nikto. Complementary to SAST: SAST finds code bugs; DAST finds runtime behavior vulnerabilities.
SCA — Software Composition Analysis
SCA identifies and manages open-source and third-party dependencies, detecting components with known vulnerabilities (CVEs). With open-source libraries making up 70%+ of many products' codebase, SCA is essential. Tools: Snyk, Black Duck, Dependabot, OWASP Dependency-Check. SCA is also the foundation for SBOM generation — mandatory under the CRA.
IAST — Interactive Application Security Testing
IAST combines SAST and DAST: it analyzes the application from the inside during execution via an instrumented agent that monitors code behavior in real time during functional tests. Has full internal data-flow visibility, detecting vulnerabilities with high precision and very few false positives. Particularly effective for web applications and APIs. Examples: Contrast Security, Seeker.
Penetration Testing (Pentest)
Penetration Testing is a simulated, authorized attack by security experts to discover real, exploitable vulnerabilities. Unlike automated tools, pentesting applies human intelligence to identify complex logical vulnerabilities and chain weaknesses into realistic exploits. Modes: black-box, grey-box, white-box. The CRA requires periodic security assessments for Class I and above products. Pentesting is the most effective tool for validating security posture before release.
SecDevOps / DevSecOps
DevSecOps integrates security into DevOps, transforming it from a final gate into a shared responsibility across development, security, and operations. The core principle is "shift left": move security controls as early as possible in the development cycle. In practice: security tools in the IDE, SAST/SCA in the CI pipeline, DAST in the CD pipeline, IaC scanning, automated vulnerability management, and policy as code. DevSecOps is the operational model for scaling a Secure SDLC.
CI/CD Pipeline Security
CI/CD Pipeline Security protects the build and deployment pipeline from attacks and integrates automated security tests into the development flow. Includes: secure secret management (no hardcoded credentials), cryptographic artifact signing (supply chain integrity), least-privilege access to CI/CD systems, and security gates that block deployment on critical vulnerabilities. The SolarWinds compromise demonstrated how the CI/CD pipeline can be a critical attack vector.
SBOM — Software Bill of Materials
An SBOM is a formal inventory of all software components in a product: third-party libraries, open-source dependencies, build tools, and firmware. Enables rapid answers to: "Are we vulnerable to this CVE? Which products use this library?" Standard formats: SPDX and CycloneDX. The Cyber Resilience Act makes SBOM maintenance mandatory for all manufacturers subject to the regulation — making it a central element of CRA compliance and the Secure SDLC.
Vulnerability Management
Vulnerability Management is the ongoing cycle of identifying, classifying, prioritizing, remediating, and monitoring security vulnerabilities. Phases: Discovery → Assessment → Prioritization → Remediation → Verification → Reporting. The CRA requires formal Vulnerability Management processes and mandates that manufacturers notify ENISA of actively exploited vulnerabilities within 24 hours of discovery.
CVD — Coordinated Vulnerability Disclosure
Coordinated Vulnerability Disclosure is the process by which a discoverer of a vulnerability privately notifies the manufacturer, giving time to patch before public disclosure. A well-structured CVD policy includes: dedicated reporting channel, clear response SLAs (typically 7 days acknowledgment, 90 days remediation), optional Bug Bounty program, and CVE assignment. The CRA makes CVD mandatory for all manufacturers — with a 24-hour ENISA notification requirement for actively exploited vulnerabilities.
Security Awareness & Training
Security Awareness & Training is the ongoing education program for developers and technical staff. A developer with good security skills introduces fewer vulnerabilities and catches them earlier. Effective programs combine theoretical training (secure coding, OWASP Top 10, cryptography), hands-on practice (labs, CTF events, guided code reviews), and continuous updates on new threats. In mature Secure SDLCs, training is often a prerequisite for the Security Champion role within development teams.
SDLC and Cyber Resilience Act Compliance
The CRA does not prescribe a specific SDLC framework, but its requirements map directly to Secure SDLC practices:
- Security by Design (Annex I, Part I, §1): Threat Modeling and Security Architecture Review in the design phase
- Secure default configurations (§2): No default passwords, minimized attack surface — enforced through Secure Coding and hardening
- No known exploitable vulnerabilities (§1e): Systematic SAST, DAST, SCA, and Penetration Testing
- Mandatory SBOM (Annex I, Part II, §1): Automated SCA and SBOM generation in the CI/CD pipeline
- Mandatory CVD (Art. 13, §6): Public CVD policy with dedicated reporting channel and defined SLAs
- Vulnerability notification (Art. 14): Formal Vulnerability Management with ENISA escalation path
- Security updates for 5 years: Sustainable Vulnerability Management and patch management processes
A well-implemented Secure SDLC is not in conflict with CRA compliance: it is exactly the operational path that leads to compliance in an organic and sustainable way.
How We Can Help
Implementing a CRA-compliant Secure SDLC — or improving existing processes — requires combined technical and regulatory expertise. Knowing what to do is not enough: you need to know how to do it in your specific product and organizational context.
The CRA.tips team supports manufacturers at every stage: from the initial CRA Gap Analysis to SDLC design, from DevSecOps implementation to SBOM integration and technical documentation, through to CE marking preparation. Contact us for a personalized assessment.