Most organizations are far too trusting of third-party applications. Commercial-off-the-shelf software, vendor APIs, SaaS integrations: they're installed, connected, and largely forgotten. The SolarWinds breach proved how catastrophically wrong that approach can go. An advanced persistent threat actor injected malware directly into a widely-distributed software update, using the trusted software channel to compromise thousands of organizations, including major government agencies.
Identity: Securing Privileged Vendor Developer Access
Third-party applications are built, deployed, and maintained by people: developers, DevOps engineers, administrators, who often have elevated privileges in your environment. Applying Zero Trust to this population means:
• Privileged User Groups: Create dedicated groups for vendor privileged users. Membership should be minimal and regularly justified.
• MFA Without Exception: Privileged vendor access must use MFA: biometrics or OTPs preferred over simpler factors.
• Just-In-Time Access: Privileged access should be granted only for specific, time-bounded tasks and revoked immediately upon completion.
• PAM Integration: All vendor privileged accounts must flow through your Privileged Access Management system for automated rotation, session tracking, and audit logging.
• No Shared Accounts: Every individual must have their own privileged account. Sharing is a compliance failure and a security nightmare.
Device/Workload: Verifying Application Integrity
Vendor applications running in your environment must be continuously verified against known-good states. A mature Zero Trust deployment can:
• Detect new zero-day vulnerabilities in third-party software through continuous scanning correlated with a CMDB and threat intelligence feeds
• Quarantine affected resources before a known vulnerability can be exploited
• Require all third-party applications to integrate with your PAM system rather than storing their own credentials
Critical rule: Never accept a vendor application that requires root or super-user access. Any vendor who insists their software requires it is demonstrating poor security architecture, not a technical necessity.
Access: Least Privilege for Applications and Workloads
Applications, services, and APIs should follow the same least-privilege principles as human users. Third-party workloads should: - Only access the resources they need to function - Integrate with PAM for any privileged operations - Be reviewed and re-approved at least quarterly - Be monitored by your SIEM team as a separate, high-risk category
Transaction: Scanning Vendor Application Traffic
All data flowing from third-party applications should be: - Encrypted in transit (confirmed, not assumed) - Monitored for unauthorized data exfiltration - Scanned for behavioral anomalies via SIEM integration - Auditable through comprehensive logging
Key Takeaway: The SolarWinds attack worked because organizations trusted third-party software implicitly. Zero Trust for applications requires treating every vendor workload as potentially hostile until continuously verified: from the developers who build it to the traffic it generates.
Tags: Third-Party Applications | SolarWinds | PAM | Least Privilege | Application Security | Zero Trust
From Third Party Threat Hunting™ (TPTH™)
Put it to work
Privileged access
The free VAULTS™ training: 31 minutes on privileged access review, with a worked review.
Get the free training →Have us run it
Managed third-party threat hunting: practitioners on your systemically critical vendors, automation on the rest.
See the managed tiers →