California’s revised CCPA rules took effect on January 1, 2026, and they expose a gap that most compliance teams have been ignoring.

After you’ve updated your privacy policy, deployed a consent management platform, and added the ‘Do Not Sell or Share My Personal Information’ link to your footer, you might think you’re covered. By every visible measure, your website looks CCPA-compliant, and you’re confident it won’t breach the rules.

But here’s what your consent banner can’t see: the dozens of third-party scripts running on your site right now, quietly collecting users’ data, fingerprinting browsers, and firing pixels to ad networks; often beyond what users consented to.

The CCPA 2026 Amendments

Under California’s 2026 CCPA amendments, all of that’s a problem. The revised rules don’t just tighten requirements around privacy disclosures; they demand that you actually know what your website is doing with consumer data, at the point of collection, in real time (and that you can prove it). For most organizations, though, that’s going to be a challenge, because it isn’t their own code that’s doing the collecting, and they don’t have the right technology in place to monitor anyone else’s.

What the 2026 CCPA Rules Actually Require

The updated regulations, effective January 1, 2026, are more prescriptive than anything California has issued before. The headline changes include:

• Notice at Collection: Companies must provide a detailed disclosure at or before the point of personal information collection — including categories of data, purposes, whether it’s sold or shared, and retention periods. This applies to every touchpoint, online and offline.
• Expanded Privacy Policy: Policies must now include specific disclosures about data sources, third-party categories, business purposes, retention criteria, and all Automated Decision-Making Technology (ADMT) use cases.
• No Dark Patterns: All opt-out mechanisms must be easy, accessible, and non-manipulative. Confusing or obstructive consent interfaces are explicitly prohibited. You can’t trick users.
• Mandatory Cybersecurity Audits: Certain companies must now conduct annual independent security audits, provide executive certification of audit completion to the CPPA by April 1 each year, and maintain formally documented security programs covering technical, administrative, and organizational controls. Audit reports must be retained for five years. This is not a checkbox exercise — the CPPA has greater enforcement resources than ever, and the requirement for signed executive certification means personal accountability sits at the top of the organization.
• Vendor Contract Requirements: Service providers and third parties must be bound by contracts specifying exact purposes, privacy obligations, and pass-through responsibilities to any subcontractors.

Notice the common thread running through all of these requirements: you cannot comply with any of them if you don’t have accurate, real-time visibility into what data your website is actually collecting, including, and especially, through third-party code.

The Third-Party Script Problem

The average enterprise website runs between 30 and 80 third-party scripts at any given time. They can include analytics platforms, tag managers, advertising pixels, A/B testing tools, chatbots, customer data platforms, retargeting trackers, and more. And it’s a list that grows longer with every new vendor relationship and marketing initiative a business undertakes.

Each of those scripts can:

• Read form field values, including fields the user hasn’t submitted
• Access session data and cookies, including those set by other vendors
• Send data to external domains not listed in your privacy policy
• Load additional fourth-party scripts that you never reviewed or approved
• Silently change their behavior after a vendor update

That’s a lot of behaviors that you need to track. When your Notice at Collection says you collect ’email address, browsing behavior, and device identifiers for the purpose of analytics and personalization,’ that statement is only accurate if you’ve verified what every script on your page is actually doing. If a retargeting pixel is also capturing keystrokes, or a chatbot vendor added a new data-sharing integration in their last release, your disclosure will be wrong, and you may not even know it.

Why Consent Management Isn’t Enough

Consent management platforms (CMPs) are a critical part of any CCPA program, but they operate on a fundamental assumption: that you’ve correctly configured which scripts belong to which consent categories, and that those scripts behave as expected.

In practice, that assumption is broken constantly by everyday events like these:

• A vendor update means that scripts categorized as ‘analytics only’ begin passing data to ad networks
• A team member adds a new marketing pixel tag without going through the consent review process
• A fourth-party script — loaded by one of your approved vendors — introduces undisclosed capabilities
• An injected script modifies a consent banner to obscure the opt-out option

Your CMP controls what users consent to in the abstract, but it doesn’t monitor what scripts are doing in practice. That gap between what you say they’re doing and what they’re actually doing is where your CCPA 2026 liability lives.

What Continuous Monitoring Changes

The only way to close that gap is with continuous behavioral monitoring of every script running on your website — not with a quarterly audit or a one-time inventory scan, but real-time visibility into what third-party code is doing during each user session.

This is what Reflectiz is built for. By monitoring client-side behavior continuously across your entire web estate, Reflectiz provides the visibility needed to make your CCPA 2026 compliance program fit for purpose. It lets you:

• Know exactly what data each third-party script is collecting, what external domains it communicates with, and whether that behavior has changed since your last review
• Detect unauthorized script additions, behavioral drift after vendor updates, and fourth-party dependencies that were never disclosed
• Identify consent bypass attempts. That means scripts that fire outside the user’s consent preferences, or DOM manipulation that could constitute a dark pattern
• Generate an accurate, continuously updated inventory of your data collection practices to underpin your Notice at Collection and privacy policy disclosures
• Produce the audit evidence needed to demonstrate compliance to the CPPA — and to support independent cybersecurity audits

The CCPA 2026 requirement to maintain ‘written technical and organizational security controls, including inventorying and vendor management‘ is not something you can satisfy with a spreadsheet that only gets updated once a year. For that, you need an always-on view of your third-party supply chain.

The Vendor Contract Problem — And What it Means for Your Third Parties

The 2026 rules are more prescriptive about what your contracts with service providers and third parties should include, and agreements have to specify the exact purposes that data will be used for (you can’t get away with generic language). They impose privacy obligations, prohibit use for other purposes, and require full cooperation with your cybersecurity audits and risk assessments, and these obligations also apply to your subcontractors.

This means you need to know what your vendors are doing on your site, not just generally, but in enough detail to write accurate, specific contracts about their activities. And you need to be able to verify that they’re honoring those contracts after they’ve signed.

Continuous client-side monitoring covers you for both requirements. It gives you the behavioral data to draft precise contractual language, and the ongoing evidence to detect when a vendor’s actual behavior diverges from what they agreed to.

Practical Steps for Privacy Teams

If you’re responsible for CCPA compliance at your organization, here’s where to focus ahead of January 1, 2026:

• Audit your current script inventory: How many third-party scripts run on your site? Do you know what data each one collects and where it sends it? If the answer is ‘not exactly,’ that’s your starting point.
• Pressure-test your Notice at Collection: Compare what your notice says against what your scripts actually do. The gap between those two things is your compliance exposure.
• Review your consent configuration: Are all data-collecting scripts properly categorized in your CMP? Is there a process for reviewing new scripts before they go live?
• Assess your vendor contracts: Do your existing agreements with analytics, advertising, and marketing vendors meet the specificity requirements of the 2026 rules? Do they include audit cooperation clauses?
• Implement behavioral monitoring: Static inventories and CMP configurations alone cannot keep pace with the dynamic reality of third-party script behavior. Continuous monitoring is the operational foundation that makes the rest of your program credible.

Conclusion

The 2026 CCPA amendments are not just another round of disclosure tweaks. They establish a compliance standard that is grounded in operational reality: what you actually collect, what you actually do with it, and whether you can prove it.

For most organizations, the hardest part of meeting that standard will not be updating the privacy policy; it will be confidently describing what every script on their website is doing right now, and saying whether that matches what they’ve told their users and their regulators.

Third-party scripts are the hidden liability in your CCPA program. The question is whether you find that out on your own terms or whether the first you hear of it is during an enforcement action.

Want to see what your third-party scripts are actually doing?

Reflectiz continuously monitors client-side behavior across your entire web estate, giving privacy and compliance teams the real-time visibility they need to make CCPA 2026 compliance operationally defensible. Request a demo.

FAQ: CCPA 2026 and Third-Party Script Compliance

My website already has a consent banner and a ‘Do Not Sell’ link. Am I compliant with the 2026 rules?

Not necessarily. The 2026 amendments require you to demonstrate what your website actually does with consumer data at the point of collection — not just what your policy says. If third-party scripts are collecting or transmitting data beyond what users consented to, you have a compliance gap even if your visible disclosures look correct.

What exactly is a “Notice at Collection” and what does it need to include?

Under the updated rules, a Notice at Collection must be provided at or before the point where personal information is collected. It needs to specify: the categories of data being collected, the purposes for collection, whether the data is sold or shared, and retention periods. Critically, this notice must accurately reflect what every script on your page is actually doing — not just what you intended when you drafted it.

What’s the difference between a consent management platform (CMP) and continuous behavioral monitoring?

A CMP controls which scripts are permitted to fire based on user consent preferences. Behavioral monitoring watches what those scripts actually do once they’re running. CMPs rely on the assumption that scripts behave as configured — but vendor updates, unauthorized tag additions, and fourth-party dependencies can break that assumption silently. Monitoring catches the gap between what you’ve authorized and what’s happening in practice.

What are “fourth-party scripts” and why do they matter for CCPA compliance?

A fourth-party script is code loaded by one of your approved third-party vendors — not by you directly. If your analytics platform loads a data-sharing library that you never reviewed or approved, that library’s behavior is still your compliance responsibility. The 2026 rules don’t exempt you because the code was introduced by a vendor; you’re accountable for what runs on your site.

Who is required to conduct mandatory cybersecurity audits under the 2026 rules?

Certain companies meeting defined thresholds must now conduct annual independent security audits, with executive certification submitted to the CPPA by April 1 each year. Audit reports must be retained for five years. The signed executive certification creates personal accountability at the leadership level — this is not a routine checkbox exercise.

What do the new vendor contract requirements actually require us to document?

Contracts with service providers and third parties must specify the exact purposes for which data will be used (generic language is no longer sufficient), bind vendors to defined privacy obligations, prohibit use for other purposes, and require their cooperation with your audits and risk assessments. These obligations also flow down to subcontractors. In practice, this means you need granular behavioral data on what your vendors are doing before you can draft contracts that accurately describe it.

How often do I need to monitor my third-party scripts to meet the “real-time visibility” standard?

The regulation’s intent is clear: static annual audits or one-time inventories are not sufficient. You need continuous monitoring because script behavior can change at any time — through vendor updates, new tag deployments, or injected code. The requirement to maintain an accurate, current inventory of your data collection practices implies an always-on capability, not a periodic snapshot.

What’s the enforcement risk if my third-party scripts are out of scope in my privacy disclosures?

If a script on your site is collecting or transmitting data that isn’t accurately reflected in your Notice at Collection or privacy policy, your disclosures are incorrect — regardless of whether your own team made that happen. The CPPA has expanded enforcement resources and the ability to verify what websites are actually doing technically. The first indication of a problem may be an enforcement inquiry rather than an internal audit finding.

California’s revised CCPA rules took effect on January 1, 2026, and they expose a gap that most… was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recent work by Check Point Research has shown how cybercriminals could use AI to enhance an existing attack method. Check Point has dubbed it AI as a C2 Proxy, and it introduces more headaches for anyone with a web supply chain to protect. It can be defended against, but before we get to that, let’s begin with a definition.

What’s C2?

C2 is short for command and control. It’s the communication channel attackers use to remotely control compromised systems. Whenever you see a story about “botnets,” a C2 server is at the heart of it.

In a typical cyberattack, malware infects a device, which then connects to a C2 server controlled by the attacker. They use it to send commands, telling the device (or multiple devices in the case of a botnet) to do things such as exfiltrate data, download additional malware, or flood a target with requests to overwhelm it. Once the infected system completes its assigned tasks, it reports back to the attacker.

The New Approach

The problem with this method for attackers is that it’s fairly easy to scupper. Domains can be blocked, infrastructure taken down, and suspicious traffic patterns detected by defenders.

But Check Point Research realized that AI could help attackers work around this problem using the following approach:

• The attacker infects a machine and installs a piece of malware.
• The malware communicates with an AI assistant through its public web interface.
• It prompts the AI agent to issue an HTTPS request to an attacker-controlled URL, pull content from that site, and return the attacker’s response via the AI output back to the malware.

In this way, the AI service effectively acts as an intermediary between the malware and the attacker, doing the job of a C2 server, but with none of the hassle.

The researchers demonstrated the concept using publicly accessible AI chat interfaces for Grok and Microsoft Copilot, which allow prompts to retrieve or summarize external web content without the need for direct API integration.

Because the AI model retrieves the content and returns it in its response, the malware never needs to contact the attacker’s infrastructure directly.

Instead, the communication happens through the AI platform itself.

The Advantage

There are several major benefits of this approach.

• By hooking into major AI services, attackers can take advantage of encrypted traffic via trusted infrastructure that organizations are unlikely to block.
• Requests to AI platforms typically occur over HTTPS, which limits visibility into the content of those interactions, and with the traffic looking like normal interactions with trusted platforms, this makes detection significantly harder.
• When employees routinely use AI assistants, this creates background noise that attackers can hide their activities within. When it becomes the norm for AI tools to retrieve external content on behalf of users, these requests stand a better chance of avoiding suspicion.

Together, these factors add up to an environment where AI platforms could potentially be used as stealthy communication channels.

Where Traditional Security Controls Fall Short

Although this exploit hasn’t been observed in the wild yet, it’s only a matter of time, now that the concept has been made public. With that in mind, it’s best to start preparing to defend against it now, but typical methods will make that tricky.

Many existing security controls focus on network or server-side threats. However, AI-assisted attacks often operate within the browser or user environment, where visibility is limited.

Because the communication occurs through legitimate browser sessions and trusted AI platforms, traditional network defenses may see only normal HTTPS traffic to well-known services.

Common blind spots include:

• AI-driven requests to external domains
• Prompt-injection payloads embedded in URLs or content
• Malicious scripts triggering AI queries
• Data exfiltration through AI responses

Without client-side monitoring, these activities may go unnoticed.

Defending Against AI-Assisted Client-Side Attacks

AI-driven third-party interactions in the browser demand the same level of deep visibility and constant monitoring as other third parties. Prompt injection and hidden commands embedded in URLs should be detected before they execute, and security teams also need to identify unexpected data flows leaving the browser.

Where Reflectiz Can Help

The AI as a C2 Proxy technique highlights a broader challenge: as AI tools become embedded in websites and web workflows, they expand your attack surface in ways traditional security controls weren’t built to see. That’s precisely where Reflectiz is designed to shine.

1. Detecting unexpected outbound data flows from your website

The most direct risk this research surfaces for website owners is data leaving the browser through channels that look legitimate. Reflectiz continuously monitors all outbound network requests made by scripts on your pages, and uses AI-powered code analysis to surface hidden data flows and identify when a script begins sending data to unexpected domains. If a third-party component on your site starts routing information through an AI platform as part of an exfiltration path, Reflectiz will flag the anomaly — even when the destination is a trusted service like Copilot or Grok.

2. Monitor AI components embedded on your pages for behavioral changes

Many websites now embed AI assistants and chat widgets as third-party components. Like any third-party script, these can be compromised or updated without your knowledge. Reflectiz continuously monitors all scripts, iframes, tags, and web components on your pages for behavioral changes — revealing not just whether they’re present, but what they’re doing. If an embedded AI widget suddenly starts making requests it didn’t make before, or communicating with domains outside its normal pattern, Reflectiz issues an immediate alert. You set the behavioral baseline; any deviation triggers a notification.

3. Supply chain visibility across your entire web ecosystem

The AI as a C2 Proxy technique exploits trust — trust in platforms, in traffic patterns, in familiar services. Supply chain attacks work the same way. Reflectiz maps your entire digital supply chain, giving you a complete inventory of every first-, third-, and fourth-party component on your site, who it communicates with, and what data it touches. When a new AI script or integration appears on one of your pages — whether you added it intentionally or not — Reflectiz surfaces it immediately. Security teams can then enforce allowlists, restrict domains, or block the component entirely via an API call to your WAF.

Conclusion

This exploit turns AI assistants into potential stealth command-and-control channels. While the research demonstrated a proof-of-concept, it highlights how AI platforms could become an additional layer in modern attack infrastructure.

As AI assistants become embedded in everyday workflows and web applications, they effectively expand the client-side web supply chain.

Reflectiz can help reduce risk by monitoring browser-side AI interactions, detecting suspicious external requests, and giving security teams deeper visibility and control over third-party AI integrations. Try it for yourself today!

Subscribe to our newsletter

Stay updated with the latest news, articles, and insights from Reflectiz.

AI As Malicious C2 Servers Is Almost Here was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Each year, Gartner releases its “Top Strategic Technology Trends,” offering a high-level view of where enterprise technology is heading. But the real signals, the ones that actually change how security teams operate, tend to sit deeper in its “Predicts” research.

One of those signals is easy to miss, but hard to ignore once you see it: third-party cyber risk management (TPCRM) is quietly breaking under the AI era, rather than evolving to meet it.

The prevailing model, built on vendor questionnaires, periodic assessments, and the assumption that risk can be understood upfront, is being stress-tested by two forces at once:

• increasingly dynamic, interconnected supply chains
• and the rapid adoption of generative AI on both sides of the assessment process

The result is something more dangerous than mere inefficiency; it’s a growing gap between how confident organizations feel about third-party risk and how well they actually understand it.

In its piece, Predicts 2026: Third-Party Cybersecurity Risk Management Evolves for the AI Era, Gartner points to many of the underlying shifts driving this gap, but taken together, they suggest a more fundamental conclusion:

AI is accelerating the failure of the old model of third-party risk management, not fixing it.

To understand what comes next, we need to look beyond faster questionnaires and incremental improvements; we need to rethink what “managing third-party risk” actually means in an AI-driven environment.

The Core Challenge: Speed Without Insight

Third-party cyber risk management is facing a fundamental crisis. Organizations are experiencing a surge in breaches originating from their vendor ecosystems, yet the tools they rely on haven’t evolved to match the threat landscape. According to Gartner, 62% of organizations still place excessive trust in due diligence questionnaires to inform their risk decisions.

This presents a problem, because those questionnaires are increasingly AI-generated and being evaluated by AI systems, so the entire process is becoming faster while simultaneously becoming less reliable.

This creates a dangerous illusion of progress. Organizations believe they’re becoming more efficient and data-driven, when in reality, they may be making decisions based on increasingly unreliable inputs.

The implication is clear: speed is improving, but insight isn’t keeping pace.

The AI Acceleration Paradox

Generative AI is rapidly transforming how third-party risk assessments are completed and reviewed. Gartner predicts that by 2028, 70% of organizations and their vendors will be using GenAI on both sides of the questionnaire process. Vendors will use it to generate responses, and security teams will use it to analyze them.

On the surface, this looks like progress, and in one narrow sense, it is.

Questionnaires that once took weeks to complete can now be turned around in hours. Security teams can process responses from hundreds of vendors without the same operational bottlenecks. Throughput increases, backlogs shrink, metrics improve.

But as we said, although the speed of assessment may be improving, the quality of insight remains largely unchanged.

Third-party questionnaires remain what they have always been: self-reported, point-in-time representations of a vendor’s security posture.

AI doesn’t change that underlying limitation. It just makes the process more efficient.

And when both sides rely on AI, vendors generating responses and enterprises analyzing them, the process risks becoming increasingly detached from reality. What looks like a richer signal is often just faster synthesis of the same underlying assumptions.

The real danger is that AI amplifies existing problems while masking their impact.

Organizations see improved cycle times and assume they’re making better risk decisions, but in reality, they may just be moving faster through a model that was never designed to capture how third-party risk actually behaves.

Faster onboarding doesn’t mean better risk management; it just means you can be wrong at scale.

The Output Degradation Problem

Perhaps the most concerning trend Gartner identifies is what they call “output degradation”: a phenomenon that occurs when AI-generated content is analyzed by AI systems, creating a cycle where errors compound over time.

Think of it like a photocopy of a photocopy. Each generation introduces subtle distortions.

When vendors use AI to generate questionnaire responses, those responses contain patterns, assumptions, and artifacts. When security teams then use AI to analyze those responses, those same patterns can be reinforced, misinterpreted, or amplified.

Over time, this creates a gradual loss of signal, a growing disconnect between what the system reports and what is actually happening in a vendor’s environment.

This is where the risk becomes operational.

Decisions about vendor onboarding, risk acceptance, and remediation are increasingly based on outputs that may be internally consistent but externally inaccurate.

In other words, the process becomes not just faster but self-referential, and that’s far more dangerous than being slow.

Where AI Actually Adds Value

Despite these risks, the answer is to apply AI more deliberately, not to avoid it.

The highest value of AI in third-party risk management lies in enabling continuous visibility, detection, and response.

Used well, AI can help organizations:

• Scale monitoring across large vendor ecosystems
• Detect control drift after onboarding
• Surface weak signals and emerging patterns
• Prioritize investigation and response efforts

This shifts human effort away from repetitive documentation tasks toward higher-value work: incident response planning, dependency mapping, and real-time decision-making during vendor incidents. AI should be used to improve awareness, not merely accelerate documentation.

This is also where many organizations are starting to rethink their tooling.

Instead of relying solely on vendor-provided information, they’re complementing it with externally validated, continuously updated signals; observing how third-party code behaves in real environments, how dependencies change over time, and where new exposures emerge without waiting for a reassessment cycle.

This shift, from self-reported posture to observed behavior, is what makes continuous monitoring meaningful, rather than just more frequent data collection.

The Convergence of Cyber GRC and Third-Party Risk

Another major shift is the breakdown of silos between cyber GRC (Governance, Risk, and Compliance framework) and third-party risk management.

Historically, these functions have operated separately, with different tools, workflows, and reporting structures. That separation made sense when third-party risk was treated as a discrete process, but it no longer does.

Third-party risk is now inseparable from overall enterprise risk. When a vendor is compromised, the impact spans systems, data, compliance obligations, and business operations.

Maintaining separate systems for these domains creates:

• fragmented visibility
• slower response times
• unclear ownership

Integration changes that. When TPCRM and GRC are aligned, organizations gain:

• a unified view of risk exposure
• faster incident response coordination
• clearer accountability across teams

More importantly, they can understand not just whether a vendor is risky, but how that risk propagates across the enterprise.

From Prevention to Resilience

The most important shift is philosophical. Traditional TPCRM is built on a prevention mindset: the idea that thorough due diligence can stop third-party incidents before they happen. That assumption no longer holds.

Modern supply chains are too complex, too dynamic, and too interconnected for upfront assessments to provide lasting assurance. Organizations need to shift to a resilience-based model which accepts that:

• vendors will be compromised
• control environments will change
• new risks will emerge after onboarding

You can no longer expect to prevent every incident, but you can detect issues early, respond effectively, and minimize their impact.

This requires investment in continuous monitoring, clear response workflows, and cross-functional coordination.

Prevention still matters, but it’s no longer the center of the strategy.

The Path Forward

Gartner’s recommendations point toward a fundamentally different approach:

• Stop automating outdated processes
• Invest in continuous monitoring (particularly approaches that provide independent visibility into third-party behavior, not just refreshed vendor inputs)
• Integrate TPCRM with broader cyber GRC
• Build for resilience, not just prevention
• Apply AI where it improves insight, not just speed

Taken together, these shifts represent a different operating model, one that reflects how third-party risk actually behaves in the real world.

Conclusion

Gartner’s message is clear: the traditional, questionnaire-driven model of third-party risk management is under strain, but the deeper implication is more uncomfortable:

TPRM in the AI Era: Gartner Top Tech Trends Revealed was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most security teams know which third-party vendors they trust. They know which pages require strict controls. They know their regulatory boundaries. But that knowledge lives in Slack conversations, spreadsheet trackers, and institutional memory, not in their security tooling.

That gap, between having visibility and having standards, is exactly what Reflectiz Policies closes.

The Problem: Visibility Without Standards

Web security tools excel at detection. But detection alone doesn’t answer the question security leaders actually need answered: Are we meeting our own security standards?

Most platforms force you to answer that manually:

Alert comes in → someone reviews it → someone makes a judgment call → repeat 200 times per week

That approach creates three compounding problems:

No single source of truth. Security policies live in documentation, compliance frameworks, vendor contracts, and tribal knowledge — with no authoritative system to enforce them.

No objective measurement. Without defined standards, you can’t report to leadership: “We’re consistently meeting our Restricted security requirements.” You can only say: “We got 200 alerts and handled most of them.”

That’s not security posture management. That’s alert administration.

The Solution: Define Standards, Enforce Automatically, Measure Objectively

Reflectiz Policies turns your risk appetite into executable governance. You define your security standards once, the platform enforces them automatically across your entire web environment, amplifying the value of both the Security Hub and Privacy Hub with a centralized control layer across all digital assets.

1. Define Your Security Standards

Policies is organized into three areas covering distinct dimensions of your web environment:

• Sensitive Data Protection — defines which applications types and specific applications can access credit card (CC) and personally identifiable information (PII)
• Sensitive Zones — specifies what security arrangements are required for sensitive pages – checkout, login, and authenticated pages – as well as non-sensitive pages
• Infrastructure & Supply Chain — sets rules for vendor access (number of apps allowed on the site) and defines tolerance for site changes (severity of script change alerts)

For each area, you choose the enforcement level that matches your risk appetite:

• Secured — baseline protection with automated checks for common risks. A payment page at Secured level, for example, permits first-party applications and verified analytics tools to operate without restriction.
• Enforced — moderate controls balancing security and usability. At Enforced, external data transfers require explicit approval, and new third-party scripts on authenticated pages trigger review before they’re allowed to run.
• Restricted — strict controls for regulated or high-security environments. At Restricted, no external data transfers are permitted from sensitive pages, and any unrecognized script — regardless of vendor — triggers an immediate alert.

Each area follows the same logic, giving you full control to mix and match tiers rather than applying a blanket policy across your entire environment. A retail bank might run Restricted across all authenticated and payment pages while keeping marketing properties at Secured — without managing two separate tooling stacks.

2. Audit Before You Enforce

Before policies go live, preview their impact, seeing exactly which violations your chosen settings would trigger. Calibrate with confidence, without risk of unintended disruption.

3. Auto-Approval for Compliant Activity

Once live, the platform enforces your standards automatically across your full website portfolio. New components or behaviors that align with your chosen tier are approved instantly, no manual review, no ticket queue. In practice, this eliminates manual review for up to 90% of alerts. Marketing adds a trusted analytics vendor to a blog page? Auto-approved if it fits your framework.

4. Instant Alerts for Policy Violations

Anything outside your defined parameters triggers immediate alerts. The key distinction: you’re not being notified that a new third-party was detected. You’re being notified that something violated your stated security standards, and severity is determined by those standards, not a flat list of 200 undifferentiated notifications.

5. Quantified Security Posture

A built-in scoring system shows which standards you’re meeting and where gaps exist. Instead of subjective assessments, you get objective measurement: “We’re compliant with our Restricted tier requirements, here are the open gaps.” Security reporting shifts from alert counts to posture metrics.

What This Looks Like in Practice

Castore, the premium British sportswear brand, manages online stores for over 30 professional sports team partners — a portfolio that shifts with sponsorships and runs continuously across soccer, F1, and cricket. Every store carries its own stack of analytics tags, ad pixels, customer service widgets, and chat tools. Each of those brings its own dependencies. Monitoring all of it manually wasn’t just difficult — it wasn’t happening.

Before: Script visibility across 30+ sites tracked in spreadsheets. Every new tag or pixel requiring individual review. No consistent way to enforce which vendors were permitted on which pages, or to flag when an approved tool started behaving unexpectedly.

After (Enforced tier): Payment pages set to Restricted, marketing pages to Secured, authenticated sessions to Enforced. Policy impact audited before go-live. Up to 90% of routine alerts auto-resolved — trusted vendors doing expected things on expected pages. Only genuine violations escalate for review.

The operational difference was immediate. As Alistair Knowles, Cyber Security Lead at Castore, put it:

“Not going through and having to do the same thing for 30 websites is a lot easier. I just check in every now and again and deal with the odd change or the odd script, instead of having to constantly look at 30 different websites myself and keep track of that in some spreadsheet.”

Result: The security team manages posture instead of triaging alerts. Marketing knows upfront what’s allowed and what triggers review. Leadership gets quantified reporting on security effectiveness rather than raw alert counts.

Who Should Use Policies

Enterprises managing third-party sprawl. If your website environment runs on dozens of vendors — analytics, advertising, personalization, payments — you already know that manually reviewing every new script or pixel is unsustainable. Policies replaces that review queue with automated enforcement: trusted vendors on expected pages get approved instantly; everything else gets flagged on your terms, not the tool’s.

Jamie Rossato, former CISO at Lion, the Australian beverage conglomerate managing dozens of brand websites across multiple territories, described exactly this challenge when evaluating solutions: “We wanted a lightweight tool that could give us security insights into the code and applications deployed at all our key sites… that can give us that ability to rapidly and easily get us that continual oversight.”

Regulated organizations under compliance pressure. PCI DSS, GDPR, HIPAA: compliance frameworks demand that you demonstrate control over what accesses sensitive data on your pages. Policies gives you that demonstration in concrete terms: defined standards, documented enforcement, and a scoring system that shows auditors exactly where you stand and what you’re doing about gaps.

Multi-property businesses with governance gaps. When different brands or regional teams set their own informal rules, inconsistency becomes a liability, both operationally and from a risk standpoint. Policies standardizes protocol across directors, teams, and regions without requiring each property to manage its own security tooling configuration.

What all three share: they’ve outgrown reactive monitoring and need governance that scales with the business.

Policies is a core capability of the Professional Tier, designed for organizations that prioritize scalable operations, executive-level reporting, and centralized governance. Enterprise customers additionally get custom-made policies — fully bespoke standards beyond the three built-in tiers, for organizations with unique risk profiles or complex multi-region requirements.

The Shift That Matters

The fundamental question in web security is changing.

Old question: “What alerts did we get this week?”
New question: “Are we meeting our security standards?”

The first is reactive. The second is a measurable business function with defined benchmarks and objective outcomes. The difference isn’t just operational, it’s the difference between a security team that reports activity and one that demonstrates control.

Policies is built for organizations ready to make that shift. And given what’s sitting unreviewed in most alert dashboards right now, the time to define your standards isn’t after the next incident.

Reflectiz Policies is available now for Pro and Enterprise customers. [Schedule a demo →]

FAQs

Can different pages have different policy tiers in Reflectiz?

Yes. Reflectiz Policies allows organizations to apply different enforcement tiers to different page types within the same environment. A financial institution can run Restricted controls on checkout and authenticated pages while applying Secured settings to marketing properties — all within a single platform, without managing separate tooling stacks per property.

How does Reflectiz Policies differ from standard web security monitoring?

Standard monitoring detects and alerts. Reflectiz Policies adds a standards layer on top of detection: you define what’s acceptable for each page type and vendor category, and the platform auto-approves compliant activity while escalating only genuine policy violations. The result shifts security reporting from raw alert counts to objective posture metrics.

How does Reflectiz Policies handle multi-site or multi-brand environments?

Reflectiz Policies is designed for organizations managing multiple websites, brands, or regional properties. A single policy framework applies across the entire portfolio, eliminating the inconsistency that arises when individual teams maintain their own informal rules. Castore, for example, uses Policies to manage security governance across 30+ professional sports team storefronts without requiring per-site manual oversight.

How does Reflectiz Policies reduce alert fatigue?

By auto-approving any script behavior that conforms to the defined policy tier, Reflectiz Policies eliminates manual review for up to 90% of routine alerts. Only activity that genuinely violates the defined standards escalates for human review — so instead of triaging 200 undifferentiated notifications per week, security teams act only on confirmed policy breaches.

How does Reflectiz Policies support PCI DSS and GDPR compliance?

Reflectiz Policies provides documented, enforceable standards for which applications can access payment and PII data, what behaviors are permitted on checkout and authenticated pages, and how vendor access is governed across the site. This gives compliance and audit teams a concrete posture record — defined standards, enforcement logs, and a scoring system showing current gaps — rather than a list of raw alerts.

What are the three enforcement tiers in Reflectiz Policies?

Reflectiz Policies offers three tiers. Secured provides baseline protection with automated checks for common risks, permitting verified first-party and analytics tools without restriction. Enforced applies moderate controls — external data transfers require approval, and new third-party scripts on authenticated pages trigger review. Restricted enforces the strictest controls: no external data transfers from sensitive pages, and any unrecognized script triggers an immediate alert regardless of vendor.

What is Reflectiz Policies and what problem does it solve?

Reflectiz Policies is a governance layer within the Reflectiz platform that turns a security team’s risk appetite into automatically enforced web security standards. It solves the gap between having visibility into third-party script activity and actually enforcing consistent, measurable standards — replacing manual alert triage with automated compliance against self-defined benchmarks.

What is the audit preview feature in Reflectiz Policies?

Before any policy goes live, Reflectiz provides an impact preview showing exactly which violations the chosen settings would trigger across the current environment. This allows security teams to calibrate their standards — tightening or relaxing tiers — without risking unintended disruption to live site operations.

What is the Sensitive Zones policy area in Reflectiz?

Sensitive Zones is one of three policy areas in Reflectiz Policies. It specifies the security arrangements required for high-risk pages — including checkout, login, and authenticated sessions — as well as standards for non-sensitive pages. Organizations define what script behaviors, data transfers, and vendor access are permissible on each page type, and the platform enforces those rules automatically.

Reflectiz Policies: Your Security Standards, Automatically Enforced was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

A threat actor had gained unauthorized access to MongoDB corporate systems. Customer account metadata had been exposed. For some customers, phone numbers and email addresses. For one customer, system logs.

Lena Smart was MongoDB’s CISO. She had been warning her team for years that the question was never whether a breach would happen. It was whether you’d know about it fast enough to matter, and whether the systems you’d built could limit the damage when it did. The MongoDB breach became one of the more studied incident response cases of that year, not because of what was stolen, but because of how quickly it was detected, contained, and disclosed. The kind of outcome that only happens when someone has spent years building toward it before the attackers show up.

That is the gap that separates good security leadership from reactive security theater.

Every year on June 4, National CISO Day, the industry takes a moment to recognize the people carrying that weight. The role has transformed. CISOs are the people who sit in front of boards, advise on acquisitions, shape product decisions, and make the case for why security is a business driver, not a cost center. The best ones have moved the conversation from threat chasing to exposure management, from quarterly audits to continuous visibility, from locking the door after the break-in to understanding what was exposed before anyone tried to get in.

We built this list around one question: whose thinking actually changes how organizations approach security? Not the loudest voices but the CISOs whose frameworks, research, writing, and public work make the people who follow them genuinely better at the job.

These 10 have done that. They have led security programs at some of the world’s largest platforms, written the books that practitioners carry into boardrooms, built the mental models that security teams use to think about exposure, and held the line in rooms where the pressure to cut corners was enormous.

If you are responsible for web security, application security, third-party risk, or understanding what is actually exposed on your attack surface, some version of their thinking is already shaping how you work. Whether you know it or not.

10. Sounil Yu

Platform: LinkedIn, X

Focus: Security frameworks, AI safety, Cyber Defense Matrix, exposure mapping, third-party risk quantification

Sounil Yu spent years watching security teams buy tools they could not evaluate, build programs they could not measure, and respond to threats they could not map. So he built a framework to fix it.

The Cyber Defense Matrix is now used by CISOs at some of the world’s largest organizations to map their security capabilities against real attack vectors, identify coverage gaps, and make purchasing decisions based on what they actually need rather than what vendors are selling. It is one of the most practical frameworks to emerge from the practitioner community in the last decade, and it was built entirely from the experience of someone who had lived the problem.

Sounil served as CISO at JupiterOne and Chief Security Scientist at Bank of America, and now co-founds Knostic, focused on AI safety in enterprise environments. He has also served as CISO-in-Residence at YL Ventures, advising security startups from the buyer’s side of the table.

Why his voice matters:

The Cyber Defense Matrix maps security capabilities against actual attack vectors, which means it maps directly to the exposure problem. It forces teams to ask not what tools they have, but whether those tools cover the things attackers will actually exploit. In a world where third-party scripts, web supply chain risk, and client-side exposure are routinely invisible to traditional security stacks, that kind of structured gap analysis is exactly what most organizations are missing.

What makes him influential:

He built a tool the industry needed before the industry knew it needed it. The Cyber Defense Matrix is now part of how serious security programs think about coverage. His move into AI safety signals where the next exposure frontier is. When Sounil Yu publishes thinking, practitioners pay attention because it tends to arrive about two years before the rest of the industry catches up.

9. Lena Smart

Platform: LinkedIn

Focus: Cloud security, enterprise risk, security culture, developer-integrated security, board communication

Lena Smart left school at 16 in Scotland, started her career in a single-parent household without university access, and worked her way from tech support to CISO of a $16 billion company. That path matters not because it is unusual, but because it shaped how she thinks about security: practically, from the ground up, with no patience for theater.

As CISO at MongoDB, she built a security program inside one of the fastest-scaling database companies in the world, where the pressure to ship fast always competed with the pressure to ship safely. She also led the response to MongoDB’s 2023 security incident, which became a reference case for how disclosure and containment should work. Before MongoDB, she served as Global CISO at Tradeweb and as CIO and Chief Security Officer at the New York Power Authority, the largest state power organization in the country. She is a founding member of Cybersecurity at MIT Sloan, a collaborative body connecting academia and private sector security leadership.

Why her voice matters:

Lena has spent her career securing platforms where third-party integrations, cloud dependencies, and developer velocity are all in constant tension with security posture. Her thinking on how to maintain visibility across a fast-moving engineering organization is directly relevant to the challenge of web supply chain risk, where the code your team did not write and cannot fully see is often the code that gets exploited.

What makes her influential:

She talks about security the way practitioners actually experience it, without the abstraction that makes so much CISO content useless on the ground. Her Security Champions program at MongoDB, which trained cross-functional employees to identify and raise security issues, became a model for embedding security culture without slowing development. She is one of the rare CISOs whose thinking translates directly from the boardroom to the engineering team.

8. Alyssa Miller

Platform: LinkedIn, X, Blog

Focus: Application security, DevSecOps, penetration testing, risk communication, security leadership

Alyssa Miller bought her first computer at 12 and taught herself to hack. Her career started as a penetration tester in financial services, moved through application security consulting, and arrived at the CISO seat at Epiq Global, where she now leads security for a global legal services company operating in some of the most heavily regulated environments in the world. She is also the author of Cybersecurity Career Guide and a pilot.

She is known for bridging two worlds that often fail to connect: the technical depth of offensive security and the business language of executive leadership. Her content does not choose between those audiences. It holds both, which is why practitioners and CISOs follow her in roughly equal numbers.

Why her voice matters:

AppSec is where web exposure lives at the code level. The vulnerabilities that enable client-side attacks, script injection, API misconfiguration, and third-party library risks are not sophisticated zero-days. They are insecure development practices that survive because security and engineering never learned to speak the same language. Alyssa has spent her career closing that gap. Her work on developer-integrated security directly addresses the upstream source of most web exposure.

What makes her influential:

She is one of the most authentic voices on what it actually feels like to be a security leader, not the conference-keynote version, but the version that involves difficult board conversations, resource constraints, and decisions made with incomplete information. Her X presence and LinkedIn content consistently generate real conversation rather than engagement-bait. Over 20 years of practitioner experience means that when she offers a framework or a take, it has been stress-tested against reality.

7. Joanna Burkey

Platform: LinkedIn

Focus: Enterprise cybersecurity transformation, board-level security governance, diversity in technology, risk management, digital transformation

Joanna Burkey spent years at HP Inc., one of the world’s largest technology companies, running a global security program that spanned endpoints, infrastructure, supply chain, and product security across dozens of countries. She has lived and worked in both the US and Europe, which gives her a more expansive view of regulatory complexity than most of her peers. She holds a computer science and mathematics background from Angelo State University and the University of Texas Austin, and a certificate in Finance and Accounting from Stanford GSB.

Since leaving the CISO seat at HP Inc., she has moved into board governance, serving as an independent director at Beyond Inc. and CorVel Corporation, and as chair of the risk and compliance committee at ReliabilityFirst. She was named to the Top 100 CISOs list in 2022 and has been published in Tribe of Hackers: Security Leaders. She is a fellow at the Center for Strategic and International Studies in Washington DC.

Why her voice matters:

HP’s security program under Joanna encompassed endpoint security, supply chain risk, and product security at a scale that few CISOs ever manage. Her experience securing a company that both produces and depends on third-party technology gives her a distinctive view of where supply chain exposure actually accumulates. Her move into board governance means she is now translating that operational experience into the language that determines security budgets and priorities at the highest level.

What makes her influential:

She represents where the most effective security leadership is headed: out of the technical silo and into the rooms where business decisions are made. Her writing and speaking on how CISOs should communicate with boards is practical, direct, and based on having sat on both sides of that table. In a field that often treats board communication as a soft skill, Joanna treats it as a technical discipline.

6. Michael Coates

Platform: LinkedIn, X

Focus: Web application security, browser security, OWASP, AppSec, platform security at scale

Michael Coates is the only person on this list who has served as CISO at three different platforms, and two of them are browsers or browser-adjacent: Mozilla, which builds Firefox, and Twitter, where he was the inaugural CISO. He later served as CISO at CoinList before co-founding Altitude Networks, a cloud data security company acquired in 2022. He now runs Seven Hill Ventures, a cybersecurity venture firm, and previously chaired OWASP, the largest nonprofit in the world focused on software security.

His career started on the offensive side. Before becoming a CISO, he was a hands-on hacker, breaking into banks, governments, and telecoms to find vulnerabilities before attackers did. That background never left him. He thinks about security the way attackers do, and his public writing reflects it.

Why his voice matters:

Mozilla and Twitter are two of the most attack-targeted platforms on the internet. Securing them requires a deep understanding of how client-side code executes, how browser behavior creates exposure, and how third-party integrations introduce risk that internal teams cannot fully control. His tenure at OWASP, the organization that defined the standards for web application security, means his thinking shaped how an entire generation of security practitioners was trained. That institutional influence is still active in every OWASP Top Ten list and every AppSec program that traces its methodology back to that work.

What makes him influential:

He brings the attacker’s perspective to executive security leadership, which is rarer than it should be. His current work backing early-stage security companies means he is evaluating the next generation of security tools from a position of deep practitioner experience. When he writes about web security or application risk, it is not theory. It is the lived experience of someone who has been inside some of the most complex attack surfaces on the internet and responsible for their defense.

5. Alex Stamos

Platform: LinkedIn, X

Focus: Platform security at scale, web application security, privacy enforcement, AI security, election security

Alex Stamos resigned from Yahoo as CISO after the company complied with a classified government order to scan all incoming email on behalf of U.S. intelligence agencies. He had not been consulted. When he found out, he tried to quit. That decision, choosing users over compliance with a surveillance request, defined how the security community came to see him: as someone who treats user protection as a genuine obligation, not a marketing position.

He went on to serve as Chief Security Officer at Facebook, where he led the company’s investigation into Russian interference in the 2016 election, testified before government committees on six continents, and oversaw security for 2.5 billion people across Facebook, Instagram, and WhatsApp. He later co-founded the Krebs Stamos Group with Chris Krebs and joined Stanford to found the Internet Observatory. He now serves as Chief Security Officer at Corridor, an AI security startup focused on preventing vulnerabilities from being introduced by AI-generated code.

Why his voice matters:

Facebook’s security program under Alex operated at a scale and complexity that almost no other organization has ever faced. The challenge of securing a platform where billions of users interact with third-party content, external applications, and data-sharing integrations is, in many ways, the purest version of the web exposure problem. His willingness to confront uncomfortable truths publicly, about his own organization’s failures, about what platform security actually requires, has made his perspective unusually valuable to practitioners who are tired of the sanitized version.

What makes him influential:

He combines operational depth with intellectual honesty in a field that does not always reward the latter. His Stanford work on AI security and election integrity has shaped how policymakers and technologists think about the next generation of platform risks. His move to Corridor signals where he believes the exposure frontier is moving: AI-generated code that developers cannot fully audit, running in production environments, with vulnerabilities baked in from the moment it was written.

4. Allison Miller

Platform: LinkedIn

Focus: Payments security, fraud prevention, real-time risk detection, platform trust, privacy

Allison Miller has spent 20 years building the systems that protect transactions, platforms, and people at internet scale. Her career ran through Visa, PayPal, Bank of America, Google, Electronic Arts, and Reddit, where she served as CISO and VP of Trust. The “Trust” in her title at Reddit was deliberate. Her view of security has always been broader than the technical perimeter: it encompasses fraud, safety, privacy, and the user-facing integrity of the platform itself.

She now runs Cartomancy Labs, an advisory firm focused on the intersection of people, money, and technology. She is one of the few security executives who has built and led real-time risk prevention systems operating at genuine internet scale, the kind of systems that make decisions in milliseconds about whether a transaction is legitimate or a session is compromised.

Why her voice matters:

The overlap between her career and Reflectiz’s world is direct. Payments security, third-party risk, web skimming, PCI compliance, and the exposure of checkout environments are all areas where her experience is immediately applicable. She has spent two decades building defenses for exactly the kind of web surface that Magecart attacks, third-party script abuse, and client-side skimming exploit. Her work at Reddit on platform trust also gives her a distinctive view of how third-party integrations create exposure that security teams cannot see from the inside.

What makes her influential:

She is one of the clearest thinkers in security about what it actually means to protect users, not just systems. Her framing of trust as a technical discipline, something that has to be engineered and measured, not assumed, reflects a maturity that most security programs are still working toward. Her advisory work at Cartomancy Labs means that thinking is now reaching a much wider range of organizations than any single employer could.

3. Rinki Sethi

Platform: LinkedIn, X

Focus: AppSec, enterprise risk, cloud security, security culture, Zero Trust, critical infrastructure

Rinki Sethi’s career reads like a tour of the most demanding security environments in the technology industry. She has served as CISO at Twitter, Rubrik, and IBM, and in senior security roles at Palo Alto Networks, Intuit, eBay, Walmart, and PG&E. She was one of the co-developers of the first national cybersecurity badge curriculum for the Girl Scouts of America. She now serves as Chief Security Officer at Upwind Security, a cloud security company that reported 4,000 percent year-over-year revenue growth in 2024.

At RSAC 2025, she joined a standing-room-only session on the surge of Chinese cyber campaigns targeting critical infrastructure, speaking alongside former NSA and DOJ leadership. Her framing was unambiguous: the air-gap mindset is no longer viable, Zero Trust must extend to operational technology, and the speed of AI-driven attacks has made manual SOC response inadequate at scale.

Why her voice matters:

Rinki has secured platforms that are simultaneously some of the most targeted and most complex environments in cybersecurity. Twitter’s scale and visibility made it a permanent target for nation-state actors, organized crime, and internal risk. Her experience at IBM and Palo Alto Networks adds enterprise and vendor-side depth that most CISOs lack. Her current work in cloud security at Upwind, focused on runtime-based detection rather than static scanning, reflects exactly the shift from reactive monitoring to continuous exposure awareness that defines the next generation of security programs.

What makes her influential:

She has held the CISO seat through some of the most difficult moments in recent platform security history and spoken publicly about what she learned. Her emphasis on AI-driven detection, resilient architecture, and operational readiness as active investments rather than aspirational goals is a practical framework that security leaders at any scale can apply. She is also one of the most active CISO voices on LinkedIn when major security events unfold, which means her commentary is reaching practitioners at exactly the moment they need it.

2. Myrna Soto

Platform: LinkedIn, X

Focus: Enterprise risk, compliance, board-level security governance, diversity in security leadership, financial sector security

Myrna Soto has been named to ALPFA’s 50 Most Powerful Latinas in Business list multiple times, ranked number one in 2019. She has also been CISO at some of the largest enterprises in America, including Comcast, where she served as Corporate SVP and Global CISO, and MGM Resorts International. Before that, she built security programs at American Express, Royal Caribbean, Norwegian Cruise Lines, and Kemper Insurance. She now advises boards, invests in cybersecurity companies through ForgePoint Capital, and serves on multiple public company boards.

Her background is unusual even by CISO standards. She holds a Master of Science in Industrial Psychology, an MBA, and a Masters Certification in Program Management. That combination of technical security depth, business strategy training, and behavioral science is not an accident. She has spent her career thinking about security as a human system, not just a technical one, and her approach to building security culture reflects it.

Why her voice matters:

Enterprise risk, regulatory compliance, and the gap between what boards think they understand about security and what they actually need to know are the areas where Myrna has spent 30 years. Her experience at Comcast, a company that operates as both a major internet infrastructure provider and a consumer platform with hundreds of millions of data touchpoints, gives her a view of third-party risk and web exposure at a scale that very few security executives have managed. Her current work advising boards means she is now translating that experience into the governance decisions that determine how seriously organizations take their exposure.

What makes her influential:

She has been right about the direction of enterprise security for three decades, and she has been willing to say it in rooms where the message was not always welcome. Her work on the intersection of compliance and real security, arguing that compliance frameworks often create the illusion of protection rather than actual risk reduction, is exactly the kind of structural critique that moves the industry forward. Her voice carries weight because it comes with receipts: decades of building and running programs that worked.

1. Phil Venables

Platform: LinkedIn, X, Blog

Focus: Cloud security, enterprise risk, AI security, third-party risk, security architecture at scale, CISO leadership frameworks

Phil Venables has been a CISO at four different organizations over 30 years. He was the first CISO of Google Cloud, where he built and led the global risk, security, compliance, and privacy teams from 2020 until 2025. Before Google, he served as CISO at Goldman Sachs for 17 years. Before that, CISO at Deutsche Bank. His career began in 1992 as an Information Security Manager at Barclays Bank.

He helped found the Center for Internet Security. He served on the President’s Council of Advisors on Science and Technology under two administrations. He advises the Bank of England, the Monetary Authority of Singapore, and the Port Authority of Singapore. He is now a Venture Partner at Ballistic Ventures and a strategic security advisor at Google, where he continues to publish one of the most read CISO blogs anywhere on the internet.

His writing does not operate at the level of buzzwords. It operates at the level of engineering discipline. Posts on API security, cloud architecture, third-party risk quantification, and how to translate security posture into terms that boards can act on are the kind of content that practitioners save and return to. He is, by most measures, the most credible CISO voice currently active on the internet.

Why his voice matters:

Google Cloud’s security program, under Phil’s leadership, had to solve the exact problems that define modern enterprise exposure: API security at scale, third-party risk across a global supply chain of cloud dependencies, client-side encryption, continuous threat monitoring across millions of customer environments. His thinking on these problems is the product of decades of practitioner experience at the highest levels of the industry. His blog posts on exposure management, cloud security architecture, and the evolving role of the CISO are not thought leadership in the marketing sense. They are working documents from someone who has built the systems he is writing about.

What makes him influential:

He is one of a very small number of people who can write with equal authority about the technical architecture of a security program and the governance structures that make it sustainable. His thinking on the CISO role, specifically on how the role is evolving from technical overseer to Chief Digital Risk Officer, is shaping how organizations define the position and what they expect from the people who hold it. After 30 years at the forefront of enterprise security, his perspective on what actually moves the needle is the perspective the rest of the field is still trying to catch up to.

Why These Voices Changed Security

These ten CISOs did not build their influence by posting more than everyone else. They built it by being right about things that mattered before the rest of the industry caught up.

They built the frameworks that practitioners use to think about coverage gaps. They secured the platforms that attackers spent years trying to break. They wrote the books that security engineers carry into job interviews and board presentations. They held the line when the pressure to cut corners was enormous, and then wrote about what that experience actually taught them.

They proved, collectively, that the most dangerous risk is the one you cannot see. Not the attack that triggers your alert. The exposure that already existed before anyone started looking. A misconfigured API. A third-party script with access it was never supposed to have. A checkout flow that passes every compliance scan and still leaks payment data to a domain no one recognized.

That is the problem these voices have spent their careers defining, measuring, and working to solve. Not chasing threats after the fact. Eliminating the exposure that makes threats possible in the first place.

Every tool reacts to attacks. The real risk lives in your exposure.

FAQs

How did Alex Stamos’s resignation from Yahoo and his work at Facebook define his influence?

Alex Stamos (ranked #5) resigned from Yahoo as CISO after the company complied — without consulting him — with a classified government order to scan all incoming email on behalf of U.S. intelligence agencies. This decision, choosing user protection over compliance with a surveillance request, shaped how the security community views him.

At Facebook, he led the investigation into Russian interference in the 2016 election, testified before government committees on six continents, and oversaw security for 2.5 billion people across Facebook, Instagram, and WhatsApp. He later co-founded the Krebs Stamos Group, founded Stanford’s Internet Observatory, and now serves as CSO at Corridor, an AI security startup focused on vulnerabilities introduced by AI-generated code.

What criteria were used to select the ten CISOs on this list?

The list was built around a single question: whose thinking actually changes how organizations approach security? The criteria explicitly excluded volume — “not the loudest voices” — in favor of CISOs whose frameworks, research, writing, and public work make practitioners who follow them genuinely better at the job.

The specific areas of relevance stated are web security, application security, third-party risk, and attack surface visibility. The profiles emphasize practitioners who built the mental models security teams use today, held the line under pressure to cut corners, and then wrote publicly about what those experiences actually taught them.

What distinguishes Allison Miller’s security philosophy and why is it relevant to payments and PCI compliance?

Allison Miller (ranked #4) spent 20 years building fraud prevention and risk systems at Visa, PayPal, Bank of America, Google, Electronic Arts, and Reddit, where she served as CISO and VP of Trust. Her career is distinguished by building real-time risk prevention systems that make decisions in milliseconds about whether a transaction or session is legitimate.

Her relevance to payments security and PCI compliance is direct: she has spent two decades building defenses for exactly the web surfaces that Magecart attacks, third-party script abuse, and client-side skimming exploit. Her broader contribution is framing trust as a technical discipline — something engineered and measured, not assumed — which applies directly to checkout security and third-party risk in web environments.

What is Myrna Soto’s critique of compliance frameworks and why does it matter for enterprise security?

Myrna Soto (ranked #2) has served as CISO at Comcast and MGM Resorts International and built security programs at American Express, Royal Caribbean, Norwegian Cruise Lines, and Kemper Insurance. She now advises boards and invests in cybersecurity companies through ForgePoint Capital.

Her central critique is that compliance frameworks often create the illusion of protection rather than actual risk reduction — a structural argument she has made in rooms where the message was not always welcome. After 30 years building programs at enterprise scale, she holds that real security and compliance are not the same thing, and that organizations treating compliance as a security proxy are systematically underinvesting in actual exposure reduction.

What is Sounil Yu’s Cyber Defense Matrix and why does it matter for web exposure?

The Cyber Defense Matrix is a security framework developed by Sounil Yu (ranked #10) that maps an organization’s security capabilities against real attack vectors, helping CISOs identify coverage gaps and make purchasing decisions based on actual need rather than vendor marketing. It is now used by CISOs at some of the world’s largest organizations.

For web exposure specifically, the matrix forces teams to ask not what tools they have, but whether those tools cover what attackers will actually exploit — making it directly applicable to third-party scripts, web supply chain risk, and client-side exposure that traditional security stacks routinely miss.

What is the central argument of the article about what separates effective security leadership from “reactive security theater”?

The article argues that the defining difference between effective CISOs and reactive ones is the shift from threat-chasing to exposure management — from responding to attacks after the fact to eliminating the exposure that makes attacks possible in the first place. The MongoDB incident is used as the opening example: the outcome was good not because the breach was prevented, but because years of investment in detection and containment infrastructure meant it was discovered and disclosed quickly.

The article frames the most dangerous risk as “the one you cannot see” — a misconfigured API, a third-party script with unintended access, a checkout flow that passes every compliance scan but still leaks data to an unrecognized domain. The ten CISOs profiled are selected specifically because their work addresses this structural problem: continuous visibility, third-party risk, and web supply chain exposure, rather than perimeter defense and incident reaction.

What positions have Rinki Sethi held and what is her stance on AI-driven threats and Zero Trust?

Rinki Sethi (ranked #3) has served as CISO at Twitter, Rubrik, and IBM, and in senior security roles at Palo Alto Networks, Intuit, eBay, Walmart, and PG&E. She is currently CSO at Upwind Security, a cloud security company focused on runtime-based detection.

At RSAC 2025, she argued that the air-gap mindset is no longer viable, that Zero Trust must extend to operational technology, and that AI-driven attacks have made manual SOC response inadequate at scale. Her position is that AI-driven detection, resilient architecture, and operational readiness are active investments — not aspirational goals — and that runtime-based detection is more effective than static scanning for modern cloud environments

What security frameworks and roles across the industry has Michael Coates held, and how does his background shape his thinking?

Michael Coates (ranked #6) has served as CISO at Mozilla (which builds Firefox), Twitter (as inaugural CISO), and CoinList. He previously chaired OWASP, the largest nonprofit in the world focused on software security. He now runs Seven Hill Ventures, a cybersecurity venture firm. His career began as a hands-on penetration tester breaking into banks, governments, and telecoms.

His offensive security background gives him an attacker’s perspective at the executive level, which his public writing reflects. His OWASP chairmanship means his thinking shaped how an entire generation of practitioners was trained — the OWASP Top Ten list and its AppSec methodology trace directly to that institutional influence.

What was notable about MongoDB’s 2023 security incident and Lena Smart’s response?

In December 2023, a threat actor gained unauthorized access to MongoDB corporate systems, exposing customer account metadata including phone numbers and email addresses for some customers, and system logs for one. MongoDB CISO Lena Smart (ranked #9) led the response, which became a widely studied incident response case — not because of what was stolen, but because of how quickly it was detected, contained, and disclosed.

Smart had previously built a Security Champions program at MongoDB that trained cross-functional employees to identify and raise security issues without slowing development. The incident response outcome is attributed to the years of security infrastructure built before the breach occurred.

Who is ranked #1 on Reflectiz’s Top 10 Most Influential CISOs list and why?

Phil Venables ranks #1. He has served as CISO at four organizations over 30 years, most recently as the first CISO of Google Cloud (2020–2025), and previously as CISO at Goldman Sachs for 17 years. He helped found the Center for Internet Security, has advised the Bank of England and the Monetary Authority of Singapore, and served on the President’s Council of Advisors on Science and Technology under two administrations.

His influence stems from combining deep technical authority — writing substantively on API security, cloud architecture, and third-party risk — with the governance frameworks that translate security posture into board-level decisions. He is described as “the most credible CISO voice currently active on the internet.”

If you are responsible for securing your organization’s web presence, you already know the exposure surface has changed. The scripts, third-party tools, and integrations running on your site are often invisible to traditional security stacks — but not to Reflectiz. Discover how Reflectiz protects your website from web exposure risks, client-side threats, and third-party script vulnerabilities.ost Influential CISOs to Follow in 2026.

10 Most Influential CISOs to Follow in 2026 was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Not a single CISO has full visibility into how AI is operating across their organization. Not one.

That's the headline finding from Pentera's AI Security & Exposure Benchmark 2026 – a survey of 300 U.S. CISOs and senior security executives – and it should give every web security team pause. Because a significant share of that invisible AI isn't hiding deep in cloud infrastructure or internal networks. It's running on your website, right now, in your customers' browsers.

AI Is Everywhere. Visibility Is Not.

66% of CISOs report limited visibility into AI usage across their environments, acknowledging shadow AI as a known and ongoing issue. The remaining 33% consider themselves relatively well-informed. But still expect unauthorized or unmanaged AI activity within their environments. Zero reported full visibility with no shadow AI present.

This isn't a governance edge case. It's the baseline condition of enterprise AI adoption in 2026.

Shadow AI is usually discussed in terms of employees using unsanctioned tools like ChatGPT or niche AI platforms. But the less-discussed dimension is what happens when AI capabilities are quietly introduced through software already embedded in your environment. Third-party pixels, analytics scripts, session-replay tools, recommendation engines, and ad-tech integrations are all examples of code executing on your web properties that can carry AI-powered data collection, behavioral profiling, or unauthorized data processing — without ever triggering an internal procurement review.

Reflectiz continuously monitors exactly this layer. The Reflectiz platform maps every script and third-party integration running across your web properties, detecting behavioral changes and unexpected data flows in real time — the kind of activity that never appears in a network log or SIEM alert.

Legacy Controls Are Covering AI Risk. Badly.

75% of CISOs rely on traditional endpoint, cloud, application, or API security tools (originally designed for other attack surfaces) to protect their AI ecosystems. Only 11% have security tools built specifically for AI.

This pattern is familiar. It mirrors what happened when organizations tried to stretch legacy perimeter defenses over cloud environments, or endpoint tools over mobile. The attack surface moved; the controls didn't.

Client-side web environments are a textbook example of this mismatch. WAFs, SIEMs, and DLP solutions monitor what crosses your network perimeter. They have no visibility into what happens inside a browser session: which scripts execute, what data they access, where that data goes, and whether any of that behavior changed since yesterday.

When a third-party tool begins routing sensitive session data to an unexpected domain, whether due to supply chain compromise or a deliberate vendor-side change, it happens entirely within the client-side execution context. Most of the security stack never sees it.

Reflectiz has documented exactly this type of incident in real enterprise environments, including cases involving payment card data with direct PCI DSS implications.

Web-Facing Assets Are the #1 Breach Entry Point

When the report asked CISOs which parts of their infrastructure were compromised in successful attacks, web-facing assets ranked first, cited in 62% of breach incidents, ahead of endpoints (60%), identity and access controls (53%), and cloud infrastructure (46%).

The report also shows that attackers don't stop at the entry point. Once a foothold is established through a web asset, movement continues toward identity systems, APIs, cloud infrastructure, and in 18% of incidents, AI ecosystems directly.

Protecting web-facing assets isn't just about preventing initial access. It's about closing the gateway through which broader, deeper compromise becomes possible.

The Barrier Is Visibility and Expertise, Not Budget

The report identifies the top two barriers to securing AI as lack of internal expertise (50%) and limited visibility into AI usage (48%). Only 17% cite budget constraints as their primary challenge.

The problem isn't resources; it's the foundational work of understanding, governing, and monitoring AI systems already embedded across the enterprise.

This maps directly to what security teams face on the client side. Most organizations lack a clear inventory of every third-party script running on their websites, let alone visibility into how those scripts behave session-to-session. Reflectiz delivers that inventory automatically and continuously, without requiring code changes or agent deployment, thus closing the visibility gap without adding to the operational load of an already stretched team.

Continuous Validation Is What Builds Confidence

The report frames Continuous Threat Exposure Management (CTEM) as the operating model best suited to the AI era, moving from point-in-time assessments to ongoing validation across the full attack surface. And the data backs it up: CISOs at organizations that test quarterly report higher AI security confidence (80%) than those who test annually (71%).

Confidence comes from continuous validation, not assumptions.

Reflectiz operates on the same principle. Web exposure isn't a status you establish once, it's a condition that requires continuous monitoring, because third-party scripts change, vendors update their code, and supply chains shift without warning. For organizations working toward PCI DSS 4.0.1 compliance, which now mandates controls for scripts on payment pages, that continuous monitoring isn't optional hygiene. It's a regulatory requirement.

The Pentera report makes clear that the security challenges of the AI era are not fundamentally new. They are existing problems: incomplete asset visibility, legacy controls stretched beyond their design, fragmented ownership, inconsistent validation – amplified by the speed and scale of AI adoption.

Solving them requires looking in the right places. On the web, that means the client side.

See what's running on your website right now. Start your 30-day free trial at reflectiz.com

The AI Visibility Gap Is Real – And It Lives on Your Website was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

At a Glance

• Customer: Broadway Gaming Group
• Industry: Online Gaming (Bingo & Casino)
• Challenge: Meet new PCI DSS 4.0.1 script security requirements (6.4.3 and 11.6.1) without diverting development resources.
• Solution: Reflectiz PCI DSS compliance solution.
• Results:
• Passed first PCI DSS 4.0.1 audit with zero observations.
• Audit evidence exported cleanly, with AI-assisted script justifications.
• Full script visibility across all payment pages, with no internal dev burden.

The Challenge: New Requirements, One Checkout Page, for Many Brands

Broadway Gaming Group is a Dublin-based online gaming operator with many bingo and casino brands in the UK and Ireland.

When CISO Kfir Tzukrel reviewed the PCI DSS 4.0.1 requirements — specifically 6.4.3 and 11.6.1 — he knew the company had a problem. All brands funnel customers through the same checkout page, creating a concentrated, high-value target for client-side attacks.

The new requirements demand that organizations:

• Maintain a complete, justified inventory of all scripts on payment pages.
• Continuously monitor those scripts for unauthorized changes.

Kfir explored building an in-house solution but quickly ruled it out. The development team was candid: it was technically possible, but prohibitively expensive and a massive distraction. As Kfir put it, “If I’d made them do it, they wouldn’t have had time for anything else.”

Why Reflectiz? The Risk Was Real

For Kfir, this wasn’t a theoretical compliance exercise. Earlier in his career, the FBI showed up at one of his employer’s US sites to report malicious activity in their payment process — later identified as a Magecart attack.

That experience shaped his vendor selection criteria. Third-party scripts represent genuine, documented risk, and meeting the new PCI requirements wasn’t just about satisfying auditors — it was about real-time protection at scale.

After evaluating options, Kfir chose Reflectiz, citing both product fit and confidence in the team: “I had good vibes from talking to Idan [Reflectiz CEO]. I decided to go with who I felt most comfortable with.”

Reflectiz stood out for three reasons:

• Agentless Architecture: No agent installation, no disruption to payment flows or existing infrastructure.
• Broad Coverage: Monitors scripts across every page of a website — not just payment pages — preventing lateral movement from an attacker foothold elsewhere.
• Audit Readiness: Automated evidence generation, including AI-assisted business justifications for each script, aligned directly with PCI DSS 4.0.1 examiner requirements.

Implementation: Intuitive From Day One

Onboarding was straightforward. Kfir got up to speed quickly, then brought in the development group manager and tech lead to handle script approvals — a role that required minimal ramp-up time given how intuitive the platform is.

“It was very intuitive to understand the management dashboard and to master it. Really easy and comfortable.” — Kfir Tzukrel, CISO / Broadway Gaming Group

Audit Success: Zero Observations

Broadway Gaming’s first PCI DSS 4.0.1 audit — the first year the script monitoring requirements were mandatory — went without a hitch.

Kfir walked the auditor through the Reflectiz dashboard live, exported the compliance report, and demonstrated the full script management workflow. The audit team had what they needed.

The AI-assisted justification feature proved particularly valuable:

“It could’ve taken us a lot of time thinking about what to write for the justifications for each script. You just let the AI suggest the wording, check that it makes sense, approve, and move on to the next. It was really comfortable.” — Kfir Tzukrel, CISO / Broadway Gaming Group

The Business Impact

• Developer Efficiency: Zero internal development resources consumed on compliance tooling.
• Audit Confidence: Clean, exportable evidence that satisfied Level One PCI scrutiny first time.
• Ongoing Protection: Continuous script monitoring across the full site surface, not just payment pages — closing the lateral movement risk that pure payment-page tools leave open.
• Low Maintenance: Minimal support needed; occasional sync sessions are all it takes to stay current.

The Bottom Line

Broadway Gaming’s experience shows that PCI DSS 4.0.1 compliance — even for organizations running many brands through a shared checkout — doesn’t have to mean a costly internal project or a fraught audit. With Reflectiz, Kfir got clean evidence, zero observations, and kept his development team focused on what actually grows the business.

“If you have to meet PCI requirements, it’s a no-brainer. PCI is hard, so it’s a must.” — Kfir Tzukrel, CISO / Broadway Gaming Group

How Broadway Gaming Achieved PCI DSS 4.0.1 Compliance was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just when you thought the desert was safe, the great worm has awakened again.

In September 2025 we covered the first Shai-Hulud npm supply-chain campaign. Two months later, on November 21, the attackers launched a far more aggressive second wave. Multiple vendors reported the outbreak on November 24, and as of November 25, 2025, there are hundreds of malicious package versions, with combined monthly downloads over 100 million, according to early vendor estimates, and the worm is still spreading at an alarming pace.

Over 25,000 GitHub repositories belonging to hundreds of maintainers have already been compromised, with new infections appearing every 30–40 minutes. The list of high-profile victims includes Zapier, ENS Domains, PostHog, Postman, and hundreds of others.

Why these targets? The attackers aren’t randomly carpet-bombing npm, they’re strategically hunting maintainers with broad publishing rights. A single compromised Zapier or Postman developer can poison dozens of high-trust packages in one stroke, cascading the infection to millions of downstream users. High-profile victims also generate less suspicion when publishing updates, making malicious versions harder to spot in the noise.

This is not a repeat offender. This is an escalation, so let’s go through what’s changed.

TL;DR

New Shai-Hulud 2.0 wave hits npm in late November 2025, with hundreds of malicious package versions and nine‑figure monthly downloads.

Tens of thousands of GitHub repos and hundreds of maintainers are impacted, including large, well‑known projects.

Shai-Hulud 1.0 vs 2.0

2.0 moves from postinstall to preinstall, abuses a fake Bun environment plus Node, and spreads faster and more aggressively.

It adds self‑healing via GitHub search, more privilege‑escalation tricks, and a destructive fallback that may wipe home directories.

How the infection works

Trojanized npm packages run a preinstall chain (setup_bun.js, bun_environment.js), download TruffleHog, and hunt for secrets.

Stolen tokens and data are pushed to marked GitHub repos, new self‑hosted runners and workflows are deployed, and more malicious packages are published.

Indicators of compromise

Look for suspicious preinstall scripts invoking Bun/curl/wget and files like setup_bun.js, bun_environment.js, or verify.js.

Watch for odd self‑hosted runners, new workflows, and GitHub repos using the “Sha1Hulud: The Second Coming” beacon phrase or similar markers.

Immediate mitigation steps

Pin dependencies to safe versions, guided by current dates and curated IOC/package lists.

Hunt for IoCs across dev and CI, rotate all exposed credentials, remove rogue runners/workflows, and enforce MFA and scoped tokens.

Reflectiz

Traditional SCA alone cannot keep up with a fast‑moving, mutating worm like Shai‑Hulud 2.0.

Reflectiz provides behavioral monitoring that can detect anomalous install hooks, exfiltration attempts, and destructive behavior without adding agents.

Final word

Shai-Hulud 2.0 raises the stakes from stealthy theft to potential sabotage if blocked.

Teams should act before the next wave by tightening supply‑chain defenses and validating their visibility into npm and GitHub attack paths.

Shai-Hulud 1.0 vs 2.0 — What Changed?

The first Shai-Hulud campaign was already one of the most advanced npm supply-chain attacks on record, yet it was still primarily focused on stealthy credential theft and gradual propagation. The second wave is fundamentally different: it’s faster, more destructive, and engineered to survive cleanup attempts. What started as a sophisticated espionage operation has evolved into an aggressive, self-replicating worm that escalates to outright sabotage the moment its primary goals are blocked. The differences are not minor refinements; they represent a clear leap in both capability and malice. Here’s exactly how much worse Shai-Hulud 2.0 has become:

How the Infection Works — Step by Step

1. Victim runs npm install on a trojanized package.

2. The package’s preinstall script executes setup_bun.js → bun_environment.js.

3. Payload detects OS and runtime. It creates a fake “Bun” environment by dropping setup_bun.js and bun_environment.js — scripts that mimic Bun’s faster execution but actually run malicious Node.js code under the hood. This disguise helps evade detection tools looking for suspicious Node processes, since “bun run” appears benign in logs.

4. TruffleHog is downloaded and scans the local environment and mounted Git repositories for secrets (NPM tokens, AWS/GCP credentials, GitHub tokens, etc.).

5. Secrets are triple Base64-encoded (encode → encode → encode) to evade simple pattern-matching tools that flag base64 strings in GitHub commits. Each encoding layer makes the exfiltrated data look increasingly like random gibberish to automated scanners, buying the attackers time before detection.

6. The machine is registered as a self-hosted GitHub Actions runner by dropping shaihuludworkflow.yml (or similar) into .github/workflows/.

7. Using any stolen NPM token, the worm publishes malicious versions of up to dozens of other packages the maintainer has access to.

8. If exfiltration or propagation fails for any reason → destructive payload wipes the user’s home directory (Linux/macOS/Windows).

Indicators of Compromise (IoCs)

• Suspicious preinstall scripts calling bun run, curl, or wget
• Files named setup_bun.js, bun_environment.js, verify.js
• New GitHub repositories with the description “Sha1Hulud: The Second Coming”
• Unexpected self-hosted runners appearing in your organization
• New workflow files, such as shaihuludworkflow.yml or shai-hulud-workflow.yml
• Outbound connections to webhook.site or other temporary paste services

Immediate Mitigation Steps

1. Pin all dependencies to versions published before November 21, 2025 (Note: pinning to versions “published before November 21, 2025” is based on current knowledge and that attackers could backdate or republish, so teams should also rely on curated IOC/package lists from trusted vendors and registries.)

2. Scan every workstation and build server for the IoCs listed above.

3. Rotate every credential that might have been exposed (NPM tokens first, then cloud + GitHub).

4. Delete and block any rogue self-hosted runners in GitHub Settings → Actions → Runners.

5. Enforce MFA and scoped tokens across npm and GitHub.

6. Use npm audit or Snyk/Dependabot to identify and remove infected package versions.

How Reflectiz Helps Stop This Attack in Its Tracks

Traditional SCA tools excel at finding known vulnerabilities, but Shai-Hulud 2.0 is a zero-day worm that mutates in real time — static scans alone can’t keep up.

Reflectiz provides behavioral monitoring that detects anomalous install hooks, secret exfiltration attempts, and destructive commands before they execute. Because it’s agentless, it catches supply-chain threats that traditional endpoint or SCA solutions never see.

Final Word

The desert never forgives the unprepared. Shai-Hulud 2.0 is faster, smarter, and willing to burn everything down if it can’t steal your secrets.

Don’t wait for the next wave; get ready for it.

Schedule a free Reflectiz supply-chain risk assessment today and make sure the worm never makes it past your gates.

Shai-Hulud 2.0: The Worm Returns — Bigger, Meaner, and Ready to Wipe Your Home Directory was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Between March 9 and March 11, 2026, attackers had a 48-hour window inside one of the most widely embedded JavaScript libraries on the internet. The AppsFlyer Web SDK — present in over 100,000 web and mobile applications — was quietly rewritten on AppsFlyer’s own CDN to steal cryptocurrency. No perimeter defense would have caught it. No WAF, no firewall, no endpoint agent. The attack lived entirely inside trusted third-party code running in your users’ browsers.

If you operate in fintech, e-commerce, crypto, or any vertical where users enter payment or wallet data, this one is worth your full attention.

AppsFlyer SDK Supply Chain Attack — What Happened?

Attackers injected malicious JavaScript into the AppsFlyer Web SDK hosted on AppsFlyer’s CDN — notably, not the mobile SDK. The compromised code intercepted cryptocurrency wallet addresses entered by end users, silently replacing them with attacker-controlled addresses while exfiltrating metadata: page URLs, timestamps, and user agents. The script continued to perform its legitimate analytics functions throughout, making it exceptionally difficult to detect through conventional means.

As of this writing, no stolen funds have been confirmed. But that’s not the point. The point is that for 48 hours, any business running this SDK was potentially serving malware to its own customers — and most had no way of knowing.

Why This Attack Is So Hard to Stop

This attack didn’t exploit a vulnerability in your code. It exploited your trust in someone else’s.

Developers embed the AppsFlyer SDK directly into their applications. Once integrated, it runs in the background with broad access to user activity and data flows — tracking installs, sign-ups, purchases, and campaign events. That access is what makes it valuable for analytics. It’s also what makes it a high-value target.

Traditional security controls failed here for a simple reason: the script source was already trusted. The malicious logic was heavily obfuscated within code your systems had been told was safe. Signature-based detection, SRI checks on a hash that was never flagged, allowlists — none of these catch an attack that originates from within the trusted source itself.

How Reflectiz Would Have Detected This

Reflectiz doesn’t ask “is this script allowed?” It asks: “Is this script behaving the way it should?”

Behavioral drift in a trusted SDK

The compromised AppsFlyer SDK kept doing its job while running additional malicious logic underneath. Reflectiz monitors runtime behavior continuously, so even when a script comes from a trusted source, it flags anomalies like:

• New or unusual outbound network connections
• External domains appearing for the first time
• Scripts executing logic outside their established behavioral baseline

Here’s what that looks like in practice: a Reflectiz customer running AppsFlyer would have seen an alert that the SDK had initiated connections to an unrecognized domain — something like analytics-appsflyr[.]com or a similarly disguised endpoint — within hours of the compromise. That alert would have been the earliest signal of something wrong, long before any vendor advisory.

Suspicious data flows on sensitive inputs

The injected code was designed specifically to intercept wallet addresses — a form of input that should never leave the page through a marketing SDK. Reflectiz maps data flows in real time and flags when sensitive user inputs are accessed or transmitted by scripts that have no business touching them. This shifts the detection model from access control to behavioral validation.

Hidden third-party dependencies

Supply-chain attacks routinely introduce secondary infrastructure — additional scripts, callbacks, or exfiltration endpoints — that weren’t part of the original integration. Reflectiz surfaces these by revealing which third parties an SDK is calling, whether new entities have appeared in the execution chain, and how far trust is being extended beyond your direct control. In this attack, that visibility would have exposed the malicious backend infrastructure operating behind AppsFlyer’s legitimate facade.

Script integrity monitoring

The simplest signal of all: the script changed. Reflectiz alerts on modifications to third-party scripts, behavioral differences between versions, and unexpected increases in code complexity or obfuscation. In a two-day attack window, real-time detection of a script change is often the difference between catching an incident and reading about it afterward.

The Broader Shift

The AppsFlyer incident follows a now-familiar pattern: Polyfill.io, Magecart, Ticketmaster/Inbenta. In each case, the attack vector wasn’t a misconfiguration or an unpatched CVE — it was trust. A trusted vendor, a trusted CDN, a trusted script.

The security perimeter has moved. It now extends to every third-party component running in your users’ browsers, and the only way to defend it is continuous monitoring of what those components actually do.

That’s what Reflectiz is built for.

If you’re unsure whether AppsFlyer or similar SDKs are running on your properties — and what they’re doing when they get there — request a free website scan.

FAQs

What was the AppsFlyer SDK supply chain attack?

Between March 9 and March 11, 2026, attackers injected malicious JavaScript into the AppsFlyer Web SDK hosted on AppsFlyer’s CDN. The compromised code intercepted cryptocurrency wallet addresses entered by users and replaced them with attacker-controlled addresses, while continuing to perform its normal analytics functions to avoid detection.

Which version of the AppsFlyer SDK was affected?

Only the web SDK was compromised. The mobile SDK was not affected. Businesses running the AppsFlyer JavaScript library directly on their websites were the exposed population.

Was any cryptocurrency actually stolen in the AppsFlyer attack?

No stolen funds have been confirmed as of this writing. However, the absence of confirmed theft doesn’t reduce the severity — the malicious code was live and capable of redirecting payments for approximately 48 hours across a vast number of websites.

Why didn’t traditional security tools catch this attack?

Because the attack originated from within a trusted source. WAFs, firewalls, endpoint agents, and allowlists are all predicated on identifying untrusted sources. When a script you’ve explicitly trusted is the one that’s been compromised, signature-based and perimeter-based controls have no basis on which to flag it.

What is a JavaScript supply chain attack?

A JavaScript supply chain attack occurs when an attacker compromises a third-party script or SDK that is widely embedded in other websites or applications. Rather than attacking a target directly, the attacker poisons a trusted dependency, effectively turning the vendor’s own infrastructure into a delivery mechanism for malicious code.

How can businesses detect compromised third-party SDKs at runtime?

By monitoring the behavioral output of scripts rather than just their source or signature. This means tracking what network connections a script initiates, what user inputs it accesses, what domains it communicates with, and whether its behavior deviates from an established baseline. Solutions like Reflectiz do this continuously and in real time.

What industries are most at risk from SDK supply chain attacks like this one?

Any vertical where users enter sensitive data through a browser is exposed — fintech, cryptocurrency exchanges, e-commerce, healthcare, and online gaming are the highest-risk categories. These sectors tend to run the most third-party analytics and marketing SDKs, which expands their attack surface significantly.

What is the difference between SRI checks and runtime behavioral monitoring?

Subresource Integrity (SRI) checks verify that a script matches a known cryptographic hash before it executes. They’re effective against unauthorized script substitution from external sources, but they fail when the compromise originates at the trusted source itself — as in the AppsFlyer case, where the CDN serving the script was the attack vector. Runtime behavioral monitoring operates after execution, flagging anomalous behavior regardless of where the script came from.

How quickly could an attack like this be detected with the right tools?

In the AppsFlyer case, behavioral monitoring would have surfaced the anomaly within hours of the compromise — likely through alerts on new outbound connections to unrecognized domains. The attack window was approximately 48 hours; early detection tools could have reduced exposure to a fraction of that.

How does this attack relate to Magecart and Polyfill.io?

All three follow the same attack pattern: compromise a trusted third-party component to deliver malicious code through legitimate channels. Magecart attacks target payment skimming; Polyfill.io involved a compromised open-source CDN affecting hundreds of thousands of sites; the AppsFlyer incident used a marketing SDK as the vector. The common thread is that trust in a vendor or CDN was weaponized against the businesses relying on them.

AppsFlyer SDK Exploited in New Supply Chain Crypto Attack was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Advertising on TikTok is the obvious choice for any company trying to reach a young market, and especially so if it happens to be a travel company, with 44% of American Gen Zs saying they use the platform to plan their vacations. But one online travel marketplace targeting young holidaymakers with ads on the popular video-sharing platform broke GDPR rules when a third-party partner misconfigured a TikTok pixel on one of its regional sites. An intriguing new case study reveals how Reflectiz, which discovered the problem stopped a data breach from becoming a costly flood.

For the full case study, click here.

Dangers Close to Home

Cyberattacks often make the headlines because hacking is a natural attention-grabber. The groups behind the attacks seem like modern-day highwaymen, shadowy figures who can rob countless victims from behind a mask of anonymity. Faceless criminals like these will always grab readers’ attention, and while this is understandable, we’d do well to pay attention to some of the less dramatic security risks that can be just as damaging.

It’s been said that if news outlets focused on reporting the biggest threats to our lives, then every story would cover heart disease and how to prevent it, because it kills many times more people than events like wars and car crashes. It’s the same with cyber threats. While big hacks make us sit up and take note, many breaches are caused by simple, mundane failures of ‘housekeeping’, and that’s what happened to the company featured in this new downloadable case study.

What Happened?

While we’re not going to name the global travel marketplace involved (to spare it any embarrassment), the cybersecurity company that caught the problem is called Reflectiz. Its main product is a platform with some innovative monitoring technology that presents its findings in a clear, intuitive dashboard. Under the hood it scans websites using a proprietary browser that mimics user behavior. It maps every third-party web app or code snippet that’s connected with the site, including objects embedded in iFrames, so if any code acts suspiciously or sends data somewhere that it shouldn’t, Reflectiz notices and alerts the user.

The case study details how one of its scans revealed a misconfigured TikTok pixel. TikTok has 1.6 billion users, so you’ve probably heard the name. If you haven’t, it’s a video sharing social media platform based in China that’s wildly popular amongst young people. When the travel company started using Reflectiz, it found that the pixel was collecting and sending sensitive user data to TikTok’s Chinese servers without their permission, because it hadn’t been implemented correctly.

While it doesn’t look like there was any malicious intent in this case, the big takeaway for companies of any size should be that it doesn’t change the outcome. Online businesses that release customer data without the express permission of users will still be in breach of data privacy regulations like GDPR and the regulator may see fit to sanction them.

For the full case study, click here.

The Cost of Non-Compliance

Non-compliance with GDPR (the General Data Protection Regulation) can lead to significant penalties:

• Fines: up to €20 million or 4% of annual global turnover, whichever is higher. The exact amount depends on the nature of the violation and the organization’s size.
• Reputational Damage: non-compliance can harm an organization’s reputation, causing loss of customer trust and potential business opportunities.
• Orders to Cease Processing: regulatory authorities can order the company to stop processing personal data, which can disrupt business operations.
• Compensation Claims: individuals affected by the breach may file claims for damages.
• Increased Scrutiny: non-compliant organizations may face more attention from regulators and could be subject to audits.
• Legal Costs: defending against claims or fines can incur significant legal expenses.

While that can all sound a bit hypothetical, regulators have been taking action. In one recent example, from June 2024, the Swedish Data Protection Agency (IMY) fined an online pharmacy 15 million Swedish kronor (approximately $1.45 million) for improperly using the Facebook Pixel. The pharmacy activated Facebook Pixel’s Automatic Advanced Matching (AAM) and Automatic Events (AE) features “by mistake,” which resulted in the transfer of sensitive personal data to Facebook/Meta. This inadvertent breach affected between 500,000 and a million individuals from 2019 to 2021.

For the full case study, click here.

The Solution

While we don’t know the exact scale of the breach in the travel company case study, we do know that Reflectiz caught the TikTok misconfiguration before it could do more damage, likely saving the company a fortune in fines and reputation loss.

Despite being so powerful, Reflectiz does not require installation. There is just a straightforward onboarding process that begins with a remote scan to map the entire web ecosystem. After that it continuously monitors all sensitive webpages and will detect and flag any suspicious activity by any web component.

The solution can identify third-party web components that track customers’ activities without their consent, including attempts to capture their geographical locations, or to use their cameras and microphones without consent. With so much at stake, no company can afford to risk being caught out by something as avoidable as a tracking pixel misconfiguration.

For the full story on this cautionary tale, download the full case study here.

TikTok Pixel Privacy Nightmare: A New Case Study was originally published in Reflectiz on Medium, where people are continuing the conversation by highlighting and responding to this story.