Notifications
Clear all
Topic starter
01/08/2026 10:43 pm
TL;DR: WELL Health says it moved from quarterly pentests to 100% web attack-surface coverage within the same budget, using continuous exploit validation to separate noise from verified business impact, according to Terra. The signal for practitioners is that application security now depends on truth quality and coverage continuity, not just more findings.
NHIMG editorial — based on content published by terra: How WELL Health Scaled Application Security Without Increasing Budget
By the numbers:
- WELL Health says it achieved 10X web attack surface coverage within the same budget.
Questions worth separating out
Q: How should security teams replace point-in-time pentests with continuous validation?
A: Start by attaching validation to the changes that actually alter risk, including releases, new API routes, cloud configuration updates, and identity bindings.
Q: When does continuous validation provide more value than traditional testing?
A: It becomes more valuable when the environment changes faster than a fixed test cycle can keep up, especially in cloud-native and business-logic-heavy applications.
Q: What do security teams get wrong about appsec alert volume?
A: They often treat more findings as more security, when the real problem is whether the findings are true, reachable, and worth fixing.
Practitioner guidance
- Shift from quarterly testing to change-driven validation Tie application validation to release events, new integrations, infrastructure changes, and identity binding updates so coverage tracks the real attack surface instead of a calendar.
- Use exploitability as the primary triage filter Require verification that a finding is reachable, reproducible, and business-impacting before it is escalated into the engineering queue.
- Map cloud and AI service identities into appsec scope Include workload identities, service accounts, tokens, and AI-facing access paths in validation plans when applications run across EKS, Bedrock, and similar managed services.
What's in the full article
Terra's full article covers the operational detail this post intentionally leaves for the source:
- The customer statement on how continuous pentesting was operationalised across web attack-surface coverage.
- The details behind the 10X coverage claim, including what changed in testing cadence and scope.
- The business-logic validation approach used to separate exploitable issues from noisy findings.
- The customer-facing results language that security leaders can use for internal reporting and prioritisation.
👉 Read terra's analysis of how WELL Health scaled application security without increasing budget →
Continuous exploit validation: is your appsec programme keeping up?
Explore further
01/08/2026 10:52 pm
Continuous validation is becoming a governance control, not just a testing model. The article shows that the real bottleneck is not tool output volume but confidence in what the outputs mean. For security and IAM programmes, that is the same problem seen in secrets, workload identity, and privileged access reviews: visibility without verified impact does not support good decisions. Teams should treat continuous validation as a control for prioritisation quality, not only a way to collect more findings.
A question worth separating out:
Q: How do application risk programmes affect identity and access governance?
A: They expose the same governance weakness seen in identity programmes that rely on periodic review alone. If service accounts, API keys, and workload identities are not validated in the context of real runtime paths, access drift can persist unnoticed. Continuous validation helps confirm whether trust relationships still match intended privilege boundaries.
👉 Read our full editorial: Continuous exploit validation is reshaping application risk management
