Vulnerability Response
Technical investigation of reported vulnerabilities and third-party CVEs, reproduce the issue, determine exploitability and product impact, support remediation and verify the fix.
With a Response Retainer, product context, contacts and commercial setup are already in place, and technical response capacity is secured before the next critical report arrives.
A vulnerability report is only the beginning.
A report may identify a symptom without establishing exploitability, affected versions or root cause. Product teams still need to determine whether the issue is real, what an attacker can achieve, which products are affected and whether the proposed fix actually closes the attack path.
From report to verified fix.
Technical triage
Review of reports, evidence, affected interfaces, prerequisites and initial product impact.
Reproduction
Recreate the reported behavior in a controlled environment and establish the conditions required to trigger it.
Exploitability analysis
Determine what an attacker can actually achieve, required access, attack complexity and whether the issue can be chained with other weaknesses.
Root-cause analysis
Trace the vulnerability into firmware, source code, protocols, applications, cryptography or backend components as required.
Remediation support
Work with engineering on candidate fixes, mitigations and the technical consequences of proposed changes.
Retesting
Re-run the original attack path and test relevant variants to verify that the remediation closes the vulnerability.
The response follows the vulnerability across product layers where necessary.
A CVE in a component does not automatically describe the product impact.
When a vulnerability is reported in a third-party component, we determine whether the affected code is present, reachable and exploitable in the actual product configuration.
From incoming report to verified fix.
- SOURCE
- external researcher
- AFFECTED
- gateway firmware 4.6–4.9
- PATH
- network service → message parser → length handling → privileged process
- EXPLOITABILITY
- remote code execution confirmed
- FIX
- validation moved before buffer operation
- VERIFY
- original exploit blocked, variant cases tested
Two ways to use technical response.
On-demand
For a vulnerability that already needs investigation.
Response Retainer
For product teams that want technical response capacity established before the next critical report.
See the retainer ↓Technical response capacity before you need it.
A critical vulnerability is the wrong time to search for specialist capacity, negotiate terms and explain the product from scratch. A Response Retainer establishes the working relationship in advance so technical investigation can start with product context already available.
- Report arrives
- Find external expertise
- NDA / procurement
- Explain product architecture
- Agree scope
- Wait for capacity
- Investigation starts
- Report arrives
- Escalate to Redlings
- Investigation starts
Product context already known
Architecture, relevant components and previous assessment context can be established before an incident.
Commercial setup already complete
NDA, contracting, contacts and engagement mechanics do not need to be created during an active vulnerability case.
Response capacity secured
Agreed technical capacity is held for vulnerability investigation according to the retainer terms.
Faster path to a verified fix
The same technical team can move from reproduction and exploitability into root cause, remediation review and retesting.
The retainer reduces the time between “we received a serious report” and “engineering understands what is actually affected.”
What you get
Reproduction status
Whether the reported behavior can be reproduced and under which conditions.
Exploitability & product impact
Required attacker access, achievable impact, affected components and relevant product versions.
Root-cause context
The implementation or trust path responsible for the vulnerability.
Remediation verification
Technical assessment of the proposed fix and retesting against the original and relevant variant paths.
Technical disclosure material
Where relevant: technical communication with reporters or involved vendors.
Start with the report.
Send us the vulnerability report, affected product or component, available evidence and current engineering assessment. We determine the initial investigation scope from there.
Incomplete reports are normal. Reconstructing the missing technical context can be part of the response.
When technical response is needed
Technical reproduction, impact analysis and remediation evidence can support a manufacturer's vulnerability-handling obligations.
Technical response and evidence. Regulatory or legal assessment is outside the scope.
Dr. Ewan Fleischmann
22+ years IT security · PhD cryptography · OSCP · OSCE · CISSP
Establish vulnerability-response capacity in advance.
Product context, contacts and commercial setup can be agreed before an urgent report arrives.