Vulnerability Lifecycle Management
==================================

Purpose
-------

This document describes how Thinkwerke designs and implements a **predictable, auditable vulnerability
lifecycle** that operates across software, cloud platforms, containers, and open-source dependencies.

The objective is not scanning, but **end-to-end control**:
from detection through remediation, verification, closure, and evidence generation.

This model is designed for organisations operating under **NIS2, CRA, ISO 27001, and customer assurance
requirements**, where vulnerabilities must be handled consistently and provably.

---

Why Vulnerability Management Fails in Practice
-----------------------------------------------

In many regulated organisations, vulnerability management breaks down due to:

- Findings spread across multiple tools with no single ownership
- Manual triage and spreadsheet-based tracking
- Unclear SLAs and escalation paths
- No linkage between fixes and compliance evidence
- Repeated audit findings despite tooling investment

The result is **risk accumulation, delayed remediation, and weak audit confidence**.

---

Thinkwerke Vulnerability Lifecycle Model
----------------------------------------

Thinkwerke implements a **closed-loop vulnerability lifecycle** with automation and governance
embedded by design.

High-level flow:

Code & Platform Signals → Detection → Triage → Remediation → Verification → Closure → Evidence

Every step is traceable, owned, and auditable.

---

1. Detection
------------

Vulnerabilities are detected continuously from multiple sources, including:

- Secure Software Lifecycle (SSLM) pipelines
  - SAST
  - SCA / SBOM
  - DAST
  - Secrets detection
- Container and image scanning
- Infrastructure-as-Code (IaC) scanning
- Cloud posture and runtime findings
- Kubernetes and CNAPP signals

All findings are normalised into a **single intake stream**, avoiding tool silos.

---

2. Triage
---------

Each finding is automatically classified based on:

- Severity (CVSS or equivalent)
- Exploitability and exposure
- Affected asset (application, service, cluster, account)
- Regulatory relevance (e.g. CRA supply-chain impact)

This ensures engineering teams focus on **real risk**, not raw scanner output.

---

3. Remediation
--------------

Validated findings are converted into **tracked remediation tasks**, typically via Jira or equivalent systems.

Each task includes:

- Clear ownership
- Severity-based SLA
- Technical context and reproduction guidance
- Compliance linkage (why this matters)

Ownership is explicit: no unassigned findings, no silent backlog.

---

4. Verification
---------------

Fixes are validated through:

- Automated re-scans
- Pipeline re-runs
- Code review or configuration validation

Verification ensures that vulnerabilities are **actually resolved**, not just marked as closed.

---

5. Closure and Escalation
-------------------------

Once verified, issues are automatically closed.

If SLAs are breached or fixes fail verification:

- Issues are escalated
- Risk acceptance or compensating controls are recorded
- Decision trails are preserved

This creates defensible outcomes during audits and customer reviews.

---

6. Evidence Generation
----------------------

Every lifecycle stage generates **audit-ready evidence**, including:

- Detection timestamps
- Ownership and SLA assignment
- Remediation actions
- Verification results
- Closure records

Evidence is exportable and reusable across:

- ISO 27001 audits
- NIS2 and CRA assessments
- Customer security questionnaires
- Tender submissions

---

Architecture Overview
---------------------

Typical implementation flow:

SSLM & Platform Scans  
→ Central Finding Intake  
→ Ticket Automation (SLA + Ownership)  
→ Engineering Fix  
→ Re-scan / Verification  
→ Evidence Storage (ISMS / GRC layer)

This architecture supports **continuous compliance**, not annual reviews.

---

SLA Guidance (Example)
----------------------

Thinkwerke commonly recommends:

- Critical: 7 days
- High: 14 days
- Medium: 30 days
- Low: 60 days

SLAs are adapted based on regulatory exposure, asset criticality, and business impact.

---

Business Outcomes
-----------------

Organisations adopting this model typically achieve:

- Faster vulnerability closure
- Reduced audit findings
- Clear accountability across teams
- Predictable remediation timelines
- Stronger regulator and customer confidence

Most importantly, vulnerability handling becomes **operational**, not reactive.

---

Compliance Mapping
------------------

This lifecycle directly supports:

- **NIS2** – Article 21 (vulnerability handling, risk management)
- **CRA** – Annex I (secure design, vulnerability lifecycle)
- **ISO/IEC 27001**
  - A.5.10 (Information security in development)
  - A.8.8 (Management of technical vulnerabilities)
- **SOC 2**
  - CC 7.1, CC 7.2

---

Related Topics
--------------

- :doc:`secure-software-lifecycle`
- :doc:`cloud-security-foundations`
- :doc:`cnapp-kubernetes`
- :doc:`../compliance/nis2`
- :doc:`../evidence-library/control-to-proof`