Every Environment Security Audit check

A .env file committed to git — even once, even years ago — permanently exposes every secret it contained. Git history is not cleared by deleting the file from the working tree. Attackers who clone your repo, access a GitHub fork, or pull a leaked archive get your database passwords, API keys, and OAuth secrets instantly. OWASP A05 (Security Misconfiguration) and NIST SC-28 both flag unprotected sensitive data at rest. The blast radius is immediate: a single committed production .env means every secret in it is compromised and must be rotated before you do anything else.

Why this severity: Critical because a committed .env file permanently exposes production credentials to anyone with repository access, making secret rotation mandatory regardless of when the commit occurred.

Hardcoded secrets in source code violate CWE-798 (Use of Hard-coded Credentials) and OWASP A07 (Identification & Authentication Failures), and they are permanent: unlike a leaked .env file, a credential baked into a function call survives every deployment, every refactor, and every repo clone. A Stripe live key or database password embedded in a TypeScript file is readable by every developer, CI runner, contractor, and open-source contributor who touches the repo. NIST IA-5 requires credential management controls — hardcoded values have no rotation path, no access control, and no audit trail.

Why this severity: Critical because hardcoded credentials are unrevokable without a code change and are visible to everyone with repository access, making targeted rotation impossible.

CI/CD pipeline logs are often stored for months and accessible to every team member, contractor, and sometimes even public viewers on open-source projects. A secret printed to a GitHub Actions log — even for one second before a run is cancelled — is captured and searchable. CWE-532 (Insertion of Sensitive Information into Log File) and OWASP A09 (Security Logging and Monitoring Failures) both classify this as a security failure. Rotating a secret that appeared in a CI log is non-trivial because you cannot know who has read or downloaded the log before you noticed the exposure.

Why this severity: High because CI logs are broadly accessible within an organization and often retained for months, giving a long window for secret exfiltration after accidental exposure.

Flat `.env` files synced to servers are a single point of compromise: one leaked file, one misconfigured S3 bucket, or one server breach exposes every production credential at once. Dedicated secrets managers — AWS Secrets Manager, HashiCorp Vault, Azure Key Vault — provide access control per secret, audit logs of every retrieval, automatic rotation, and versioned history. OWASP A05 (Security Misconfiguration) and NIST SC-12 both require protecting the integrity of keys and credentials throughout their lifecycle. PCI-DSS 4.0 Req-3.5 mandates protecting stored credentials, which flat files cannot satisfy for any cardholder data environment.

Why this severity: High because flat .env files on servers have no per-secret access control or audit trail, making breach detection and targeted rotation impossible when any one credential is exposed.

An API key with full administrative access is a skeleton key: if it leaks — through a log line, a git commit, a compromised developer laptop — the attacker inherits every permission you have. OWASP A01 (Broken Access Control) and NIST AC-6 (Least Privilege) both require limiting credentials to only the operations they need. A Stripe key scoped to charge creation cannot be used to delete customer data or issue refunds. A SendGrid key scoped to sending cannot expose your contact list. PCI-DSS 4.0 Req-7.2 requires that access to system components is appropriately defined and granted — overly broad API keys violate this at the integration layer.

Why this severity: High because an over-permissioned API key that leaks grants an attacker the same broad access as the application, expanding the blast radius of any credential compromise.

Using the same environment configuration across development, staging, and production means a developer mistake in a test environment can hit production data, a staging webhook fires against live Stripe, or a misconfigured query runs against the production database. CWE-1188 (Use of Hardcoded Default Values) and OWASP A05 both flag shared configurations as a misconfiguration risk. NIST CM-6 requires controlled configuration management — shared `.env` files with no environment separation make that impossible to enforce. Beyond security, shared configs make incident response harder: you cannot revoke a staging credential without also revoking the production one.

Why this severity: High because shared environment configs mean a misconfiguration, test, or breach in any environment can directly impact production systems and data.

A staging environment connected to the production database is not a staging environment — it is a second production environment with weaker access controls. Bugs discovered during staging testing can corrupt, delete, or expose real user data. Developers routinely write aggressive cleanup scripts, run schema migrations, and insert test data in staging, assuming isolation that doesn't exist. NIST SC-7 requires boundary protection between system components. OWASP A05 flags misconfiguration that allows unintended data access. A staging breach that exposes a shared database URL puts the production database password in the attacker's hands.

Why this severity: Medium because connecting staging to a production database or using production credentials in staging directly risks real user data during routine development and testing operations.

Production credentials accessible without MFA mean a single compromised developer account — through phishing, credential stuffing, or a breached password manager — gives an attacker full access to modify environment variables, redeploy the application, or exfiltrate secrets. OWASP A07 (Identification & Authentication Failures) and NIST IA-3 both require strong authentication for administrative access. Without audit trails (NIST AU-2), you cannot determine whether a production credential was accessed after a breach, making incident response blind. Many insurance and compliance frameworks now require MFA for any system with access to production credentials.

Why this severity: Medium because MFA absence on production access is a single-factor authentication failure that allows credential stuffing or phishing to fully compromise production environments.

Credentials that are never rotated accumulate exposure surface: every developer who ever handled a secret, every system it transited, and every breach that went undetected leaves a window open indefinitely. NIST IA-5 (Authenticator Management) requires organizations to manage credential lifetimes. PCI-DSS v4.0 Req-8.6.3 requires passwords/passphrases for application and system accounts to be changed periodically per a targeted risk analysis — the correct control for service-credential rotation. CWE-522 (Insufficiently Protected Credentials) encompasses stale credentials as a protection failure. Without documented intervals, there is no way to verify compliance, respond to a suspected breach with targeted rotation, or demonstrate due diligence during an audit.

Why this severity: Medium because undocumented or unenforced rotation leaves credentials exposed indefinitely after any breach or insider departure goes undetected.

Feature flags hardcoded in source code or set to the same value across all environments create two distinct risks: debug panels, admin shortcuts, and incomplete features ship to production, and toggling them requires a code change and redeployment rather than a configuration update. OWASP A05 (Security Misconfiguration) and CWE-1188 both flag hardcoded defaults as a misconfiguration class. A debug panel exposed in production can leak stack traces, internal routes, or database query details. A payment feature flag stuck at `true` in staging that also runs in production will charge real customers for test transactions.

Why this severity: Medium because hardcoded feature flags allow debug or incomplete features to surface in production, where they can expose internal system details or trigger unintended behavior.

Example files and README docs are copied verbatim by developers setting up new environments. A `.env.example` containing a real-looking API key format like `sk_test_51abc...` trains developers to paste real keys into that pattern, and anyone who clones the repo might assume the example value is valid and try it. CWE-798 (Use of Hard-coded Credentials) and CWE-521 (Weak Password Requirements) both apply when examples provide credential values that normalize insecure patterns. OWASP A07 includes authentication failures caused by weak credential templates. An example with `password: 'password'` signals to every developer that weak passwords are acceptable.

Why this severity: Low because default or weak passwords in examples cannot be exploited directly but normalize insecure credential choices and increase the likelihood that developers reuse them in real deployments.

An application that silently starts without a required environment variable will either crash at the specific moment the missing config is first used — mid-request, during a payment, or at checkout — or it will fall back to an undefined value and behave incorrectly without any error. OWASP A05 (Security Misconfiguration) covers misconfigured applications that fail silently. CWE-390 (Detection of Error Condition Without Action) applies when missing configuration is neither detected nor surfaced. Startup validation converts a runtime surprise into a deployment-time failure, where it is cheap to catch and easy to diagnose.

Why this severity: Low because missing startup validation causes runtime failures at the point of use rather than at startup, making configuration errors harder to diagnose and increasing MTTR for deployment issues.

Infrastructure-as-Code files are source code: they are version-controlled, shared with teams, reviewed in pull requests, and often mirrored on GitHub. A Terraform file containing a hardcoded database password or a CloudFormation template with an embedded API key exposes those credentials to everyone with repository access and permanently records them in git history. CWE-798 applies directly to IaC secrets. OWASP A05 covers misconfigured infrastructure. SSDF PW.6 requires protecting code from unauthorized disclosure, which IaC with embedded secrets violates by definition.

Why this severity: Low because IaC files are versioned and broadly accessible, meaning a hardcoded secret in a Terraform file exposes credentials to the entire development team and any future repository clone.

Configuration drift happens silently: a developer manually changes a production environment variable to debug an incident, forgets to revert it, and weeks later the application behaves differently in production than in staging with no explanation. NIST CM-3 requires controlled configuration change management. ISO 27001:2022 A.8.9 mandates configuration management. Without a drift detection mechanism, you cannot detect unauthorized configuration changes, reconcile environments after incidents, or demonstrate configuration control to auditors. The cost of undiscovered drift compounds: each subsequent change is made against an unknown baseline.

Why this severity: Low because undetected configuration drift causes environment inconsistencies that are difficult to diagnose and can silently undermine security controls applied in one environment but not another.

Backup credentials stored in the same secrets store as primary credentials collapse the security boundary between your production system and your recovery system. If primary credentials are compromised, the attacker also has the backup credentials — and the backup process may have elevated permissions to access data that the primary application cannot touch. NIST CP-9 requires protecting backup data with the same rigor as the primary system. CWE-522 applies when backup credentials are insufficiently protected. Over-broad backup credentials also create a data exfiltration vector: an attacker with backup access can pull a full database dump without triggering normal access controls.

Why this severity: Low because backup credentials stored alongside primary credentials eliminate the security isolation that makes a separate backup process valuable during a breach or insider threat scenario.

Without secrets manager audit logs, you cannot answer the most critical post-breach question: which secrets were accessed, by whom, and when? CWE-778 (Insufficient Logging) and OWASP A09 (Security Logging and Monitoring Failures) both identify missing audit trails as a security failure. NIST AU-2 requires that organizations define events to be logged — secrets retrieval is the highest-priority event in that list. PCI-DSS 4.0 Req-10.2 mandates logging all access to audit logs themselves and cardholder data resources. Without these logs, incident response is blind, forensic timelines cannot be established, and compliance cannot be demonstrated.

Why this severity: Info because audit log gaps do not directly expose secrets but eliminate the forensic record needed to detect unauthorized access and scope a breach after the fact.

Database credentials that are never rotated represent an indefinite exposure window: a breach discovered six months late, a departed employee, or a compromised developer machine may have leaked those credentials with no way to detect it retroactively. NIST IA-5 requires authenticator management including credential lifetime controls. PCI-DSS v4.0 Req-8.6.3 requires passwords/passphrases for application and system accounts to be changed periodically per a targeted risk analysis and protected against misuse — the correct control for database service-account credentials. CWE-522 covers insufficiently protected credentials, which includes stale credentials that cannot be revoked because no rotation process exists. Without documented last-rotation dates, you cannot demonstrate compliance or reason about the risk surface.

Why this severity: Info because stale database credentials do not represent an active vulnerability but create an unbounded exposure window if a past breach went undetected.

API keys that are never deactivated accumulate across developer departures, vendor changes, and tool evaluations. An old Stripe key issued to a former contractor, a SendGrid key from a deprecated integration, or an OpenAI key created for a proof-of-concept all remain valid indefinitely unless explicitly revoked. NIST IA-5 requires managing authenticator lifetimes. PCI-DSS v4.0 Req-8.6.3 requires passwords/passphrases for application and system accounts to be changed periodically per a targeted risk analysis — the correct control for API-key lifecycle. CWE-522 covers credentials that are not adequately protected throughout their lifecycle. An attacker who obtains a three-year-old API key through any historical leak finds it just as usable as one issued today.

Why this severity: Info because unrotated API keys create long-lived exposure windows but require prior credential compromise to be exploited; the risk is proportional to how old the keys are.