Cyber Threat Intelligence in the AdTech Product Lifecycle
Every AdTech product ships with two roadmaps. The one the team writes – features, partners, regions. And the one attackers write for you – new evasion tricks, new fake supply paths, new ways to ride your SDK into a publisher’s app. The second roadmap is harder to ignore each year.
Cyber Threat Intelligence (CTI) is how a security-aware AdTech company reads that second roadmap on time. Done well, it changes what gets built, not just what gets patched after launch. Done poorly, it lives in a Security Information and Event Management (SIEM) dashboard that nobody opens until an incident.
This piece is for AdTech leadership – the people deciding what a product team owes the supply chain and what level of risk a launch is allowed to carry. The argument is simple: CTI belongs in the product lifecycle, not bolted on after it.
What CTI Actually Is
Strip away the vendor language, and CTI is three things stacked together:
- Signals – domains, IPs, file hashes, behavioral patterns, attacker tooling. The raw observations from honeypots, sandboxes, dark-web monitoring, partner sharing, and your own telemetry.
- Context – who is using those signals, against whom, for what payoff, and how the technique evolves. This is the part that turns a list of indicators into something a product team can reason about.
- A way to share both: usually two open standards working together. STIX (Structured Threat Information Expression) is the data format – a common way to describe a threat: who, what, how. TAXII (Trusted Automated Exchange of Intelligence Information) is the transport – the feed and API mechanism that ships STIX descriptions between organizations.
Both are maintained by OASIS (Organization for the Advancement of Structured Information Standards), the same standards body behind OpenDocument and SAML, and have been formal standards since 2021. When a partner says “we feed our CTI to ISACs and exchanges” – ISACs are Information Sharing and Analysis Centers, industry-specific groups where members trade threat data (FS-ISAC for finance, RH-ISAC for retail, Auto-ISAC for car makers, and so on) — this is the plumbing they mean.
Most teams also map adversary behavior to MITRE ATT&CK, a public catalog of how real attackers operate. ATT&CK matters because it gives your engineers and your security team a shared vocabulary – “T1583.008 – malvertising” lands faster in a design review than “that thing where bad ads get into the auction”.
Why AdTech Is a Different Beast
A typical SaaS company defends a perimeter. AdTech defends a market.
The attack surface is everything the bid request touches: publishers, SSPs, DSPs, DMPs, measurement vendors, creative servers, CDNs, the end-user browser, and the mobile SDK.
Each hop is a potential point where a bad actor can insert themselves: sometimes as a fake reseller, sometimes as a creative that loads a malicious payload on the 200th impression and only in one country.
The threat reports keep flagging the same patterns. Researchers have documented malvertising operations that abuse the legitimate complexity of programmatic to hide.
Brand-impersonation ads using AI-generated assets now appear in roughly 2 out of 3 detected campaigns. Supply-chain transparency standards like ads.txt, sellers.json and the OpenRTB SupplyChain object help, but HUMAN Security’s adoption tracking shows around 8% of web bid requests and 9% of in-app bid requests still come from sellers with no sellers.json entry at all. The gaps are where the threats live.
For an AdTech leadership team, that means three things. Your product is the attack surface, not just the support tier. Risk decisions made at design time are cheaper by an order of magnitude than the same decisions made post-incident. And your partners’ security posture is part of your own, whether your contracts say so or not.
CTI inputs across the AdTech product lifecycle
Discovery
Threat landscape brief
Design
Abuse-case modeling
Build
Indicator feeds in CI
Launch
Pre-launch attack rehearsal
Operate
Live signal-to-roadmap loop
Each stage takes one concrete CTI input. None of them are optional.
Where CTI Plugs In – Five Stages, One Loop
Discovery
Before scoping a new feature – a new SDK target, a new exchange integration, a new ID solution – somebody on the team should be able to answer: who is already attacking products that look like this one, and how? Not in the abstract. Specific groups, specific techniques, specific recent incidents.
This is a 30-minute threat landscape brief, not a 40-page document. If nobody can produce it, the team is designing in the dark.
Design
Threat modeling in AdTech usually fails for a boring reason: the threats are too generic. “Account takeover” doesn’t tell a developer what to build. “An attacker registers as a publisher, uploads creatives that pass static scanning, then swaps the payload at serve time via a third-party tag” tells them exactly what to build.
CTI feeds make threat models concrete. ATT&CK mappings give them structure. A useful design review ends with a list of abuse cases the feature must survive — not just user stories it must support.
Build
This is where CTI becomes plumbing. Indicator feeds get wired into CI: known-malicious domains in creative URLs fail the build. Detection rules for the new feature land in the same sprint as the feature itself. The acceptance criteria for the story include the rule, the test that fires it, and the alert it produces.
Researchers have noted that ATT&CK historically lacked good tooling for the early SDLC, which is precisely why a leadership push matters here – the defaults won’t get you there.
Launch
A pre-launch adversary emulation runs the top three or four abuse cases against the staging environment, using real (sanitized) indicators from your CTI sources.
Operate
This is the loop that turns CTI from a one-time gate into a product capability. New threats surface in feeds and partner exchanges. They become detection rules. The rules generate signals. The signals become tickets. The tickets become roadmap items. The roadmap items reshape the product.
When that loop is short – days, not quarters – your product evolves on the same clock as the attackers. When the loop is broken, you’re shipping last year’s defenses.
Signals Leadership Should Actually Track
You don’t need a 40-metric dashboard. Four numbers cover most of it.
- Coverage. What share of new feature designs went through a CTI-informed review? Below 80%, and the lifecycle integration is decorative.
- Time-to-detection: Median days from an indicator being published in a feed your team consumes to a detection rule being live in production. Two days is good. Two weeks means your CTI program is a library, not a pipeline.
- Sharing depth. How many active two-way intelligence relationships do you have? One-way feed consumption is the entry level. Sharing back into industry exchanges and ISACs is where mature programs live.
- Avoidable incidents. Share of P1/P2 incidents traceable to a signal you had access to but didn’t act on at design time. The goal is zero. The honest first measurement is rarely zero.
Generative AI and the Tightening of Supply-Chain Rules
Two trends are worth budgeting against.
Generative AI is cutting the cost of producing convincing malicious creatives, fake landing pages, and impersonation campaigns to near zero. The Media Trust’s 2026 report and similar industry tracking suggest this is already reshaping detection economics: manual review can’t scale to the volume, and signature-based filtering ages out faster.
Supply-chain transparency is becoming a regulatory expectation, not just an industry good practice. The teams that wired sellers.json, ads.txt, and SupplyChain handling into their products three years ago are now extending those primitives. The teams that didn’t are bolting them on under deadline pressure.
CTI in the product lifecycle is the unglamorous prerequisite for both. It’s the difference between a product that learns from the rest of the industry’s incidents and a product that has to learn from its own.
