Topic starter
24/06/2026 5:48 pm
TL;DR: Unosecur reports that two exposed AWS access keys and multiple hard-coded service tokens gave access to more than 70 TB of Tata Motors data across cloud and analytics systems, showing how static credentials and client-side secret handling create invisible entry points that perimeter controls miss. The real failure is treating secrets as deploy-time artefacts instead of governed identities with lifecycle controls.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Lessons from Tata Motors: When Static Keys Expose 70TB of Data”.
Key questions
Q: What breaks when secrets are embedded in browser code?
A: The secret stops being secret.
Q: Why do exposed API keys and tokens create such a high-risk failure mode in software delivery?
A: Exposed secrets matter because they often grant direct access to cloud accounts, source repositories, databases, or release pipelines.
Q: How can security teams tell whether token issuance is too weak?
A: Look for token creation paths that do not require strong server-side verification, especially when administrative or impersonation access is involved.
Practitioner guidance
- Remove credentials from public assets Scan client-side code, repositories, and public web bundles for live keys, tokens, and decryption routines, then eliminate any secret that can be recovered by a page load.
- Replace static keys with short-lived authority Move high-value cloud access to temporary roles and scoped tokens so exposed credentials expire quickly and cannot be reused across storage or analytics systems.
- Tighten token issuance controls Require password verification, multi-factor checks, or equivalent server-side proof before any workflow can mint dashboard or admin tokens.
Bottom line: This incident shows that exposed cloud secrets are identity exposures, not isolated configuration mistakes.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The exact Tata Motors exposure paths, including E-Dukaan, FleetEdge, Tableau, and the test-drive portal
- The specific credential patterns that allowed public recovery of AWS keys and trusted tokens
- The remediation actions described after coordinated disclosure, including rotation and containment steps
- The identity telemetry patterns the vendor says teams should monitor for early warning
👉 Read Unosecur's analysis of exposed cloud keys and tokens at Tata Motors →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:43 am
Cloud key exposure is an identity failure, not a storage failure. When access keys and API tokens live in public assets, the organisation has already lost control of the identity boundary that protects cloud data. Storage encryption and perimeter monitoring cannot compensate for credentials that are distributed through client-side code. The practical conclusion is that secrets governance must be treated as core IAM work, not as a developer hygiene side issue.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should organisations prioritise secret rotation or secret discovery first?
A: They should do both, but rotation is the control that reduces immediate exposure when a secret is already live. Discovery tells you where the problem is. Rotation and revocation tell you whether the credential still works. If you can only choose one urgent action after a leak, invalidate the credential and confirm it is no longer active.
👉 Read our full editorial: Exposed cloud keys and tokens expose the limits of secrets management