TL;DR: A secure development lifecycle (SDLC) integrates security into every stage of software development, from design to maintenance. The Cyber Resilience Act mandates this from December 2027 for all digital products in the EU market. Fixing a bug in production costs up to 100 times more than during design. Belgian software companies that start now will save time, money and avoid fines of up to €15 million.
Your development team is delivering features at record speed. But what about the security of that code? At many Belgian software companies, security is tested late in the process, often just before release. The result: vulnerabilities that are expensive to fix, pen test results that lead to rewrites, and customers who increasingly demand proof that your software was developed securely.
A secure development lifecycle turns that around. Instead of testing security after the fact, you build it in from the first design decision. In this article, you’ll read about what SDLC specifically means, which framework fits a team of 5 to 15 developers, and why the Cyber Resilience Act will soon make it mandatory.
What exactly is a secure development lifecycle?
A secure development lifecycle is a structured process that adds security activities to each phase of software development. From capturing security requirements at inception, through threat modeling during design and automated code analysis during development, to penetration testing before release and vulnerability monitoring after deployment.
The concept is not new. Microsoft introduced the SDL model back in 2004. What is new: the Cyber Resilience Act makes the principle of “security by design” legally mandatory for all products with digital elements on the EU market. For Belgian software companies, SDLC thus shifts from best practice to compliance requirement.
The difference from a standard development process? In a traditional process, developers write code, QA tests for functionality, and an outside team performs a pen test just before release. Security issues are then discovered only when they are most expensive to fix. In an SDLC approach, security is in every sprint: from analyzing threats at design time to automatically scanning every pull request.
Why a mistake in production costs 100 times more than in design
The economic argument for SDLC is compelling. Research from the IBM Systems Sciences Institute shows that the cost of fixing a vulnerability increases exponentially the further into the product’s life cycle. A bug that takes 30 minutes to fix during the design phase can cost 2 to 5 days and more than $10,000 in production.
Specifically, that cost ratio looks like this:
| Discovery Phase | Cost multiplier |
|---|---|
| Requirements or design | 1x (basic) |
| Implementation (coding). | 6x to 10x |
| Testing (QA) | 15x |
| Production (after release) | 100x |
| Post-release with downtime | 150x or more |
Moreover, for the Benelux region, the financial impact of data breaches is higher than the global average. The IBM Cost of a Data Breach Report 2025 reports average costs of $6.24 million per data breach in this region, versus $4.44 million globally. Organizations with a mature DevSecOps approach save an average of $1.7 million per incident compared with companies that treat security as an afterthought.
The conclusion is clear: investing in security early in the process is not an additional cost, but a direct savings.
Which SDLC framework fits your team?
There are four dominant frameworks on the market. The choice depends on your team size, maturity and compliance requirements. For Belgian SMEs with 5 to 15 developers, OWASP SAMM is usually the most pragmatic starting point.
OWASP SAMM (Software Assurance Maturity Model) is an open source maturity model that allows organizations to grow incrementally. It scores your current security level on a scale of 0 to 3 across five domains: Governance, Design, Implementation, Verification and Operations. The advantage: you don’t have to implement everything at once. You start where the biggest gaps are and grow incrementally. That makes it ideal for teams taking their first steps toward CRA compliance.
NIST SSDF (Secure Software Development Framework, SP 800-218) describes what security outcomes you need to achieve, without prescribing how. It is particularly suitable for companies that operate internationally and want to demonstrate their security maturity to partners or regulators. SAMM and SSDF are largely complementary in content: SAMM often serves as a roadmap to achieve the goals of SSDF.
Microsoft SDL is the pioneer in this area and has evolved to support AI systems. For companies integrating AI components, it provides specific guidelines for protecting models and preventing data poisoning.
ISO/IEC 27034 focuses specifically on application security as an extension of ISO 27001. For organizations that are already ISO 27001 certified, this is the logical extension to demonstrate that security does not stop at the infrastructure but extends into the code.
| Criterion | OWASP SAMM | NIST SSDF | Microsoft SDL | ISO 27034 |
|---|---|---|---|---|
| Suitable for SME | Very suitable | Suitable | Medium | Suitable (at ISO 27001) |
| Character | Maturity Model | Results-oriented | Process-oriented | Standards-based |
| Measurability | Score 0-3 | No built-in score | Gate-based | Compliance audit |
| CRA alignment | Very high | High | High | High |
| Starting threshold | Low | Medium | Medium | Medium |
The six phases of a secure development lifecycle
SDLC is not an abstract concept. It translates into concrete activities for each development phase. Below you will find for each phase what needs to be done, what tools are involved, and how much effort it requires.
Phase 1: Planning and requirements (5-10% of project budget). Translate legal frameworks such as the GDPR and the CRA into functional and non-functional security requirements. Establish authentication methods, encryption standards and data classification before drawing the architecture. Tools: Jira, Confluence, or your existing project management environment.
Phase 2: Design and threat modeling (10-15%). Analyze the architecture from an attacker’s perspective. Use STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to systematically identify threats by component. Research shows that systematic threat modeling during design can lead to 75% fewer vulnerabilities after deployment. Tools: OWASP Threat Dragon, Lucidchart or a whiteboard session with your team.
Phase 3: Implementation and coding (30-40%). Integrate Static Application Security Testing (SAST) into the IDE and CI/CD pipeline. SAST analyzes the source code without running the application and finds vulnerabilities such as SQL injection and weak cryptography already during coding. In addition, add Software Composition Analysis (SCA) to monitor vulnerabilities in open source components. This is essential: 97% of code bases contain open source components. Tools: Semgrep, Snyk, GitHub Advanced Security.
Phase 4: Testing and QA (15-20%). Deploy Dynamic Application Security Testing (DAST) to test the running application as a black-box. DAST finds runtime problems, misconfigurations and authentication errors that SAST cannot see. In addition, perform penetration testing on critical systems. Automated tools find patterns, but human pentesters discover logical flaws that scanners miss. Tools: OWASP ZAP, Burp Suite, and an external pentesting partner.
Phase 5: Deployment (5-10%). Harden the deployment pipeline: secure secrets management, configure container security and implement monitoring. Tools: HashiCorp Vault, Docker security scanning, Jenkins hardening.
Phase 6: Maintenance (ongoing, 15-20% annually). Maintenance accounts for 60 to 80% of the total software lifecycle cost. Reserve 15 to 20% of your development budget annually for patching vulnerabilities, updating dependencies and reducing technical debt. Monitoring with tools like Datadog or Sentry is indispensable here.
What is the difference between SAST, DAST and SCA?
Three abbreviations that are often used interchangeably, but perform fundamentally different functions. Your SDLC needs all three.
| Feature | SAST | DAST | SCA |
|---|---|---|---|
| What is scanned | Source code or bytecode | Running application | Open source libraries |
| When to deploy | During coding (shift-left) | During testing and staging | During each build in CI/CD |
| Strength | Finds errors in own code | Finds runtime and configuration errors | Manages supply chain risk |
| Limitation | More false positives | No access to source code | Only known vulnerabilities (CVEs) |
| Typical tools | Semgrep, Snyk Code | StackHawk, Burp Suite, OWASP ZAP | Snyk Open Source, Black Duck |
The trend in 2026 is “correlation” or “fusion”: tools that combine SAST findings with DAST results. Does a SAST scan find a potential SQL injection point and does the DAST scan confirm that this point is exploitable through the interface? Then that vulnerability is automatically given top priority. That significantly reduces the noise for your team.
What the Cyber Resilience Act means for your development process
The Cyber Resilience Act (Regulation EU 2024/2847) is the first European law to impose horizontal cybersecurity requirements on all products with digital elements. For Belgian software companies, this changes the status of “security by design” from a best practice to a prerequisite for market access.
The CRA works with two deadlines:
- Sept. 11, 2026: manufacturers must report any actively exploited vulnerability to ENISA and the national CSIRT within 24 hours. A detailed report will follow within 72 hours and a final report within 14 days.
- Dec. 11, 2027: full compliance required, including CE marking, technical file and a current Software Bill of Materials (SBOM).
The SBOM is a structured, machine-readable overview of all software components in your product, including open source libraries and their versions. At a minimum, the CRA mandates top-level dependencies. You do not have to make the SBOM public, but regulators may ask for it. Without the SBOM, you cannot in practice comply with the September 2026 notification requirement: you simply do not know which components are affected by a new vulnerability.
Fines for non-compliance are substantial: up to €15 million or 2.5% of annual global turnover. In addition, products can be banned from the European market.
The bottom line: SDLC is the “how” behind CRA obligations. Threat modeling, automated security testing, SBOM generation and vulnerability monitoring are no longer optional extras. They are the building blocks by which you demonstrate compliance.
A pragmatic start-up plan for Belgian software companies
You don’t have to implement everything at once. A phased approach works best, especially for teams that don’t have a formal SDLC process in place today.
Month 1 to 6: Building foundation. Start with an OWASP SAMM baseline measurement to determine where the biggest gaps are. Designate a Security Champion for each development team: a developer who receives additional training in security and serves as the first point of contact. Integrate a SAST tool into your CI/CD pipeline for the fastest gains.
Month 6 to 18: Integrate processes. Make threat modeling a standard part of sprint planning for every new feature. Automate the generation of SBOMs with every build. Add DAST scanning in the staging environment and SCA monitoring for your open source dependencies. Establish a process for vulnerability reporting towards the September 2026 CRA notification requirement.
Month 18 to 36: Optimize and certify. Prepare the technical file for CE marking. Have periodic external penetration tests to validate the effectiveness of your internal controls. Consider ISO 27001 certification if your customers request it.
The investment in SDLC pays for itself through multiple channels: fewer vulnerabilities in production, lower pen testing costs, faster compliance paths and a shorter sales cycle with customers who have increasingly stringent security requirements for their vendors.
Frequently asked questions about secure development lifecycle
What is a secure development lifecycle?
A secure development lifecycle (SDLC) is a structured process that integrates security activities into every stage of software development. From security requirements and threat modeling at design, to automated code analysis during development and vulnerability monitoring after release.
Is an SDLC required under the Cyber Resilience Act?
The CRA requires manufacturers to design products in accordance with “security by design” principles and to conduct a risk assessment that is updated throughout the life cycle. A formal SDLC process is the most effective way to meet these obligations. The first notification requirements will apply from Sept. 11, 2026.
Which SDLC framework is best for an SME?
OWASP SAMM is usually the most pragmatic starting point for Belgian SMEs. It is free, modular and lets you grow incrementally without paralyzing the development process. Companies operating internationally often combine SAMM with NIST SSDF.
How much does it cost to implement an SDLC?
The initial investment is mainly in tooling (SAST, SCA) and training. Open source tools such as Semgrep and OWASP ZAP reduce tooling costs. The ROI is positive: organizations with mature DevSecOps save an average of $1.7 million per data breach compared with those without a formal process.
What is an SBOM and why is it important?
A Software Bill of Materials is a machine-readable listing of all software components in your product, including versions and open source libraries. The CRA requires an SBOM as part of the technical documentation. Without an SBOM, if a new vulnerability occurs, you cannot quickly determine which products are affected.
How long does it take to set up an SDLC?
Expect 6 months for the basic fundamentals (SAST integration, Security Champions, secure coding policies) and 18 to 36 months for a fully integrated process with threat modeling, SBOM generation and automated compliance. Start early: the CRA notification requirement starts on Sept. 11, 2026.
The next step: know where your development process stands
A secure development lifecycle starts with insight. Where are the vulnerabilities in your current code? How secure is your CI/CD pipeline? And how far away are you from CRA compliance?
Cyberplan helps software companies with SDLC integration, threat modeling and application pentesting to structurally build security into the development process. Not a one-time test, but a partnership that strengthens your team.
Flemish software companies can receive up to 50% subsidy on professional guidance on setting up a secure development lifecycle through the VLAIO Cybersecurity Improvement Program. Explore grant options.
Schedule an introductory meeting and find out how Cyberplan supports your development team in the transition to security by design.
