Vulnerability Fixation
Remediation Support
Most organisations have more findings than capacity and no reliable way to choose between them. The backlog grows, the same issues reappear in the next assessment, and the security function becomes the department that produces work for other people. Remediation support exists to close that gap: validating what is real, sequencing what matters, and doing the work where the client's teams lack the time or the specialism.
Methodology
- 01
Finding consolidation
Findings from every source — penetration tests, scanners, audits, bug bounty — merged into one register, deduplicated across tools that report the same issue differently.
- 02
Validation
Each finding confirmed or discarded. False positives are removed with the reason recorded, because a backlog full of noise is why nobody trusts the backlog.
- 03
Risk-based prioritisation
Ranking by exploitability in the client's actual environment, asset criticality and exposure — not by CVSS alone, which ignores whether the affected system is reachable or holds anything.
- 04
Root cause grouping
Findings grouped by underlying cause, so one fix closes forty findings rather than forty tickets being worked individually.
- 05
Remediation planning
Owner, effort, dependency and window for each group, agreed with the teams who will do the work rather than assigned to them.
- 06
Implementation support
Working with development, infrastructure and platform teams: code-level guidance, configuration changes, and direct implementation where the client prefers.
- 07
Verification
Each fix tested to confirm it closes the finding and does not introduce a new one. Fixes that create new issues are common enough to be expected.
- 08
Closure reporting
Evidenced closure per finding, with a register the client can take to an auditor, a customer or a regulator.
Approach to testing
- Root cause grouping first. Forty instances of the same missing authorisation check are one problem, and treating them as forty tickets is why backlogs never shrink.
- Prioritisation uses environmental context, not CVSS alone. A critical on an isolated internal host with no sensitive data outranks nothing, and a medium on an internet-facing system holding customer records outranks most things.
- False positives are removed and the reason recorded. A register nobody trusts is a register nobody works.
- The client's team does the work wherever possible, with CSS supporting. Capability that transfers is worth more than a fix that does not.
- Every fix is verified. Unverified remediation is an assumption, and a meaningful proportion of fixes either do not work or break something else.
Types of assessment
Remediation programme (default)
An existing backlog worked down over an agreed period, with CSS supporting the client's teams.
Embedded remediation
A CSS engineer working within the client's team for a fixed period, doing the work directly. Appropriate where the client lacks the specialism.
Post-assessment fixation
Attached to a penetration test, taking the findings through to verified closure rather than ending at the report.
Backlog triage
A one-off exercise validating and prioritising an accumulated backlog, so the client knows what actually matters before committing effort.
Frameworks and standards
- CVSS v3.1 with environmental scoring
- Base score adjusted for the client's actual environment, which is the part most organisations skip.
- EPSS
- Exploit prediction scoring, used alongside CVSS to prioritise what is actually likely to be exploited.
- CISA Known Exploited Vulnerabilities catalogue
- Anything on this list is prioritised regardless of its CVSS score.
- SSVC
- Stakeholder-specific vulnerability categorisation, for decision-tree prioritisation where the client prefers it to scoring.
- CIS Controls v8 Control 7
- Continuous vulnerability management maturity framing.
Tools used
Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.
DefectDojo / client vulnerability platform
Consolidated finding register with deduplication across sources.
Client ticketing system
Remediation tracked in Jira, ServiceNow or wherever the teams already work — a separate tracker is a tracker nobody updates.
Semgrep / CodeQL
Finding every instance of a root cause across the codebase, so grouping is complete rather than based on what was reported.
Nuclei
Templated verification that a fix actually closes the finding across all affected hosts.
Burp Suite
Manual verification of application fixes.
Checklist approach
The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.
Consolidation
- All sources merged into one register
- Deduplication across tools reporting the same issue
- Findings from prior assessments reconciled against current state
- Accepted risks recorded with owner and expiry
- Findings without an owner identified
Validation
- Every finding confirmed or discarded by hand
- False positives removed with reason recorded
- Severity adjusted for the actual environment
- Reachability confirmed for each affected asset
- Compensating controls identified where a fix is not possible
Prioritisation
- Environmental CVSS applied
- EPSS and known-exploited status incorporated
- Asset criticality from the business, not from IT
- Internet exposure confirmed rather than assumed
- Chained findings escalated above their individual scores
Root cause
- Findings grouped by underlying cause
- Full codebase or estate searched for other instances of each cause
- Systemic causes distinguished from one-off defects
- Process or training gaps identified where a cause recurs
Delivery
- Owner agreed per group, with the team not just the manager
- Effort estimated with the implementing team
- Dependencies and change windows identified
- Rollback plan for each change
- Progress visible to the client's own management
Verification
- Every fix tested to confirm closure
- Regression checked for issues introduced by the fix
- Closure evidenced and recorded
- Register kept current so it remains trustworthy
How findings are scored
Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.
- Critical
- Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
- High
- Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
- Medium
- Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
- Low
- Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
- Informational
- A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.
Scan types selected
- Safe Checks
- Standard / OWASP Top 10
- Destructive
- SANS Top 25
- Business Logic Vulnerability Testing
Standard toolset by stage
- OSINT
- Datasploit, Google Dorks, Shodan
- Enumeration & Scanning
- Nmap, Wfuzz, Unicornscan
- Domain Enumeration
- Nikto, DnsRecon, Knock
- Crawling & Fuzzing
- Burp Suite, Acunetix, Netsparker
- Vulnerability Analysis
- OpenSSL, sqlmap, CVE-Details
- Exploitation
- Metasploit, Netcat, Exploit-DB
How CSS tests
A unified swarm of agents, for blind spot detection
AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.
Root cause grouping across thousands of findings from several tools requires semantic comparison rather than string matching, which is where most consolidation efforts fail.
Finding every instance of a root cause across a large codebase is search at a scale manual review cannot reach — and the instances nobody reported are the ones that remain exploitable after the fix.
Reachability analysis across the estate determines which findings are actually exposed, which is the single largest factor in honest prioritisation.
Verification across many affected hosts is repetitive checking, and sampling verification is how a fix gets recorded as complete when it is not.
Every validation and every closure decision is made by a human engineer. Agents consolidate, search and verify at scale; they do not decide that a finding is a false positive or that a fix is adequate. A wrongly closed finding is worse than an open one, because it stops being looked at.
Why this differs
What CSS does that most vendors do not
Every one of these is checkable. Ask any vendor for the same and compare the answers.
This is the differentiator
Most vendors deliver a report and leave. CSS is measured on findings closed rather than findings discovered, which is the opposite incentive and the reason this service exists.
Root cause, not instance
Findings are grouped so one fix closes many. A backlog worked instance by instance never shrinks faster than assessments add to it.
Prioritised on your environment
CVSS alone ignores whether a system is reachable or holds anything. Environmental scoring, EPSS and confirmed exposure produce a much shorter list of things that genuinely matter first.
Closure is evidenced
Every fix is verified and the evidence retained, so closure can be shown to an auditor, a customer or a regulator rather than asserted.
Reporting
Two documents, two audiences
Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.
Technical assessment report
For the engineers who will fix it
- Disclaimer, and Limitations on Disclosure and Use
- Risk Level & Description — the five levels above, scored on CVSS 3.1
- Scan Type — which of the five assessment types were selected
- Assessment Scope — the control areas covered
- Assessment Date — the exact testing window
- Objective of the Assessment — objectives listed against completion status
- Tools Utilization — manual and automated tooling by stage
- Summary of the Assessment
- Overall Recommendations, split into Must Have and Should Have
- Vulnerability Overall Classifications as per Organization
- Security Issues Highlighted
- The Key Findings — each with evidence and detailed recommendation
- Summary of Findings & Conclusion
For this assessment specifically
- Consolidated register: sources, deduplication and final finding count
- Validation outcomes with false positives and the reason for each
- Prioritisation methodology and the resulting ranking
- Root cause groups with every affected instance listed
- Remediation plan with owner, effort, dependency and window per group
- Verification evidence per closed finding
- Findings accepted as risk, with owner, rationale and review date
Executive summary
For the people who will fund the fix
- Objectives, each against a completion status
- Overall Finding of the Assessment — total threats identified, broken down by component and severity
- Summary of the Assessment
- Artefacts of the Assessment — the key findings as a numbered register with severity
- Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
- Overall Recommendation, including a Business Enabling Recommendation sequence
- Must Have and Should Have actions
For this assessment specifically
- Findings closed, by severity, over the period
- Backlog trend: whether it is shrinking, and how fast
- Systemic causes addressed, and what they prevent recurring
- Outstanding risk with a completion forecast
- The constraint limiting faster progress, stated plainly — usually capacity rather than knowledge
- One page
Case studies
What this finds in practice
Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.
A fintech with 1,400 open findings accumulated across two years of assessments and scanning.
- Finding
- Validation discarded 380 as false positives or no longer applicable. Root cause grouping reduced the remaining 1,020 to 47 underlying causes; the largest, a missing authorisation helper, accounted for 211 findings across one codebase.
- Recommendation
- Fix by root cause. Implement the authorisation helper once, apply it across all 211 call sites, and add a lint rule preventing new endpoints without it.
- Outcome
- The backlog fell from 1,400 to 190 in one quarter. The lint rule is what stopped it regrowing — the following year's assessment found four instances rather than the expected hundreds.
A manufacturer with a vulnerability management programme reporting 94% patch compliance.
- Finding
- The 6% outstanding contained every internet-facing system and four appliances on the CISA known-exploited list, because those systems were hardest to patch and had been repeatedly deferred. Compliance was measured by host count, so deferring the difficult ones improved the figure.
- Recommendation
- Weight compliance reporting by exposure and criticality rather than host count, and treat known-exploited vulnerabilities as a separate track with its own SLA.
- Outcome
- All known-exploited items closed within six weeks once they were visible. The measurement change was the actual fix; the previous metric had been rewarding the wrong behaviour.
A healthcare provider where the same findings recurred in three consecutive annual assessments.
- Finding
- Findings were assigned to an IT team with no capacity and no application knowledge. Nothing was ever verified, so items were closed on assertion and reappeared the following year. The register had lost all credibility internally.
- Recommendation
- Rebuild the register with validated findings only, assign by capability rather than by department, and require verification evidence before closure.
- Outcome
- Closure rate went from 31% to 88% over two quarters. The verification requirement caught nine fixes that had not worked, all of which had been recorded as complete the previous year.
Next
Scope this assessment
Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.