Loading module...
Loading module...
GSA-07
Recognize how apps and services connected to work accounts create supply chain risk, and know how to evaluate tools before adopting them.
General Security Awareness Training
Estimated Time: 15 minutes
By the end of this module, you will be able to:
Your company doesn't operate in isolation. It relies on dozens (sometimes hundreds) of third-party tools, platforms, and services to function: cloud hosting, email, CRM, payroll, project management, customer support, analytics, billing, and more. Each of those vendors has access to some portion of your company's data or systems. And each one represents a potential entry point for an attacker.
This isn't hypothetical. In 2025, 30% of all confirmed data breaches involved a third-party vendor, double the rate from the previous year. When a breach originates from a third-party system, the average remediation cost is nearly $4.8 million. Attackers have figured out that compromising a vendor is often easier and more scalable than attacking their real target directly. By breaching one vendor, they can reach dozens or hundreds of downstream customers at once.
The uncomfortable truth: your security is only as strong as your weakest vendor. You can have excellent internal controls, a well-trained team, and best-in-class tools, but if a vendor with access to your customer data gets compromised, your customers' data is still exposed. And in the eyes of your customers and your auditor, that's your problem.
A supply chain attack targets an organization indirectly by compromising a product, service, or vendor that the organization trusts. Rather than breaking through your front door, the attacker walks in through a side door that you left open because you trusted the person who installed it.
Most supply chain attacks follow a recognizable sequence:
1. The attacker identifies a vendor with broad access. They look for SaaS platforms, integrations, or service providers that connect to many customer environments. A single compromised vendor can unlock access to hundreds of organizations.
2. The attacker compromises the vendor. This can happen through phishing, credential theft, exploiting a software vulnerability, or social engineering a vendor's employees. The vendor's own security practices determine how hard (or easy) this step is.
3. The attacker uses the vendor's trusted access to reach downstream targets. Because the vendor's connection to your systems is legitimate, your security tools may not flag the activity. The attacker appears to be the vendor doing normal work.
4. Data is exfiltrated, ransomware is deployed, or further access is established. By the time anyone notices, the attacker has been operating under the cover of a trusted relationship.
The Salesforce/Salesloft campaign (2025) showed this pattern in action. Attackers used social engineering and stolen OAuth tokens from a trusted third-party integration (Salesloft's Drift connection) to gain API-level access to Salesforce customer environments. The attackers claimed to have compromised data from 91 organizations through a single vendor relationship. Your company didn't have to be targeted directly. If you used the affected integration, you were exposed.
Earlier examples like the MOVEit breach (2023) followed the same logic: attackers exploited a vulnerability in a widely used file transfer tool, and every organization that relied on MOVEit became a victim. One compromised product, hundreds of affected organizations.
Every time you click "Allow" or "Authorize" when connecting a third-party app to a work account (Google Workspace, Microsoft 365, Slack, Salesforce), you're granting that app an OAuth token. That token gives the app ongoing access to your data, often without requiring your password again.
OAuth tokens are powerful. Depending on the permissions you approved, the connected app may be able to read your email, access your contacts, view your calendar, browse your files, or interact with your data through APIs. And unlike a password, which you actively use each time you log in, OAuth tokens work silently in the background. You may forget the app exists long after you authorized it.
Here's the security problem: if the third-party app is compromised, the attacker inherits whatever access you granted through that OAuth token. They don't need your password. They don't need to bypass MFA. They already have a legitimate, authenticated connection to your data.
OAuth tokens also survive many security actions. Changing your password won't necessarily revoke an existing OAuth token. Disabling a user's SSO login may not kill all active token-based connections. This is one of the reasons offboarding failures (Module 5) are so dangerous: former employees may have authorized apps that retain access long after the person's primary account is disabled.
Think before you authorize. When an app asks for access to your work accounts, read the permissions it's requesting. Does a project management tool really need access to your entire Google Drive? Does a calendar scheduling tool need to read your email? If the permissions seem broader than necessary, that's a red flag.
Use only IT-approved integrations. Your company may maintain a list of approved third-party apps. If it does, stick to the list. If you want to connect something new, ask IT to evaluate it first.
Periodically review your connected apps. In Google Workspace, check your authorized apps at myaccount.google.com/permissions. In Microsoft 365, check at myapps.microsoft.com. In Slack, check your connected apps in your workspace settings. Revoke access for anything you no longer use.
Third-party risk isn't limited to software. It also includes the people from outside your organization who have access to your systems: contractors, freelancers, consultants, and agency partners.
Contractors often receive access to the same tools and data as full-time employees, but the governance around that access is frequently less rigorous. They may be onboarded informally, given broader access than needed to "make it easy," and kept active long after the engagement ends. As we covered in Module 5, offboarding failures for contractors are among the most common and longest-lasting access control gaps.
The risks:
What you can do: If you manage contractor relationships, ensure that access is scoped to the specific project, provisioned through IT's standard process, and has a defined end date. When the engagement wraps up, confirm with IT that access has been fully revoked. Don't assume someone else handled it.
You don't need to be a security expert to ask the right questions before bringing a new tool into your workflow. Here's a practical checklist:
Does the vendor have a SOC 2 report? For any tool that will handle your company's data, this is the baseline question. A current SOC 2 Type II report means an independent auditor has verified that the vendor's security controls are designed and operating effectively. If the vendor doesn't have one, that's worth flagging.
What data will this tool access? Be specific. Will it see customer data? Employee data? Financial data? Source code? The classification level of the data (from Module 4) determines what security controls the vendor needs to have in place.
How does it authenticate? Does it support SSO? Does it require its own separate credentials? Tools that integrate with your company's identity provider are easier to manage and easier to revoke.
What permissions does it request? Review the OAuth scopes or API permissions. If the tool is requesting broader access than what it needs to do its job, that's a concern.
Where is the data stored? Is it in a region that complies with your company's data residency requirements? Is it encrypted at rest and in transit?
Is IT aware of it? If the answer is no, that's the first thing to fix. Every tool that touches company data should be known to the security team, even if the evaluation comes after the initial discovery.
You don't need to answer all of these questions yourself. But you should know enough to bring the right questions to IT or your manager before signing up.
SOC 2 doesn't just evaluate your internal controls. It also looks at how you manage the risk introduced by your vendors. Common Criteria 9.2 (CC 9.2) requires that your organization assess and manage risk from business partners, vendors, and other third parties. Auditors look for evidence of vendor risk assessment, contractual obligations around data protection, and ongoing monitoring of vendor security posture.
If an employee signs up for an unapproved tool that handles customer data, and that tool is later breached, the auditor's question will be: "Did your organization have a process for evaluating and approving third-party tools, and was it followed?"
The answer needs to be yes.
Next up: Module 8, AI Tools & Security, where we'll cover how to use AI assistants safely, what data you should never paste into them, and how to recognize AI-generated content aimed at deceiving you.
Module Version: 1.0
Last Updated: March 2026
Framework References: NIST Cybersecurity Framework 2.0 (Govern, Identify), SOC 2 Trust Services Criteria (CC 9.2, CC 3.1)
Data Sources: Verizon Data Breach Investigations Report 2025, IBM/Ponemon Cost of a Data Breach Report 2025, SecurityScorecard 2025 Global Third Party Breach Report