DEV Community: Tech Legend

How Attackers Find Exposed Cloud Credentials in Your Repos — and How to Stop Them

Tech Legend — Fri, 13 Nov 2026 21:53:59 +0000

Introduction

Every fast-moving development team pushes code daily. Somewhere in that flow, a developer pastes an API key into a config file, commits it, and pushes. It takes seconds — and automated scanners can find that key just as fast.

Exposed secrets in code repositories are one of the most common and most preventable ways cloud environments get compromised. This post breaks down what counts as an exposed secret, how attackers find them, and the practical steps that actually reduce the risk.

What counts as an exposed secret

Cloud access keys — AWS access key IDs and secret keys, GCP service account JSON, Azure storage account keys.
Third-party API keys — Stripe, Twilio, OpenAI, SendGrid, and similar tokens.
Private keys — SSH private keys, signing certificates, .pem files.
Database connection strings — URLs that embed a username and password.
Configuration data — internal endpoints, bucket names, or architecture details that help an attacker move laterally.

How attackers find them

Automated secret scanners. Tools like Gitleaks, TruffleHog, and GitHub's own secret scanning crawl public repositories and match patterns — AWS key formats, Slack tokens, private key headers, and hundreds more.
GitHub dorking. Attackers run targeted searches for filenames and strings: filename:.env, AWS_SECRET_ACCESS_KEY, extension:pem private key.
Mass scanning services. Dedicated services continuously scan the public commit stream and publish or sell what they find. A leaked key can be picked up within minutes of being pushed.

Why it matters

An exposed key is not a theoretical risk:

Data exfiltration — a compromised database credential can dump an entire dataset.
Cloud bill fraud — stolen cloud keys are routinely used to spin up compute resources at the victim's expense.
Lateral movement — a build server or CI credential becomes a beachhead into internal systems.
Service impersonation — an API token lets an attacker act as your application.

Prevention that actually works

1. Never hardcode secrets. Use environment variables or a secrets manager:

# Instead of this
aws_secret_access_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# Do this
export AWS_SECRET_ACCESS_KEY="$(aws secretsmanager get-secret-value --secret-id prod/app --query SecretString --output text)"

2. Add pre-commit hooks. Catch secrets before they ever reach the remote:

# Install gitleaks and run it on staged changes
brew install gitleaks
gitleaks protect --staged

3. Enable secret scanning in CI. Run a scanner on every push and block merges that introduce a match.

4. Use a vault for production. AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault inject secrets at runtime instead of baking them into artifacts.

5. If a secret leaks, rotate immediately. Deleting the file in a new commit is not enough — the secret remains in Git history. Revoke the credential first, then scrub history with git filter-repo and force-push.

A quick checklist

[ ] No secrets in source code or IaC templates
[ ] .env and key files in .gitignore
[ ] Pre-commit secret scanning enabled
[ ] CI blocks merges with detected secrets
[ ] Production secrets come from a vault
[ ] Incident runbook: revoke → rotate → scrub history

Non-Human Identities Are Your Next Security Blind Spot

Tech Legend — Fri, 13 Nov 2026 20:46:03 +0000

Most security programs assume every login belongs to a person. You onboard employees, assign roles, enforce multi-factor authentication and watch for odd behaviour. That model made sense when the only credentials in your environment were human ones. It no longer matches how modern software runs.

Today's infrastructure runs on machine credentials. Service accounts let microservices authenticate to each other. API keys and OAuth tokens connect integrations and internal tools. CI/CD pipelines authenticate to container registries and cloud APIs. Containers and IoT devices carry identities of their own. And a newer category — autonomous AI agents — now holds permissions to read data, approve actions and trigger workflows.

None of these identities has a human typing a password, and most were never designed with the same controls you apply to employee accounts.

Three weaknesses show up repeatedly:

Static, long-lived credentials. API keys and hardcoded secrets often never expire and are rarely rotated. A leaked key can stay valid for months.
Over-privilege. Service accounts accumulate permissions they no longer need, because removing access feels riskier than leaving it in place.
Poor visibility. Logging and monitoring are tuned to human behaviour. Machine traffic looks different, and without context it is hard to tell a legitimate automated call from a compromised identity.

What actually helps:

Inventory first. Catalog service accounts, API keys, tokens and agents, and give each one an owner.
Apply least privilege, and revisit permissions when the workload changes.
Shorten credential lifetimes — rotating tokens or certificate-based authentication beat static keys.
Centralise secrets management in a vault that supports rotation and audit logging.
Monitor machine behaviour: call volume, destination and timing, not just failed logins.
Validate every API call — authenticate, authorise and schema-validate, even when the call comes from inside your network.

Securing non-human identities is less about buying a product and more about changing a default: every identity, human or machine, is verified, scoped and monitored.

Full analysis: https://hsecurities.in/blog/non-human-identities-cybersecurity-risks
More security deep-dives: https://hsecurities.in/blog

Some AI-assisted.

RHEL 10.3 and 9.9: the security and AI changes worth planning around

Tech Legend — Thu, 12 Nov 2026 00:40:30 +0000

Red Hat's latest enterprise Linux releases — RHEL 10.3 and RHEL 9.9 — land with a clear focus: harder defaults, verifiable supply chains, and AI tooling that runs inside the OS rather than bolted on top.

The security side is the part most teams will feel first. Both releases tighten default kernel parameters, improve memory-protection mechanisms such as Control Flow Integrity, and give administrators more granular SELinux policy controls. Red Hat has also leaned into supply-chain provenance, tracking the origin and integrity of dependencies in container images and installed packages. For regulated environments, that is a meaningful reduction in attack surface without waiting on application changes.

The AI angle is more practical than it sounds: RHEL 10.3 ships tooling that can use local or private-cloud LLMs to help with debugging, code generation, and producing initial hardening scripts from application manifests. The goal is to make secure configuration the default path rather than a specialist task.

If you run RHEL in production, treat this as a security milestone rather than a routine bump. Inventory your hosts, pilot the upgrade on staging, check the release notes for breaking changes, and re-scan after patching to confirm the vulnerable packages are gone.

We broke down the full advisory — the key changes, affected components, and upgrade steps — in our report: https://hsecurities.in/blog/red-hat-rhel-10-3-and-9-9-security-ai-features

Some AI-assisted.

Non-human identities are the access problem nobody tracks

Tech Legend — Tue, 10 Nov 2026 10:17:48 +0000

Most access reviews still focus on human users. Yet a typical estate holds far more machine identities than people: service accounts, API keys, OAuth tokens, container workload identities and AI agents — each with credentials that can read data or trigger actions.

The lifecycle is where these identities go wrong. They are created quickly, given broader permissions than needed, rarely rotated, and almost never deactivated. A leaked API key in a public repository, or a forgotten service account with admin rights, is a direct path into production.

A practical starting point:

Inventory every credential that is not a person. Include API keys, tokens, service accounts and workload identities.
Apply least privilege. Each identity should hold only the permissions its workload needs.
Rotate on a schedule and revoke credentials the moment a workload is retired.
Treat AI agents as identities. An agent that can call your APIs is an access principal and should be audited like one.

The risk is not that machines are logging in. It is that nobody is keeping track of what they can do. The full threat-landscape overview, with the attack path and the controls that actually help, is here: https://hsecurities.in/blog/non-human-identities-cybersecurity-risks

This post is an AI-assisted summary of hSECURITIES research.