dependency security Shipped
What this lens looks for
Treat dependencies as attack surface and manage them actively. Lockfiles are mandatory and must be committed (package-lock.json, Podfile.lock, gradle.lockfile, poetry.lock, Cargo.lock, packages.lock.json), with CI using locked installs (--frozen-lockfile / npm ci / dotnet restore --locked-mode). Automated scanning must run in CI (npm audit, pip-audit, Dependabot, Snyk, or dotnet list package --vulnerable), and builds must fail on critical or high vulnerabilities. Dependencies must be pinned to exact versions or narrow ranges; wildcard (*) or overly broad semver must not be used. For any CDN-hosted scripts or styles, use Subresource Integrity (integrity attributes with SHA-384/SHA-512 hashes). Watch for supply-chain attacks: typosquatting, maintainer compromise, malicious post-install scripts, and dependency confusion via internal/public name collisions.
What its verifier checks
A lockfile exists and is committed for each package ecosystem, and CI installs use a locked/frozen mode rather than re-resolving; CI runs an automated vulnerability scan (npm audit / pip-audit / Dependabot / Snyk / dotnet list package --vulnerable) and the build fails on critical or high findings; dependency versions are pinned to exact versions or narrow ranges, with no wildcard (*) or overly broad semver; CDN-hosted scripts and styles carry SRI integrity attributes using SHA-384/SHA-512; the change shows no signs of supply-chain risk (typosquatted names, suspicious maintainer changes, malicious post-install scripts, or internal/public dependency-confusion collisions).