Can I trust the packages my AI assistant added?
Check that a suggested package is the intended project, inspect the version actually installed, and review available vulnerability advisories. A package's existence or a clean CVE result does not prove it is trustworthy. Review new dependencies before installation and test upgrades before release.
Who this is for: Teams reviewing package.json changes, dependency updates and packages suggested by AI assistants.
STEP 01
Confirm the package before adopting it
A plausible package name is not evidence that the library exists or belongs to the project you expect. Open the official project's installation instructions and check the publisher, repository and maintenance context. Review why the new dependency is needed and whether your existing stack already provides the behavior. A lookalike name deserves investigation even if no vulnerability has been published.
Try this: Require a purpose and an official project reference for each newly introduced dependency.
STEP 02
Use installed versions for vulnerability triage
A manifest may specify a version range while a lockfile records the versions selected for an installation. Include both when reviewing a release. Dependency advisories describe known issues; they do not provide a complete assessment of malicious behavior or unknown vulnerabilities. Investigate whether affected code is reachable in your application before deciding urgency.
Try this: Record the resolved version, advisory reference, affected usage and proposed fixed version for every confirmed issue.
STEP 03
Treat upgrades as application changes
An upgrade can fix a known issue while changing an API your product relies on. Read the package's release guidance, review the lockfile diff and test the affected behavior. Keep dependency changes small enough to investigate. Document temporary mitigations and an owner when an immediate safe upgrade is unavailable.
Try this: Run the relevant tests after updating and preserve the resulting scan with the release commit.
Your review checklist
- Verify new package names against official installation instructions.
- Review the package's publisher and repository context.
- Include lockfiles and inspect resolved versions.
- Check published advisories and assess application reachability.
- Test upgrade behavior and review the dependency diff.
- Record mitigations, an owner and a review date for deferred fixes.
What Bryxe can check
Bryxe's dependency checker accepts a package.json and reports supported dependency findings using available advisory data. Repository scans can add code context to the review.
What you still need to verify
The public manifest checker is not a complete transitive lockfile audit or a proof of package authenticity. Advisory availability and supported ecosystems vary. Use package-manager tooling and manual review alongside it.
Common questions
Does no known CVE mean a package is safe?
No. It means the checked data did not identify a matching known vulnerability under that check's scope. Unknown vulnerabilities, malicious packages and configuration-dependent behavior require additional evaluation.
What is an AI-hallucinated dependency?
It is a package name or API suggested by an assistant that does not correspond to the intended real dependency. Verify suggestions using the official project documentation before installing or trusting them.
Is package.json enough for a complete dependency audit?
No. A manifest lists direct requirements, often as ranges. Lockfiles and package-manager inspection help establish the resolved dependency graph, including transitive packages. Check the artifact you actually ship.
Documentation & further reading
These primary sources explain the platform behavior discussed above. Check the documentation for the versions and configuration you use.