Third-Party Code Just Beat Passwords in Google’s Cloud Data

Procurement Proof

Threat Horizons H1 2026 shows attackers moving through third-party software and OAuth paths, forcing SaaS founders to prove blast radius before procurement does.

Share free access to this member-only story with a friend: Read it free here.

Google's H1 2026 cloud intrusion chart belongs in the same deal room as the security questionnaire your buyer has not sent yet. Approve the wrong integration, and procurement can put a contract on ice before an attacker ever touches your tenant. For SaaS founders, "trusted vendor" no longer carries the weight it used to.

In Google Cloud Threat Horizons Report H1 2026, third-party software-based entry accounted for 44.5% of observed Google Cloud initial-access vectors in H2 2025, up from 2.9% in H1 2025. Weak or absent credentials dropped from 47.1% to 27.2%.

Google says the chart reflects a subset of observed activity, not every cloud customer. But the sales signal is plain: stronger identity defaults make password attacks more expensive, so the cheaper path shifts toward unpatched software, OAuth consent, and the SaaS relationship your team already approved.

Thank you.

The trusted app is now the cheapest door

Google's report names React2Shell, tracked as CVE-2025–55182, and XWiki's CVE-2025–24893 as examples of the new economics. The attack window collapsed from weeks to days in the second half of 2025. Google also observed XMRig cryptocurrency miners deployed within roughly 48 hours of React2Shell's public disclosure.

That is not a romantic spy novel. It is a queueing problem with better automation.

Attackers follow payoff. If phishing an executive takes longer than scanning exposed third-party software, the scanner wins. If stealing a password is blocked by phishing-resistant MFA, the next best move is a trusted integration with useful permissions and quiet logs.

Defensive maturity in one lane pushes pressure into the next lane.

For founders, that changes the buyer conversation. The old answer, "we use reputable vendors," sounds polished until someone asks which vendor can read customer records, which token survives a password reset, and how fast your team can cut access without breaking the product. Buyers are no longer evaluating a logo wall.

They are evaluating the doors those logos open.

The token is now a revenue surface.

The breach starts before the breach

The Salesloft Drift case made the quiet version visible. On August 26, 2025, Google Threat Intelligence Group and Mandiant published an advisory on widespread data theft targeting Salesforce instances through Salesloft Drift. The actor, tracked as UNC6395, used compromised OAuth tokens tied to the third-party app and targeted Salesforce customer instances from as early as August 8 through at least August 18.

The key detail for founders is not the brand name. It is the shape of access. GTIG said the actor systematically exported large volumes of Salesforce data, then searched that data for AWS access keys, passwords, and Snowflake-related tokens.

Salesloft and Salesforce revoked active Drift access and refresh tokens on August 20, and Salesforce removed the Drift app from AppExchange pending investigation.

The core Salesforce platform was not the point. The relationship was.

That distinction matters in enterprise sales because the buyer's loss does not wait for your direct breach. A sales tool, chat tool, analytics connector, support integration, or enrichment vendor can sit close enough to customer data to create the same uncomfortable question: if this partner fails, do we absorb the blast radius?

The FBI drew the same line in its September 12, 2025 FLASH on UNC6040 and UNC6395. It warned that OAuth tokens issued by Salesforce can make malicious app activity look like a trusted integration, bypassing many traditional cues such as MFA, password resets, and normal login monitoring.

That is the procurement nightmare. Nothing looks wrong until the data is already moving.

Procurement is learning to ask for mechanics

Buyers are being trained to ask better questions. CISA's Secure by Demand Guide tells software customers to bring security into procurement and ask manufacturers for proof of security practice, not vibes wrapped in a SOC 2 report. NIST pushed the same direction when Cybersecurity Framework 2.0 added the Govern function and put more weight on supply chain risk.

That language sounds bureaucratic until it lands in a deal. Then it becomes a clock.

A buyer does not need to prove you are careless to slow a contract. They only need unanswered mechanics. Which connected apps have access to production customer data?

Which scopes are broader than the job? Who owns token rotation? Where would bulk API exports appear?

What breaks if a vendor is revoked by noon?

This is where many founders get trapped by good intentions. They bought the market-standard tools. They passed the obvious audit.

They have SSO, MFA, and a clean security page. Then the buyer asks about OAuth scope review for revenue tools, and the packet goes soft.

The failed answer is "our vendors are trusted." The better answer is a map.

What to prove before the buyer asks

Start with the integrations that can touch customer data, source code, support tickets, billing records, CRM objects, analytics exports, or secrets accidentally pasted into notes. Pull the connected-app inventory. Sort by data sensitivity, granted scope, last use, owner, and revocation path.

Then write down what evidence would convince a skeptical buyer that a vendor failure stays contained.

Put three artifacts in the deal room before the question lands:

A connected-app inventory mapped to customer data, business owner, approval date, and last review.
A blast-radius note showing scopes, logs, revocation path, token rotation date, and known downstream systems.
A patch-speed receipt showing how exposed software gets a virtual patch under 24 hours and full remediation under 72 hours.

That last target comes straight from Google's H1 2026 recommendations. The report tells organizations to update patching methods toward less than 24 hours for virtual patch mitigation and less than 72 hours for full patch remediation. That is the new measuring stick.

Monthly patch theater does not survive a two-day miner clock.

The operating move is not to rip out every vendor. That would punish growth while pretending purity is security. The better move is to price each relationship like an attacker would: data value, permission depth, exploit speed, detection quality, and exit cost.

If an integration helps close revenue but has broad scopes, stale tokens, weak logs, and no owner, the risk is not theoretical. It is sitting in the sales machine.

This is the overlooked founder lesson in Google's 44.5% chart. Third-party risk used to live in a questionnaire after the champion wanted to buy. Now it lives earlier, inside the buyer's confidence that your product will not import someone else's failure.

The companies that win will not be the ones with the longest vendor list or the cleanest slogan. They will be the ones that can show which relationships matter, how far each one reaches, and how fast they can close the door.

Thank you to the founders who make trust provable before procurement makes it expensive.

Contents