ENISA Secure SDLC + CRA Art.13: Software Lifecycle Compliance Guide for SaaS Developers

Post #3 in the sota.io EU ENISA Secure by Design 2026 Series

The Cyber Resilience Act's September 2026 deadline is approaching fast. While posts #1 and #2 in this series covered the ENISA Secure by Design Playbook and the Art.12(2) secure-by-default hardening guide, this post focuses on CRA Article 13 — the obligation that hits every SaaS team's engineering process directly: you must maintain a documented, security-integrated Software Development Lifecycle (SDLC).

This isn't about one-time certification. Art.13 is an ongoing obligation that runs for the entire supported lifetime of your product. ENISA's Secure by Design guidance maps neatly onto the lifecycle phases most engineering teams already use — but you need to make the security gates explicit, documented, and auditable.

What CRA Art.13 Actually Requires

Before mapping ENISA guidance to your sprints, understand what the regulation demands:

Art.13(2): Manufacturers must ensure products are designed, developed, and produced in accordance with Annex I Part I essential requirements. For software, this means security cannot be bolted on after development — it must be integrated from requirements through deployment.

Art.13(3): You must carry out a cybersecurity risk assessment before placing the product on the market. For SaaS, this is a continuous obligation — every major feature release or architecture change requires a reassessment.

Art.13(4): Technical documentation must be maintained for 10 years. This documentation must demonstrate that your SDLC produces products meeting Annex I requirements. Regulators want evidence, not promises.

Art.13(6): You must have established procedures for handling potential cybersecurity vulnerabilities — both in your own code and in third-party components you integrate.

Art.13(7): Critical vulnerabilities must be addressed "without undue delay, and in any event within 24 hours of becoming aware" (for actively exploited vulnerabilities, per Art.11).

Art.13(1): Due diligence when integrating third-party components — meaning you can't just npm install and hope for the best. Every dependency must be assessed for security posture.

The practical question: how do you build an engineering process that satisfies all of this while still shipping product?

The 6-Phase CRA-Compliant SDLC

ENISA's Secure by Design playbook (v0.4, 2025) organises secure development into six phases. Each phase has specific CRA Art.13 touchpoints:

Phase 1: Security Requirements

What ENISA says: Security requirements must be gathered alongside functional requirements. This includes regulatory requirements (CRA, GDPR, NIS2), contractual requirements (customer SLAs), and threat-derived requirements.

CRA Art.13 mapping: Art.13(3) risk assessment starts here. You must document what security properties your product must have before writing a line of code.

Practical implementation for SaaS teams:

Security Requirements Checklist (CRA Art.13 §3):
☐ Authentication: MFA support, session management, credential storage
☐ Authorisation: RBAC model documented, least-privilege by default
☐ Data protection: Encryption at rest (AES-256), in transit (TLS 1.3+)
☐ Audit logging: All security-relevant actions logged, tamper-proof
☐ Availability: SLA targets, DDoS protection requirements
☐ Third-party integrations: Vendor security assessment criteria
☐ Incident response: RTO/RPO targets, breach notification timeline (72h GDPR)

Documentation artifact (required for Art.13 §4): A Security Requirements Specification (SRS) document, versioned with each release, cross-referencing CRA Annex I requirements. This becomes part of your technical documentation file.

Tooling: Jira security labels + a custom "Security Requirements" issue type works. For teams that want dedicated tooling, OWASP Threat Dragon integrates security requirements with threat models.

Phase 2: Threat Modeling

What ENISA says: Threat modeling is the cornerstone of secure design. Every product with significant security surface area should have a threat model. ENISA recommends STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) as the primary framework.

CRA Art.13 mapping: Directly supports Art.13(3). The threat model is your documented risk assessment — regulators will ask for it.

STRIDE applied to a typical SaaS API:

Practical tip: Threat models don't need to be elaborate. A structured table in Confluence or Notion, updated at each major feature design review, satisfies Art.13 documentation requirements better than a 50-page document reviewed once.

Minimum viable threat model for Art.13 compliance:

1. Data flow diagram (DFD) showing all trust boundaries
2. STRIDE table with identified threats and mitigations
3. Risk rating (likelihood × impact) for each threat
4. Status: mitigated / accepted / deferred
5. Owner and review date

Tooling: OWASP Threat Dragon (free, runs locally), Microsoft Threat Modeling Tool, or IriusRisk for enterprise. The ENISA playbook also references PASTA (Process for Attack Simulation and Threat Analysis) for mature security programmes.

Phase 3: Secure Development

What ENISA says: Security must be built into the development phase through coding standards, code review policies, and automated static analysis.

CRA Art.13 mapping: Art.13(2) — products must be designed and developed in accordance with Annex I. The development phase is where those requirements become code.

ENISA's secure coding baseline for SaaS developers:

Input validation: All external inputs validated at the API boundary. Never trust client-side validation. Use allowlists, not denylists. Reject malformed data early with specific error messages for developers (never expose internals in production).

Output encoding: Context-appropriate encoding for HTML, SQL, and shell contexts. ORM usage does not eliminate SQL injection risk if raw queries or EXECUTE statements are used.

Authentication implementation:

• Passwords: bcrypt (cost ≥12), scrypt, or Argon2id. Never MD5/SHA1.
• Sessions: Cryptographically random session IDs (≥128 bits entropy), regenerated on privilege change.
• MFA: Required for administrative access. TOTP minimum, WebAuthn preferred.
• API keys: Hashed in database (SHA-256 minimum), never logged, full key only shown once.

Secrets management: No secrets in source code, ever. CRA Annex I §1.3 explicitly requires that products "protect the confidentiality of stored, transmitted or otherwise processed data." Environment variables in CI/CD pipelines are not sufficient if build logs capture them — use a secrets manager (HashiCorp Vault, AWS Secrets Manager, or open-source Infisical).

Dependency management (critical for Art.13 §1):

# Weekly dependency audit — make this a CI/CD gate
npm audit --audit-level=high      # Node.js
pip-audit --requirement requirements.txt  # Python
bundle audit                       # Ruby
mvn dependency-check:check         # Java (OWASP)

Art.13(1) requires "due diligence when integrating third-party components." An npm install followed by ignoring npm audit output is not due diligence. Fix critical and high vulnerabilities before merging.

SAST (Static Application Security Testing):

SAST should run on every pull request. Blocking the PR on critical/high findings is the ENISA-recommended approach (and makes Art.13(4) documentation much cleaner — you can demonstrate that critical findings never reach production).

Phase 4: Security Verification

What ENISA says: Testing must include security-specific activities beyond functional QA. ENISA distinguishes between SAST (build time), DAST (runtime), and penetration testing (pre-release).

CRA Art.13 mapping: The risk assessment (Art.13 §3) must be validated through testing. Documentation (Art.13 §4) must include test results. For products with significant security impact, penetration testing results must be available to market surveillance authorities.

DAST (Dynamic Application Security Testing):

DAST tests your running application — unlike SAST it finds configuration issues, authentication bypasses, and runtime vulnerabilities that static analysis misses.

# GitHub Actions — OWASP ZAP DAST scan (runs against staging)
- name: ZAP Full Scan
  uses: zaproxy/action-full-scan@v0.9.0
  with:
    target: 'https://staging.yourapp.example.com'
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-a'

ENISA recommends running DAST against a staging environment mirroring production configuration. Key checks: authentication bypass, injection vulnerabilities, broken access controls, security header gaps.

Dependency vulnerability scanning (in CI/CD):

# Trivy scan — containers + IaC
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'your-image:${{ github.sha }}'
    format: 'sarif'
    exit-code: '1'          # Fail build on CRITICAL/HIGH
    severity: 'CRITICAL,HIGH'

Penetration testing cadence:

CRA doesn't mandate annual pentests explicitly, but Art.13(3) requires that the risk assessment be "commensurate with the risks posed." For SaaS products handling personal data or payment information, ENISA guidance implies:

• Annual external penetration test (full scope)
• Test after major architecture changes
• Specific testing after vulnerability remediations

SBOM generation (Art.13 §4 documentation):

The CRA requires manufacturers to provide an SBOM (Software Bill of Materials) identifying all third-party components. ENISA recommends generating this automatically in your build pipeline:

# CycloneDX format (CRA-aligned, EU preferred)
cyclonedx-npm --output-format json --output-file sbom.json

# SPDX format (also accepted)
syft dir:. -o spdx-json > sbom.spdx.json

Store SBOMs per release. They become part of your 10-year technical documentation file under Art.13(4). Market surveillance authorities may request them directly.

Phase 5: Secure Deployment

What ENISA says: Security doesn't end at the code review. The deployment pipeline and runtime environment must maintain the security properties established in earlier phases.

CRA Art.13 mapping: Art.13(2) applies to production as much as development. If your deployment pipeline injects hardcoded credentials or disables TLS verification "for speed," you've violated the obligation regardless of how clean your code is.

CRA-compliant deployment checklist:

Infrastructure Security (CRA Annex I §1 + §2):
☐ Container images scanned for vulnerabilities (Trivy/Grype) before deploy
☐ Images run as non-root user
☐ Read-only root filesystem where possible
☐ Network policies restricting inter-service communication
☐ Secrets injected via secrets manager (not environment variables in plaintext)
☐ TLS 1.3 enforced on all ingress
☐ Security headers: HSTS, CSP, X-Frame-Options (see Post #2 in this series)
☐ WAF configured for OWASP Top 10 blocking
☐ Rate limiting on authentication endpoints (≤10 failed attempts/minute → lockout)

IaC security scanning:

Infrastructure as Code must also be scanned — a misconfigured Terraform module that opens a security group to 0.0.0.0/0 is a CRA violation regardless of how clean your application code is.

# Checkov — IaC security scanner (Terraform, CloudFormation, Kubernetes)
checkov -d ./infrastructure --framework terraform

# tfsec — Terraform-specific
tfsec ./infrastructure

Phase 6: Maintenance and Vulnerability Management

What ENISA says: This phase is continuous — it doesn't end until end-of-life is declared. ENISA's guidance maps directly to CRA Art.11 (actively exploited vulnerabilities, 24h reporting) and Art.13(6-7) (vulnerability handling obligations).

CRA Art.13 mapping: This is where most SaaS teams are under-prepared. Art.13(6) requires "established procedures" — not a vague commitment, but documented processes with owners, SLAs, and escalation paths.

Minimum viable Vulnerability Management Programme (CRA-compliant):

Tier 1 — Continuous monitoring:

• Dependabot or Renovate bot: automated PRs for dependency updates
• Container image scanning on a schedule (daily minimum for production images)
• CVE database monitoring for your component stack (OSV.dev API is free)

Tier 2 — Triage and response:

Severity    | Response SLA      | CRA Obligation
------------|-------------------|--------------------------------
CRITICAL    | Patch within 24h  | Art.11: May require ENISA/CSIRT reporting
            | (if exploited)    | if actively exploited in the wild
HIGH        | Patch within 7d   | Art.13(7): Without undue delay
MEDIUM      | Patch within 30d  | Art.13(7): Without undue delay (contextual)
LOW         | Next regular      | Best effort
            | maintenance cycle |

Tier 3 — Coordinated Vulnerability Disclosure (CVD):

CRA Art.13(6) requires procedures for handling externally reported vulnerabilities. This means you need a published security contact and a documented CVD policy before September 2026.

Minimum CVD policy components:

1. /.well-known/security.txt — RFC 9116 compliant, with contact email and PGP key
2. Acknowledgement to reporter within 48 hours
3. Fix timeline communicated to reporter
4. CVE assignment process (via MITRE or a CNA)
5. Coordinated public disclosure after fix is deployed

Tier 4 — End-of-life (EOL) management:

CRA requires that manufacturers communicate when a product reaches end-of-life and will no longer receive security updates. For SaaS, this typically means major version deprecation policies. Document them in your technical documentation file.

Mapping ENISA Phases to CRA Art.13 — Compliance Matrix

The 10-Year Technical Documentation File

CRA Art.13(4) requires technical documentation to be maintained for 10 years after a product is placed on the market. For SaaS products with continuous delivery, "placed on the market" is interpreted as each significant version.

What the documentation file must contain:

1. Product description and intended use — Including security-relevant use cases and explicitly excluded use cases
2. Risk assessment — The threat model and risk register from Phase 1-2 above
3. Essential requirements compliance — How each Annex I requirement is addressed (a compliance matrix)
4. Verification evidence — SAST reports, DAST reports, pentest reports referenced by date and version
5. SBOM — Per release, in CycloneDX or SPDX format
6. Vulnerability handling records — History of vulnerabilities reported, triaged, patched, and disclosed
7. EU Declaration of Conformity — The formal declaration that the product meets CRA requirements

Practical storage recommendation: A private Git repository (not the same repo as your source code — market surveillance authorities should not have access to your source). Version-controlled Markdown documents + attached PDFs for reports. Named by product version and date.

What "Established Procedures" Means in Practice

A recurring theme in CRA Art.13(6-7) is "established procedures." Regulators interpret this as:

• Written — Not a verbal agreement or tribal knowledge
• Owned — Named individuals responsible for each step
• Tested — Evidence that the procedure has been rehearsed (e.g., a tabletop exercise for the incident response playbook)
• Updated — Review date documented, updated after each incident

For a typical 10-50 person SaaS team, the minimum set of documented procedures for Art.13 compliance:

1. Vulnerability triage procedure — Who receives CVE alerts? Who assesses impact? Who approves emergency patch releases?
2. CVD policy — Published at /.well-known/security.txt and in your docs
3. Incident response plan — Including ENISA/national CSIRT reporting thresholds per Art.11
4. Dependency update procedure — When is Dependabot merged without review vs. requiring human sign-off?
5. Release security review gate — Who signs off that the SAST report is reviewed before a major release?

Toolchain Summary for CRA Art.13 SDLC Compliance

Most teams don't need every commercial tool. An open-source stack covering SAST + DAST + dependency scanning + SBOM generation satisfies CRA Art.13 documentation requirements — provided you actually run the tools and keep the reports.

Getting Started: The 90-Day CRA SDLC Sprint

With September 2026 approximately 15 weeks away, here's a pragmatic 90-day plan:

Days 1-30 (Foundation):

• Document your current architecture in a data flow diagram
• Run a first STRIDE threat model on your core user data flows
• Implement Semgrep or equivalent SAST in CI/CD (blocking on CRITICAL/HIGH)
• Set up Trivy for container image scanning
• Generate first SBOM (store in documentation repo)

Days 31-60 (Procedures):

• Write and publish CVD policy + security.txt
• Implement Dependabot + set merge policy for dependency updates
• Complete risk assessment documentation (even if rough — iteration is fine)
• Run internal vulnerability scan (OWASP ZAP against staging)

Days 61-90 (Evidence):

• Engage external penetration tester for final assessment
• Close critical/high SAST and pentest findings
• Compile technical documentation file (compliance matrix + test reports + SBOM)
• Draft EU Declaration of Conformity
• Rehearse incident response procedure (tabletop exercise)

Key Takeaway

CRA Art.13 doesn't require perfection — it requires evidence of process. A mature SDLC with documented threat models, SAST reports, dependency audits, and a CVD policy satisfies the regulation far better than a one-time security audit with no ongoing procedures.

The ENISA Secure by Design playbook provides the exact framework. Post #4 in this series covers CRA Art.14 — the Vulnerability Disclosure (CVD) obligation in depth: what format your security.txt must take, how to engage with national CSIRTs, and what the ENISA vulnerability database reporting workflow looks like.

Next in this series:

• Post #4: ENISA Vulnerability Disclosure + CRA Art.14: CVD Programme Guide for SaaS Teams
• Post #5: ENISA Secure by Design CRA Compliance Scorecard: Final 2026 Assessment Framework

Previously in this series:

• Post #1: ENISA Secure by Design Playbook 2026 — SaaS CRA Implementation Guide
• Post #2: Secure by Default: CRA Art.12(2) Hardening Guide for SaaS Developers