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

—