Exposure Management: Find What Attackers Could Exploit

Last verified on Nov 8, 2026.

Exposure is the part of your system that an attacker could use, whether or not anyone has tried yet. It differs from an active attack. A leaked API key, a dependency with a known exploit or an endpoint missing an authorization check does nothing until someone finds it, and the fix is to find it first.

This guide covers four kinds of exposure you can detect with logs, repositories and dependency data, and how to rank what you find.

Four kinds of exposure

• Secrets and personal data in logs. CWE-532 names this weakness as inserting sensitive information into a log file. The OWASP Logging Cheat Sheet lists what to keep out of logs, including access tokens, authentication passwords, database connection strings, encryption keys and payment card data.
• Vulnerable dependencies. A package you ship has a published advisory.
• Risky code. A new endpoint without an authorization check, or input passed unchecked to a query.
• Risky configuration. Public storage, permissive roles or debug modes left on. The configuration drift guide covers finding these when they appear.

Evidence you can look for

A secret in a log usually arrives inside an error message or a dumped request. Example line:

2026-11-08T16:20:11Z level=error msg="upstream call failed" url=https://api.example.test/v1/charges headers="Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.e30.fake" status=401

Anyone with read access to the log store can now replay that token. Read access to a log store can be broader than access to the production database, which makes this worse.

For dependencies, the evidence is a lockfile entry matching an advisory. For code, it is a diff.

Detect it step by step

1. Scan logs for credential shapes. Search for the formats you actually use: bearer tokens and JWTs (three base64 segments separated by dots), private key headers, connection strings with embedded passwords and cloud keys. AWS documents that IAM access key IDs begin with the prefix AKIA, which gives you a cheap first filter.

-- Example: log lines that contain likely credentials, last 24 hours
SELECT service, count(*) AS hits, min(ts) AS first_seen
FROM logs
WHERE ts >= now() - interval '24 hours'
  AND (message ~ 'AKIA[0-9A-Z]{16}'
       OR message ~ 'eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.'
       OR message ~* 'authorization: *bearer')
GROUP BY service
ORDER BY hits DESC;

2. Scan repositories for hardcoded secrets. GitHub secret scanning looks through the full Git history on all branches for credentials such as API keys, passwords and tokens.
3. Match dependencies against advisories continuously, not at release time. GitHub's Dependabot sends alerts when a new vulnerability is added to the GitHub Advisory Database and when your dependency graph changes. See new advisories and supply chain attacks for the details.
4. Review new code for missing authorization on every route added in a pull request. The risky code guide covers it.

Ranking what you find

A long list of findings is not a plan. Rank by three questions: is it reachable from the internet, is it being exploited and what does it expose?

CISA maintains the Known Exploited Vulnerabilities catalog, which it describes as the authoritative source of vulnerabilities exploited in the wild, and recommends using it as an input to vulnerability prioritization. A dependency advisory that appears in that catalog moves to the top. A secret that grants production write access moves above one that grants read access to a sandbox.

Pitfalls

• Pattern matching on logs produces false positives. Hashes, UUIDs and base64 payloads look like tokens. Validate matches, for example by checking whether a candidate token authenticates, in a controlled way.
• Old logs matter. A secret logged six months ago is still valid if never rotated, so scan retained history once.
• Redacting at query time does not help. The sensitive value is already stored, so fix it at the source or in the pipeline.
• Advisory matching on package name alone overstates risk. Check that the vulnerable function is actually called.

What to do when something is exposed

Rotate first. A secret in a log is compromised for planning purposes, so issue a new one, revoke the old one and review access logs for use of the old one between exposure and revocation. Then fix the code that logged it, redact in the logging layer and purge the affected log range if your store allows it.

For dependencies, upgrade or add a mitigation, and record the exception if you cannot. Whatever collects your logs, such as OpenTelemetry, redact before storage. Scan your GitHub repositories on the same schedule. For the wider picture, read the security monitoring guide.