How we read a repository for risky dependencies and leaked secrets

Summary

How Dralvia reads a code repository for risky dependencies and leaked secrets, and where that review stops.

Threat model

AI-assisted coding can pull in an unknown dependency or paste a secret into history without anyone noticing. The risk is a supply-chain path or a leaked credential that ships because no one looked.

Why it matters

A repository is where risk enters before anything runs. Catching a bad dependency or an exposed secret early is cheaper than catching it in the wild.

Test setup

The scanner reads a repository in a sandbox, inspects its declared dependencies and lockfile, and looks for patterns that read like secrets, without executing the code.

What Dralvia observed

Reading the lockfile alongside the declared dependencies surfaced trust gaps that a shallow read misses, and secret-shaped patterns stood out clearly in history.

What worked

Working from the lockfile as the source of truth, in a sandbox, gave a reproducible read without trusting the repository to behave.

What did not work

Signals from a single file were noisy, so the review weighs the declared dependencies and the lockfile together rather than either alone.

Product improvements

We read the lockfile as the trust source and pair it with declared dependencies, and we flag secret-shaped patterns from repository history.

Defender recommendations

Review the lockfile, not just the manifest, and scan history for secrets before you publish a repository. What is declared and what is locked can disagree.

Limitations

This reads a repository statically in a sandbox; it does not run the code and is not a full audit. A clean read is not a guarantee of safety.