From Vulnerabilities to Exposures: When Risk Hides in Integration

The incidents of the past few weeks are a reminder that the most expensive blow isn’t always the one that pierces a firewall—it’s the one that slips through a legitimate door no one is really watching.

While Jaguar Land Rover extended a production halt after an attack that immobilized entire plants and compounded losses, Kering confirmed the theft of customer data from Gucci, Balenciaga, and McQueen—proof that industrial disruption and large-scale data exposure can coexist when a single weak link strains a digital supply chain. These aren’t isolated anecdotes; they’re symptoms of hyper-connected ecosystems where one extra permission—or a poorly understood integration—becomes the main attack vector.

Against that backdrop, the most instructive breach is Tenable’s—not because someone “broke” their security products, but because attackers exploited a Salesforce support integration to read data that looked innocuous (case subjects, descriptions, contacts) but often hid operational secrets pasted in at the last minute. The public timeline aligns: between August 8 and 18 2025, the attackers abused OAuth tokens tied to Salesloft’s Drift app to run SOQL queries and extract information from customer Salesforce instances.

The response was to revoke credentials, disable the app, and notify affected customers.

The nuance that matters is the vector: Salesforce’s core wasn’t compromised; a trusted, authorized connector was abused. That’s the difference between being compromised andbeing compromised through an integration that had been authorized. Put plainly: Salesforce wasn’t the problem—the open door you approved was.

Calling it “a support data leak” misses the lesson. The adversary wasn’t after a list of cases; they were hunting for keys buried in business fields, comments, and descriptions: cloud credentials, Snowflake references, reused passwords—any secret someone pasted into “temporary” text.

That’s the point behind the industry ’s pivot from vulnerability management to exposure management: stop hoarding low-signal findings and prioritize by asset criticality, threat context, and real exploitability—so you tackle the 1% that explains 99% of the risk.

An equally instructive—because familiar—fault sits on the desktop: Google Drive for Windows and its local cache folder DriveFS. Multiple technical write-ups show that, on shared machines, copying one user’s DriveFS and pasting it into another profile can make the client load the other person’s Drive without re-auth.

The problem isn’t “the cloud”; it’s near-blind trust in local cache and weak per-user isolation—exactly the opposite of a zero-trust endpoint stance. Some sites tie a specific CVE to this, but precision matters: the officially registered CVE-2025-5150 maps to a different issue (docarray), not Drive Desktop.

Until there’s an unambiguous correlation, treat this as a widely documented isolation flaw with obvious mitigations: avoid Drive Desktop on shared PCs, purge cache on sign-out, and restrict usage to managed endpoints. In other words: if you share your device, someone could open your Drive without a password.

Label aside, the technical fact is clear: if the local session outweighs the identity, the weak link is the physical device and session hygiene. This connects to a broader truth: a vuln scan is a snapshot, not a diagnosis. Security happens when we add context: which assets are critical, which integration can read free-text fields where someone dropped an API key, which token should be short-lived and source-restricted, which alert matters because it touches billing instead of a test server.

That lens turns tools into decisions: treat tokens as first-class credentials with rotation and minimal scopes; regularly review connected apps and cut excess permissions; inspect SaaS systems for secrets buried in tickets or comments; and most importantly, join technical telemetry with business impact so prioritization is real, not cosmetic.

If we’re talking about impact, we have to talk about sensitive data. Keeping PII, credentials, or payment data unencrypted or un-tokenized isn’t just unwise—it’s operational negligence. Tokenization removes exploitable value as data moves across systems and can narrow compliance scope.

Encryption protects what must never leave the vault—ideally with serious key-management policies and, where needed, format-preserving encryption to avoid breaking legacy flows. This isn’t a religious debate about techniques; it’s architecture guided by risk and budget.

For an SMB in 2025, the goal isn’t to mimic a bank’s SOC—it’s continuous visibility and discipline: well-run EDR/XDR, sensible SIEM correlation or MDR when the team is small, extreme hygiene in integrations (Salesforce, Google Workspace, and whatever SaaS matters), secret detection in repos and CRMs—and the conviction that no tool saves you if you keep pasting passwords into the “description” field of a ticket.

Platforms like Splunk/QRadar can fitmodest budgets if you prioritize by risk, not catalog. What fits no budget is unlimited permissions and tokens with no expiry. The lever isn’t the tool—it’s the interpretation.

If I had to condense this into one practical idea, it’s this: the problem wasn’t “a scan missed something”; it was a trust relationship no one interpreted in time. The antidote is disciplined practice: scope and rotate tokens; clean and isolate local caches; inspect “free” text fields where prose and secrets mingle; tokenize what travels through many hands; encrypt what must never leave the vault; and demand that every alert arrives with business context.