This is the second post in our “Bring Your Own Source” series, where we explore practical, real-world ways to extend secrets detection far beyond traditional code repositories.

The recent Salesloft Drift breach has sent shockwaves through the enterprise security community, affecting hundreds of organizations through Salesforce, including major players like Cloudflare, Farmers Insurance, Palo Alto Networks, and Zscaler.

What makes this incident particularly significant goes beyond the massive scale (over 1.1 million customers impacted at Farmers alone) to Google's explicit recommendation in their threat intelligence advisory to run secrets scanning tools to find secrets and hardcoded credentials" and "search for potential secrets" across Salesforce data.

The breach demonstrates that attackers are systematically harvesting credentials from compromised business systems, and as Cloudflare discovered, they're finding them. 

The threat actor, tracked as UNC6395 by Google and GRUB1 by Cloudflare, went beyond simple data theft to actively search through stolen information for "sensitive credentials such as Amazon Web Services (AWS) access keys (AKIA), passwords, and Snowflake-related access tokens".

Cloudflare's own investigation revealed that attackers had already begun attempting to use stolen credentials before the breach was fully understood. On August 9, 2025, the threat actor was attempting to verify a token against a Cloudflare Customer Tenant, receiving a 404 error. This shows that hardcoded secrets discovered in previous attacks were already being weaponized against other targets.

The message is clear: secrets sprawl represents an active attack vector being exploited at scale by sophisticated threat actors.

This guide demonstrates how to build a Salesforce secrets scanning pipeline by combining Salesforce CLI's powerful querying capabilities with GitGuardian's ggshield scanner, ensuring that sensitive credentials are detected, and exported into our platform to facilitate remediation.

Let's break down the essential commands and understand what each step accomplishes:

Step 1: Authenticate with Your Salesforce Org

sf org login web

This command opens your default web browser and initiates the OAuth flow to authenticate with your Salesforce organization. It will retrieve the OAuth access and refresh tokens and store them on your filesystem. On macOS, they are located in a JSON file, such as ~/.sfdx/peter.parker-l5gs@force.com.json.

Step 2: Discover Available Objects

sf force:schema:sobject:list -o peter.parker-l5gs@force.com > objects.txt

This command retrieves a comprehensive list of all standard and custom objects available in your Salesforce org and saves them to a text file. The -o flag specifies the target org.

Step 3: Export Object Data with SOQL

sf data query -o peter.parker-l5gs@force.com --query "SELECT FIELDS(ALL) FROM Lead LIMIT 200 OFFSET 0" --json > Lead.jsonl

This command exports data from specific Salesforce objects using SOQL (Salesforce Object Query Language) as a JSON document. Due to system limitations, each export operation is restricted to a maximum of 200 records per query, and pagination can be achieved using the OFFSET keyword for retrieving additional batches of data. When working with larger datasets, you'll need to run multiple queries with incremental OFFSET values to capture all records systematically.

Step 4: Create a Custom Integrations

Now that we have Salesforce data to scan, let’s setup a custom source, as detailed in https://docs.gitguardian.com/internal-monitoring/integrate-sources/bring-your-own-sources

This integration transforms ad-hoc security scanning into a systematic approach where your Salesforce data exports receive the same enterprise-level secret detection and incident management as your code repositories, creating a unified security posture across all your data sources.

First, create a custom source, and retrieve your unique integration ID:

Then, configure a service account:

Step 5: Scan for Secrets and Create Security Incidents

ggshield secret scan path Lead.jsonl --source-uuid YOUR_INTEGRATION_ID

This final step leverages GitGuardian's powerful secrets detection engine through ggshield to analyze your exported Salesforce data for over 500+ types of hardcoded secrets and sensitive credentials. By including the --source-uuid parameter, you're not just scanning locally – you're integrating your Salesforce data exports into GitGuardian's comprehensive security monitoring platform as a custom source.

Following the scanning of the Salesforce Lead.jsonl file, a GitHub Personal Access Token was detected and a security incident was automatically created .

What makes this approach particularly powerful is the centralized incident management capability, where detected secrets automatically create incidents in your GitGuardian dashboard, providing full visibility alongside your other security monitoring. Your Salesforce exports become a monitored data source with the same management capabilities as native GitGuardian integrations, utilizing the same enterprise-grade detection engine that monitors millions of repositories worldwide. Each finding includes validity checks, remediation guidance, and detailed context, delivering actionable intelligence rather than just alerts.