dependency-audit
Assesses what a project depends on — known vulnerabilities, licence obligations, abandoned packages, and supply chain risk. Use this whenever the user asks what their dependencies look like, mentions a CVE or security advisory, needs a licence review, is evaluating whether to adopt a library, or has a dependency tree nobody has looked at in years. For performing the upgrades this identifies, use dependency-upgrade.
Target: Cloud, operations & security. Automatically collected · unverified.
Excerpt from the author’s documentation
Extracted from a fixed version of SKILL.md in its original language. This is the author’s documentation; installation, compatibility and runtime results have not been verified by this site.
Read the original English text
Topics in the source
- Dependency audit
- 1. See the whole tree, not the manifest
- 2. Run the scanners, then triage the output
- 3. Check licences before they become expensive
- 4. Assess maintenance, which no scanner does
- 5. Look for supply chain smells
- 6. Reduce the surface
- Report
Most of the code shipping in a typical application was written by strangers. An audit answers three questions about that code: is it dangerous, is it legal, and is it maintained. Scanners answer the first well. The second and third need judgement, and they are where the expensive surprises live — a licence discovered at acquisition, a critical library abandoned three years ago. Your manifest lists what you asked for. The lockfile lists what you got, and it is usually five to twenty times larger. Transitive dependencies are where most risk sits, because nobody chose them. Note the depth and the total count — a project with 1,400 packages has a different risk profile from one with 40, whatever the direct list looks like. Done when: you are working from the resolved tree, not the manifest. Scanner output is not a finding list; it is a starting list. Triage each: Is the vulnerable code path reachable from your usage? A deserialization CVE in a library you only use for formatting is not exploitable. govulncheck does this analysis properly; most tools do not. Is it a dev dependency? A vulnerability in a build tool is real but has a different threat model than one in the server. Severity
This is an excerpt. Refer to the complete source and its current requirements.
- Source repository
- OKHP3/skillz
- Source file
- community/dependency-audit/SKILL.md
- Fixed revision
- 7b187777d42ab7bc7bab1e5f2c940cd3139ecebf
Sources and evidence
This record was collected automatically. Its documentation, suitability and runtime behavior have not been manually verified.
Author: OKHP3/skillz · original repository metadata. Documentation review: Not reviewed. Last source check: 2026-11-10T10:00:54.155Z.
Categories are inferred from names, descriptions and paths. They do not establish compatibility.
License and attribution
MIT. Third-party content and copyright remain with their authors. Refer to the original license and terms.
Original license ↗Synchronization, copying and user-reported success do not mark a resource as runtime-tested.
Limitations and notes
- Collecting metadata does not mean this site has installed, adapted, runtime-tested or security-reviewed the resource.