Credential / API Token: Data Point Intelligence Guide

An exposed credential is not a curiosity to explore. It is an incident with a clock running, and the only correct first move is revocation.

Understanding the Credential / API Token as an intelligence artifact

A credential data point is a secret that authenticates access: an API key, OAuth token, JSON web token, cloud access key pair, database connection string, private key or webhook URL. Most have recognisable structure, whether a provider prefix, a fixed length, an embedded checksum, or encoded segments carrying claims. That structure is what makes automated detection feasible at scale. The secret represents delegated authority: it names a principal, carries a scope, and frequently has no expiry, which is why a single exposure can grant durable access to data and infrastructure.

Formats drive triage. Provider-prefixed tokens are identifiable and often revocable programmatically. High-entropy random strings without prefixes require contextual detection and generate far more noise. JSON web tokens are decodable without any key and expose issuer, subject, audience, scope and expiry in the payload. Cloud key pairs identify an account directly. Connection strings bundle host, database, username and password on one line, making them the highest-impact single-line exposure.

Why it matters

Exposed secrets are the shortest path from public information to internal access, which is precisely why defenders must find them first. Detection tells you which systems are reachable, which teams have weak secret hygiene, and whether rotation processes actually work in practice. In incident response the credential defines scope: the principal it names bounds what an attacker could have touched, and its creation and exposure dates bound the window that logs must be examined for.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Provider prefix and format identifying which service the secret belongs to, and therefore who must revoke it.
Token claims such as issuer, subject, audience, scope and expiry that define blast radius without ever using the token.
Commit or publication timestamp and author, bounding the exposure window and identifying the team that must be notified.
Location of exposure, whether public repository, package artifact or paste, indicating whether search engines have already indexed it.
Surrounding configuration revealing environment, hostnames and whether the secret belongs to production or a sandbox.
Repeat exposures by the same author or pipeline, marking a process failure rather than an individual mistake.
Presence inside build artifacts, container image layers or minified bundles, where secrets survive long after source is cleaned.
Audit log activity for the named principal after the exposure date, determining whether the leak was actually used.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

TruffleHog — Scans repositories, filesystems and images for secrets and can verify whether a detected credential is still live.
gitleaks — Fast rule-based secret scanning across git history, with pre-commit hooks and customisable detectors.
GitHub secret scanning and push protection — Native detection with provider partnerships that can automatically revoke leaked tokens on public repositories.
detect-secrets — Baseline-driven scanning designed for CI integration and for managing known false positives over time.
GitHub code search — Locates configuration patterns and accidental commits across public repositories during defensive sweeps.
Cloud provider audit logs — CloudTrail, Azure Activity and Cloud Audit Logs determine whether an exposed principal was used and from where.
Provider token management consoles — Authoritative scope, last-used and revocation controls for tokens issued to your own organisation.
Have I Been Pwned domain monitoring — Alerts when organisational addresses appear in credential dumps requiring forced rotation.

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Contain first — Revoke or rotate the credential through the issuing provider immediately, before any further analysis, and never test it against the target.
Identify the principal — Determine which account, scope and environment the secret authorises, using provider consoles and decoded token claims.
Bound the window — Find the commit, build or post that introduced it and the moment it became public, to define the exposure period precisely.
Check for use — Pull audit and access logs for the principal across the exposure window and look for unfamiliar source addresses or unusual calls.
Purge every copy — Remove from git history, build caches, container layers, artifact registries, wikis and backups, not only the current branch.
Fix the pipeline — Add push protection, pre-commit scanning and a managed secrets store so the same class of exposure cannot recur.
Notify and document — Inform the owning team and, where third-party data was reachable, assess and discharge breach notification obligations.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Collected by these disciplines

Cyber Intelligence — Adversary Activity in Networks and Systems
Identity Intelligence — Resolving and Verifying Who Someone Is
Attack Surface Intelligence — Your Own Exposed Attack Surface
Breach Intelligence — Exposed Credentials and Compromised Data
Certificate Intelligence — TLS Certificates and Certificate Transparency
Domain Intelligence — Domains, DNS, and Registration Intelligence

Investigated in these domains

Pivots to these data points

Detection Signature — A YARA/Sigma/Snort rule encoding detection logic for a malware family or behavior.

Inside the platform: where Credential / API Token lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

datapoint.php?dp=dp_api_key — Data point hub
domain.php?d=opsec — Operational Security dashboard
domain.php?d=insider — Insider Threat dashboard
domain.php?d=emergingtech — Emerging Technology & AI Security dashboard
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Enrichment Runner
Enrichment → Local
Correlate Infrastructure
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Contain first is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Bound the window turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Notify and document feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Credential / API Token

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Revocation comes before analysis. A defence organisation or contractor that finds an exposed credential treats it as an incident with a running clock: rotate through the issuing provider first, then investigate. Credentials leaked from defence supply chains expose build pipelines, telemetry stores and partner integrations, which is a force protection and operational security matter rather than an IT housekeeping one. Analysts must never authenticate with a discovered credential to see what it reaches, including against a contractor system; that is unauthorised access and is separately a counter-intelligence risk if it alerts an adversary. Products are exposure reports, rotation completion evidence and supply chain advisories to programme offices.

🕵 National intelligence

For national intelligence the defensive question is what exposure exists across national infrastructure and the industrial base, and the answer is delivered as notification and remediation, not exploitation. Where a credential belonging to a national entity is found in public space, the correct response is rapid notification to the owner and the issuing provider so it can be revoked. Analysts do not test, validate or use discovered credentials under any circumstance. Aggregate reporting on exposure rates by sector supports policy and assurance requirements. Handle discovered secrets as sensitive: retain only the minimum needed to enable revocation and notification, and record disposal.

👮 Law enforcement

Law enforcement encounters exposed credentials in seized material, breach reports and public exposure. The first action on an organisation's own credential remains revocation by its owner. Investigators do not authenticate with a suspect's or a victim's credential without specific legal authority, because doing so is itself unauthorised access and will taint the case. Evidence value lies in provenance: where the credential was published, when, by whom, and whether provider audit logs show subsequent use from attacker infrastructure. That log evidence, obtained under production order from the provider, is what converts exposure into an evidenced intrusion supporting a charging decision.

🔍 Private investigation and corporate security

Corporate security runs this as detection, rotation and incident response. On discovery of an organisational secret, revoke first, then identify the principal, bound the exposure window and check audit logs for use. For third-party secrets found during diligence or research, notify the affected organisation and the issuing provider and retain nothing beyond what is needed to report. A private actor may not validate a credential against any system it does not own, may not use a client's authority to justify testing a supplier's systems, and may not retain third-party secrets for leverage. Repeat exposures by the same team indicate a process defect worth escalating to the board.

📰 Journalism and OSINT media

Journalists occasionally encounter live credentials in leaked datasets, exposed configuration or contributed material. Do not use them. Testing whether a key works is unauthorised access in most jurisdictions regardless of journalistic purpose, and it destroys the public interest defence you would otherwise rely on. The responsible path is to notify the organisation and the issuing provider, allow time for revocation, and then report the exposure without publishing the secret or details sufficient to reconstruct it. Redact keys from published documents and screenshots including partial values. Give the organisation right of reply and report the remediation as part of the story.

🌍 NGO, humanitarian and human rights

Civil society organisations are frequent victims of credential exposure because tooling is improvised and staff turnover is high. Practice is protective: scan your own repositories and configuration, revoke on discovery, and move to managed secret storage and short-lived tokens. Where an exposed credential could reach data about beneficiaries, survivors or at-risk partners, treat it as a safeguarding incident and assess whether individuals must be warned, applying do-no-harm reasoning to how that warning is delivered. Never test a discovered credential belonging to another organisation, including a hostile one. Support staff who report a leak without blame, because concealment is the greater risk.

🎓 University and research

Research on secret exposure must be designed so that no credential is ever used. Measure detection and prevalence from public artefacts, and treat validation as out of scope; institutional ethics boards should be told explicitly that no authentication attempts will occur. Report findings in aggregate, never publishing a live secret or enough context to locate one. Coordinate disclosure with affected parties and providers before publication and allow a remediation window. Reproducibility is served by releasing detection rules, corpora identifiers and analysis code rather than the secrets themselves. Data management plans must specify secure handling and prompt destruction of any collected secret material.

Playbook: working Credential / API Token end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Revoke before analysis

The moment a credential is confirmed exposed, revoke or rotate it through the issuing provider. Do not wait to understand its scope, do not test what it reaches, and do not schedule it for the next change window. Treat the secret as compromised from the instant of exposure regardless of whether logs show use, because public exposure means automated harvesters have almost certainly already collected it. If rotation risks an outage, rotate anyway with a rollback plan and notify the service owner; an outage is a smaller incident than an active credential in public space.

Phase 2 — Confirm ownership and route

Establish whose credential it is. If it belongs to your organisation, you own revocation directly. If it belongs to a third party, do not act on the secret at all: notify the affected organisation through its security contact or disclosure programme and notify the issuing provider, both of which can revoke without anyone authenticating. Record what you sent, to whom and when. Retain only the minimum needed to enable revocation, and delete it once confirmed. Escalation to a national CERT is appropriate where the owner cannot be identified.

Phase 3 — Identify the principal and scope

Determine which account, role, project and environment the secret authorises, using the provider console and, for token formats that carry claims, by decoding the payload without using it. Decoding a JSON web token reveals issuer, subject, audience, scope and expiry with no authentication involved. Record whether the principal is production or sandbox, what data and services it can reach, and whether it can create further credentials. This scope statement bounds the incident and drives every subsequent decision about notification and log review.

Phase 4 — Bound the exposure window

Find the commit, build, artefact or post that introduced the secret and the point at which it became publicly reachable. In git this means locating the introducing commit, not the file's current state. Record the creation date of the credential itself, the exposure start, and the revocation time. The window defines which logs must be examined and what an attacker could have done. Where the artefact was indexed by search engines or mirrored, assume exposure began at publication rather than at discovery.

Phase 5 — Check for use

Pull provider audit logs for the named principal across the exposure window and look for authentication from unfamiliar addresses or autonomous systems, unusual API calls, enumeration patterns, new credential creation, permission changes and data egress. Absence of evidence is not evidence of absence where logging was not enabled or retention has lapsed, and you must say so explicitly. Where use is confirmed, this becomes an intrusion investigation with its own scope, containment and notification track rather than a secret hygiene finding.

Phase 6 — Purge every copy

Removing the file does not remove the secret. Purge from git history including all branches and tags, then account for forks, mirrors, caches, build artefacts, container image layers, artefact registries, CI logs, wikis, ticket attachments, chat history and backups. Where the repository is public, assume third-party mirrors and clones exist and that purging is best-effort; this is precisely why revocation, not deletion, is the control that matters. Document what could not be purged so nobody later assumes the exposure was cleaned.

Phase 7 — Assess downstream impact

Determine what data and systems the principal could reach and whether any of it belongs to customers, partners or data subjects. This drives contractual and regulatory notification. Where the credential authorised access to a third-party service, notify that provider so they can review their own logs. Where a signing or deployment credential was exposed, assess whether artefacts could have been tampered with and whether re-signing or rebuild is required. Record the assessment and its reasoning, because notification decisions are audited later.

Phase 8 — Fix the pipeline, not the incident

Deploy push protection and pre-commit scanning so secrets cannot enter the repository, move to a managed secret store with short-lived credentials, and remove long-lived static keys from workflows in favour of federated identity where the platform supports it. Add scanning to build artefacts and container images, not just source. Measure adoption rather than announcing policy. A rotation without a pipeline change guarantees the same exposure recurs, usually from the same team within months.

Phase 9 — Baseline and manage detector noise

Entropy-based detection generates heavy false positives on hashes, test fixtures, minified bundles and sample data. Establish a baseline of accepted findings, tune detectors per repository, and prefer verified provider-prefixed detections for alerting. Unmanaged noise is the main reason secret scanning programmes are quietly abandoned, and an ignored queue is worse than no queue because it creates a false assurance. Track precision by repository and retune rather than allowing analysts to develop the habit of bulk-dismissing findings.

Phase 10 — Notify and document

Inform the owning team without blame, since punitive handling drives concealment and concealment is what turns an exposure into a breach. Record the incident timeline: introduction, exposure, discovery, revocation, log review, purge and pipeline fix, each with a timestamp and an owner. Where third-party data was reachable, discharge breach notification obligations within the applicable deadlines. Preserve the evidence under access control if litigation or prosecution is foreseeable, and note the retention period for any secret material held.

Phase 11 — Sweep for the same class

One exposure of a given type usually means more. Search the estate for the same provider prefix, the same configuration pattern, the same author and the same pipeline. Check build artefacts, container layers and public packages published by your organisation, which are commonly missed because scanning stops at source. Extend to public repositories owned by staff personally where organisational credentials may have been committed. The output is a scoped sweep result rather than a single closed ticket.

Phase 12 — Review architecture

Long-lived credentials with no expiry are the underlying defect, and rotation is a control that manages a design weakness rather than removing it. Review which integrations still require static keys, move them to short-lived tokens, workload identity or mutual authentication, and set expiry where the provider allows it. Reduce scope on every remaining credential to the minimum required. Report the count of long-lived unscoped credentials as a standing risk measure so the architectural debt is visible rather than rediscovered at the next incident.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
TruffleHog	Open	Secret scanner covering repositories, filesystems, container images and logs with provider-aware detectors.	Primary detection tool for finding exposed credentials across your own estate before others do.
gitleaks	Open	Fast rule-based secret detection across git history with configurable detectors and pre-commit hooks.	History scanning and developer-side prevention, catching secrets before they reach a remote.
detect-secrets	Open	Baseline-driven scanner designed for continuous integration with managed false positive tracking.	Keeps the finding queue usable in large codebases where entropy detectors would otherwise flood it.
GitHub secret scanning and push protection	Registration	Native detection with provider partnerships, blocking pushes containing recognised credential formats.	Prevents introduction and triggers automatic revocation for partnered providers on public repositories.
OWASP Secrets Management Cheat Sheet	Open	Practitioner guidance on storing, rotating and scoping application secrets across environments.	Reference for the architectural fix once the immediate rotation and purge are complete.
OpenSSF	Open	Open Source Security Foundation guidance and tooling for supply chain and repository security practice.	Frames pipeline controls, signing and secret handling requirements for open development workflows.
NIST Computer Security Resource Center	Open	Publications on key management, digital identity and incident handling including SP 800-57 and SP 800-61.	Authoritative basis for key lifecycle, rotation intervals and incident response process design.
Cloud provider audit logging services	Registration	AWS CloudTrail, Azure Monitor activity logs and Google Cloud Audit Logs record API calls per principal.	Determines whether an exposed principal was actually used, from where, and for what.
HashiCorp Vault	Open	Secret management platform providing dynamic short-lived credentials, leasing and centralised revocation.	Architectural replacement for long-lived static keys embedded in configuration and pipelines.
Have I Been Pwned domain monitoring	Registration	Notification service for organisational addresses appearing in known credential breach corpora.	Triggers forced password rotation and step-up authentication for affected staff accounts.
disclose.io	Open	Open framework and directory for coordinated vulnerability disclosure policies and safe harbour terms.	Locates the correct disclosure channel when notifying a third party about their exposed credential.
CISA	Open	United States cyber defence agency publishing advisories, secure by design guidance and reporting channels.	Escalation route where an exposed credential affects critical infrastructure and the owner is unreachable.
National Cyber Security Centre	Open	United Kingdom guidance on secure development, credential management and incident reporting.	Reference guidance and national reporting route for significant credential exposure incidents.
MITRE ATT&CK	Open	Technique knowledge base including valid accounts, unsecured credentials and cloud credential abuse.	Maps observed post-exposure activity in audit logs to recognised techniques for reporting.
Sigstore	Open	Keyless signing infrastructure using short-lived certificates bound to workload identity.	Removes long-lived signing keys from pipelines, eliminating a high-impact category of exposure.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Credential / API Token. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

TruffleHog — Broad detection across code, images and archives with provider-aware detectors. Limitation: its verification feature must be restricted to credentials you own, never used against third-party services.
gitleaks — Fast git history scanning and pre-commit prevention. Limitation: regex-driven detection misses unprefixed high-entropy secrets and generates noise on test fixtures.
detect-secrets — Baseline management keeps large codebases triageable over time. Limitation: baselines drift and become a place where real findings are silently accepted.
Push protection on the code host — Blocks recognised credential formats at push time, which is the only control that prevents exposure. Limitation: covers partnered formats only, not bespoke or unprefixed secrets.
Container image layer scanners — Find secrets baked into intermediate layers that source scanning never sees. Limitation: often absent from pipelines, leaving a whole class of exposure unmeasured.
Managed secret stores and workload identity — Replace static keys with short-lived scoped credentials. Limitation: migration is slow and legacy integrations frequently cannot support anything but a static key.
Cloud audit log query tooling — Establishes whether an exposed principal was used and from where. Limitation: retention is often shorter than the exposure window, producing an unresolvable gap.
Provider token management consoles — Authoritative scope, last-used timestamp and revocation for credentials you own. Limitation: last-used granularity varies and may not resolve individual calls.
Secret rotation automation — Coordinates rotation across consumers to avoid outages that cause teams to delay. Limitation: requires an accurate consumer inventory, which is usually the missing piece.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Revoke first, investigate second. Every minute spent understanding scope before rotation is a minute the credential is live, and automated harvesters index public repositories within seconds of a push.
Never authenticate with a credential you found. Confirming that a key works against a system you do not own is unauthorised access under computer misuse law regardless of motive, and it converts a good deed into an offence.
Decode, do not use. A JSON web token discloses issuer, subject, audience, scope and expiry from its payload with no authentication involved, which gives you blast radius without touching the service.
Deleting the commit is theatre. Git history, forks, clones, caches, CI logs and third-party mirrors all retain the value, which is exactly why revocation rather than removal is the control that ends the exposure.
The exposure window starts at publication, not at discovery. Anchoring log review to when your scanner found it is the most common way teams conclude a leak was never used.
Repeat findings from the same author or pipeline are a process defect, not an individual failing. Treating them punitively produces concealment, and concealed exposures are what become breaches.
Scan artefacts, not just source. Secrets survive in container layers, minified bundles and published packages long after the repository was cleaned, and most programmes never look there.
An unmanaged finding queue is worse than none. Once analysts learn to bulk-dismiss entropy noise, the one verified production key in the queue gets dismissed with it.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Credential / API Token is producing anything, and they are worth baselining before you change process or tooling.

Median time from exposure detection to confirmed revocation by the issuing provider, measured in minutes rather than days.
Proportion of exposures prevented at push time versus detected after publication, which is the measure that a pipeline fix is working.
Percentage of credentials in the estate that are short-lived or federated rather than long-lived static keys.
Recurrence rate of exposures by the same team or pipeline within ninety days of a previous incident.
Detector precision by repository, and the proportion of the finding queue triaged within the agreed window rather than aged out.
Share of incidents where audit log coverage was sufficient to determine whether the credential was used, exposing logging gaps.
Time from third-party exposure discovery to notification of the affected organisation and the issuing provider.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Deleting a commit does not remove the secret; git history, forks, caches and third-party mirrors retain it indefinitely.
Treat any publicly exposed secret as compromised from the moment of exposure, regardless of whether logs show use.
Validating a discovered credential against a system you do not own is unauthorised access, not research, whatever the intent.
Entropy-based detectors produce heavy false positives on hashes, test fixtures and minified code, and unmanaged noise kills the programme.
Rotating without first identifying every consumer causes outages, which is the usual reason teams delay rotation dangerously.
Long-lived keys without expiry are the underlying defect; rotation alone does not fix an architecture that depends on them.

Legal and ethical considerations

Never use a discovered credential to access any system, including merely to confirm that it works; that is unauthorised access under computer misuse law regardless of motive. For secrets belonging to third parties, notify the affected organisation and the issuing provider through a security contact or coordinated disclosure programme, and retain nothing beyond what is required to report. Internally, treat exposed production secrets as a security incident with documented timelines, and assess regulatory notification duties where customer data was reachable.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Credential / API Token, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 intelligence disciplines, 3 mission domains, 1 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Should I test the key to see whether it is still valid?

No. Authenticating with a credential you do not own is unauthorised access in most jurisdictions, and intent to help is not a defence. It also alerts the operator in an attacker-controlled scenario and destroys any later prosecution. You do not need to test it: for credentials you own, the provider console shows status, scope and last-used data; for third-party credentials, the provider can revoke without anyone authenticating. Provider-format detection tells you which service it belongs to, and token payloads can be decoded offline. Report and rotate; validation is never your step.

The commit is deleted. Are we clean?

No. The object usually remains reachable in the repository, and even a full history rewrite does not touch forks, clones, mirrors, package caches, CI job logs, container layers or search engine and archive copies. Public exposure should be assumed permanent. Deletion is worth doing to prevent reintroduction, but the control that actually ends the exposure is revocation at the provider. Document explicitly what could not be purged so that nobody in a later review concludes the secret was contained by the cleanup.

Rotation will break production. What now?

Rotate anyway, with a plan. An unrevoked public credential is a live intrusion path; a controlled outage is recoverable. The usual sequence is to issue a replacement credential, update consumers, verify, then revoke the old one, which requires knowing every consumer. If the consumer inventory does not exist, that is the real finding and it should be recorded as such. Where the credential is high scope and production-critical, consider immediately restricting its permissions or network conditions at the provider while the replacement is rolled out, then revoke.

How do we handle a third party's exposed credential we found?

Do not use it, do not retain it beyond what is needed to report, and do not publish it. Notify the affected organisation through its security contact or published disclosure programme, and notify the issuing provider, who can often revoke unilaterally. Keep a record of what you sent and when. If the owner cannot be identified, escalate to the issuing provider alone or to a national CERT. Delete the material once revocation is confirmed and record the deletion. Reporting is a defensible act; possession without purpose is not.

Our scanner produces thousands of findings. How do we make it usable?

Split detection into verified provider-format findings, which should alert immediately, and heuristic entropy findings, which should feed a baseline rather than a queue. Tune per repository, exclude test fixture and vendored directories deliberately with recorded justification, and measure precision. Put prevention ahead of detection: push protection and pre-commit hooks stop the inflow, which is the only sustainable path. Track queue age and precision as programme metrics, because the failure mode is not too many alerts but analysts learning to dismiss all of them.

What do audit logs actually tell us after an exposure?

Whether the named principal authenticated during the window, from which addresses and networks, and what it called. Look for unfamiliar source addresses, enumeration patterns, creation of further credentials, permission changes and data egress. Two caveats matter. Retention is frequently shorter than the exposure window, so a clean result may simply mean the logs are gone. And some services log at a granularity that cannot distinguish legitimate from illegitimate use. Say so explicitly in the report rather than writing that no misuse occurred.

Is rotation enough?

No. Rotation manages the symptom of an architecture that depends on long-lived static credentials. The durable fixes are short-lived tokens, workload identity federation so pipelines hold no static key at all, tightly scoped permissions so a leak has limited reach, and centralised secret storage with automated rotation. Track the count of long-lived unscoped credentials as a standing risk measure. Organisations that only rotate will keep having the same incident, and the interval between recurrences is usually measured in months rather than years.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

Computer misuse and unauthorised access legislation, which makes using a discovered credential against a system you do not own an offence regardless of intent.
NIST SP 800-57 on key management, defining key lifecycle, cryptoperiods and rotation requirements.
NIST SP 800-61 on incident handling, which frames containment, eradication, recovery and post-incident review for credential exposure.
OWASP Application Security Verification Standard and Secrets Management guidance, defining requirements for secret storage, scoping and rotation.
ISO/IEC 27001 Annex A controls on access management, cryptographic key handling and secure development lifecycle.
PCI DSS requirements on protection of authentication credentials, applicable wherever payment data is in scope.
UK GDPR and EU GDPR breach notification duties, engaged where an exposed credential could reach personal data.
Coordinated vulnerability disclosure norms, including ISO/IEC 29147 and safe harbour frameworks, governing notification to third parties.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

TruffleHog — Truffle Security. Open source secret detection across repositories, filesystems and container images.
gitleaks — gitleaks project. Open source git history secret scanner with pre-commit prevention.
detect-secrets — Yelp. Baseline-driven secret detection designed for continuous integration.
OWASP Secrets Management Cheat Sheet — OWASP Foundation. Guidance on secure storage, rotation and scoping of application secrets.
NIST Computer Security Resource Center publications — National Institute of Standards and Technology. Key management and incident handling standards underpinning rotation and response process.
Sigstore — Open Source Security Foundation. Keyless signing using short-lived certificates, removing long-lived signing keys from pipelines.
OpenSSF — Open Source Security Foundation. Supply chain and repository security guidance including secret handling practice.
disclose.io — disclose.io. Open framework for coordinated disclosure policies and safe harbour terms.
CISA secure by design resources — Cybersecurity and Infrastructure Security Agency. Guidance and reporting channels for credential exposure affecting critical infrastructure.
MITRE ATT&CK valid accounts and unsecured credentials techniques — MITRE. Technique definitions for mapping post-exposure activity observed in audit logs.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: detects exposed secrets across code, artifacts and pastes, driving revocation, rotation and exposure-window reporting. Explore the platform, or browse the rest of the library by following any tag above.