Hardcoded credentials: find the secrets your repo ships.
Source intelligence finds the passwords, keys and tokens written into your code and committed files, follows each one to where it is used, and tells you what it opens. The report never holds the secret.
A hardcoded credential is a password, key or token written into source code or a committed file instead of read at runtime from the environment or a secrets manager. NightVision finds them with source intelligence. In Python code it follows each literal to the call that uses it as a credential, and in any language it reads the committed files that hold credentials, such as .env files and private keys. Each finding says what the credential is, where it is written, where it is used and what it opens, in a report that never contains the secret.
A secret in the repo is a secret in every clone.
Code gets copied. Every clone, fork, CI cache and build log that touches the repository carries the secret with it, and deleting the line later does not take it out of history. A signing key in the repo lets anyone who reads it mint a valid session or token. A database password in the repo works for anyone who can reach the database. A scanner pointed at the running app never sees any of it, because the secret sits in the source, not in a response.
Treat a committed secret as exposed: rotate it, then load it from the environment or a secrets manager.
Read in code, and read in committed files
Two passes, one report. One follows a credential through Python code to the call that consumes it. The other reads the files that should never be committed, whatever the language.
Where a credential is consumed
A string literal is followed through assignments, attributes, Flask's config and settings defaults to the API that takes it as a credential.
- JWT signing keysPyJWT, python-jose, Flask-JWT-Extended and the SimpleJWT signing key
- Framework secret keysFlask's
SECRET_KEYand CSRF key, Django'sSECRET_KEY - DatabasesDjango database passwords, SQLAlchemy URLs, and connections from psycopg2, psycopg, PyMySQL, mysqlclient and aioodbc
- SMTPFlask-Mail and Django email passwords
- HTTP authBasic auth and
Authorizationor API-key headers on requests and httpx calls - AWSAccess key pairs handed to boto3 and aioboto3 clients
- MAC and cipher keyshmac, pyca/cryptography and PyCryptodome keys
Files that should not be committed
Each value is read the way the tool that loads the file reads it, so a value that refers to an environment variable is left alone.
- .env filesCredential variables and any connection string that carries a password, including JDBC URLs
- Private keys
*.pem,*.key,id_rsaand other SSH keys, with encrypted keys marked - .npmrcnpm and Yarn registry tokens and passwords
- .pypircPackage index passwords
- .netrcPasswords per machine
- .git-credentialsGit URLs that carry a password
- AWS credentialsThe secret access key of each profile in
.aws/credentials
What a finding tells you
Enough to rotate the credential and fix the code, without ever printing the value.
What kind of credential it is
A signing key, password, API key, access key, token, private key or encryption key.
Where it is written
The file and line of the literal, or of the entry in a committed file.
Where it is used
Each place the value is consumed, so you know every call to change when you rotate it.
What it opens
The app's own JWT or session signer, a PostgreSQL or MySQL database, SMTP, AWS, an HTTP API, or the registry or package index a committed file signs in to.
Whether it is only a default
When the literal is the fallback in an environment read, the finding names the variable, since production may set it to something else.
Hardcoded JWT signing key
RedactedFlask app, Python code
- Rule
python.pyjwt.key- Kind
signing-key- Written at
config.py:13- Used at
models/user_model.py:48- Opens
- The app's JWT signer,
HS256 - Default for
- The
SECRET_KEYenvironment variable - Value
- ••••••not in the report
One literal, two rules: the same value is Flask's SECRET_KEY, so it is also reported under python.flask.secret-key.
The report never holds the secret.
A finding records where a credential is and what it opens, not the credential. Nothing derived from the value goes in either: a finding's ID is a hash of the rule and the location, never of the secret, and a database URL in the report keeps its host but drops the user, password and query string. The report is as safe to share as the API spec, so it can go into a ticket, a pull request or a chat with a teammate without creating a second leak.
Placeholders are skipped
A finding means a real value is written in your tree. A value like mysecretkey is still reported, because it is one.
Placeholders
Empty values, ${VAR} references, template markers such as {{ var }}, and values like xxxx or your_api_key_here.
Template files
.env.example, .env.sample, example.env and the other template names teams commit on purpose.
Values the source does not fix
A value read from the environment with no default, from a file or from a vault.
Keys that only verify
A public key handed to a JWT decode under an asymmetric algorithm.
Connections with no password
A connection string or URL that names a host and user but carries no secret.
Code outside your tree
Literals inside installed packages and wheels are not yours to rotate.
Linked to the cryptography at the same place
Run --credentials together with --weak-crypto and each weak cryptography finding lists the IDs of the credentials found where it is. A hardcoded key and the weak cipher or signing algorithm it feeds read as one problem with one fix. See quantum readiness for what the cryptography pass reports.
Part of source intelligence in the NightVision CLI
Add --credentials to nightvision openapi extract and the redacted report is written beside the generated API spec. Run it on a laptop or in your pipeline. By default the spec and the redacted report are uploaded to NightVision; add --no-upload to send nothing. Your source code is never uploaded, and no LLM reads it. Code analysis covers Python today, and committed files are read in any language. Viewing and tracking these findings in the NightVision platform is in development.
The same run maps your API routes from source code and surfaces the shadow APIs your spec forgot.
Leaked credential testing takes passwords exposed in public breach data and tries them against your app's login. This page is about the secrets written into your own code and committed files, found from source.
More from source intelligence
Hardcoded credential questions, answered.
What is a hardcoded credential?
A password, key or token written into source code or a committed file instead of read at runtime from the environment or a secrets manager. Anyone who can read the repository, a clone of it or a log that prints it holds the credential.
Does the report contain our secrets?
No. A finding records where a credential is written, where it is used and what it opens, never the secret or anything derived from it. The report is as safe to share as the API spec.
Which languages does NightVision cover?
Code analysis covers Python today. Committed files that hold credentials, such as .env files, private keys, .npmrc, .pypirc, .netrc, .git-credentials and AWS credentials files, are read whatever language the application is written in.
Are placeholders and example files reported?
No. Empty values, ${VAR} references, template markers such as {{ var }}, and values like xxxx or your_api_key_here are skipped, and template env files such as .env.example are not read.
How is this different from leaked credential testing?
It is a different problem. Leaked credential testing takes passwords exposed in public breach data and tries them against your app's login. Hardcoded credential findings are the secrets written into your own code and committed files, found from source.
Is this in the NightVision platform?
It runs in the NightVision CLI today, as a redacted report written beside the API spec that source intelligence generates. Viewing and tracking these findings in the NightVision platform is in development.
Find the secrets before they ship.
See every hardcoded credential in your code and committed files, with where it is used and what it opens, then test the running app with NightVision DAST.