Enji GuardSCA for the dependencies AI keeps adding
Guard is not just a dependency checker, it is software composition analysis for AI-assembled code. When an assistant picks the libraries, no human vetted them. Guard inventories everything your code actually depends on, direct and transitive, and flags what is vulnerable, abandoned, or never should have been there.
1 repo · setup in about 5 minutes · no card, no commitment
01
Your app is mostly code you didn't write
Most of a modern app is third-party packages, and with AI choosing them, even fewer were a deliberate decision. Software composition analysis answers the basic question nobody can otherwise answer: what is actually in here, and is it safe? Most software composition analysis tools assume a human chose the libraries; with AI, that assumption no longer holds.
02
What Guard's SCA covers
Guard uses software composition analysis and dependency scanning to build a real picture of the dependency tree:
- A full inventory of direct and transitive dependencies
- Known-vulnerable packages and versions
- Abandoned and unmaintained libraries
- Hallucinated or unvetted packages AI introduced
- Typosquatted and slopsquatted package names
- License risk that can bite later
03
Continuous, because the tree keeps changing
An inventory is only true until the next AI-assisted commit adds a package. Guard re-analyses on a schedule and as the repo changes, so the picture of your supply chain stays current.
04
From inventory to action
Risky components come back as reviewable GitHub issues explaining the exposure. When a fix is bounded and useful, Guard can open a pull request that removes or upgrades them with verification evidence where available.
Quick questions
What is the difference between SCA and SAST?
SAST checks the code you wrote; SCA checks the third-party packages your code pulls in. With AI choosing libraries you never reviewed, the dependency side is where a lot of the risk now lives.
Does it produce an SBOM?
It builds a dependency-source inventory and records SBOM evidence when your repo already has it. Treat Guard as repo-aware SCA context, not as a formal SBOM system of record.
Does it check licenses, not just vulnerabilities?
License files and package metadata can appear as evidence, but the audit is focused on dependency control, known vulnerabilities, stale or risky packages, and unsafe acquisition paths.
How is this different from a generic SCA tool?
Generic SCA assumes a human deliberately chose each dependency. Guard adds repo context for AI-era risks: invented, unvetted, or just-registered packages an assistant may have pulled in.
See everything your AI code depends on.
Connect a repo and get your first composition report in a few minutes. No card.