Notifications
Clear all
Topic starter
30/07/2026 10:49 pm
TL;DR: python-dotenv still works for solo prototypes, but .env files create leak risk, no audit trail, and manual rotation pain once teams, multiple environments, or production deployments enter the picture, according to Infisical. The real issue is that plaintext secrets and environment separation by convention do not scale into governed NHI practice.
NHIMG editorial — based on content published by Infisical: Should You Still Use python-dotenv in 2026?
By the numbers:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
- 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.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams handle .env files in team-based Python projects?
A: Use .env files only as a local development convenience, not as a shared secret store.
Q: Why do .env files create problems for secret rotation?
A: Because one secret is usually copied into many places, and each copy must be changed separately.
Q: What do teams get wrong about using os.environ for secrets?
A: They assume the runtime lookup is the control, when it is only the retrieval method.
Practitioner guidance
- Inventory every .env file and secret copy Map where each credential appears across local machines, repositories, CI jobs, and deployment artefacts.
- Move shared environments to controlled secret retrieval Replace team-shared .env files with a secrets manager or workload identity flow that injects secrets at runtime.
- Separate prototype convenience from production governance Allow .env usage only in isolated development or single-user contexts where the blast radius is small.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Side-by-side Python examples for os.environ, python-dotenv, pydantic-settings, and Infisical runtime injection
- Framework-specific notes for Django, Flask, and FastAPI configuration flows
- CLI and SDK usage patterns for importing .env files and fetching runtime secrets
- Practical migration detail for moving from local files to centrally managed secrets without rewriting application logic
👉 Read Infisical's analysis of why python-dotenv stops scaling for shared secret governance →
Python dotenv and .env files: where do they break down for teams?
Explore further
30/07/2026 10:57 pm
.env files are a secret distribution mechanism, not an identity governance mechanism. The article is correct that python-dotenv solves local friction, but it also normalises plaintext secret sprawl across repositories, laptops, and shared deployment paths. That is an NHI problem because the credential's reach is now determined by file copying rather than policy, ownership, or lifecycle state. Teams should stop treating .env usage as a configuration preference and recognise it as a governance decision.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should organisations do instead of sharing .env files?
A: Use a secrets manager or workload identity approach that delivers secrets to the process at runtime, tied to a specific human, server, or pipeline identity. That gives you control over access, rotation, and logging, while preserving the same application behaviour inside Python.
👉 Read our full editorial: Python dotenv still fits prototypes, not team-scale secret governance
