Long Term: Twelve Months and Beyond
The first two horizons are projects, and projects end. The pressures that produced your original exposure do not. The market keeps shipping architectures that build more of the interface on the client rather than less, because the economics still pay: a provider ships instructions instead of a finished product, the user's device pays to build it, and that cost splits across billions of devices with no line item anywhere. The same economic fact saves the provider money and leaves the runtime open, which is why nobody is giving the design up. What a longer horizon buys you is every mid-term control converted into a standing function with an owner, a metric and a renewal date, plus something no shorter horizon can buy: leverage over what gets built next, in your own architecture and in the industry's.
Past twelve months, enforce architecture standards at design review, monitor supplier ownership as a standing function, use procurement as market pressure, join the collective work on the problems bigger than any one organization, and write the risk itself into how your organization is run.
Architecture Standards and Design Review
Months three to twelve rearchitected the high-stakes surfaces you already had. Design review governs the ones that do not exist yet.
Make new systems justify every third-party resource at design review, the way they already justify open ports and data flows. The dependency budget stops being a cleanup measure and becomes an architecture standard: a named ceiling for each surface, owned by someone, applied at review, so a new dependency has to be approved rather than simply added. At every proposal, ask what popularity makes it easy to skip: what did anyone establish about this component besides the fact that a lot of people use it? The cheapest dependency to defend is still the one you never took, and design review is the only point in a system's life where refusing costs nothing.
Default high-stakes surfaces to server-side assembly in new builds. Building on the client has permanent economics and nobody here pretends otherwise. The claim is narrower: how much any one surface leans on the client is a choice, and for consequential screens the conservative end should be the default that somebody has to argue against rather than for.
Design consequential workflows with a second path to the truth. The first ninety days bolted out-of-band verification onto processes that already existed. Now build it in. Treat a workflow whose only source of truth is a single rendered screen as a design finding, recorded and remediated like any other. Specify out-of-band confirmation and dual-source checks when the workflow is designed, test them when it changes, and let every system that implements the workflow inherit them.
And sunset what you said you would sunset. The counts and coverage metrics from the mid-term feed an annual reduction target with an owner's name on it. Schedule a rebuild for surfaces that cannot meet the standard. Waivers expire, and the register remembers.
Design review is how a remediation outlives the team that performed it. Everything else in this horizon assumes it.
Continuous Supplier Ownership Monitoring
A hostile supplier sits undisturbed because nobody outside can find out who controls it, and what is missing here is the record rather than the technology. A land registry says who holds title to a building. Securities filings say who controls a listed company. Threshold reporting leaves a trail when large sums move. Nothing equivalent covers the CDNs, package namespaces and publisher accounts that deliver code to a screen: a company registry will name an owner, but nothing names the operator, and nothing files a report when a CDN is sold, a package is handed to a new maintainer, or a publisher account is transferred. The most important supply chain ever built has no way of telling anyone when the people controlling it change. What is available today is not a technology. It is sustained, unglamorous diligence, run as a standing function rather than as a procurement gate.
Monitor who controls your suppliers continuously: ownership, operating control and jurisdiction for the providers, packages and infrastructure your runtimes depend on, refreshed on a cycle and on event. Corporate-registry research, registration and certificate monitoring, and commercial due-diligence services all exist for this. What the long term commits to is running them continuously and joining the results to your inventory, so every entry in your dependency list carries a current answer to who controls it.
Change of control is the alert that matters most, and you have to hunt for it rather than wait, because control moves through channels that leave no technical trace: a company sale, a stolen credential, a maintainer or namespace transfer, a DNS repoint. None of those alter the address, the hash or the certificate. Everything a scanner measures stays green while the party deciding what that asset serves becomes someone else. Polyfill.io and XZ Utils were both changes of control before they were incidents, and both were visible beforehand, one publicly and one in the project's own records. Then comes the interval that defeats detection: whoever acquired the asset operates it normally, serving exactly what its dependents expect, for as long as they choose, and often the first detectable event is the attack. Monitor so that the next change of control reaches you as a warning while it is still only a warning, because the quiet stretch afterward will not produce one.
Keep the operator separate from the financier as a standing discipline, treat the operator as the sharper risk wherever both appear, and never take legal ownership as a proxy for who holds the credentials. Then watch for asset cycling. The pattern runs in four stages: somebody acquires an asset that arrives with its trust and its installed dependents already attached, runs an operation through it, abandons it before sustained attribution can resolve, and re-emerges on new infrastructure related to the abandoned operation but not formally linked to it. Each stage exploits a specific gap in the record, and the last one sends an investigator back to the start. What that means operationally is that a takedown is not an ending. The same operator returns under a different name, sometimes reusing code patterns, naming conventions or recognizable behavior, and often reacquiring an overlapping population of dependents. Track operators and not only events, or you will keep finding the same operator behind new names.
Monitoring does not close the industry's ownership gap, and no single organization can. It closes your instance of it, one supplier at a time, and turns an unbounded unknown into a watch list somebody manages.
Procurement Terms and Flow-Down
Write the runtime supply chain into the terms of every purchase whose code renders for your people. One complaint changes nothing about a market; buying criteria applied for years do.
Write five terms into every one of those contracts, all of them following directly from the mid-term diligence work: disclosure of ownership and operating control, notification of change of control, enumerated sub-processors, provenance attestation for delivered software, and audit rights. These are ordinary clauses to negotiate, and their power is cumulative. A supplier who meets them for one customer can meet them for the next, and a market segment where buyers routinely demand them is a segment where they become the default cost of doing business. Change-of-control notification carries the most weight of the five, because it is the only one that turns an unannounced change of owner into a notified one for any provider you contract with.
A vendor who cannot tell you who operates their delivery infrastructure has answered a different question, and that answer belongs in your scoring. Weighting supplier selection toward the ones who can answer moves a market in a way no security review ever will.
And make the terms flow down. Primes pass them to subcontractors. Platform customers ask platforms what they load at run time and from whom. The suppliers that matter are often two or three contracts removed from the one you signed, and a term that stops at the company you signed with governs almost nothing.
Procurement is how your requirements reach organizations that will never read a security whitepaper. It is slow, it compounds, and for the supply chain that reaches the Glass it is badly underused.
Standards, Incident Sharing, and the Capability Gap
Four problems outrun any single defender: what the runtime platform specifies next, how little anyone knows about actual scale, who owns the delivery infrastructure, and a defense nobody sells yet. Each of them has something you can act on today.
Take seats in the standards bodies that specify the runtime's future integrity mechanisms. Web platform, package ecosystem and security standards groups extend the load-time primitives, and whoever shows up to define rendering-layer verification will define it. Participation is not a gesture. It is how an operator's requirements become a platform default a decade later. Carry the same three requirements into every one of those rooms: one authoritative source of truth for what a runtime actually loaded, detection of content swapped after load, and protection against tampering with an application's state in memory while it runs.
Share every well-documented substitution incident through your ISAC or the equivalent sector body, both of which exist now. Nobody knows the true scale of ATG-class operations, and the reason is structural rather than anecdotal: nobody has deployed, at population scale, the instrumentation that would show a swap at the rendering surface, so finding nothing tells you nothing about whether swaps are happening. Absence of evidence is not evidence of absence, and a blind spot is exactly where not seeing something differs from its not being there. That cuts against a defender's optimism and an analyst's alarm equally. Sharing one incident turns a private loss into collective visibility and sharpens the field's picture of actual use.
No registry, no filing and no report exists for an outsider to check an ownership claim against, and that gap is what your monitoring program spends money working around. Support industry disclosure norms, research into infrastructure ownership, and transparency initiatives, all of which push on the gap itself rather than on the workaround. Observe it and engage, and stop there. Substantive policy design sits outside this.
Nobody sells a capability today that watches how content behaves at the rendering layer, on every device class, and no plan here pretends otherwise. It is also not a mystery. Partial versions exist in narrow forms: in-browser script-behavior telemetry from client-side attack surface management vendors, runtime sandboxing layers that observe a subset of API calls, and policy layers that check a model's output against fixed rules before an application uses it. None of them is a runtime default with rendering-layer breadth. Part of the obstacle is economic, because inspecting what running code has changed as fast as the runtime changes it costs CPU, memory and energy, against the same incentives that put the rendering cost on the user's device to begin with. A per-vendor answer will not do, because every runtime inherits this from a shared design, and a patch in one runtime does not reach that design. What you can do today is create demand: state the requirement in R&D agendas, in procurement signals and in standards contributions, so that what eventually ships is shaped by the operators who need it. Funding research toward it, where you have the means, is the strongest form of the same signal. You can state the requirement today. You cannot buy the capability, and never let one stand in for the other.
None of those four protects you this quarter. All four decide what protecting you costs in five years, and they are the only actions here whose benefit reaches defenders who never took them.
Risk Registers, Metrics, and Training
Put the Glass in your enterprise risk register as a named risk with an owner, a stated appetite, its current controls and its honest residual: rendered content is not behaviorally verified on any surface this organization operates, and no standard capability currently closes that gap. Written that way, the residual is not an admission of failure. It is the sentence that keeps the risk funded.
Show leadership the numbers on a cycle: third-party resource count per interface, coverage of pinning and monitoring, how current your diligence is across the supplier base, and compliance with the verification procedures, reviewed like any other control family. Those numbers already exist from the mid-term. Making them permanent means they stop being a project's report and become a function's obligation.
Keep training permanent and role-specific. Operators, finance staff, administrators and executives each get shown a different kind of false screen, and each group's curriculum, tabletop cycle and out-of-band verification drills continue for as long as the architecture that motivates them does. One point belongs in every version, because it is the one that ages worst if left out: an attacker chooses who receives a change and can serve different content to several groups at once, so what a colleague saw on their screen is no evidence about what anyone else saw. Rehearse the procedures, or they are documents rather than controls.
And retain the expertise deliberately. Supply chain intelligence, client-side architecture and dependency governance are skill sets, not projects. This survives staff turnover only if those roles are permanent and have named successors, rather than initiatives attached to individuals.
The register, the metrics, the calendar and the roles are what separate an organization that remediated Attack the Glass once from one that stays remediated.
What Carries Forward
Past twelve months you have an architecture that builds less on the client by standard, a supply chain whose owners are known, watched and contractually bound, workflows that never rest on a single rendered screen, a market pushed deliberately toward transparency, and an institution that carries all of it beyond the tenure of the people who built it.