Remediation Economics by Finding Source Archetype

Why remediation cost varies by finding source

Most enterprise remediation cost reporting collapses every finding into a single per-finding cost line and reports an average across the open population. The single line is operationally useful for budget forecasting but conceals the source-specific cost shape that drives most of the variance. A scanner finding and a pentest finding may both close as remediated with the same labour-hour total, but the distribution of that labour across triage, investigation, remediation, and verification is dramatically different, and the intervention path that lowers the cost is different too.

Source changes remediation cost because each source produces findings with different evidence quality, different scope clarity, different reproduction overhead, different stakeholder expectations, and different time pressure on the closure. A pentest finding arrives with hand-curated evidence and a named severity rationale; the remediation cycle is dominated by fix design and verification rather than triage. A scanner finding arrives with raw output and machine severity; the remediation cycle is dominated by triage, deduplication, and asset binding before any engineering work begins. A bug bounty finding arrives with adversarial proof-of-exploit and a researcher who expects coordination; the remediation cycle includes a coordination overhead that no other archetype carries. A self-attestation finding arrives with internal evidence and bounded reproduction; the remediation cycle includes a reproduction overhead that other archetypes do not. A threat-intelligence-driven advisory arrives with external pressure and a closure deadline driven from outside the programme; the remediation cycle includes prioritisation churn against the open backlog. A supply-chain advisory arrives with vendor-disclosed evidence and a patch path; the remediation cycle is dominated by dependency-upgrade work and asset enumeration. The six archetypes produce six different cost stacks even when the finding underneath looks superficially identical.

Reading remediation cost as a per-archetype stack rather than as a per-finding line is the first move that lets the programme decide where to invest and where the per-source cost shape actually points the intervention. The frame surfaces the dominant cost component before it absorbs the budget silently. Context on how cycle-time stages decompose the engineering-side work that follows the per-archetype triage decision is covered in the vulnerability remediation throughput research.²⁹

The six finding source archetypes

Six finding source archetypes cover the bulk of enterprise inflow and produce six distinct remediation cost shapes. The archetypes are not the only possible sources, but they capture the operational variance that uniform per-finding cost reporting hides.^1,2,7

Each archetype produces its own cost stack signature. The next six sections walk each archetype through its dominant cost components, the engineering and operational shape of the work, and the intervention path that lowers the cost without compromising the closure record.

Archetype 1: pentest findings

Pentest findings carry a remediation cost stack dominated by fix design and verification rather than by triage. The pentest tester has already eliminated false positives, set severity against an organisational rubric, and described reproduction steps in narrative form; the intake hygiene work that absorbs scanner cost is largely pre-paid by the report itself. Where pentest remediation cost lands is in the engineering hours on the fix and in the verification effort that proves the original exploit path is blocked rather than that the surface behaviour changed.^1,2,30

The intervention path that lowers pentest remediation cost is on the engineering side: a clearer fix design template, a sharper engagement-record handoff to the engineering owner, faster regression confirmation, and a verification path that pairs to the original engagement evidence rather than spawning a separate retest record. The retest cost decomposition research covers the verification-side cost shape that pentest findings carry through closure.³⁰

Archetype 2: scanner findings

Scanner findings carry a remediation cost stack dominated by triage rather than by fix design. Scanner output is high-volume, includes machine severity that often needs recalibration, and contains duplicates across modules. Deduplication, severity normalisation, asset binding, and false-positive suppression absorb engineer time before any remediation work begins. The dominant cost component on scanner findings is intake hygiene, not engineering.^1,2,31,32

The intervention path that lowers scanner remediation cost is on the intake side: deduplication at scanner-output stage, severity normalisation at intake, asset binding rules tied to the canonical asset inventory, and false-positive suppression captured on the engagement record rather than re-litigated each scan. The security finding deduplication economics research covers the dedup cost shape that dominates scanner archetype intake, and the scanner finding merge economics research covers the upstream rollup discipline that compresses the per-finding scanner footprint before it reaches the remediation queue.^31,32

Archetype 3: bug bounty findings

Bug bounty findings carry a remediation cost stack with a researcher-coordination component and a reward payout component that no other archetype produces. The researcher has supplied proof-of-exploit but may have submitted against an out-of-scope target, claimed a duplicate of an existing finding, or asserted higher severity than the rubric supports. The coordination overhead is real and recurring.^1,20

The intervention path that lowers bug bounty remediation cost is on the coordination side: clearer scope documentation, a published severity rubric the researcher and the programme share, a duplicate-check pattern that catches re-submissions against open findings, and an embedded researcher communications channel rather than an out-of-band email thread. The reward payout itself is not a cost to lower but a cost to budget honestly; programmes that under-budget reward payouts produce friction with researchers that compounds into reputational cost on the programme rather than savings on the line item.

Archetype 4: self-attestation findings

Self-attestation findings (developer-flagged risks, threat-modelling outputs, post-incident root-cause findings, internal security-review notes) carry a remediation cost stack with an unusually high reproduction-overhead component because the original evidence is internal and bounded. The developer who filed the finding may have moved teams, the threat model may have been a workshop output without captured artefacts, and the post-incident finding may sit on a postmortem document rather than on the engagement record where the remediation cycle reads against.^1,2

The intervention path that lowers self-attestation remediation cost is on the capture side: pulling the attestation onto the same engagement record the remediation cycle reads against, capturing the original observation with enough evidence that the future investigation has something to reproduce against, and anchoring threat-modelling outputs and post-incident findings into the same finding model the scanner and pentest sources use. Self-attestation that lives on documents and chat channels rather than on the engagement record absorbs the reproduction cost silently because the future investigator has nothing to replay against.

Archetype 5: threat-intelligence-driven findings

Threat-intelligence-driven findings (CISA KEV inclusion, vendor advisories, exploit-in-the-wild reports, EPSS jumps, sector-specific intel) carry a remediation cost stack dominated by prioritisation churn and elevated stakeholder review rather than by engineering effort alone. The intel signal arrives with external urgency that has to be reconciled against the existing open backlog; the prioritisation work consumes capacity before any engineering begins. The stakeholder review burden is unusually high because KEV-listed or actively-exploited findings often require executive, legal, regulatory, and customer-facing coordination.^14,15

The intervention path that lowers threat-intelligence remediation cost is on the prioritisation and communication side, not on the engineering side: a documented exception path for findings that genuinely cannot move within the intel window, a pre-agreed stakeholder review pattern for KEV and exploit-in-the-wild findings, and a finding-record schema that ties the intel signal (KEV inclusion date, EPSS jump, vendor advisory ID) directly to the live engagement record so the audit chain reads the urgency as a captured event rather than as inferred context. Programmes that treat KEV findings as ordinary high-severity findings under-budget the prioritisation churn and the stakeholder review burden, then absorb the cost inside engineering hours that read as missed SLA on routine work.

Archetype 6: supply-chain advisory findings

Supply-chain advisory findings (npm vulnerabilities, PyPI advisories, container base image CVEs, third-party SaaS vulnerabilities, open-source dependency disclosures) carry a remediation cost stack dominated by dependency-upgrade work and asset enumeration rather than custom fix design. The same dependency may sit in dozens or hundreds of repositories, container images, build artefacts, or running services; reachability analysis and SBOM consultation absorb engineer time before any upgrade work begins.^6,9,17,18,19

The intervention path that lowers supply-chain remediation cost is on the SBOM and reachability side rather than the engineering side: a current SBOM that lists the dependency footprint at the time of advisory inclusion, reachability analysis that distinguishes vulnerable code paths from inherited but unreached function exposure, and an asset-binding model that ties the dependency to the owning teams without re-running enumeration on every advisory. Programmes that lack a current SBOM pay the asset enumeration cost from scratch on every advisory and produce remediation cycles that read as slow engineering response when the actual delay sat on the upstream enumeration step.

The inflow-versus-cost asymmetry

Inflow volume varies sharply across archetypes, and the count-share rarely matches the cost-share. Scanner inflow is typically the highest by count, often producing 60 to 80 percent of the total open queue. Supply-chain advisory inflow has been rising fastest year-over-year as SBOM adoption increases. Pentest inflow is the lowest by count but among the highest by per-finding cost. Bug bounty inflow varies by programme scope and reward design. Self-attestation inflow tracks engineering culture. Threat-intelligence inflow is sporadic but each entry can be high-cost. Reading inflow volume alongside per-archetype cost surfaces the gap between count-share and cost-share that uniform per-finding budgeting hides.^1,7,15

The asymmetry produces budget misallocation when programmes assume cost-share follows count-share. A programme allocating remediation budget by count would over-fund scanner triage and under-fund pentest engineering, supply-chain enumeration, and threat-intelligence stakeholder coordination. The defensible budget reads against cost-share rather than count-share, source by source, with the dominant component named per archetype.

Five paired metrics for source-aware reporting

Five paired metrics outperform total-cost-only reporting and survive audit scrutiny. Per-archetype cost stack reads the dominant component per source rather than the total. Per-archetype inflow versus closure rate reads whether closure is keeping up with discovery on each source. Per-archetype SLA performance reads whether the cost is buying the closure cadence committed to. Per-archetype exception rate reads where risk acceptance is absorbing the variance source by source. Per-archetype reopen rate reads whether the closures are durable. The five paired metrics replace the single per-finding-cost debate with a per-source operational picture.^1,7,11

The five paired metrics work because they read the cost shape against the operational outcomes the cost is buying. Programmes that adopt the frame catch the misallocation that single-line per-finding cost reporting hides and produce closure records that the audit chain reads source by source rather than as an undifferentiated population.

Framework citations across finding sources

Most enterprise frameworks expect documented remediation, captured evidence, and a defensible closure record regardless of the source the finding came from. The framework citations pin the floor on the documentation discipline. The cost frame does not replace the citations; it surfaces where the programme is funding the documentation work the citations expect, source by source.^{3,4,5,6,7,10,11,12}

The pattern is consistent: each framework expects the closure record to read against captured evidence regardless of source. Programmes whose closure records read source by source can answer the audit question (where did this finding come from, how was it remediated, what evidence supports the closure) from one record. Programmes whose closure records collapse source provenance into a generic remediation status pay the cost back at audit fieldwork time when the auditor reconstructs source-specific evidence at a higher rate per closure than the original capture would have cost.

For vulnerability management, AppSec, internal security, and security engineering teams

The per-archetype cost frame has different operating implications across the audience layers that read against the same finding population.

• Record source provenance on the finding model so per-archetype cost reporting reads against the actual population rather than against an assumed mix.
• Report per-archetype cost stacks on the operational dashboard so the dominant cost component is observable per source rather than averaged out.
• Budget intake hygiene against the scanner archetype rather than against the per-finding average; intake cost dominates scanner remediation.
• Budget engineering effort against the pentest, bug bounty, self-attestation, and supply-chain archetypes; the engineering-heavy archetypes carry most of the remediation labour.
• Budget stakeholder review and external coordination against the threat-intelligence archetype; KEV-listed and exploit-in-the-wild findings carry an outsized review burden.
• Capture researcher coordination cost as a separate budget line on the bug bounty archetype; coordination and reward payout sit outside engineering labour but are real cost lines.
• Pair every finding to the same engagement record regardless of source so per-archetype cost decomposition is reproducible at any moment.

For vulnerability management teams, AppSec teams, internal security teams, product security teams, and security engineering teams, the operating commitment is to keep the source provenance, the per-archetype cost components, the closure evidence, and the activity log on the same engagement record regardless of where the finding came from. The vulnerability finding intake workflow use case covers the intake shape that surfaces source provenance at the point of capture, and the security engineering handoff latency research covers the handoff segment that absorbs source-specific friction before any remediation work begins.³³

For security leadership and audit committees

Security leaders and audit committees read remediation cost through the defensibility lens. The leadership question is whether the remediation budget the programme is funding matches the actual cost shape across finding sources, or whether one or two sources are silently absorbing capacity that the count-share view conceals. Per-archetype cost reporting is the operational discipline that surfaces this picture before it accumulates into a management-letter finding at audit time.

• Read per-archetype cost stack, inflow versus closure, SLA performance, exception rate, and reopen rate together as one source-aware programme picture rather than as separate operational metrics.
• Investigate cost-share stretches that diverge from count-share; the gap is usually a source where the dominant cost component is being absorbed silently inside engineering hours.
• Pair the per-archetype cost report with the framework citations the audit chain reads against; the cost frame surfaces where the documentation discipline is funded source by source.
• Tie per-archetype reporting to the same engagement record the audit evidence comes from so the leadership read and the audit read are the same record rather than two reports.

The leadership-side platform discipline that supports this is covered on SecPortal for CISOs and security leaders, which describes how findings, remediation, exceptions, and reporting hold the defensible read of programme health source by source rather than only at quarterly review week.

How SecPortal supports per-archetype remediation cost discipline

SecPortal pairs every finding to the same engagement record regardless of source: pentest findings, bulk-imported scanner output, code scan results from connected Git providers, manually entered self-attestation findings, and CVE-enriched supply-chain advisories all sit on the same finding model with CVSS 3.1 vector, severity band, owner, evidence, status, and activity log.^21,22,27

• Findings management records source provenance so per-archetype cost stacks can be reported against the actual finding population.
• Bulk finding import accepts Nessus (.nessus), Burp Suite (.xml), and CSV with custom column mapping so scanner archetype findings carry intake hygiene discipline at the point of capture.
• Authenticated scanning, external scanning, and code scanning generate scanner archetype inflow inside the same workspace.
• Retesting workflows preserve the finding identity through verification regardless of source.
• Activity log captures every state change with named actor, timestamp, and entity reference and exports to CSV so per-archetype cycle time and per-archetype cost decomposition are reproducible.
• Compliance tracking across framework templates carries the finding-to-control mapping so the audit chain reads the same finding regardless of source.

The platform does not pick the cost model for the programme, does not auto-classify per-archetype budgets, and does not push to ticketing systems. It keeps every source on one live engagement record so per-archetype cost reporting is reproducible at any moment between reporting cycles and the audit fieldwork reads against the live record rather than against a reconstructed source-by-source trail.

Conclusion

Remediation cost is six (or more) cost stacks side by side, not a single per-finding line. Pentest findings concentrate cost in engineering and verification. Scanner findings concentrate cost in triage, deduplication, and asset binding. Bug bounty findings add researcher coordination and reward payout to engineering effort. Self-attestation findings carry an unusually high reproduction overhead. Threat-intelligence findings concentrate cost in prioritisation churn and stakeholder review. Supply-chain advisories concentrate cost in asset enumeration, reachability analysis, and dependency-upgrade engineering. The count-share rarely matches the cost-share, and uniform per-finding budgeting under-invests in some sources while over-investing in others.

Treating remediation cost as a property of the source archetype rather than as a uniform per-finding average is the highest-leverage discipline for defensible per-source budgeting and audit-ready closure records. The platform you use does not have to set the per-archetype budget for the programme. It does have to keep the source provenance, the per-archetype cost components, the closure evidence, the actor and timestamp, and the framework mapping on one engagement record so the per-archetype cost decomposition is reproducible at any moment between reporting cycles and the audit fieldwork reads against the live record rather than against a reconstructed source-by-source trail.

Frequently Asked Questions

Sources

1. OWASP, Vulnerability Management Guide
2. OWASP, Risk Rating Methodology
3. PCI Security Standards Council, PCI DSS v4.0 (Requirement 6.3.3)
4. ISO/IEC 27001:2022 Annex A 8.8
5. AICPA, SOC 2 Trust Services Criteria (CC7.1)
6. NIST, SP 800-53 Revision 5 (RA-5, SI-2, SR-3)
7. NIST, Cybersecurity Framework (CSF) 2.0 (ID.RA, PR.PS, RS.MI)
8. NIST, SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
9. NIST, SP 800-161 Cybersecurity Supply Chain Risk Management
10. CIS, Critical Security Controls v8.1 (Safeguard 7.7)
11. European Union, Digital Operational Resilience Act (DORA) Articles 5 and 28
12. HHS, HIPAA Security Rule Risk Management 164.308(a)(1)(ii)(B)
13. FIRST, Common Vulnerability Scoring System (CVSS) Specification
14. FIRST, Exploit Prediction Scoring System (EPSS)
15. CISA, Binding Operational Directive 22-01 Known Exploited Vulnerabilities (KEV)
16. CMU SEI, Stakeholder-Specific Vulnerability Categorization (SSVC)
17. OWASP, Software Component Verification Standard (SCVS)
18. OWASP, CycloneDX SBOM Specification
19. NTIA, The Minimum Elements for a Software Bill of Materials (SBOM)
20. CMU SEI, Coordinated Vulnerability Disclosure Guide
21. SecPortal, Findings Management
22. SecPortal, Bulk Finding Import
23. SecPortal, Authenticated Scanning
24. SecPortal, External Scanning
25. SecPortal, Code Scanning
26. SecPortal, Retesting Workflows
27. SecPortal, Activity Log
28. SecPortal, Compliance Tracking
29. SecPortal Research, Vulnerability Remediation Throughput
30. SecPortal Research, Retest Cost Decomposition
31. SecPortal Research, Security Finding Deduplication Economics
32. SecPortal Research, Scanner Finding Merge Economics
33. SecPortal Research, Security Engineering Handoff Latency