Severity Methodology and Reference Matrix Guide

ATG has multiple dimensions: some deeply technical, down at the runtime-language level; others are not technical at all and come down to how an organization runs its controls. The methodology measures ATG across those dimensions, and the Reference Matrix records the score it produces for each row.

The Reference Matrix carries equal weight with the chapters rather than the standing of an appendix. It is meant to be read alongside the framework chapters and to stay understandable on its own.

16.1: The Severity Ramp and Color Encoding

The severity ramp runs from 1 Critical at the most severe end to 5 Low at the least severe end, with 2 High, 3 Moderate, and 4 Limited filling the intermediate steps. A 0 / N/A category sits outside the ordinal scale and applies to cells where the dimension being scored is inapplicable to the row category.

Inverted ordering is deliberate. Readers trained on CVE and CVSS expect "critical" at the top of the page, so placing 1 at Critical keeps the highest-severity rows where the eye looks first. Color encoding follows standard heat-map convention: deep red at 1 Critical through deep green at 5 Low, with the intermediate steps held consistent across all three sheets, so a reader can compare sheets by eye without relearning the colors.

Inapplicability is not the lowest score. A 0 / N/A cell records that the dimension being scored is inapplicable to the row category. A 5 Low cell records that the dimension applies, but the realized severity is the lowest the ramp carries. The distinction matters because the two scores say different things about the row category. CSS scored against eval is 0 / N/A: CSS has no mechanism that evaluates a string as code, so the dimension does not apply to it. HTML scored against runtime code execution is 5 Low: the capability is present in the rendering pipeline but structurally constrained.

The same distinction applies when a reader scans a whole column. A column with many 0 / N/A cells indicates that the dimension simply does not apply to many of the row categories scored on the sheet. A column with many 5 Low cells indicates that the dimension applies to those row categories and is well defended in practice. The critical-count summary at the foot of each column treats the two cases differently.

16.2: Inclusion Criterion and Scope Boundary

The inclusion criterion draws a precise boundary, and it is deliberately conservative. A vulnerability is in scope for ATG, and therefore eligible for inclusion in the matrix, if and only if it manifests through code or content execution inside a CSR-capable Client Runtime at the rendering surface. Admitting a runtime only when it passes that test keeps the matrix from thinning out into a general supply-chain inventory, and the caution makes the scoring more defensible rather than less. The criterion has two structural parts; each is necessary; neither is sufficient on its own.

CSR-capable Client Runtime. The runtime environment must be one that loads, interprets, or generates content at runtime to influence what is rendered or what executes. Precompiled-only Client Runtimes (runtimes that load and execute only precompiled code, with no runtime modification of behavior) are out of scope by structural definition. ATG cannot occur in a runtime that never modifies its own behavior while running, and the matrix draws its boundary at the same place.

Rendering-surface manifestation. The vulnerability must produce its effect at the rendering surface where the user experiences the system. Vulnerabilities that exist in the supply chain but never reach a CSR-capable Client Runtime, build-time-only compromises that affect server-side build output alone, and configuration-only compromises that do not affect rendered code or content are out of scope even when they share supply-chain mechanics with in-scope vulnerabilities. Supply-chain mechanics run through all of these cases, but the boundary stays at the rendering surface.

A CDN-delivered third-party script compromised at the source and executing inside the CSR-capable Client Runtime of a mobile WebView is in scope: code execution inside a CSR-capable Client Runtime at the rendering surface, both structural parts satisfied. A build-time CI/CD compromise that injects code into server-side build output that never reaches any CSR-capable Client Runtime is out of scope: the rendering-surface manifestation part fails. The mobile-WebView example is deliberate: the test is where the rendering happens, not whether a browser is involved, and client-side rendering runs on far more hosts than browsers.

The criterion is conservative in two senses. First, it excludes server-side runtime scripting and server-side template injection (SSTI) outright. Second, it requires manifestation in the CSR-capable Client Runtime at the rendering surface rather than treating any supply-chain reach as sufficient. Reading either condition loosely would turn the matrix into a general supply-chain inventory and give up what the rendering-surface focus buys. The criterion sits at the structurally meaningful boundary, and the conservatism is deliberate.

16.3: The Exclusion of Server-Side Runtime Scripting and SSTI from ATG

The exclusion is one of scope, not of relevance. Server-side runtime scripting (server-side template injection, server-side request forgery used as a code-execution vector, RCE in server-rendered languages, server-side eval-class vulnerabilities) is out of scope for ATG and therefore out of scope for the matrix. The exclusion is not a claim that server-side runtime scripting does not matter; it is a claim that the matrix covers the layer where the structural defensive gap sits.

D5 effects can be produced on any tier of a system architecture. Malice Without Malware describes a defensive blind spot that is not unique to client devices; the pattern appears wherever a system trusts fetched code or content at runtime without checking how it behaves. Supply Chain Injection is the general form and applies to any supply chain that delivers code or content into an executing environment. The concepts reach server-side environments. The matrix does not.

Server-side runtime scripting sits inside the traditional defensive boundary of modern cybersecurity frameworks. The boundary is not perfect, but it carries identified controls: input validation at trust boundaries, runtime application self-protection where deployed, network segmentation, perimeter monitoring, server-side WAFs, server-process EDR. Client-side rendering layers carry none of those controls as a matter of architectural default. The matrix records the layer where the defensive boundary is missing; including server-side runtime scripting would mix two defensive situations that are structurally different and weaken the per-axis scoring.

Server-side environments are addressed by NIST SP 800-161 and adjacent supplier-relationship frameworks; the matrix does not duplicate that work or claim it is missing. ATG-class scope and server-side scope are complementary, not competing. The matrix names what the rest of the framework landscape does not: the unprotected rendering layer where CSR meets the digital supply chain.

16.4: The Four Scoring Dimensions

Four dimensions inform every cell of the matrix. Each dimension is read against the row-column intersection; together they produce the cell's severity score.

• Default availability: whether the capability is available by default in the row category, or requires non-default configuration or installation. Higher default availability raises severity. When a capability is there without anyone switching it on, the matrix scores it as part of the architectural default.
• Prevailing mitigations: defenses in widespread practical use against the row-column combination, and their realistic coverage. Stronger prevailing mitigations lower severity; weaker mitigations raise it. The dimension is "prevailing," not "available." A defense that exists but is rarely deployed does not meaningfully reduce the damage an exploited capability actually does. The matrix scores what is operating in practice, not what is theoretically reachable.
• Blast radius: the scope of impact if the capability is exploited. The dimension is informed by the user-experience-presence analysis on the Languages sheet, the device-scale analysis on the Platforms sheet, and the reach analysis on the Providers sheet. Larger blast radius raises severity.
• Exploit precedent: confirmed historical evidence of the capability being exploited in production systems. Confirmed precedent raises severity: the capability is operationally weaponized, not theoretical. Absence of precedent is treated cautiously. Detection is not deployment, and the dimension is informational rather than determinative. The dimensions combine through analyst judgment, not a formula, and that is a deliberate choice. CVSS-style algorithmic scoring optimizes for cross-analyst reproducibility at the cost of analytical nuance; the matrix optimizes for analytical nuance at the cost of reproducibility. The rendering surface has too many dimensions for a formula to compress without losing what matters.

Algorithmic scoring is the right choice when reproducibility is the governing concern and the dimensional structure is well-bounded. Neither condition holds here. The capability set, the surface landscape, and the operational profile of the rendering surface together produce a scoring problem where an analyst's judgment does better than a formula. The cost is that two analysts may differ on a cell; the trade-off is named here and handled through the calibration notes in the workbook and the published review schedule.

16.5: User-Experience Prevalence (Languages Sheet)

The Languages sheet scores each language by how much of the deployed CSR landscape its user-experience attack surface appears on, running from a narrow slice up to nearly every surface. The ramp anchors to the User Experience Attack Surface by Language dimension. A language present on a majority of rendering surfaces carries a different total-impact profile than a language present on a narrow slice of them, even if the two languages share a capability set.

Capability and prevalence are independent. The Languages sheet scores capabilities (the seventeen language-level capabilities, eight code-introduction and nine runtime-manipulation) along their own columns; user-experience prevalence sits as a separate axis. A language can carry a rich capability profile and a narrow UX prevalence: languages used heavily in industrial niches with deep capability sets but limited deployed-surface presence. A language can carry a constrained capability profile and a broad UX prevalence: HTML and CSS appear on essentially every web rendering surface but constrain the realized capability set. Both directions exist in the deployed landscape, and the matrix records each separately.

Scoring runs from 1 Critical UX Prevalence at the global-surface band to 5 Low UX Prevalence at the narrow-slice band, on the same scale as the severity ramp so cross-axis reading is consistent. JavaScript, HTML, and CSS occupy the 1 Critical band because the modern rendering pipeline is built on them. Languages present on a narrow slice of the deployed landscape sit at 5 Low. The 0 / N/A category applies where UX prevalence is structurally inapplicable: a language used only in build-time tooling that never reaches a rendering surface scores 0 / N/A on the ramp.

Total impact is a function of capability and prevalence together, not either one alone. A language with severe capabilities and narrow prevalence carries a different operational risk picture than a language with limited capabilities and global prevalence; the matrix preserves both axes precisely so each cell can be read against the language's full operational footprint, not against capability or prevalence in isolation.

16.6: Device Scale (Platforms Sheet)

The Platforms sheet scores each platform category by deployed device scale, the blast-radius argument that runs from a single device to billions. The ramp anchors to deployed device scale, and to the Devices (Global) column that carries the per-category device-count estimates. The estimates are best-estimate at release. Data-sourcing methodology is documented in the workbook, and the caveats section records the per-version review cadence.

Device scale is a blast-radius indicator, not a count of unique devices. Compromise at the platform level reaches every device running that platform by default; the count says how far a compromise travels, not how many distinct devices were tallied. A capability scored 1 Critical against a platform category at 1 Critical Device Scale carries a structurally larger blast radius than the same capability against a category at 5 Low Device Scale. A mobile WebView capability that affects every WebView instance globally and a niche industrial-display capability that affects a few thousand units may share a 1 Critical capability score; the platform-side total impact differs because the deployed footprint differs.

Scoring runs from 1 Critical Device Scale at the global-deployment band to 5 Low Device Scale at the narrow-deployment band, on the same scale as the severity ramp so cross-axis reading is consistent. The 0 / N/A category applies where deployed device scale is structurally inapplicable to the platform category being scored.

Total platform-side impact is a function of platform capabilities and device scale together. This parallels the Languages sheet's capability-and-prevalence pairing: capability without scale and scale without capability each tell only part of the platform-category risk picture, and the matrix preserves both axes so each cell can be read against the platform's full operational footprint.

16.7: D5 Effects as a Cross-Sheet Score

D5 effects are scored as a cross-sheet axis on every sheet of the matrix. Every row-by-column intersection on the Languages sheet, the Platforms sheet, and the Providers sheet carries a D5 score that records which of the five effects (Deceive, Disrupt, Degrade, Deny, Destroy) the capability or compromise mode is structurally suited to produce. D5 is the operational expression of the Malice Without Malware argument and applies wherever the matrix scores a capability or compromise mode, not only in places where a specific subset of effects predominates.

The cross-sheet treatment is deliberate because operational effects are properties of the operation, not properties of the row or column dimension scored on any single sheet. A capability on the Languages sheet, runtime code execution in JavaScript, can produce different D5 effects depending on which platform hosts it (the Languages-by-Platforms intersection) and which provider supplies it (the Languages-by-Providers intersection). Treating D5 as a per-sheet axis would split the operational effect across three sheets and leave the reader to combine them in their head; treating D5 as a cross-sheet axis puts the combined reading in each cell.

Scoring is multidimensional, not ordinal. Each of the five effects is scored independently: a cell can be a structural fit for Deceive and Disrupt and not for Destroy, and the matrix records that profile rather than collapsing it into a single number. A short code in each cell carries the five-part reading in the room a spreadsheet cell allows; the workbook walk-through documents the code and how to expand it into the full five-axis interpretation. The short form is a presentation choice rather than a simplification. Each cell still carries all five readings.

D5 carries the information-manipulation hierarchy into the matrix. A cell that fits Deceive sits where the framework places the center of gravity for the ATG threat, because information manipulation is the easiest to execute, the most rewarding to run, and the most dangerous category of ATG attack. That is a claim about prevalence and damage, not an ordering of the five effects against one another, and the matrix must not be read as placing an operation somewhere on a line running from Deceive to Destroy. Scoring D5 in every cell records which effects a capability or compromise mode is structurally suited to produce.

16.8: Critical-Count Summaries

Each column of each sheet carries a critical-count summary at the foot. The summary is the count of cells in the column scored 1 Critical, optionally paired with a secondary count at 2 High. A reader scanning a sheet's columns can identify the dimensions most heavily concentrated at the top of the severity ramp without reading every cell; the summary is the column-glance reading.

The summary is informational, not determinative. A column with a high critical count is a column that warrants attention; it is not a column that supersedes per-row analysis. Two columns with the same critical count can differ structurally if their distributions across row categories differ, and the matrix's per-row analytical work is what surfaces those differences. The summary is a navigational aid; the per-cell analysis is the substance.

0 / N/A and 5 Low counts tell different stories. A column with a high critical count and a high 0 / N/A count is a column where the dimension is critical when applicable but structurally inapplicable to many row categories. A column with a high critical count and a low 0 / N/A count is a column where the dimension applies broadly and concentrates at the severe end. The two pictures are different operational realities, and the summary surfaces the count without resolving them.

A reader checking the runtime-code-execution column on the Languages sheet finds a high critical count. The capability is structurally critical wherever the language hosts it, and the column directs per-row reading to the languages where the capability is available.

16.9: Caveats and Review Cadence

The methodology's caveats are named plainly.

• Analyst-judgment-driven: the scoring dimensions combine through analyst judgment, not a formula. Cross-analyst reproducibility is not the goal and is not claimed.
• Best-estimate inputs: the Devices (Global) figures and the exploit-precedent inputs are best-estimate at release. Data-sourcing methodology is documented in the workbook.
• Conservative inclusion: the matrix excludes vulnerabilities that fall outside the conservative inclusion criterion. A broader vulnerability inventory is available in the established frameworks: CVE/NVD, MITRE ATT&CK, and the sectoral regulatory frameworks.
• Living workbook: the matrix is intended to change as the rendering-surface attack landscape changes. Per-cell scores will change over time as new evidence emerges.
• D5 multidimensionality: the cross-sheet D5 score is multidimensional. It is not collapsible into a single ordinal value, and the matrix preserves the per-cell five-axis reading as a methodological commitment. Review cadence is published. The matrix is reviewed and revised on a documented schedule, with per-version diffs maintained to show what changed between releases. The document version and the workbook version are aligned; each document revision carries a corresponding workbook revision.

The rendering-surface attack landscape keeps moving, and the matrix is revised to keep pace. Per-version diffs are how the matrix records that motion, and the published cadence is how readers know when to check.

16.10: The Workbook, Sheet by Sheet

The Reference Matrix workbook is organized as three primary sheets and a small set of supporting sheets. The primary sheets carry the per-row severity scoring; the supporting sheets carry the legend, the change log, the version metadata, and the per-sheet methodology summaries that let the workbook stand on its own. Critical-count summaries sit at the foot of each column on all three primary sheets.

• Languages sheet: rows are the languages used in the deployed CSR-capable Client Runtime landscape. Columns are the seventeen language-level capabilities (eight code-introduction; nine runtime-manipulation), plus user-experience prevalence as a separate axis and a D5 cross-sheet score per cell.
• Platforms sheet: rows are the frameworks, runtimes, and libraries grouped under the ten platform categories. Columns are the eight platform-level structural dimensions, plus the Devices (Global) column that anchors device scale and a D5 cross-sheet score per cell.
• Providers sheet: rows are the providers within the twenty provider categories from the provider landscape. Columns include the six provider dimensions (injection vectors, defendability, trust model, update authority, aggregation depth, dependency chain depth), the five ways an adversary gets in (account takeover, network-path hijack, ownership change, insider compromise, cyber exploitation), the reach indicator, and a D5 cross-sheet score per cell. The supporting sheets are what let a reader interpret the workbook without outside help. The legend expands the severity ramp and the D5 notation. The change log records per-version diffs on the published review cadence. The version metadata names the workbook version, the release date, and the document version alignment. The per-sheet methodology summary restates the relevant methodology on a single page, sheet by sheet, so the workbook is interpretable on its own.

Per-cell D5 notation is a compact five-character code, one position per effect (Deceive, Disrupt, Degrade, Deny, Destroy), with documented values per position. The code is short because a spreadsheet cell has limited room; the legend sheet documents the values and how to expand them. A reader can expand any per-cell D5 code into the full five-axis reading by consulting the legend.

The workbook is interpretable on its own. Held without the framework chapters, the matrix is read through the per-sheet methodology summaries. Held without the workbook, the framework chapters give the analysis without the per-cell scoring. Either is usable on its own. Together they give the full picture.