Will It Vibe?SecureRandom re-seeded with a constant
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A file using SecureRandom calls .setSeed(...) with a literal number. Explicitly seeding a SecureRandom with a constant makes every run produce the exact same output, which defeats the entire reason to use SecureRandom over java.util.Random. Heuristic: it does not prove the receiver of setSeed is the SecureRandom instance rather than an unrelated object in the same file.
Why it matters
SecureRandom exists specifically to produce output that cannot be predicted even by someone who knows the algorithm. Calling setSeed with a literal constant overrides that guarantee: every run of the program produces the exact same sequence of "random" bytes, which is exactly the property a secure token, key, or nonce must not have.
How to fix it
Remove the setSeed call entirely. SecureRandom seeds itself from the operating system's entropy source on construction; reseeding it yourself is almost never necessary and never safe with a constant. If you need a deterministic sequence for a test, use a plain java.util.Random there instead, not SecureRandom.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo