When we “trust” someone in business or our personal lives, we’re really giving up control. We typically default to giving the benefit of the doubt, but there’s always some level of doubt.

What does this mean for information technology (IT)? Recent breaches and published research findings reveal that even our most relied-upon providers can and do harbor unknown risks. From compromised open-source libraries to identity services handing out undocumented tokens, the third-party and supply-chain risks abound.  Without a solid strategy to deal with them, the security and operations teams look like Yosemite Sam firing off in every direction.

How do we reduce that doubt and create an environment of collaboration? Constantly verify that the other party is performing the duties as requested. This is more than outcomes. This is six sigma at heart, verifying the sausage is made to spec at all times, and there is minimal process deviation.

The solution is to strengthen our ability to trust with continuous validation. By applying Zero Trust principles, we know that every action is verified, monitored, and limited to what is necessary, based on risk. This is trust but verify… through a Zero Trust lens.

 

CASE STUDIES: When Trust Was Broken

NPM/”Shai-Hulud” Worm (2025)

In September 2025, the Node Package Manager (npm) ecosystem was hit by a sophisticated supply chain attack. A self-replicating worm, dubbed “Shai-Hulud,” compromised hundreds of npm packages.[1]

 

What Happened

A threat actor convinced developers to “update” their multi-factor authentication (MFA) login options, allowing the threat actor to gain access. Once obtained, the threat actor deployed a malicious payload that functioned as a worm that executes a post-installation script which scans the environment for sensitive credentials, including .npmrc files for npm tokens, environment variables, and configuration files, and API keys for cloud services like 2] AWS, GCP, and Azure.[3]

The harvested credentials were exfiltrated to an actor-controlled environment. The malware creates a new public GitHub registry under the victim’s account called “Shai-Hulud”, commits the stolen secrets to it, and exposes them publicly. Using the stolen npm token, the malware then authenticates to the NPM registry as the compromised developer.[4] It then identifies other packages maintained by that developer, [5] compromises them, and continues the process, spreading exponentially.

Customers who pulled vendors’ packages by default imported backdoors. Vendors had to rebuild and republish, all the while explaining to their own customers how they were impacted. The breach went from developer laptops through CI/CD pipelines, cloud accounts, and to downstream product consumers.

The point is pretty obvious, and it hurts. Packages that were approved and trusted were compromised at their source. The registry became the distribution channel for the attack, and every team that trusted it had to deal with the fallout.

Learnings

  • Trust based on code origin is not enough. Approved sources can be compromised post-approval. Verify signed code independently before use with SBOM[6] validation, dependency scanning, and signature checks.
  • Include integrity validation in token protections. Verify authentication tokens at the application or API gateway level.
      • Token claims, including audience, issuer, signature, expiry, and scope, require validation.
      • Use CDR or SIEM to detect replay, reuse, or scope changes.
      • Segment token scopes when creating API permissions to limit compromise
  • Dependencies must be treated as untrusted input in CI/CD pipelines.
    Validate all dependencies, vendor code, and AI-generated components before build and release.
  • Supply chain now includes developer identities and tokens. Depending on your risk, tighter controls, including hardware-backed MFA, scoped access, and build time verification, can be implemented to reduce credential abuse and limit the extent of compromise.
  • Monitoring and verification must be continuous CDR and SSPM integrations can be used to monitor registry, SaaS, and cloud activities to identify OAuth token abuse, privilege escalation

 

MICROSOFT ENTRA (Actor Tokens)

Identity systems are foundational to trust in the enterprise. When Microsoft Entra issued flawed “actor tokens” without adequate logs, trust in the identity provider was shaken. Core applications and services were suddenly exposed..

 

What Happened

The legacy Access Control Service (ACS), circa 2010 – 2018 but still used internally by Microsoft for service-to-service communication, especially Exchange Online and SharePoint, issued undocumented, unsigned JSON Web Tokens (JWTs), known as Microsoft Entra ID actor tokens.

In July 2025, a researcher discovered that because the actor tokens were unsigned and not validated through conditional access or tenant-scoped boundaries, they could be forged and accepted by legacy APIs, like the Azure AD Graph API. This meant that the tokens could be used to impersonate users and global administrators across tenants.

An attacker from a free-trial tenant was able to create a token that impersonates a user in another tenant. They did not validate the tenant origin in its scope, which allowed the request to be accepted. The result was unauthorized cross-tenant access and elevated privileges in the target tenant.

Actor tokens bypassed conditional access, produced no tenant logs since they were created in the trial tenant, and were valid for up to 24 hours. A compromise was essentially invisible in standard Entra or Microsoft 365 logs. Microsoft assigned CVE-2025-55241 and removed the ability to request actor tokens.

This challenge illustrated how complex system artifacts can remain long after deprecation, reminding all of us of the importance of systems and services lifecycle management.

Learnings

      • Even Tier-1 providers can make mistakes.
      • Identity tokens and session authentication must be independently verified. This means:
        • Validating token integrity (audience, issuer, expiry) within applications or gateways.
        • Enforcing short token lifetimes and requiring re-authentication with MFA for sensitive actions.
        • Monitoring token use with Cloud Detection & Response (CDR) or Security Information and Event Management (SIEM) for anomalies such as replay, unusual geographies, or abnormal scopes.
        • Segmenting token scopes so that compromise of one token cannot cascade across systems.
      • CDR must monitor identities, token behavior, and identify anomalies beyond the identity provider’s assurance.
      • Relying solely on the provider’s assurances leaves organizations blind when the provider itself is compromised.

 

 

CROWDSTRIKE OUTAGE/FAILURES

When CrowdStrike pushed a flawed update, it broke systems worldwide. Customers who had tied their endpoint visibility and control entirely to that single vendor suddenly lost both. Servers crashed, endpoints failed, and recovery became a scramble. The outage showed how fragile it can be to lean too heavily on one provider, even a leading security vendor.

 

What Happened

July 19, 2024, CrowdStrike’s Falcon sensor for Windows took a faulty update, causing large-scale system failures worldwide. When a malformed content file included in the update and distributed through Falcon’s cloud-based delivery service was installed, systems blue-screened.

Failures occurred before Windows could fully start, meaning remote management tools that could operate outside the OS, or manual intervention was required to repair or reimage the machines. 

The lesson is not that vendors will occasionally fail, but that vendor failure must be part of the threat model. Controls need to exist outside of the vendor’s own tools. Endpoint health should be monitored through independent sources such as configuration management, performance monitoring, or additional telemetry streams. Updates from a vendor should roll out in stages, with dev and test absorbing the risk before production.

 

Learnings

      • Vendor trust cannot replace independent monitoring and validation.
      • Plan for vendor failure:
        • Use staged rollouts (dev/test first, production later) to limit the blast radius of updates.
        • Continuously monitor service health and performance through sources independent of the vendor. This could include telemetry from endpoint monitoring, device configuration management, and performance management tools.
        • Run tabletop exercises that include vendor outages to identify operational challenges.
      • Validate in dev/test that vendor tools themselves are behaving correctly and haven’t been hijacked.

 

 

SALESLOFT/OAUTH PLUGIN ACCESS 

In September 2025, Mandiant confirmed that a compromise of the Salesloft Drift plugin had exposed OAuth tokens used by hundreds of organizations. The breach showed how dangerous and widespread third-party connectors can be when they hold broad permissions.

 

What Happened

In this case, a plugin that many companies trusted had access to sensitive data across hundreds of organizations, making it a juicy target. Once compromised, the attackers didn’t need to go after each company individually; the plugin itself became the entry point, giving attackers the keys to multiple databases at once.

The problem isn’t just this one plugin. It is the entire model of SaaS integrations that run on OAuth that are granted sweeping access to mailboxes, CRM records, and internal data. Once those tokens are issued, most environments have little visibility into what the integration is doing in real time.

Limiting damage starts with reducing the potential for impact. Vendor integrations, APIs, and plugins should only be granted the minimum permissions needed, nothing more. Administrative approvals for new connectors should not be left to a single person. Requiring privileged access management controls such as vault-backed secrets and two-person approvals makes it harder for a compromised account or a stressed-out person to approve a dangerous integration.

Monitoring is equally important. OAuth usage cannot be treated as “set and forget.” Tokens need runtime visibility. Unusual scopes, unexpected geographic activity, or spikes in requests should trigger alerts. Without this, a plugin can operate invisibly while exfiltrating data.

The Salesloft compromise underlined a basic truth: every plugin or extension connected to core systems is another potential breach point. Trusting them without continuous oversight is a mistake.

 

Learnings

      • Use the principle of least privilege (PoLP) for vendor integrations, APIs, plugins, and extensions.
        OAuth scopes are defined by the integration, not the user. Limit the permissions of the identities and service accounts used for these integrations instead of assuming the scopes themselves are safe.
        • Limit user or service account privilege: Issue tokens only from non-admin accounts with scoped roles. Refrain from using global admin or identities with high privilege for third-party connectors.
        • Use conditional access and risk scoring: Enforce device trust, IP reputation, and session controls for OAuth-based access, and apply the same policies as used for human users and agents.
      • Use a vault and enforce Two-Person Approvals with PAM for admins to accept and deploy new extensions and plugins.
      • OAuth usage needs runtime monitoring for oddities (unexpected scopes, geographies, rates) using Cloud Access Security Broker (CASB), CDR, or identity analytics solutions.

 

The How: Solutions Through a Zero Trust Lens

Code and Supply Chain Security

The risk isn’t only malicious code from the start. “Trusted” code can be compromised later. NPM packages, open-source libraries, and vendor updates all harbor risk.

 

Solutions:

      • SBOM (Software Bill of Materials) and Dependency Validation Require a SBOM from vendors and generate your own. Run static analysis, dynamic testing, dependency checks, secrets scanning, and license reviews in CI/CD. These checks must be continuous, not one-off. For practical examples of integrated SCA (Software Composition Analysis) and SBOM tooling, see the Appendix.
      • Signed Commits and Package Verification Enforce commit signing with Sigstore. Verify package signatures before builds. If the chain of trust breaks, block the build.
      • Runtime Monitoring Monitor deployed code for integrity issues. Application security monitoring, runtime instrumentation, and EDR should flag behavior that doesn’t match expectations.
      • Vendor Code Review Review vendor libraries and extensions on a schedule. Treat them like your own code. What was safe once may no longer be safe. When direct source access isn’t possible, use models that allow independent verification, such as vendor-executed Veracode scans, customer-run artifact analysis (JFrog Xray, Anchore), or shared GitHub, GitLab pipelines. Require vendors to provide verifiable, timestamped scan results as part of ongoing security assurance.

 

SAAS AND VENDOR INTEGRATIONS

Third-party SaaS integrations and plugins expand your attack surface. OAuth scopes are often too broad, APIs multiply quickly, and a single compromised connector can expose customer data or internal systems.

Solutions:

      • Scoped OAuth Permissions Limit permissions at the point of token issuance. Remove unused or overbroad scopes during regular reviews.
      • Continuous Vendor Verification Do not rely on questionnaires or SOC 2 reports alone. Monitor vendor activity directly through SSPM and CDR, watching for excessive API calls, new token grants, or strange geographical access. Run scheduled access reviews through IGA (Identity Governance and Administration) to confirm that vendor tokens, service accounts, and roles remain appropriate for current business needs.
      • CASB (Cloud Access Security Broker) Use a CASB to apply access and session controls on sanctioned apps, and surface unsanctioned ones. Create a risk score for unsanctioned apps to prioritize for incident response to block, revoke, and/or review with the employee.
      • Browser Extensions and Plugins Leverage revalidation, behavior monitoring and conditional access to track runtime behavior, grant minimal privileges, revoke tokens, and block plugins if strange activity is detected.

 

PROVIDER RELIANCE (Microsoft, Google, Salesforce, CrowdStrike, etc.)

Mistakes can be made by Tier 1 providers. The CrowdStrike update failure and the Entra actor token abuse illustrated the core nature of the services across a breadth of industries. To mitigate the risks of provider missteps, organizations need to continuously verify the quality of delivery.

Solutions:

      • SSPM (SaaS Security Posture Management) Scope roles to least privilege, enforce secure configurations, and monitor for drift from “known-good”. See Appendix for example tools.
      • CDR (Cloud Detection and Response) Monitoring for token abuse, cross-tenant oddities, and strange API calls will help you identify if something is not right before it goes wrong. See the appendix for example tools.
      • Resilience Planning Plan for provider failures. This includes maintaining fallback identity paths, a secondary IdP if you’re cloud native, for critical apps or emergency accounts. Remember to test failover for those accounts.
      • Microsegmentation Enforce conditional access and isolate workloads to limit the extent of damage in case something does go wrong.
      • Independent Logging Do not depend solely on the provider’s console to tell you how the service is functioning. Stream SSPM, CDR, and SaaS logs into your SIEM under your control. Relying on the providers’ console is insufficient for data retention and long-term investigations.
      • Customer-Controlled Encryption Hold your own encryption keys instead of relying only on the provider’s.  Use customer-managed key (CMK) or external key management (EKM) solutions to separate key custody from data housing. For higher levels of resilience, use external HSM or KMS solutions (Thales, Fortanix) to remove reliance upon Google, Amazon, or Microsoft. This ensures that even if the provider is breached, they cannot decrypt your data.

 

BROWSER SECURITY AND PLUGINS 

The browser has become the place where work gets done, making it a juicy target for the attacker. Network defenses are critical, but additional protection is needed at the browser layer to deal with these threats.

Solutions:

      • Enterprise Browser Security Platforms Depending on your needs, there are “secure browser” solutions, and there are “browser security solutions”. Both add inline SaaS visibility, enforce data policies, and protect session integrity inside the browser.
      • SSPM (SaaS Security Posture Management) Scope roles to least privilege, enforce secure configurations, and monitor for drift from “known-good”.  
      • Extension Controls While an Enterprise Browser Security Platform has a lot of governance, it enforces extension policy through GPO or MDM to block unsanctioned extensions. Once approved, monitor with the browser security platform.
      • Session Token Security While not practical in some cases, we need to do our best to limit risk by issuing short-lived tokens, requiring re-authentication for sensitive apps, and detecting replay or misuse with CASB or CDR.
      • Harden the Browser Be sure to enforce HTTPS-only mode, disable password saving, and block developer mode. Leverage CIS guidance as appropriate.
          •  

Reference our prior paper on Browser Security, which illustrated how the browser has become where the work gets done, and provided practical guidance for securing the browser environment.

 

AI WORKERS (we work with) and AI PRODUCTS (we build with AI)

From writing code to checking code, automating SaaS tasks, summarizing meetings, and being embedded in browsers to summarize content across tabs, learn behavior, and execute tasks, AI (artificial intelligence)  is without a doubt here and not going away. Integrations are becoming more ubiquitous, and AI workflows are crossing organizational boundaries. These “integrations” change how identity, tokens, credentials, and data are stored and passed. These changes create risks that cannot be assumed to be safe.

Solutions:

  • Verify AI-generated code Not because it’s AI-generated, but because it’s code. Treat AI output like untrusted third-party code. Run it through SAST, DAST, dependency scanning, and secrets checks before merging.
  • AI Agents require managed identities in your environment. IGA (Identity Governance and Administration) solutions are accounting for this, and you need to take advantage of it. Discover agents and restrict access with least privilege. Log everything as though it’s an insider threat.
  • For AI systems using Model Context Protocol (MCP) servers or agent-to-agent communication, secure the session as though it were a third-party connector. Treat the model as untrusted, verify tool definitions cryptographically, and enforce runtime controls at a policy-aware execution gateway layer.
  • Conduct security reviews Monitor AI agents’ handling of credentials, tokens, session keys, and stored data. Verify they are not leaking or storing credentials in a way that evades normal detection.

Reference our previous work on AI Native Browsers, which includes practical steps to evaluate AI browser security readiness for your organization.

Reference our paper, Securing Agent-to-Agent Communication: Considering MCP, which provides guidance on securing MCP, enforcing policy-aware execution, and validating AI tool definitions.

 

Culture of Verification

Verification has to be continuous and second nature to how teams operate, instead of being left as a one-time check. Reliance on vendors’ assurances and audit reports tends to create blind spots.

Strategies to reduce blind spots:

  • Continual automated verification Embed measurable technical controls in the development pipeline, identity, SaaS, endpoint, and remediated.
      • CI/CD integration: Every build requires a SAST and SBOM dependency scan. Apply DAST in staged test environments or pre-production to validate runtime behavior without slowing down the pipeline.
      • Identity and Access verification: Contextual access; device posture, user behavior, and location at sign-in and during the session, combined with Continuous Verification, which will revoke access if the risk profile changes during the session.
      • SaaS and Cloud Monitoring: Use CDR and SSPM via provider APIs to identify misconfigurations and strange activity, including OAuth abuse, mass downloads, and privilege escalation.
      • Browser and Endpoint telemetry: EDR/XDR and enterprise browser security can be used to continuously confirm device and browser integrity.
      • Automate remediation: Trigger workflows with detections that revoke tokens, isolate devices, or block suspicious plugins to cut containment time.
  • Risk-based enforcement When risk signals rise, odd token behavior, unusual geographies, and unusual access to confidential data increase verification requirements.
  • Leadership messaging Frame verification as a way to protect trust instead of demonstrating a lack of it.

Trust is how collaboration happens. Verification through Zero Trust practices is how we keep it secure. Leaders can take the following tactical steps to progress the broader concepts outlined above.

 

Tactical Steps for Security Leaders

Zero Trust is a philosophy and a long-term program, but security leaders can take practical steps now to cut risk and progress on the journey.

  • Leverage PAM and Strengthen Identity Services Monitoring
            • Enforce MFA across all accounts.
            • Shorten token lifetimes and apply conditional access.
            • Monitor both cloud (Entra, Okta, Duo) and on-prem AD for privilege escalation.
            • Hybrid sync jobs require monitoring for changes.
            • Stream identity events to SIEM or XDR.
  • Stage vendor updates, like patching cycles
            • Roll out agents, connectors, and patches in phases to minimize impact.
            • Verify updates in dev/test before pushing to production to contain failures.
  • Token lifetime
            • Shorten token lifetimes and use step-up re-authentication for sensitive tasks. This is common when moving from work to profile administration, for example.
            • Enforce conditional access policies across both cloud and on-prem apps.
            • No exception for Dev environments
  • Revalidate plugins and extensions 
            • Restrict and audit extensions and OAuth integrations on a regular basis.
            • Remove unused and restrict over-permissioned plugins.
            • Monitor runtime behavior in case an extension is compromised.
  • Automate dependency scanning
            • Add SBOM checks and dependency scanning into every CI/CD build.
            • Apply the same process to vendor and AI-generated code.

 

These tactical steps can deliver meaningful risk reduction while the broader Zero Trust strategy matures. Trust enables collaboration, but verification is what sustains it.

 

Appendix

Useful Resources
NTIA How-To Guide for SBOM Generation

OpenSSF SBOM tools

Sigstore

GitHub Security

 

Practical Tools and Models for Software and Vendor Verification

 

SBOM and Dependency Validation

Purpose: Continuous verification of both internal and external code.

  • GitHub Advanced Security – Provides SAST (CodeQL), dependency scanning, and secret detection directly in CI/CD.
  • GitLab Ultimate – Includes integrated SCA, SBOM export, and pipeline-based policy enforcement.
  • Veracode SCA – Third-party dependency scanning with centralized reporting for vendors.
  • OpenSSF Scorecard – Evaluates the security posture of open-source repositories.
  • CycloneDX – “OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction.”

 

Vendor Code Review Models

Purpose: Enable Independent security verification of third-party software without full source access.

 

SaaS Security Posture Management (SSPM) and Cloud Detection Tools
Purpose: These tools provide continuous visibility, configuration monitoring, and anomaly detection across SaaS and cloud environments. They combine posture assessment (SSPM/CSPM) with behavioral analytics and response. (CDR/XDR).

 

Dedicated SSPM Platforms

  • AppOmni – Monitors and enforces configuration and access policies for major SaaS platforms such as Salesforce, ServiceNow, and Slack.
  • CrowdStrike Falcon Shield – A SaaS posture and identity security tool for the Falcon platform. Helps identify misconfigurations, privilege creep, and non-human identities across SaaS applications.[7]
  • DoControl – Provides automated data access governance, focusing on SaaS files sharing and data exfiltration controls.
  • Grip Security – Identifies shadow SaaS usage, monitors sanctioned apps for posture drift, and enforces least-privilege access.
  • Obsidian Security – Focused on identity and activity visibility across SaaS apps, detecting behavioral anomalies and misconfigurations.
  • Wing Security – Discovery-first SSPM platform that maps unsanctioned SaaS usage and continuously enforces data controls.
    Zscaler Posture Control – Combines SaaS and cloud posture management with integrated CDR capabilities.

 

Cloud Detection and Response Platforms

  • CrowdStrike Falcon CDR – Extends Falcon’s endpoint visibility into SaaS and cloud workloads.
  • Microsoft Defender for Cloud Apps – Combines SaaS posture management with CASB and identity monitoring capabilities for Microsoft 365, Salesforce, Okta, and Github.
  • Microsoft Defender for Cloud – CNAPP and cloud posture management with runtime detection.
  • Prisma Cloud – Integrated CNAPP and CDR for cloud and SaaS workloads.
  • Wiz – Posture and anomaly detection across multi-cloud, API, and identity layers.

 

Sources
CISA, “Widespread Supply Chain Compromise Impacting npm Ecosystem” September 23, 2025, https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

ISS Source, “Supply Chain Alert for npm” September 25, 2025, https://www.isssource.com/supply-chain-alert-for-npm/

Mollema, Dirk-jan. “One Token to rule them all – obtaining Global Admin in every Entra ID tenant via Actor tokens.” September 17, 2025, https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/

Unit 42, ‘”Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack (Updated September 23).’ September 23, 2025, https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

[1] Unit 42, “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack (Updated September 23)

[2] Unit 42, “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack (Updated September 23)

[3] ISS Source Supply Chain Alert for npm

[4] ISS Source Supply Chain Alert for npm

[5] CISA Widespread Supply Chain Compromise Impacting npm Ecosystem

[6] Software Bill of Materials

[7] CrowdStrike Falcon® Shield

Review Your Security and Risk Profile