TigerSwan exposed thousands of applicant resumes through a publicly accessible AWS S3 bucket identified by UpGuard in July 2017, with the repository remaining open until August 24 despite repeated notification. The incident combines two recurring enterprise failures: insecure third-party handling of sensitive data and weak cloud governance over internet-accessible storage.
UpGuard identified 9,402 publicly reachable files in the tigerswanresumes bucket, including resumes containing home addresses, contact details, driver’s license numbers, passport numbers, partial Social Security numbers and references to security clearances. The exposed population included military veterans, law enforcement personnel and Iraqi and Afghan nationals who had supported US and coalition operations. The evidence points to a severe control failure: sensitive data was placed in storage configured for anonymous public access on a known AWS endpoint that is easily discoverable and routinely scanned. The month-long remediation delay after external notification further shows incident response weakness, poor ownership clarity and insufficient vendor oversight for high-risk data.
| What’s happening | Cause | Action |
|---|---|---|
| Sensitive applicant data was stored in a publicly accessible S3 bucket | UpGuard found an AWS S3 bucket at tigerswanresumes configured for public access, allowing any internet user to access the files directly. The source article below attributes the bucket to former recruiting vendor TigerSwan. We speculate that the architecture likely relied on S3 public website-style exposure or equivalent anonymous access patterns, which are inappropriate for private applicant data. |
Validate that no storage bucket containing applicant, customer, employee or partner data permits anonymous read access, whether through bucket policy, ACLs or website hosting configuration. SkySiege assesss public exposure paths for object storage, identify internet-reachable buckets on known provider endpoints and flag architectures using anonymous-access features for non-public data. |
| The wrong cloud architecture was used for private data | AWS S3 supports fully public content delivery for data intended to be accessible without authentication. The exposed resumes were not public content, yet the repository was reachable by any user on a discoverable AWS-hosted endpoint. This made discovery materially easier because exposed buckets on standard cloud endpoints are routinely enumerated and scanned. | Validate that private records are only stored behind authenticated application paths, not directly in publicly reachable object storage endpoints. SkySiege assesss whether sensitive data is hosted on storage services designed for anonymous public distribution and determine whether that design creates avoidable discoverability and exposure risk. |
| Third-party vendor governance failed | TigerSwan told UpGuard the files were left unsecured by a former recruiting vendor terminated in February 2017. The source report directly ties the exposure to third-party handling of sensitive information. | Validate which vendors store regulated or sensitive data, where they store it, what cloud controls they use and whether offboarding includes verified data removal or secure transfer. SkySiege scans vendor-owned or vendor-managed cloud assets, ownership gaps, stale repositories and missing contractual or technical controls around data custody. Visibility whilst offboarding vendors is a key use case. |
| Sensitive data minimization and handling controls were inadequate | The exposed files included home addresses, phone numbers, email addresses, driver’s license numbers, passport numbers, partial Social Security numbers and security clearance details. References were also exposed. This indicates excessive sensitive data in resumes and no effective segregation or protective controls once uploaded. | Validate whether hiring workflows collect more sensitive data than necessary and whether submitted files are sanitised, encrypted, access-restricted and lifecycle-managed. SkySiege searches for broadly accessible repositories and checks whether controls match the sensitivity of personnel and identity data. |
| Exposure affected high-risk populations with elevated threat implications | The repository included resumes from military veterans, law enforcement personnel, individuals claiming Top Secret/SCI clearances and Iraqi and Afghan nationals who supported US and coalition efforts. The original report highlights the risk of identity theft, phishing, intelligence targeting and potential endangerment of exposed foreign nationals. | Validate whether data classification accounts for personnel whose exposure creates elevated physical, intelligence or national security risk. |
| Incident response and remediation were too slow | UpGuard notified TigerSwan on July 21, followed up on July 22 and called again on August 10 after the files remained exposed. The data was not secured until August 24. A TigerSwan representative reportedly did not know why the bucket remained exposed. | Validate that external exposure reports trigger immediate containment, named ownership, escalation and verification of closure. SkySiege was built to help organisations identify exposed cloud assets quickly, assign accountability and confirm remediation rather than relying on informal follow-up. |
| Asset ownership and accountability were unclear | TigerSwan initially said they were working with Amazon to secure the data, but later said the unsecured repository belonged to a former vendor. The delay and confusion suggest weak inventory and ownership mapping for cloud-stored sensitive data. | Validate that every cloud data store has a current owner, business purpose, data classification and lifecycle status, including inherited or vendor-created assets. SkySiege looks for orphaned storage, ambiguous ownership and repositories left behind after vendor termination or process changes as well as access rights. |
This incident is a clear example of how sensitive data can be exposed without any sophisticated intrusion. Anonymous public access on AWS object storage is a known and heavily scanned exposure path. When private data is placed on a service designed to distribute public content, the organisation is not just misconfigured; it has chosen an architecture that makes discovery and abuse easier.
The operational impact extends beyond data leakage. TigerSwan’s delay in securing the bucket after repeated notice shows a weak response process, unclear ownership and insufficient escalation for externally reported cloud exposures. That is a governance problem as much as a technical one. If an enterprise cannot rapidly identify who owns an exposed repository and shut it down, the same weakness will affect future incidents.
The business risk is significant. Exposed applicant and reference data creates direct identity theft and phishing risk, but the profile of the affected individuals raises the stakes: veterans, law enforcement, cleared personnel and foreign nationals linked to coalition operations are attractive targets for criminal and intelligence collection. That increases reputational damage, potential contractual fallout and possible legal exposure where personal data handling duties were not met.
For cloud security programs, the lesson is clear: third-party data handling, public storage architecture and internet-exposed object stores require continuous validation. Visibility must include vendor-managed assets, known public cloud endpoints and storage configurations that permit anonymous access. Without that, enterprises inherit high-severity exposure risk while losing the ability to detect and contain it quickly.
