Attack the Glass (ATG)

Relationship to Existing Frameworks

Cybersecurity work is organized through frameworks. CVE/NVD catalogs vulnerabilities. MITRE ATT&CK catalogs adversary techniques. NIST SP 800-161 governs supply chain risk management. NERC CIP, TSA directives, DORA, and the SBOM regime under EO 14028 govern compliance for the regulated sectors. Practitioners work inside those frameworks. If ATG cannot be located inside them, it sits to one side of the work practitioners actually do.

CVE/NVD does not register ATG. MITRE ATT&CK registers it partially. NIST SP 800-161 covers supplier relationships but not the runtime trust boundary. NERC CIP, TSA directives, DORA, and EO 14028 each fall short at the runtime layer.

15.1: Why ATG Does Not Appear in CVE/NVD

CVE/NVD catalogs vulnerabilities in identifiable software products. Each entry has a vulnerable product, a vulnerable version range, and a path to a patch. ATG presents none of those.

  • No identifiable vulnerable product: ATG is a type of supply chain injection vulnerability that targets client-side rendering, and it lives in the architectural pattern where a CSR-capable Client Runtime meets a digital supply chain, not in any single product. The product the vendor shipped and the application the user is running can be technically identical and operationally different. The CVE system has no slot for that distinction.
  • No clear vulnerable version range: the vulnerability lives in the runtime composition, not the codebase. Two users running the same version of the same application can have different runtime exposure based on what their host runtime actually loaded. A version number says nothing about what the runtime assembled.
  • No clear patch: the patch model assumes a vendor releases an update that closes the vulnerability in subsequent versions. Closing ATG requires architectural change in how runtimes verify and monitor what they execute, which is the point Malice Without Malware makes. Per-product patches do not reach it. Organizations relying on CVE/NVD as the vulnerability stream will not see ATG-class threats reported there. The frameworks that catalog vulnerabilities need to be extended to cover it.

15.2: ATG Mapped to MITRE ATT&CK

ATT&CK is the working vocabulary of detection and response. The mapping for ATG is partial: some operations register in ATT&CK terms, and some structural patterns do not.

T1195 (Supply Chain Compromise) is the closest technique. Its three sub-techniques cover ATG-relevant operations: T1195.001 (Compromise Software Dependencies and Development Tools), T1195.002 (Compromise Software Supply Chain), and T1195.003 (Compromise Hardware Supply Chain). ATG operations that compromise upstream code, build tooling, or distribution register as supply chain compromise in ATT&CK terms.

Client-side execution techniques in ATT&CK are anchored to the browser. T1185 (Browser Session Hijacking), T1176.001 (Browser Extensions), and T1539 (Steal Web Session Cookie) all assume the browser is where execution happens. ATT&CK has since widened the parent technique to T1176 (Software Extensions) and added an IDE-extension sub-technique, which reaches one non-browser host rather than the landscape. ATG runs in the broader Client Runtime landscape: mobile, desktop shells, vehicle infotainment, IoT and operational-technology dashboards, AR/VR, productivity-tool hosts, and user-generated content interactive runtimes. ATT&CK has no equivalent client-side techniques for the non-browser hosts.

Three ATG-specific patterns lack first-class ATT&CK representation.

  • The dormancy and activation pattern: ATT&CK's tactic structure has no place for the pattern ATG operations follow: sit quiet for a long time, then activate. The dormancy phase is the absence of malicious behavior; ATT&CK is built on the presence of it.
  • Runtime Anarchy: vendor and supply-chain code executes with the host application's privileges, on equal footing with the application's own code. ATT&CK's privilege models do not register this case: the vendor's code is not malware in the ATT&CK sense, and the privileges it inherits are not escalation in the ATT&CK sense.
  • The Endemic Flaw: ATT&CK's enterprise matrix is broad, but its non-browser client-side coverage is sparse, and nothing in the matrix represents a flaw that is architectural and reaches across runtimes. ATG behaviors fall partly inside ATT&CK and partly outside. The mapping works for what falls inside; the framework needs extension for what does not.

15.3: ATG and NIST SP 800-161

NIST SP 800-161 is the federal government's guidance on cybersecurity supply chain risk management. It addresses supplier identification, supplier risk assessment, supplier monitoring, and incident response involving suppliers. These are the upstream controls that operate before runtime delivery.

Coverage starts at the supplier-relationship layer. Where an ATG operation involves compromise of an upstream supplier (a CDN operator's account, a package maintainer's credentials, an analytics vendor's build pipeline), SP 800-161-compliant supplier risk management reduces the surface.

The framework does not extend to the runtime trust boundary. Verification ends before execution: once the supplier-relationship controls have done their work, a fetched file crosses into execution inside the host runtime. Suppliers may be vetted, contracted, and monitored, and their products may still deliver adversarial content into the runtime through Supply Chain Injection. The runtime-trust-boundary gap appears in every Client Runtime: browser, mobile, desktop, vehicle, IoT, AR/VR, productivity-tool host.

Knowing your suppliers' suppliers is a separate problem. SP 800-161 expects organizations to maintain that visibility, and on paper the expectation is fully worked out. In practice, even SP 800-161-compliant organizations have not generally achieved transitive inventory at the depth ATG requires; Log4j is the case where the gap manifested broadly.

SP 800-161 is the right framework for the supplier-relationship layer. The runtime trust boundary needs its own.

15.4: ATG and the Sectoral Regulatory Frameworks

Regulated organizations operate under sectoral compliance frameworks that pre-date ATG.

  • NERC CIP (energy): the Critical Infrastructure Protection standards address asset identification, vulnerability assessment, and incident response across the bulk electric system, and CIP-013 addresses supply-chain risk management for those systems. ATG-class threats in operational technology dashboards and supervisory control interfaces sit largely outside the framework's current scope.
  • TSA Directives (transportation): the TSA's pipeline and rail cybersecurity directives are built around network segmentation, access control, continuous monitoring, and patching. Supply-chain integrity is largely absent from them, and the rendering layer is not addressed at all.
  • DORA (EU financial services): the Digital Operational Resilience Act addresses ICT third-party risk management and operational resilience for financial entities. Its third-party-risk provisions are the closest thing in current regulation to requiring that an organization know its providers' providers.
  • PCI DSS 4.0 (payment card): the standard governs systems that store, process, or transmit cardholder data, and its script-integrity provisions require a payment page to inventory the scripts it loads and to detect unauthorized change to them. Coverage is scoped to the cardholder-data environment, and the same scripts on pages outside that scope carry no requirement.
  • EO 14028 and SBOM mandates: Software Bill of Materials requirements make the contents of a build output visible. What the build output contains is not what ends up executing inside the runtime (Origin Laundering blends and obscures provenance once parts are composed), so an SBOM is necessary but not sufficient for ATG defense. The gap is consistent across sectors. Each framework reduces some part of the supply chain surface; none reaches the runtime trust boundary.

15.5: Standards Gaps ATG Exposes

Five standards gaps result. The frameworks were built before ATG; each falls short in a distinct way.

  • Vulnerability cataloging gap: CVE/NVD cannot capture ATG-class threats because its fields do not fit them.
  • Adversary technique cataloging gap: MITRE ATT&CK partially captures ATG; ATG-specific patterns need first-class representation.
  • Supply chain risk management gap: NIST SP 800-161 covers supplier relationships; the runtime trust boundary has no equivalent framework.
  • Sectoral regulatory gap: critical-infrastructure and financial-services frameworks have not yet been updated for ATG-class exposure.
  • Cross-runtime standards gap: browser-class standards (CSP, SRI, the Permissions API, Trusted Types) have no equivalents across the other nine platform categories. Each gap sits in a different framework, and none of those frameworks currently treats the runtime boundary as in scope.