Notifications
Clear all
Topic starter
06/06/2026 1:32 am
TL;DR: Oracle database access still relies on static, long-lived passwords in many enterprise environments, even when those credentials are hidden in secrets managers or rotated manually, according to Aembit. Policy-driven, connection-time credential injection changes the control point from stored secrets to auditable workload access, which tightens NHI governance without requiring application code changes.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
Questions worth separating out
Q: What breaks when Oracle database passwords stay embedded in application access paths?
A: Static Oracle passwords create reuse, sharing, and delayed rotation risk.
Q: Why do Oracle workloads increase NHI governance complexity?
A: Oracle workloads often sit in regulated systems, use long-lived service credentials, and span multiple deployment models such as VMs, containers, and managed databases.
Q: How do security teams know whether Oracle secret handling is actually working?
A: Look for reduction in reusable passwords, fewer shared secrets across services, and complete attribution for each database session.
Practitioner guidance
- Remove reusable Oracle passwords from application ownership Replace embedded or manually rotated database credentials with connection-time injection so the application never stores the real secret in config files or code.
- Map Oracle database access to a policy-bound workload identity Define which service, environment, and database targets are allowed to connect, then make connection approval depend on that policy rather than on possession of a long-lived password.
- Audit shared Oracle credentials across regulated services Identify every Oracle 19c and 21c workload that still uses a shared password, then trace how many services can authenticate with the same secret and when it was last rotated.
What's in the full announcement
Aembit's full post covers the operational detail this analysis intentionally leaves for the source:
- The Oracle protocol handling sequence, including transparent TNS interception and O5LOGON credential injection.
- The exact setup path for Oracle 19c and 21c on Linux VM and containerised deployments.
- The client runtime requirements for Java, Python, Go, and Node.js thin clients.
- The TCPS configuration details for client-to-proxy and proxy-to-database traffic.
👉 Read Aembit's Oracle database access post for protocol and deployment details →
Oracle database credentials: what it means for IAM teams?
Explore further
06/06/2026 2:43 am
Static Oracle passwords are a governance liability, not an implementation convenience. The pattern described here is not unusual because Oracle often sits inside ERP, finance, and regulated workloads where teams accept long-lived credentials for operational continuity. That convenience creates audit gaps, shared-secret risk, and delayed rotation. The practitioner conclusion is simple: Oracle access should be governed as a workload identity problem, not left as an application secret-management afterthought.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who is accountable for Oracle workload credentials when a service is retired?
A: The owning application or platform team remains accountable until the database entitlement is removed and any standing secret is revoked. If the workload is retired but the Oracle credential still works, offboarding has failed. Compliance teams should require a clear owner, a revocation record, and evidence that the old access path no longer authenticates.
👉 Read our full editorial: Oracle database access still exposes static secrets in NHI governance
