Skip to main content

MAL-CRED Credential-Store Reads

Planted malice often opens credential files that belong to the developer, not the application: private SSH keys, cloud credentials, registry and container-registry tokens, git credential stores, Kubernetes contexts, browser credential stores. A benign application reads its own config, not another program's secrets.

What Vulkro detects​

  • MAL-CRED-001 (High): a credential-file path appears together with a file-read or open call, on the same line or elsewhere in the file.
  • MAL-CRED-002 (Medium): a credential-file path appears with no read or open call anywhere in the file, surfaced for review only. Comments do not count.

Secrets embedded in source are a separate check (the secrets scanner). A finding means the source names or reads a credential store, not that it is malware, and never that the code is safe.

How to fix​

  • Confirm the repository has a real reason to touch that store (a deploy tool reading ~/.aws/credentials may; a UI component does not).
  • If not, treat the clone as untrusted, do not run it, and rotate every credential that machine held.

References​

See also: Confidence model.


This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.