What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Current status of the browser extensions and the Grunt plugin: several companion distributions have been retired, confirm what is still maintained
- Active maintenance cadence of the vulnerability repository: confirm
- Integration list: confirm which downstream tools still ship a current Retire.js component
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Retire.js answers a narrower question than a general composition analysis tool: which JavaScript libraries are present in this code, and are any of them known to be vulnerable. It identifies libraries three ways. It hashes files and matches them against known release hashes, it matches filename patterns such as the version embedded in a library filename, and it runs regular expressions against the file contents looking for the version banners and signature strings that libraries commonly carry in their source. Matches are then checked against a community maintained JSON repository of vulnerable version ranges.
The consequence is that it works with no manifest at all. A jQuery copy dropped into a static assets directory years ago, a vendored plugin inside a theme, or a script tag pointing at a CDN are all things a lockfile reader cannot see and Retire.js often can. It runs as a Node command line tool over a directory or a node_modules tree, and its detection logic has been embedded into other security tools, notably as a passive scan component in web proxies, so client side libraries get flagged during an ordinary crawl.
Where it fits
Two natural placements. As a CI step it scans the build output directory, where the libraries you actually ship live, as opposed to the dependency tree you declared. As a passive check inside a proxy or DAST run, it flags libraries observed being served to the browser. Either way it is cheap to run and produces a short, specific list. It complements a full SCA tool rather than replacing it.
Strengths
- Detects libraries with no package metadata, including vendored copies and files served from a CDN, which manifest based scanners miss.
- Scanning delivered assets tells you what users actually receive, not what the build was supposed to produce.
- Small, fast and trivially added to a pipeline or a testing workflow.
- Detection logic is reused inside common proxies, so the same signal appears during dynamic testing without extra setup.
Limitations
- JavaScript only, and only known vulnerable libraries. It has nothing to say about your own code or any other ecosystem.
- Aggressive bundling, tree shaking and minification break both hash matching and signature matching, so a modern webpack bundle can hide libraries from it.
- The vulnerability repository is community curated and narrower than commercial advisory data, and update cadence depends on volunteer attention.
Who it suits
Worth running by any team that ships front end code, especially where legacy static assets have accumulated outside the build system. It belongs alongside a general dependency scanner, not in place of one, and teams whose front end is entirely bundled from a lockfile will get more from scanning the manifest.
Used Retire.js? Recommend it under your own name and title.
Recommend this tool