In early 2026, a supply chain engineer at a mobile SDK vendor serving roughly 1,200 apps began what they expected to be a routine two-week patch audit of seven third-party SDKs integrated into their product. What they found instead forced an immediate reassessment of how the company treated third-party code: dormant signing keys, stored in plaintext config files, that had not been rotated in over three years. Some keys were tied to production AWS accounts; others were shared across iOS and Android builds. There was no documentation on where the keys came from or when they were meant to expire. The discovery highlighted a gap that security teams often overlook.

A Routine Audit That Uncovered a Silent Threat

The audit was triggered by a quarterly security review. The engineer, who asked not to be named due to company policy, was tasked with verifying that all integrated SDKs were on supported versions and that no known vulnerabilities had been introduced since the last check. The scope covered seven SDKs: three for analytics, two for crash reporting, one for ad mediation, and one for push notifications. Some were open-source; others were commercial libraries distributed as binary frameworks.

Within the first three days, the engineer noticed something odd. A config file for an analytics SDK contained a base64-encoded string that, when decoded, revealed a private RSA key. The file was part of the SDK's resource bundle and had been shipped with every app build for at least two years. A grep across the codebase turned up more: JWT tokens, API keys, and even a certificate thumbprint — all hardcoded and never flagged by the team's static analysis tools.

Further investigation showed that the keys had been embedded during the initial integration, roughly three and a half years earlier, and carried forward through every SDK update since. No one had questioned their presence. The engineer later told colleagues that the find felt like opening a wall socket and discovering the wiring was live and undocumented. The company's security team estimated that, at peak, the exposed keys could have affected hundreds of downstream apps that relied on the vendor's SDK. Fortunately, there was no evidence of compromise — but the audit made clear that the organization had been running on borrowed time.

How Dormant Keys Become a Supply Chain Gap

Dormant signing keys are a classic supply chain vulnerability. They typically originate during initial SDK integration, when a developer copies a configuration snippet from the vendor's documentation. That snippet often includes a sample key or token intended for testing, but it ends up in production. Once committed, the key becomes part of the codebase and is rarely revisited.

SDK updates compound the problem. When a new version is released, teams often copy the entire SDK bundle — config files and all — without auditing what's inside. The old keys persist. Over time, the original purpose of the key is forgotten. Was it for signing? Authentication? Telemetry? No one remembers.

The engineer's audit found that none of the seven SDKs had automated key expiry or rotation policies. In one case, a key was tied to an AWS IAM role that granted read access to a production S3 bucket containing customer data. The key had been active for roughly 1,200 days — far beyond any reasonable rotation window. The vendor's documentation mentioned key rotation as a best practice but provided no tooling to enforce it.

This gap is not unique to small vendors. A 2025 study by a university security lab found that roughly 12% of popular SDKs on Maven Central and npm contained hardcoded credentials, and less than half of those had been rotated within two years. The problem is systemic: SDK authors often treat keys as an implementation detail rather than a security boundary.

The Seven SDKs and the Scope of Exposure

The audit covered seven SDKs, each with a different risk profile. The analytics SDK mentioned earlier held the most damaging key — a signing certificate that could have been used to forge updates. The crash reporting SDK contained a JWT token that allowed access to the vendor's API for fetching symbolication data. An ad mediation library had a hardcoded API key for a third-party ad exchange, which could have been used to impersonate the app and serve malicious creatives.

Two of the SDKs were open-source. In those cases, the keys were visible in the public repository's commit history, though they had been removed from the latest version. The engineer checked the git log and found that one key had been accidentally pushed in a commit message three years ago and never purged. The other open-source SDK had a key that was still present in the latest release but marked as "deprecated" — with no removal date.

The commercial SDKs were distributed as binary frameworks, making inspection harder. The engineer had to use a combination of strings, nm, and a custom Python script to extract embedded strings from the compiled libraries. One framework contained a hardcoded AWS secret key in a plist file that was not even used by the SDK's code — it was left over from the vendor's internal testing.

The estimated downstream impact was significant. The company's SDK was integrated into roughly 1,200 mobile apps, many from well-known brands. If any of the dormant keys had been leaked, an attacker could have signed malicious updates that would be trusted by the operating system's code-signing verification. The engineer noted that the attack surface was similar to other supply chain incidents where a backdoor was introduced via a compromised credential — except here, the keys themselves were the weak link.

The Engineer's Methodology: What They Checked

The engineer's approach was methodical and reproducible. They started with a simple grep across the entire codebase, looking for patterns that matched known private key formats — RSA, ECDSA, Ed25519 — as well as base64-encoded blobs longer than 256 characters. The regex patterns were adapted from the open-source tool truffleHog, but the engineer ran them locally to avoid sending sensitive data to a third-party service.

Next, they cross-referenced any found keys against public GitHub leak databases, including the one maintained by the GitGuardian team. This step identified two keys that had already been exposed in public commits — one from a fork of the analytics SDK that had been deleted, but whose commit history was still accessible. The engineer also checked the shifts in configuration drift that had previously caused outages, noting that similar drift had allowed the keys to persist unnoticed.

For each SDK, the engineer examined the commit history in the vendor's repository (when available) to see when the key was introduced and whether it had ever been rotated. In one case, the key was added in the initial commit of the SDK's public repository and never touched again. In another, the key was rotated once — but the old key was left in the codebase as a comment, with a note saying "deprecated, remove in next version." The next version was released two years later, and the comment was still there.

Static analysis tools were also used. The engineer ran Semgrep with a custom rule set that flagged hardcoded credentials in configuration files. The tool caught several keys that the grep had missed because they were stored as environment variable defaults. The engineer also used Checkov to scan Docker images and CI/CD configuration files for embedded secrets, though only two of the seven SDKs had associated Dockerfiles.

To provide a concrete example, consider the case of the crash reporting SDK. The engineer extracted a JWT token from a plist file using strings. The token was base64-encoded and had no expiration claim. Decoding revealed it was a service account token for the vendor's API. The engineer traced the token back to a commit from 2022, where it had been added as part of a quick integration test. The vendor's documentation did not mention any token requirements, and the token's purpose was unclear. After contacting the vendor, the engineer learned the token was meant for server-side symbolication but had been accidentally included in the client SDK bundle. The vendor issued a new, scoped token within 24 hours and removed the old one from their distribution.

Why This Escaped Previous Reviews

The fact that these keys went undetected for years is a cautionary tale about how security reviews are scoped. The company's previous audits focused on runtime behavior — buffer overflows, injection vulnerabilities, and insecure deserialization — but did not examine static configuration files. The assumption was that SDK vendors managed their own key hygiene.

SDK updates were treated as black-box binary drops. The team downloaded the latest version from the vendor's portal, replaced the old files, and rebuilt. No one inspected the contents of the bundle. The CI/CD pipeline did not include a secret scanning step because the team believed that secrets were only an issue in their own code, not in third-party libraries.

Standard SAST tools, such as those from Veracode and SonarQube, did not flag the keys because they were not in source code — they were in resource files that the tools were configured to ignore. The engineer later discovered that the SAST configuration excluded .plist, .json, and .xml files by default, assuming they contained only data, not credentials.

The team's security culture also played a role. There was no formal policy for reviewing SDK configurations. A previous build system incident had shown how easily configuration errors could cascade, but the lessons from that incident did not extend to third-party code. The engineer noted that if the same scrutiny applied to internal code had been applied to SDKs, the keys would have been caught within weeks, not years.

Remediation: Rotating Keys and Hardening Pipelines

Once the audit was complete, the engineer's team moved quickly. All seven SDKs had their keys revoked and rotated within 48 hours. For the commercial SDKs, the team contacted the vendors directly and requested new credentials. Two vendors responded within hours; one took three days and required a signed NDA. The open-source SDKs were forked, and the keys were removed from the public repositories after coordinating with the maintainers.

The company added a secret scanning step to its CI/CD pipeline using truffleHog and GitLeaks. The scan runs on every commit, including those that update third-party SDKs. Any finding above a certain confidence threshold blocks the build and notifies the security team. The engineer also implemented automated key expiry alerts: any credential with a creation date older than 90 days triggers a warning, and at 180 days it escalates to a ticket.

Beyond internal changes, the team pushed SDK vendors to adopt short-lived certificates and ephemeral tokens. One vendor agreed to implement OAuth 2.0 device flow for their API, eliminating the need for long-lived secrets. Another vendor pushed back, arguing that short-lived certificates would increase support overhead. The compromise was to offer both options, with the short-lived path being the default for new integrations.

The company published an internal post-mortem with an actionable checklist. It included steps like: verify key origin during initial integration, set a calendar reminder for rotation, and never ship a config file without reviewing it. The checklist was shared with the wider engineering organization and later adopted by two other teams that managed similar SDK integrations.

Lessons for Engineering Teams Everywhere

The engineer's audit is a reminder that SDK integrations are ongoing security debt, not one-time setup costs. Every library version bump is an opportunity to review what's inside. Teams should treat every hardcoded credential as already compromised — because in a supply chain context, it very well might be.

Adopting infrastructure-as-code for key lifecycle management can help. Tools like HashiCorp Vault or AWS Secrets Manager allow teams to generate short-lived credentials programmatically and rotate them without human intervention. But these tools only work if they are integrated into the SDK update process, which requires vendor cooperation. Some vendors still distribute static configuration files as a convenience, and it's up to the consumer to strip them.

Industry working groups like OWASP's Software Component Verification Standard (SCVS) provide guidelines for vetting third-party components, but adoption is uneven. The engineer suggested that SDK vendors should be required to publish a security manifest that lists all embedded credentials, their purpose, and their rotation schedule. Until that becomes standard, the burden falls on downstream teams.

Not everyone agrees on the scope of the problem. Some argue that the risk is overstated — that an attacker would need both the key and access to the build pipeline to exploit it. But the engineer's counterargument is that the 2024 XZ Utils backdoor showed that a single compromised credential can be enough, especially when combined with social engineering. The dormant keys found in this audit were not exploited, but that does not guarantee future safety.

So here is the question every team should ask before their next SDK update: When was the last time you inspected the config files inside that library you just downloaded? If you cannot answer that, you may be carrying dormant keys of your own.