Dependency Supply Chain Risk Scanner
A scanner that reads a project's dependency tree and scores it on more than known vulnerabilities: maintenance activity, maintainer concentration, install scripts and recent ownership changes. The interesting risks are the ones no advisory database has recorded yet.
Intermediate
A small team, or one strong student willing to learn something new.1 semester, 2 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- Dependency resolution from lockfiles for at least one ecosystem, including transitive dependencies
- Known vulnerability matching against a public advisory database
- Risk signals beyond advisories: last release date, maintainer count, install scripts, sudden ownership change
- Software bill of materials export in a standard format
- Report ranking findings by exploitability in context rather than listing everything by severity
If you have time left
- Reachability analysis determining whether vulnerable code is actually called
- Diffing two lockfiles to show what a proposed upgrade changes in the risk profile
- Continuous integration integration failing a build on newly introduced high risk dependencies
The problem
Modern applications have thousands of transitive dependencies maintained by strangers. Existing scanners check them against advisory databases, which by definition only covers what has already been discovered and reported.
What you build
Dependency resolution from lockfiles, advisory matching, and a set of risk signals that are predictive rather than historical.
The signals worth computing
A package with one maintainer and no release in three years. A package that runs a script at install time. A package whose ownership changed recently, which is the pattern behind several real compromises. A package whose name is one character from a very popular one. None of these appear in an advisory database and all of them are computable.
Why prioritisation is the contribution
A scanner reporting four hundred findings is ignored. Ranking by whether the vulnerable code is reachable, whether the dependency is direct or deeply transitive, and whether it is in production or only in tests, is what makes output actionable. Argue and demonstrate this.
How to evaluate it
Run it against several real open source projects and report what it found and how much was actionable. If you can retrospectively identify a real compromised package your signals would have flagged, that is your strongest result.
Scope warning
One ecosystem, done properly. And do not name real packages as malicious in a published report without extreme care.
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. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.