Do you read the values of my public environment variables?

No. Only the names are collected, because the name is what tells you whether something with a server-side purpose was given a public prefix by mistake. Values are never read or shown.

Is linking to a public repository a mistake?

No, and for open-source projects it is the point. The check reports it as part of your public surface so that the contents — including the history — get reviewed with that in mind.

Why is a missing CI badge not reported as a problem?

Because it carries no evidence. A private pipeline is invisible from the internet, so absence is the normal case and reporting it would manufacture a finding out of nothing.

Tools

Exposed repository checker

An exposed repository check collects three things a site publishes about how it is built: the public repositories it links to, the public continuous-integration indications it carries, and the names of the environment variables shipped to the browser. None of these is a defect by itself. Together they describe a build surface that is readable by anyone, and the useful question is whether everything in it was meant to be there.

The three signals, and what each one means

Linked public repositories: a repository the site links to is part of its public surface, and everything committed to it is readable — including the history, which keeps files long after they are deleted from the current tree.

Public CI indications: a pipeline badge or a link to a public workflow. These say how the product is built and they are a communication choice, not a defect. A missing badge says nothing at all about your pipeline.

Browser-side environment variable names: the variables with a public prefix that frameworks deliberately ship to the client. The names are collected; the values are never read or displayed.

Private repositories are never accessed, and no attempt is made to reach one that is not linked publicly.

Why public environment variables deserve a second look

A public prefix is an instruction to the bundler: put this in the browser build. It is working as designed, and a variable behind one is not a secret by definition.

The failure mode is human. Someone needs a value at build time, the build fails without the prefix, the prefix is added, and a key that was never meant to leave the server is now in every visitor's bundle.

Which is why the names are worth reading through once. A name describing a publishable identifier is fine. A name containing the word secret, private, or a service's server-side key convention is the one to check.

Only names are collected here. The values are neither read nor shown, and finding an actual credential in a served file is the job of the exposure checks, reported on their own page.

What a problematic result looks like

A public variable name that plainly describes a server-side credential. This is the finding to act on the same day, and acting means rotating the value, not just renaming the variable.

A linked repository that contains configuration for the production deployment — internal hostnames, service names, a deployment topology. None of that is a credential and all of it is reconnaissance.

A repository whose history contains a file that was deleted later. Deleting a file does not remove it from the history, and the history is public too.

A public workflow file that names internal infrastructure in its steps, which is the same disclosure with fewer people watching for it.

The limits, stated plainly

Only publicly linked repositories are considered. Nothing private is accessed, and no repository hosting platform is searched for repositories that might belong to you.

Repository contents are not scanned. This check reports that a public repository exists and is linked; auditing what is committed in it is your work, with tooling built for that.

Environment variable names are read from the served pages. A variable that never reaches the browser bundle is not seen, which is the correct behaviour.

A missing CI indication carries no information. Most pipelines are private, and that is the normal case rather than a gap.

What VeriFixScan uses

`devops.public_repository` lists the public repositories linked from the site. `devops.cicd_public` reports public continuous-integration indications, as information rather than as a defect.

`devops.public_env_vars` lists the names of public-prefixed environment variables referenced in the served pages, without reading or displaying any value.

`devops.public_indicators` and `devops.secondary_environments` complete the picture with the other publicly observable signs of how the site is operated.

Frequently asked questions

Do you read the values of my public environment variables?: No. Only the names are collected, because the name is what tells you whether something with a server-side purpose was given a public prefix by mistake. Values are never read or shown.
Is linking to a public repository a mistake?: No, and for open-source projects it is the point. The check reports it as part of your public surface so that the contents — including the history — get reviewed with that in mind.
Why is a missing CI badge not reported as a problem?: Because it carries no evidence. A private pipeline is invisible from the internet, so absence is the normal case and reporting it would manufacture a finding out of nothing.

Sources

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website