Repository navigation
Deno
Part of the ecosystems matrix.
deno.lock (v3, v4, v5) holds two registries:
-
npm packages, reported as
node- they are npm's: same registry, same OSV ecosystem. A key's peer suffix (a@1.0.0_b@2.0.0) is the same package. -
JSR packages (
@std/fs), reported asjsr.
Every package lists its dependencies (specifiers, names, or name@version),
resolved through the lock's specifiers: the full graph. The workspace's
dependencies (and its members') are the direct set. URL imports (remote:
deno.land/x, esm.sh, ...) belong to no registry: they are counted in a
diagnostic, not assessed.
Online: npm packages through the npm registry; JSR packages through
api.jsr.io/scopes/<scope>/packages/<name> → githubRepository. New jsr
endpoint.
Vulnerabilities: npm packages go to vuln.mlab.sh as OSV npm coordinates.
JSR has no OSV ecosystem: JSR packages are not assessed (an info diagnostic
says so).
Source scanning: the project's own TypeScript / JavaScript is scanned.
Commands
- scan
- tree
- audit
- fix
- licenses
- why
- diff
- sbom
- system
- harden
- scripts
- hook
- watch
- timeline
- ghost
- hunt
- allowlist
- cache
Targets
Ecosystems (overview)
- Node
- Deno
- Python
- Conda
- Rust
- Ruby
- PHP
- Go
- JVM (Java, Scala, Clojure)
- .NET
- Swift / iOS
- Dart / Flutter
- Elixir / Hex
- C / C++
- Haskell
- R
- Perl
- Julia
System managers
Windows (overview)
- WinGet
- MSIX / AppX
- Chocolatey
- Scoop
- Add/Remove Programs
- Auto-start (ASEP)
- Scheduled tasks
- Services & drivers
- Jobs & file-based
- Privilege & trust posture
- Network posture
Concepts