Dependency Supply Chain Risk Scanner
A scanner for small development teams that reads an npm project's full dependency tree and scores it on more than known vulnerabilities: maintenance activity, maintainer concentration, install scripts, ownership changes and lookalike names. A security final year project about spotting risky packages before an advisory exists.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- Lockfile parsing for npm (package-lock.json) that resolves the full tree including transitive dependencies and marks direct, dev and production packages
- Known vulnerability matching against OSV.dev with affected version ranges checked correctly
- Risk signals beyond advisories: last release date, maintainer count, install scripts, recent maintainer or ownership change, lookalike names of popular packages
- A documented scoring model that combines signals and explains each score in plain words
- A CycloneDX SBOM export and a ranked report that puts production, direct and high-signal findings first
- A lockfile diff mode that shows how a pull request changes the risk profile
- An evaluation on at least 20 real open source projects plus a retrospective check against known past incidents
If you have time left
- Reachability analysis that checks whether vulnerable functions are actually imported or called
- A GitHub Action that comments the diff report on pull requests and can fail the build on new high-risk packages
- A second ecosystem such as PyPI reusing the same scoring core
The problem: you ship code written by strangers
A typical JavaScript web app pulls in hundreds or thousands of transitive packages maintained by people the team has never heard of. Small software houses and startups run npm install dozens of times a day without looking at what arrives. Existing scanners check those packages against advisory databases, which by definition only cover what has already been discovered and reported.
Several well-known compromises followed patterns visible before any advisory: the event-stream incident in 2018 began with a handover of a popular package to a new maintainer, and the xz utils backdoor found in 2024 followed a long campaign to gain maintainer trust. Install scripts and lookalike package names are also common routes for malicious code. These signals are computable from public metadata.
What already exists and the gap
- Dependabot (GitHub) and Snyk alert on known vulnerabilities and open upgrade pull requests.
- OSV-Scanner from Google matches lockfiles against the open OSV vulnerability database.
- OpenSSF Scorecard scores open source repositories on security practices such as code review, branch protection and pinned dependencies.
- Socket analyses package behaviour and metadata to flag supply chain risks, as a commercial product.
Advisory scanners miss what is not reported yet. Scorecard scores a repository, not your dependency tree in context. Commercial behaviour analysis is effective but closed. The gap is an open, explainable scanner that combines advisories with predictive signals for your specific tree and ranks the result so a small team can act on the top five items, not four hundred.
What you build
- Developer: runs the scanner locally or in CI on a lockfile and gets a ranked, explained report.
- Team lead: views a dashboard per project, compares scans over time, and reviews the risk diff on a pull request.
- Maintainer of the scanner (you): tunes signal weights and caches registry metadata.
The technically interesting part
Prioritisation is the contribution. A report with four hundred findings is ignored. Rank by context: direct versus deeply transitive, production versus dev-only, whether an advisory applies to the installed version, and how many risk signals stack on one package. Explain each score in a sentence (for example, "single maintainer, no release in three years, runs an install script, used in production").
Getting data at scale. Resolving thousands of packages means careful caching of registry metadata, respecting rate limits and handling scoped packages and aliases. Store metadata so repeat scans take seconds.
Lookalike detection. Compare new package names against a list of popular packages using edit distance and common tricks (swapped characters, extra hyphens), while keeping false alarms low.
How to evaluate it
- Real projects: scan at least 20 open source projects; report findings per project and what share a developer judged actionable.
- Retrospective test: reconstruct lockfiles from before known incidents and check whether your signals would have flagged the affected package.
- Noise: compare the number of items in your top ten against a plain advisory scanner's output.
- Speed: cold and warm scan times for small, medium and large trees.
Suggested plan
- Weeks 1 to 2: study past incidents, pick signals, design the data model.
- Weeks 3 to 5: lockfile parsing, tree resolution, OSV matching.
- Weeks 6 to 8: metadata collection, caching, risk signals.
- Weeks 9 to 10: scoring model, explanations, SBOM export.
- Weeks 11 to 12: dashboard and lockfile diff.
- Weeks 13 to 15: evaluation, retrospective test, report.
Path to a product
The first users are small software houses and startups that ship client projects without a security team. Release the CLI as open source to build trust and adoption, then offer a hosted dashboard with pull request comments as a paid team plan. Contributing signals back to projects like OpenSSF is another route to visibility.
Scope warning
One ecosystem, done properly. Do not build a malware sandbox or run package code. Do not publicly label real packages as malicious; report signals, not accusations.
Learn what you need on Sefism
- Trivy : an open source scanner to compare against and borrow SBOM ideas from.
- GitHub Docs: Security and code quality : Dependabot, dependency review and code scanning workflows.
- DevOps and cloud roadmap : CI pipelines where the scanner will run.
- Open source roadmap : how to release and maintain the CLI as a real project.
- Backend cheat sheet : APIs, caching and rate limiting for the metadata service.
Get help with this idea
The value of this project is in the scoring model and how you validate it, not in the number of signals. Tauseef can help you pick the signals worth computing, design the retrospective evaluation, and keep the scope to one ecosystem. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.