VERA Vendor Risk Signals Library

Exposed Secrets and Code Repository Exposure in Vendor Risk

Public code repositories can reveal far more than source code. API keys, access tokens, passwords, connection strings, private endpoints, and other secrets may be unintentionally committed alongside application code. When those artifacts can be credibly associated with a vendor, they can provide a meaningful third-party risk signal.

What are exposed secrets and code repository exposure?

Developers routinely store source code in version-control systems such as Git.

Repositories may be intentionally public, accidentally exposed, or copied into public forks and mirrors.

Source code itself is not necessarily sensitive.

Open-source software is intentionally published.

The security concern arises when a repository exposes information that was not intended for public use.

This can include:

API keys;
passwords;
access tokens;
private keys;
database connection strings;
cloud credentials;
service-account material;
internal hostnames;
configuration files; or
other secrets.

Repository history also matters.

Removing a credential from the current version of a file does not necessarily remove it from previous commits.

A secret can therefore remain publicly accessible even after the developer believes it has been deleted.

Why does this matter in vendor risk?

Exposed secrets can create a direct path from public information to systems that were intended to require authentication.

If a secret remains valid and has sufficient privileges, an attacker may be able to access:

an API;
cloud infrastructure;
a development environment;
a database;
a source-control platform;
an application;
a third-party service; or
another protected resource.

Repository exposure can also reveal useful reconnaissance information even when no active credential is present.

Internal hostnames, architecture details, software versions, service names, configuration patterns, and development artifacts can help an attacker better understand the vendor’s environment.

For third-party risk teams, this evidence is particularly useful because it can be discovered independently of vendor attestations.

A vendor may have a strong policy prohibiting secrets in source code while an individual developer accidentally commits one anyway.

The signal therefore provides evidence about observable implementation, not simply documented policy.

What can VERA observe?

Depending on the available public evidence, VERA can evaluate repositories and code artifacts that appear to be associated with a vendor.

This may include:

public repositories associated with the organization or its domains;
secrets or credentials matching recognizable patterns;
API keys, tokens, passwords, private keys, or connection strings exposed in code or configuration;
historical commits containing secrets that may no longer appear in the current file;
repository metadata connecting the code to the assessed organization;
internal infrastructure references or other sensitive technical information; and
related evidence that helps establish whether the repository and exposed material belong to the vendor.

Attribution is particularly important.

A repository that happens to contain a company’s name is not automatically an official company repository.

The evidence must support a credible connection to the organization being assessed.

What does this signal not prove?

Finding a secret-like value in public code does not automatically prove that the credential is valid.

The secret may have been:

revoked;
rotated;
intentionally published;
restricted to a development or test environment;
generated as sample data; or
invalid by the time it was discovered.

Some strings may also resemble credentials without actually functioning as authentication material.

A public repository does not inherently represent a security problem either.

Organizations intentionally publish:

open-source code;
documentation;
examples;
SDKs;
templates; and
other technical materials.

The central questions are attribution and sensitivity:

Does the repository credibly belong to the vendor, and does the exposed information represent something that should not be public?

Even where an exposure is genuine, external evidence may not establish the scope of access the secret provides or whether it was ever used maliciously.

VERA therefore distinguishes between:

an observable exposure and a proven compromise.

How VERA uses this signal

VERA evaluates public code and exposed-secret findings as part of a broader external evidence assessment.

Potential findings can be evaluated for:

organizational attribution;
the type of secret or technical information exposed;
repository context;
recency;
supporting evidence; and
related indicators associated with the same organization.

Where possible, the finding can also be considered alongside other signals such as credential exposure, cloud infrastructure, known vulnerabilities, and breach intelligence.

The goal is not to penalize vendors for maintaining public repositories.

It is to identify situations where publicly accessible code appears to expose information that could create an unintended path into the vendor’s environment.

The distinction is simple:

Public code can be intentional. Public secrets generally should not be.

Related Vendor Risk Signals

No single external signal tells the whole story. These related signals can provide additional context when evaluating this finding as part of a broader third-party risk assessment.