The Continuous Architectural Resilience Framework

—

Executive summary

Most institutions still assure their application estate with the same basic loop: scan on a schedule, raise tickets, fix what surfaces, and attest that the cycle ran. That model made sense when vulnerabilities were found by inspection and exploited one at a time. Neither condition still holds.

Autonomous tooling combines small, individually unremarkable weaknesses into paths that cross several code boundaries. The scanners most institutions own cannot see the classes of flaw those paths are built from.

The evidence is no longer anecdotal. In the RealVuln v3.1 benchmark, rule-based scanners found none of 232 broken-access-control findings and none of 173 missing-authentication findings. Semgrep missed 3,728 of 4,138 labelled vulnerabilities (90.1%). In provisional large-application results, a leading general-purpose AI scanner’s aggregate recall fell from 80.55% on small applications to 1.77% on systems of 263,000 to 816,000 lines, the size range of a bank’s core platforms.

0/232Broken-access-control findings detected by rule-based scanning

90.1%Of labelled vulnerabilities missed by Semgrep

1.77%Recall on systems of 263k–816k lines of code

246Source-supported routes to B1/B2 outcomes across 15 applications

This framework replaces scan-and-attest with a continuous loop whose unit of assurance is the reachability of protected outcomes rather than the number of findings. It has five capabilities (Observe, Validate, Prioritise, Close, Attest) and three rules that separate it from a renamed scanning programme:

Three rules

1a route is only closed when the exact path has been re-executed and fails;

2prioritisation follows outcomes and chokepoints, not severity scores;

3every assurance statement must cite evidence a third party could reproduce.

—

Three shifts: what changes from the inherited model

1From findings →
routes

A finding describes a weakness on its own. A route describes whether that weakness gives an attacker a position from which another weakness becomes reachable. Two scanners with the same finding recall can leave very different protected outcomes reachable through what they miss.

2From periodic →
continuous

A point-in-time scan produces a point-in-time artefact. An exploitable path has a lifetime: it opens when code, configuration or an identity condition changes, and it closes when someone breaks the path. Assurance has to measure that lifetime instead of the date of the last report.

3From asserted →
demonstrated closure

A resolved ticket records an intention. A path that has been re-executed and no longer succeeds is evidence. When an examiner asks how you know, the second is the one they can check.

§1

The operating model being replaced

Four structural failures make the inherited model unsafe. Each belongs to the model, not to any vendor’s product.

The instrument is blind where chaining happensPattern-based detection only covers flaws that reduce to a recognizable syntax. An authorization defect is a missing check across a call path, which gives a pattern matcher nothing to match. The benchmark corpus shows the result: zero detection across 232 access-control findings.

The queue is a false registerRemediation is managed by what was detected. If roughly nine in ten issues never enter the queue, the queue records the visible subset rather than exposure. Presented as the institution’s vulnerability position, it is misleading.

Coverage claims are configuration claims“The scanner is deployed across all repositories” describes installation. The benchmark shows a 69.5-point F3 gap between the leading general-purpose AI scanner and the leading rule-based tool on identical code.

Scale is unaddressedTools validated on small fixtures behave very differently on systems of hundreds of thousands of lines. Assurance built on sample-scale evidence is extrapolation presented as measurement.

§2

The architectural vocabulary: Rings of Risk

The framework borrows its language from the Rings of Risk model, which describes how weaknesses in application code combine to reach protected outcomes. Three devices do the work.

Access Rings place an attacker, or a protected asset, by the privilege tier held or required. The rings are numbered from the core outward: AR1 Crown jewels, AR2 Control plane, AR3 Delegated authority, AR4 Standard user, AR5 Outside. A finding is an arrow. Its tail is the position the attacker occupies and its head is the position gained. The arrow’s length is what the finding actually gives an adversary, which is often nothing and occasionally everything.

Figure 1The five Access Rings

AR5

AR4

AR3

AR2

AR1
crown
jewels

AR1 Crown jewels
host / server-process code execution; control of the datastore or identity root

AR2 Control plane
platform, tenant or organisation admin; secret and key stores

AR3 Delegated authority
another principal’s authority: admin or owner role, victim session

AR4 Standard user
low-privilege account, including self-registered or tenant member

AR5 Outside
anonymous, or holding only a lure, a leaked link or an identifier

Ring assignment reflects the privilege a capability confers, not a CVSS score. A B1 Critical account takeover can end in AR3 while server-process execution ends in AR1: consequence and position are different measurements. Definitions follow the Rings of Risk working draft, §3.4.

Consequence bands grade the harm of an outcome. Reach Rings grade a finding’s role in reaching one. The distinction matters in practice. An RR3 finding is not urgent on its own, but it may be the step that completes every route to an AR1 outcome.

Consequence band: harm

B1Critical

B2Major

B3Moderate

B4Limited

Reach Ring: role in reaching it

RR1Critical reach · reaches B1 without another code flaw

RR2Major reach

RR3Chain-dependent · contributes only with another flaw

RR4Bounded reach

A finding may appear in several routes, and a route may reach several outcomes, so the model does not aggregate findings into a score. It produces an outcome profile. For each protected outcome the profile gives its consequence band, the least demanding entry conditions, the number of distinct supported routes, and the known-route closure set: the smallest set of fixes or controls that interrupts every known route to that outcome. That last field is what turns a vulnerability list into a remediation plan.

§3

The framework: five capabilities

Figure 2The continuous loop

R1Observeroute inventory

R2Validateexecute paths

R3Prioritiserank outcomes

R4Closefix, re-execute

R5Attestevidence pack

one continuous loop: each turn produces the next turn’s input

The output of each capability becomes the input to the next, and the loop does not terminate: closure evidence from one turn becomes the baseline for the next.

Table 1Capability definitions, outputs and owners

CapabilityWhat it doesOutput (evidence)Accountable owner

R1 ObserveMaintains a current model of the estate: ingress points, identities and privilege tiers, data stores, and the routes between them. Refreshed on change, not only on schedule.Route inventory with source-anchored references; asset and identity graph; drift log against the last baseline.Application security engineering, jointly with platform owners.

R2 ValidateTests whether candidate routes are actually reachable by executing them under authorization in an isolated environment. Separates candidate from confirmed.Confirmed chains with reproducible proof-of-concept artefacts and recorded preconditions.Independent validation function (internal or service-operated).

R3 PrioritiseBuilds outcome profiles, identifies chokepoints, and computes the closure set for each protected outcome. Orders work by routes removed per unit of effort.Outcome profiles; chokepoint register; closure sets; re-prioritised backlog.CISO office with the risk function.

R4 CloseRemediates, then re-executes the exact confirmed path. Closure is recorded only on a failed re-run, not on a merged fix.Closure record per chain: re-run output, date, operator, residual path if any.Engineering delivery owner, verified independently.

R5 AttestMaps evidence to control expectations and produces the statement the institution relies on, at a cadence the regulator’s cycle requires.Control evidence pack: metrics, trends, open residual routes, exceptions with owners.Compliance and internal audit.

§4

Maturity model

Maturity is defined by what the institution can demonstrate, not by the tooling it buys. Each level is a precondition for the next: an organisation that cannot map routes cannot validate them in any meaningful sense.

Table 2Resilience maturity levels

LevelNameDefining propertyCharacteristic failure

L0Ad hocScanning is periodic and tool-driven; no route model; findings triaged individually.Assurance rests on a clean report; no ability to state exposure.

L1InstrumentedConsistent scanning across repositories and frameworks; findings tracked to closure.Confuses coverage of code with coverage of flaw classes.

L2MappedRoute inventory exists; findings placed in Access Rings; outcome owners named.Maps are static; drift between the model and the estate goes undetected.

L3ValidatedCandidate routes are executed and confirmed; POC artefacts exist; closure sets computed.Validation is a periodic campaign rather than a control; coverage of the estate is partial.

L4ContinuousLoop runs on change; every closure is proven by re-execution; residual AR1/AR2 reach is a reported, owned metric.Residual: assurance depends on the independence and quality of the validation function.

Most institutions that believe they are at L2 are at L1. They have findings and dashboards, but no model of what those findings confer. The gap between L1 and L2 is not closed by buying another tool. It closes when the institution decides to record positions and routes alongside issues.

§5

Operating cadence

The loop runs at different rates at different layers, and cadence follows rate of change: a layer that changes daily cannot be assured quarterly.

Table 3Cadence by layer

LayerCadenceTriggerEvidence produced

Application codePer merge to a protected branchCommit, dependency change, framework upgradeDiff-scoped route review; new-route register entries

Identity & authorizationContinuous / weeklyRole, tenancy or policy changeAR3–AR5 position map; access-control coverage report

Integration & API perimeterWeeklyNew endpoint, partner onboarding, schema changeIngress inventory delta; SSRF and handoff review

Runtime & configurationContinuousDeploy, config drift, feature flag changeConfiguration-route interactions; enabling-step register

Data layerMonthly + on changeSchema change, new store, retention changeAR1/AR2 outcome profiles; closure sets

Full validationQuarterly baseline; event-drivenMajor release, M&A, material incident, new business lineConfirmed-chain set; independent validation report

§6

Metrics that survive an audit

Metrics fail audits for two reasons: they measure activity rather than exposure, and nobody can reproduce them. The framework keeps a small set, defined closely enough that a third party can re-derive them.

Table 4Framework metrics

MetricDefinitionWhy it defends a position

Verified closure rateChains closed by a failing re-run ÷ chains confirmed in the period.Distinguishes remediation intent from demonstrated closure.

Median time-to-verified-closeMedian days from confirmation to a failing re-run, by consequence band.Answers the question regulators ask: how long was it exploitable?

Residual AR1/AR2 reachable outcomesCount of distinct protected outcomes whose known routes still reach AR1 or AR2, and the number of routes per outcome.States exposure in consequence terms rather than severity counts.

Closure-set coverageProtected outcomes with a computed known-route closure set ÷ outcomes in scope.Proves remediation is planned against routes, not tickets.

Chokepoint concentrationFraction of routes to a given ring passing through a single finding or circle.Identifies where one fix removes many paths, and where a single failure opens many.

Detection completeness by familyBenchmarked recall of the deployed detection stack against a labelled corpus, per vulnerability family.Replaces “we scan everything” with a measured statement about what is visible.

§7

Regulatory mapping

The framework is designed to produce evidence that maps onto existing expectations, not to create a new standard. The table below is indicative rather than exhaustive, and it is not legal advice. Confirm obligations with counsel and through the supervisory relationship in each jurisdiction.

Table 5Indicative mapping of expectations to framework evidence

SourceExpectation (in summary)Framework evidence

DORA
Regulation (EU) 2022/2554Continuous ICT risk management, protection and prevention, detection, and proportionate testing of digital operational resilience, including vulnerability handling and independent testing.Route inventory and drift log (R1); confirmed-chain register with dates (R2); verified closure records (R4); residual AR1/AR2 reporting (R3, R5).

FFIEC
IT Examination HandbookOngoing information security assessment, vulnerability and patch management, and independent testing proportionate to risk; evidence of management oversight.Cadence-by-layer schedule (Table 3); verified closure rate and median time-to-close (Table 4); exception register with named owners.

MAS
Technology Risk Management GuidelinesIdentification and mitigation of technology risk, security assessments and penetration testing, and board-level oversight of residual risk.Outcome profiles by consequence band; chokepoint concentration; independent validation report; board-level residual risk statement.

§8

Implementing in 90 days

Adoption is incremental. The first quarter should not chase full coverage. It should establish the loop on one consequential domain and produce evidence that survives challenge.

Table 6First-quarter path

W123456789101112

Map

Validate

Prioritise & remediate

Close & attest

PhaseActivityExit criterion

Weeks 1–2
MapSelect one domain with an AR1 or AR2 outcome (payments, customer data, identity root). Build the route inventory and name outcome owners.A route map exists with source references; a named owner accepts it as accurate.

Weeks 3–6
ValidateValidate candidate routes by execution in an isolated environment. Separate confirmed chains from candidates rejected on evidence.At least one confirmed chain per protected outcome, each with a reproducible artefact; rejected routes carry a stated reason.

Weeks 7–10
Prioritise & remediateCompute closure sets and chokepoints; re-order the existing backlog against routes removed. Remediate the highest-leverage steps first.Closure sets published for every in-scope outcome; backlog re-prioritised with an audit trail.

Weeks 11–12
Close & attestRe-execute every confirmed chain; record closures and residual reach; present the evidence pack to the risk committee.A closure record per chain, a residual reach statement, and a cadence committed for the next quarter.

Five ways this becomes theatre

×
Mapping without validation. A route map full of unconfirmed candidates is a hypothesis. Label it as one.
×
Validation without re-execution. Closing on a merged fix brings back the gap between intent and evidence that this framework exists to remove.
×
Closure sets that ignore shared mechanisms. Twenty variants that run through one vulnerable operation may need a single fix, while three independent routes need three. Counting tickets overstates the work and understates the concentration.
×
Cadence without change triggers. A quarterly loop on a layer that changes daily is a sampling exercise reported as continuous assurance.
×
Independence in name only. Validation done by the team that must attest to the result is not independent, however rigorous the method.

§9

Limitations and honest scope

The evidence base is a working draftThe Rings of Risk evidence base covers 15 open-source applications. Its route records are source-supported candidates, and the applications were not executed in that study. The framework therefore separates candidate from confirmed at every step. That separation is built into the method, not appended as a caveat.

Validation coverage will be partialKnown-route closure is bounded by the routes you know. Every closure statement should say so: “every known supported route to this outcome is interrupted.”

Benchmark results do not transfer automaticallyRealVuln measures detection on a published corpus. It predicts performance on an institution’s estate but does not certify it, so local validation remains necessary.

Aggressive validation carries operational riskKeep it in isolated environments under written authorization. It does not belong in production monitoring.

This is not a certificationAdoption should be evidenced against the institution’s actual obligations, not against this document.

§10

Self-assessment

There are ten questions. Each asks for evidence rather than intent, and each can be answered from records the institution already holds, or from records it does not. Score one point for every yes backed by an artefact.

0/ 10 pts

0–2 ptsL0–L1

3–5 ptsL2 Mapped

6–8 ptsL3 Validated

9–10 ptsL4 Continuous

Table 7Capability self-assessment

Can you name the protected outcomes that matter most, with a consequence band for each?Artefact · Outcome register, approved by the risk function

Does a route inventory link each finding to the position it confers?Artefact · Route register with source references

Are findings assigned to Access Rings by a stated rule rather than by CVSS?Artefact · Ring classification with judgement calls marked

Is any candidate route validated by execution, not accepted from review alone?Artefact · Confirmed-chain register with dates

Does every confirmed chain carry a reproducible artefact?Artefact · Re-runnable proof-of-concept per chain

Do you hold closure sets for each outcome: the minimum fixes that interrupt every known route?Artefact · Published closure set per outcome

Is closure recorded on a failing re-run, not on a merged fix?Artefact · Re-run output attached to each closure

Is the loop triggered by change (merge, deploy, role change) rather than by calendar alone?Artefact · Change-trigger log and drift report

Is validation performed independently of the team that attests to the result?Artefact · Named independent validator; terms of reference

Can residual AR1/AR2 reachable outcomes be stated as a number today?Artefact · Residual reach statement in the last board pack

Most institutions score two or three. The operating model they inherited was never designed to record positions and routes, so the score reflects the model rather than the quality of their engineering. An honest first score is more useful than a confident assertion.

Download the framework to plan your next level ↓

Appendix: Definitions

Access Ring (AR)Privilege tier of an attacker or protected asset: AR5 Outside, AR4 Standard user, AR3 Delegated authority, AR2 Control plane, AR1 Crown jewels. Numbered from the core.

Consequence bandHarm grading of an outcome: B1 Critical, B2 Major, B3 Moderate, B4 Limited. Independent of the ring at which the attacker stands.

Reach Ring (RR)A finding’s role in reaching an outcome: RR1 Critical reach, RR2 Major reach, RR3 Chain-dependent, RR4 Bounded reach.

RouteAn ordered sequence of findings and steps leading from a stated start position to a protected outcome, under stated conditions.

Confirmed chainA route executed and reproduced under authorization, with a minimal reproducible artefact and recorded preconditions.

Known-route closure setThe smallest feasible set of fixes or controls that interrupts every known supported route to a given outcome.

ChokepointA finding or position through which a disproportionate share of routes to a ring passes.

Sources

[1]Rings of Risk: Consequence and Reachability in Application-Code Vulnerability Chains, working draft, 22 October 2026. github.com/kolega-ai/rings-of-risk
[2]RealVuln Benchmark Comparative Report, Python & TypeScript/JavaScript stratum, v3.1.0, data generated 11 September 2026. realvuln.com

Both are published with open data, and both are subject to revision.

Disclaimer. This framework is provided for information and is not legal, regulatory or investment advice. Regulatory references are indicative summaries; obligations depend on jurisdiction, entity classification and supervisory expectation, and should be confirmed with counsel. Kolega Labs develops security products referenced in the companion documents and may derive commercial benefit from adoption of this framework; readers should weigh it accordingly and test its claims against their own evidence.