MAL-CRED Credential-Store Reads
Author-planted malice frequently opens well-known credential files that belong to the developer rather than to the application: private SSH keys, cloud credentials, registry auth tokens, container-registry logins, git credential stores, kubernetes contexts, and browser credential stores. A benign application reads its own config, not another program's secret store.
What Vulkro detects
Two rules, graded by whether an actual read is present.
MAL-CRED-001 (High) fires when a credential-file path is referenced together with a file-read or open call token, on the same line or elsewhere in the same file. That is the dominant credential-exfiltration primitive.
MAL-CRED-002 (Medium) fires when a credential-file path is referenced with no read or open token anywhere in the file: a string constant or a path constant, surfaced for review only. Comments do not count as a mention, because a docblock explaining which store a tool reads is not itself a read.
This is distinct from a secret embedded in source, which the secrets scanner owns. Here the source reads a sensitive file that lives on the machine.
What it does not claim: a finding says this source names or reads a credential store, not that the code is malware. Inspect never certifies code as safe.
Remediation. Confirm the repository has a legitimate reason to touch that store (a deploy tool reading ~/.aws/credentials may; a UI component does not). If it does not, treat the clone as untrusted, do not run it, and rotate any credential that machine already held.
See also
- Confidence model - what
High,Medium, andLowmean for findings in this category. - Safety - what Vulkro does and does not access on your machine.
References
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.