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 per i produttori di prodotti digitali nell'UE: è diventato un requisito normativo. Il CRA impone infatti che la sicurezza sia "integrata by design e by default" nel processo di sviluppo.
Perché è importante: Secondo il NIST, il costo di correzione di un bug di sicurezza scoperto in produzione è fino a 100 volte maggiore rispetto a quello rilevato durante la fase di design. Un SDLC ben implementato riduce drasticamente i costi, i rischi e i tempi di risposta agli incidenti.
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 di sviluppo. I developer seguono linee guida specifiche 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, fuzz testing e verifica dei requisiti di sicurezza definiti nella Fase 1. L'obiettivo è trovare e correggere le vulnerabilità prima del rilascio.
Deploy & Rilascio
Hardening dell'ambiente di produzione, configurazioni sicure di default, gestione dei secret e delle credenziali, firma digitale degli artefatti e documentazione SBOM. Verifica finale che i controlli di sicurezza siano attivi e configurati correttamente.
Manutenzione & Response
Monitoraggio continuo delle vulnerabilità, gestione delle patch, Coordinated Vulnerability Disclosure (CVD), risposta agli incidenti e pianificazione dell'end-of-life. 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 che incontrerai.
Threat Modeling
Il Threat Modeling è un processo strutturato per identificare, analizzare e prioritizzare le minacce potenziali a un sistema prima che venga sviluppato o modificato. Si svolge tipicamente 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 più diffuse sono STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), PASTA (Process for Attack Simulation and Threat Analysis) e TARA (Threat Analysis and Risk Assessment), quest'ultima particolarmente usata in ambito automotive e IoT. Il CRA richiede esplicitamente che i produttori eseguano una cybersecurity risk assessment (equivalente al Threat Modeling) per ogni prodotto.
Risk Analysis (Analisi del Rischio)
La Risk Analysis è il processo di identificazione, stima e valutazione dei rischi di sicurezza associati a un prodotto o sistema. Si basa sulla formula classica: Rischio = Probabilità × Impatto. Nel contesto dello SDLC, la Risk Analysis alimenta le decisioni di prioritizzazione: non tutte le vulnerabilità hanno lo stesso peso, e le risorse vanno concentrate dove il rischio è più alto. Metodologie comuni includono CVSS (Common Vulnerability Scoring System), DREAD e framework normativi come l'ISO/IEC 27005. La Risk Analysis è strettamente legata al Threat Modeling: il Threat Modeling identifica le minacce, la Risk Analysis le quantifica.
Security Architecture Review
La Security Architecture Review (SAR) è un'analisi approfondita dell'architettura di un sistema per verificare che i controlli di sicurezza siano adeguati, correttamente posizionati e coerenti con i requisiti di sicurezza definiti. Include la revisione dei flussi di dati, dei trust boundary (confini di fiducia tra componenti), delle interfacce esterne, dei meccanismi di autenticazione e autorizzazione, della crittografia implementata e delle dipendenze software. L'obiettivo è identificare debolezze strutturali che i test funzionali non rileverebbero — come un'architettura che espone dati sensibili tra microservizi senza autenticazione mutua, o trust boundary non chiari tra componenti hardware e software.
Secure Coding Standards (Linee Guida di Secure Coding)
I Secure Coding Standards sono un insieme di regole e best practice che i developer devono seguire per scrivere codice sicuro ed evitare le vulnerabilità più comuni. Le referenze principali sono l'OWASP Secure Coding Practices, il CWE/SANS Top 25 Most Dangerous Software Errors e le linee guida specifiche per linguaggio (CERT C/C++, Google Java Security Guide, etc.). Coprono argomenti come la validazione degli input, la gestione sicura della memoria, la prevenzione dell'injection (SQL, command, LDAP), la gestione sicura delle credenziali e degli errori, la crittografia corretta e l'autenticazione robusta.
Security Code Review
La Security Code Review è l'analisi manuale o semi-automatizzata del codice sorgente con l'obiettivo specifico di identificare vulnerabilità di sicurezza. Si distingue dalla normale code review (che verifica qualità, logica e stile) per il focus sulle implicazioni di sicurezza: injection flaws, gestione errata di autenticazione/autorizzazione, esposizione di dati sensibili, vulnerabilità crittografiche, race condition e logiche di business insicure. Può essere eseguita da peer developer con training di sicurezza, da security engineer dedicati o supportata da tool SAST. È particolarmente efficace per identificare vulnerabilità logiche complesse che i tool automatici faticano a rilevare.
SAST — Static Application Security Testing
Il SAST (analisi statica della sicurezza) è una categoria di tool che analizzano il codice sorgente, il bytecode o i binari di un'applicazione senza eseguirla, alla ricerca di pattern di codice vulnerabili. I tool SAST si integrano direttamente nell'IDE o nella pipeline CI/CD e forniscono feedback in tempo reale agli sviluppatori ("shift left security"). Sono molto efficaci per rilevare vulnerabilità comuni come SQL injection, XSS, path traversal, uso di funzioni insicure e hardcoded secrets. Esempi di tool: Semgrep, Checkmarx, Veracode, SonarQube, CodeQL. Il limite principale del SAST è il tasso di falsi positivi, che richiede un processo di triage per essere gestito efficacemente.
DAST — Dynamic Application Security Testing
Il DAST (analisi dinamica della sicurezza) analizza un'applicazione mentre è in esecuzione, simulando gli attacchi di un attaccante esterno. A differenza del SAST, il DAST non ha accesso al codice sorgente (black-box testing): interagisce con l'applicazione tramite le sue interfacce esterne (API, web UI, network) e cerca vulnerabilità runtime come autenticazione debole, esposizione di endpoint non protetti, configurazioni errate e problemi di sessione. Esempi di tool: OWASP ZAP, Burp Suite, Nikto. Il DAST è complementare al SAST: il SAST trova bug nel codice, il DAST trova vulnerabilità nel comportamento runtime dell'applicazione.
SCA — Software Composition Analysis
La SCA (analisi della composizione software) è il processo di identificazione e gestione delle dipendenze open source e di terze parti all'interno di un prodotto software, con l'obiettivo di rilevare componenti con vulnerabilità note. Con il crescente uso di librerie open source (in certi prodotti oltre il 70% del codice è di terze parti), l'SCA è diventata essenziale. I tool SCA analizzano i file di dipendenza (package.json, pom.xml, requirements.txt, etc.), confrontano i componenti con database di vulnerabilità come il NVD (National Vulnerability Database) e il GitHub Advisory Database, e generano notifiche quando vengono scoperte nuove CVE. Esempi di tool: OWASP Dependency-Check, Snyk, Black Duck, Dependabot. L'SCA è anche il fondamento della generazione degli SBOM.
IAST — Interactive Application Security Testing
L'IAST combina elementi del SAST e del DAST: analizza l'applicazione dall'interno durante la sua esecuzione, tipicamente tramite un agent o una libreria strumentata che monitora il comportamento del codice in tempo reale durante i test funzionali. A differenza del DAST (che opera dall'esterno) e del SAST (che analizza il codice statico), l'IAST ha visibilità completa sul flusso di dati interno all'applicazione e può rilevare vulnerabilità con molta precisione e pochissimi falsi positivi. È particolarmente efficace per applicazioni web e API. Esempi di tool: Contrast Security, Seeker. L'adozione dell'IAST è meno diffusa rispetto a SAST e DAST, ma cresce nelle organizzazioni con pipeline CI/CD mature.
Penetration Testing (Pentest)
Il Penetration Testing è un attacco simulato e autorizzato a un sistema, condotto da esperti di sicurezza (i "penetration tester" o "ethical hacker"), con l'obiettivo di scoprire vulnerabilità reali sfruttabili. A differenza dei tool automatici, il pentest sfrutta l'intelligenza umana per identificare vulnerabilità logiche complesse, concatenare più debolezze in exploit complessi e valutare il reale impatto di un compromesso. Si distingue in modalità black-box (nessuna informazione fornita), grey-box (informazioni parziali) e white-box (pieno accesso a codice e architettura). Il CRA richiede valutazioni di sicurezza periodiche per i prodotti in categoria Class I e superiori. Il pentest è lo strumento più efficace per validare la postura di sicurezza prima del rilascio.
SecDevOps / DevSecOps
DevSecOps (o SecDevOps) è l'integrazione della sicurezza nelle pratiche DevOps, trasformando la sicurezza da un gate finale a una responsabilità condivisa tra development, security e operations durante tutto il ciclo di vita del software. Il principio fondamentale è lo "shift left": spostare i controlli di sicurezza il più a sinistra possibile nel ciclo di sviluppo, cioè il più presto possibile. In pratica, DevSecOps significa: tool di sicurezza integrati nell'IDE, SAST/SCA/secret scanning nella CI pipeline, DAST nella CD pipeline, Infrastructure as Code (IaC) scanning, vulnerability management automatizzato e policy as code. L'obiettivo è eliminare il collo di bottiglia tradizionale in cui il security team esaminava i prodotti "a fine ciclo" — e sostituirlo con una responsabilità di sicurezza distribuita e continua.
CI/CD Pipeline Security
La CI/CD (Continuous Integration / Continuous Delivery) Pipeline Security comprende l'insieme dei controlli e delle pratiche per proteggere la pipeline di build e deployment da attacchi e per integrare test di sicurezza automatizzati nel flusso di sviluppo. Include: gestione sicura dei secret (no credenziali hardcoded, uso di vault come HashiCorp Vault o AWS Secrets Manager), firma crittografica degli artefatti (per garantire integrità della supply chain), policy di accesso minimo ai sistemi CI/CD, SAST/SCA/secret scanning come step della pipeline, e security gates che bloccano automaticamente il deploy se vengono rilevate vulnerabilità critiche. Attacchi recenti come il SolarWinds compromise hanno dimostrato quanto la pipeline CI/CD possa essere un vettore di attacco critico.
SBOM — Software Bill of Materials
Lo SBOM (Software Bill of Materials) è un inventario formale e strutturato di tutti i componenti software che compongono un prodotto: librerie di terze parti, dipendenze open source, strumenti di build, firmware di componenti hardware e qualsiasi altro elemento che contribuisce al prodotto finale. È l'equivalente software della distinta base (BOM) manifatturiera. L'SBOM consente di rispondere rapidamente a domande come: "Siamo vulnerabili a Log4Shell? Quali dei nostri prodotti usano OpenSSL 3.x?" I formati standard sono SPDX (ISO/IEC 5962) e CycloneDX. Il Cyber Resilience Act rende obbligatorio il mantenimento di un SBOM per tutti i produttori soggetti al regolamento, rendendolo un elemento centrale del Secure SDLC moderno.
Vulnerability Management
Il Vulnerability Management è il processo continuo di identificazione, classificazione, prioritizzazione, remediation e monitoraggio delle vulnerabilità di sicurezza in un prodotto. Non è un'attività puntuale, ma un ciclo che si ripete per tutto il ciclo di vita del prodotto. Le fasi principali sono: Discovery (rilevamento tramite scanner, SCA, intelligence esterna), Assessment (valutazione dell'impatto e della sfruttabilità reale, non solo del punteggio CVSS), Prioritization (ranking risk-based), Remediation (patch, workaround, mitigazione), Verification (conferma della risoluzione) e Reporting (KPI, SLA, trend). Il CRA impone che i produttori abbiano processi formali di Vulnerability Management e gestiscano le vulnerabilità sfruttate attivamente con notifiche ad ENISA entro 24 ore.
CVD — Coordinated Vulnerability Disclosure
La Coordinated Vulnerability Disclosure (CVD) — chiamata anche Responsible Disclosure — è il processo attraverso cui ricercatori di sicurezza, utenti o chiunque scopra una vulnerabilità in un prodotto la comunicano al produttore in modo privato, fornendo un periodo ragionevole per sviluppare e rilasciare una patch prima di rendere pubblica la vulnerabilità. Una policy CVD ben strutturata include: un canale di reporting dedicato (es. security@azienda.it, pagina security.txt), SLA di risposta chiari (tipicamente 7 giorni per conferma, 90 giorni per remediation), eventuale programma di Bug Bounty con ricompense per i ricercatori, e un processo di disclosure coordinata con CVE assignment. Il CRA rende la CVD obbligatoria per tutti i produttori soggetti al regolamento.
Security Awareness & Training
La Security Awareness & Training è il programma di formazione continua per sviluppatori, team di prodotto e personale tecnico su tematiche di sicurezza. Non è solo compliance: 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, autenticazione), training pratico (hands-on lab, Capture The Flag interni, code review guidate), e aggiornamenti continui su nuove minacce e vulnerabilità. Iniziative come il OWASP WebGoat, HackTheBox e i corsi SANS sono risorse diffuse. Nei Secure SDLC maturi, il training è spesso un prerequisito per ottenere il badge di "Security Champion" all'interno dei team di sviluppo.
SDLC e Conformità al Cyber Resilience Act
Il CRA non definisce un framework SDLC specifico, ma richiede che i produttori implementino i seguenti obblighi che si mappano direttamente sulle pratiche di un Secure SDLC:
- Security by Design: Sicurezza integrata fin dalla progettazione (Threat Modeling, Security Architecture Review)
- Configurazioni sicure di default: No password predefinite, superficie di attacco minimizzata (Secure Coding, Hardening)
- Gestione delle vulnerabilità: Processi formali di Vulnerability Management, SBOM aggiornato
- CVD obbligatoria: Policy pubblica di Coordinated Vulnerability Disclosure e canale di reporting
- Aggiornamenti di sicurezza: Minimo 5 anni di supporto e patch per i prodotti immessi sul mercato
- Documentazione tecnica: SBOM, dichiarazione di conformità, documentazione Allegato II
Un Secure SDLC ben implementato non è quindi in conflitto con la conformità CRA: è esattamente il percorso che porta alla conformità in modo organico e sostenibile nel tempo.
Come Possiamo Aiutarti
Implementare un Secure SDLC da zero — o evolvere i processi esistenti verso la conformità CRA — richiede competenza tecnica, esperienza pratica e la capacità di adattare i framework alle specificità della tua organizzazione.
Il team di ProductSecurity.it supporta le organizzazioni in ogni fase: dalla valutazione iniziale della maturità (Maturity Check) alla progettazione dell'SDLC, dall'implementazione delle pratiche DevSecOps all'integrazione degli strumenti, fino alla formazione dei team di sviluppo. 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 trying to "add on" security as an afterthought at the end.
The difference from a traditional development process is substantial: in a conventional SDLC, security is often addressed only in the testing phase, when the cost of fixes is 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 entry into force of the Cyber Resilience Act (CRA), the Secure SDLC is no longer an optional best practice for digital product manufacturers in the EU: it has become a regulatory requirement. The CRA explicitly mandates that security be "integrated by design and by default" into the development process.
Why it matters: According to NIST, the cost of fixing a security bug discovered in production is up to 100 times higher than one found during the design phase. A well-implemented SDLC dramatically reduces costs, risks, and incident response times.
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 the 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. This is the most critical phase: decisions made here impact the entire lifecycle.
Implementation (Development)
Writing code according to secure coding standards, using verified libraries, performing security code reviews, and integrating static analysis (SAST) into the development workflow. Developers follow specific guidelines to avoid the most common vulnerabilities (OWASP Top 10, CWE Top 25).
Verification & Testing
In-depth security testing: dynamic analysis (DAST), Software Composition Analysis (SCA), penetration testing, fuzz testing, and verification of security requirements defined in Phase 1. The goal is to find and fix vulnerabilities before release.
Deployment & Release
Hardening the production environment, secure default configurations, secret and credential management, digital signing of artifacts, and SBOM documentation. Final verification that security controls are active and correctly configured.
Maintenance & Response
Continuous vulnerability monitoring, patch management, Coordinated Vulnerability Disclosure (CVD), incident response, and end-of-life planning. 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 terminology you will encounter.
Threat Modeling
Threat Modeling is a structured process for identifying, analyzing, and prioritizing potential threats to a system before it is developed or modified. It typically takes place during the design phase and answers four fundamental questions: What are we building? What can go wrong? What do we do about it? Did we do a good job? The most widely used methodologies are STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), PASTA (Process for Attack Simulation and Threat Analysis), and TARA (Threat Analysis and Risk Assessment), the latter particularly used in automotive and IoT contexts. The CRA explicitly requires manufacturers to perform a cybersecurity risk assessment (equivalent to Threat Modeling) for each product.
Risk Analysis
Risk Analysis is the process of identifying, estimating, and evaluating the security risks associated with a product or system. It is based on the classic formula: Risk = Probability × Impact. In the context of the SDLC, Risk Analysis drives prioritization decisions: not all vulnerabilities carry the same weight, and resources should be focused where risk is highest. Common methodologies include CVSS (Common Vulnerability Scoring System), DREAD, and regulatory frameworks such as ISO/IEC 27005. Risk Analysis is closely linked to Threat Modeling: Threat Modeling identifies threats; Risk Analysis quantifies them.
Security Architecture Review
A Security Architecture Review (SAR) is an in-depth analysis of a system's architecture to verify that security controls are adequate, correctly positioned, and consistent with defined security requirements. It includes reviewing data flows, trust boundaries between components, external interfaces, authentication and authorization mechanisms, implemented cryptography, and software dependencies. The goal is to identify structural weaknesses that functional testing would miss — such as an architecture that exposes sensitive data between microservices without mutual authentication, or unclear trust boundaries between hardware and software components.
Secure Coding Standards
Secure Coding Standards are a set of rules and best practices developers must follow to write secure code and avoid the most common vulnerabilities. Key references include OWASP Secure Coding Practices, CWE/SANS Top 25 Most Dangerous Software Errors, and language-specific guidelines (CERT C/C++, Google Java Security Guide, etc.). They cover topics such as input validation, secure memory management, injection prevention (SQL, command, LDAP), secure credential and error handling, correct cryptography, and robust authentication.
Security Code Review
Security Code Review is the manual or semi-automated analysis of source code with the specific objective of identifying security vulnerabilities. It differs from a regular code review (which checks quality, logic, and style) in its focus on security implications: injection flaws, improper authentication/authorization handling, sensitive data exposure, cryptographic vulnerabilities, race conditions, and insecure business logic. It can be performed by peer developers with security training, dedicated security engineers, or supported by SAST tools. It is particularly effective for identifying complex logical vulnerabilities that automated tools struggle to detect.
SAST — Static Application Security Testing
SAST is a category of tools that analyze an application's source code, bytecode, or binaries without executing it, searching for vulnerable code patterns. SAST tools integrate directly into the IDE or CI/CD pipeline and provide real-time feedback to developers ("shift left security"). They are very effective at detecting common vulnerabilities such as SQL injection, XSS, path traversal, use of unsafe functions, and hardcoded secrets. Examples: Semgrep, Checkmarx, Veracode, SonarQube, CodeQL. The main limitation of SAST is the false positive rate, which requires a triage process to manage effectively.
DAST — Dynamic Application Security Testing
DAST analyzes an application while it is running, simulating the attacks of an external attacker. Unlike SAST, DAST has no access to source code (black-box testing): it interacts with the application through its external interfaces (API, web UI, network) and looks for runtime vulnerabilities such as weak authentication, exposed unprotected endpoints, misconfigurations, and session issues. Examples: OWASP ZAP, Burp Suite, Nikto. DAST is complementary to SAST: SAST finds bugs in the code; DAST finds vulnerabilities in the application's runtime behavior.
SCA — Software Composition Analysis
SCA is the process of identifying and managing open-source and third-party dependencies within a software product, with the goal of detecting components with known vulnerabilities. With the growing use of open-source libraries (in some products over 70% of the code is third-party), SCA has become essential. SCA tools analyze dependency files (package.json, pom.xml, requirements.txt, etc.), compare components against vulnerability databases such as the NVD (National Vulnerability Database) and GitHub Advisory Database, and generate alerts when new CVEs are discovered. Examples: OWASP Dependency-Check, Snyk, Black Duck, Dependabot. SCA is also the foundation for SBOM generation.
IAST — Interactive Application Security Testing
IAST combines elements of SAST and DAST: it analyzes the application from the inside during execution, typically via an instrumented agent or library that monitors code behavior in real time during functional tests. Unlike DAST (which operates externally) and SAST (which analyzes static code), IAST has full visibility into the application's internal data flow and can detect vulnerabilities with high precision and very few false positives. It is particularly effective for web applications and APIs. Examples: Contrast Security, Seeker. IAST adoption is less widespread than SAST and DAST, but grows in organizations with mature CI/CD pipelines.
Penetration Testing (Pentest)
Penetration Testing is a simulated, authorized attack on a system carried out by security experts ("penetration testers" or "ethical hackers"), with the goal of discovering real exploitable vulnerabilities. Unlike automated tools, pentesting leverages human intelligence to identify complex logical vulnerabilities, chain multiple weaknesses into complex exploits, and assess the real impact of a compromise. It comes in three modes: black-box (no information provided), grey-box (partial information), and white-box (full access to code and architecture). The CRA requires periodic security assessments for products in Class I and above. Pentesting is the most effective tool for validating security posture before release.
SecDevOps / DevSecOps
DevSecOps (or SecDevOps) is the integration of security into DevOps practices, transforming security from a final gate into a shared responsibility among development, security, and operations throughout the software lifecycle. The fundamental principle is "shift left": moving security controls as far left as possible in the development cycle — i.e., as early as possible. In practice, DevSecOps means: security tools integrated into the IDE, SAST/SCA/secret scanning in the CI pipeline, DAST in the CD pipeline, Infrastructure as Code (IaC) scanning, automated vulnerability management, and policy as code. The goal is to eliminate the traditional bottleneck where the security team reviewed products "at the end of the cycle" and replace it with distributed, continuous security responsibility.
CI/CD Pipeline Security
CI/CD (Continuous Integration / Continuous Delivery) Pipeline Security encompasses the set of controls and practices for protecting the build and deployment pipeline from attacks and for integrating automated security tests into the development flow. It includes: secure secret management (no hardcoded credentials, use of vaults such as HashiCorp Vault or AWS Secrets Manager), cryptographic signing of artifacts (to guarantee supply chain integrity), least-privilege access to CI/CD systems, SAST/SCA/secret scanning as pipeline steps, and security gates that automatically block deployment if critical vulnerabilities are detected. Recent attacks such as the SolarWinds compromise demonstrated how the CI/CD pipeline can be a critical attack vector.
SBOM — Software Bill of Materials
An SBOM (Software Bill of Materials) is a formal, structured inventory of all the software components that make up a product: third-party libraries, open-source dependencies, build tools, hardware component firmware, and any other element that contributes to the final product. It is the software equivalent of a manufacturing bill of materials. An SBOM enables rapid answers to questions such as: "Are we vulnerable to Log4Shell? Which of our products use OpenSSL 3.x?" Standard formats are SPDX (ISO/IEC 5962) and CycloneDX. The Cyber Resilience Act makes SBOM maintenance mandatory for all manufacturers subject to the regulation, making it a central element of the modern Secure SDLC.
Vulnerability Management
Vulnerability Management is the ongoing process of identifying, classifying, prioritizing, remediating, and monitoring security vulnerabilities in a product. It is not a one-time activity but a cycle that repeats throughout the product lifecycle. The main phases are: Discovery (detection via scanners, SCA, external intelligence), Assessment (evaluating actual impact and exploitability, not just CVSS score), Prioritization (risk-based ranking), Remediation (patch, workaround, mitigation), Verification (confirming resolution), and Reporting (KPIs, SLAs, trends). The CRA requires manufacturers to have formal Vulnerability Management processes and handle actively exploited vulnerabilities with ENISA notifications within 24 hours.
CVD — Coordinated Vulnerability Disclosure
Coordinated Vulnerability Disclosure (CVD) — also called Responsible Disclosure — is the process by which security researchers, users, or anyone who discovers a vulnerability in a product communicates it to the manufacturer privately, providing a reasonable period to develop and release a patch before making the vulnerability public. A well-structured CVD policy includes: a dedicated reporting channel (e.g., security@company.com, security.txt page), clear response SLAs (typically 7 days for acknowledgment, 90 days for remediation), an optional Bug Bounty program with rewards for researchers, and a coordinated disclosure process with CVE assignment. The CRA makes CVD mandatory for all manufacturers subject to the regulation.
Security Awareness & Training
Security Awareness & Training is the ongoing education program for developers, product teams, and technical staff on security topics. It is not just about compliance: a developer with good security skills introduces fewer vulnerabilities and identifies them earlier. Effective programs combine theoretical training (secure coding, OWASP Top 10, cryptography, authentication), hands-on practice (labs, internal Capture The Flag events, guided code reviews), and continuous updates on new threats and vulnerabilities. Resources such as OWASP WebGoat, HackTheBox, and SANS courses are widely used. In mature Secure SDLCs, training is often a prerequisite for earning the "Security Champion" badge within development teams.
SDLC and Cyber Resilience Act Compliance
The CRA does not define a specific SDLC framework, but requires manufacturers to implement the following obligations that map directly to Secure SDLC practices:
- Security by Design: Security integrated from the design phase (Threat Modeling, Security Architecture Review)
- Secure default configurations: No default passwords, minimized attack surface (Secure Coding, Hardening)
- Vulnerability management: Formal Vulnerability Management processes, up-to-date SBOM
- Mandatory CVD: Public Coordinated Vulnerability Disclosure policy and reporting channel
- Security updates: Minimum 5 years of support and patches for products placed on the market
- Technical documentation: SBOM, declaration of conformity, Annex II documentation
A well-implemented Secure SDLC is therefore not in conflict with CRA compliance: it is exactly the path that leads to compliance in an organic and sustainable way over time.
How We Can Help
Implementing a Secure SDLC from scratch — or evolving existing processes toward CRA compliance — requires technical expertise, practical experience, and the ability to adapt frameworks to the specifics of your organization.
The ProductSecurity.it team supports organizations at every stage: from the initial maturity assessment (Maturity Check) to SDLC design, from implementing DevSecOps practices and toolchain integration to training development teams. Contact us for a personalized assessment.