Security also starts with what we install
We install Python packages, VS Code extensions, tools that help us save time, test an idea, or simply improve our development environment.
Then we move on.
A few months or years later, some of those projects have been deprecated, archived, renamed, or are simply no longer maintained.
And they are still installed.
That is exactly the problem I wanted to address with Dependency Security Checker, an open source tool that locally scans installed Python packages and VS Code extensions, then compares them against documented alert databases.
The project is open source and available here:
Dependency Security Checker, GitHub
An alert before a vulnerability becomes your problem
The goal is not to claim that a dependency is vulnerable simply because it is no longer maintained.
That would be incorrect.
The goal is much simpler: to warn you.
If an installed package has officially been deprecated, you should be able to know about it.
If a VS Code extension you still use has been archived, you should be able to know that too.
And if a project has been renamed or its maintainers now recommend an alternative, that information should be easy to find.
A tool that does not make decisions for you
Dependency Security Checker does not uninstall anything, disable anything, update anything, or modify your projects.
It scans, detects, and displays the available information:
[!] package-name 1.0.0
Status / Statut: DEPRECATED / DÉPRÉCIÉ
Reason:
...
Raison :
...
Suggested replacement / Remplacement suggéré: ...
Source: ...
From there, the decision is yours.
You can check the source, understand why the project was flagged, review how you use it, and decide whether it should be kept, replaced, updated, or removed.
This approach matters because a security-related tool should not create another problem by automatically modifying an environment it does not fully understand.
Deprecated does not mean vulnerable
This is probably the most important distinction behind the project.
An abandoned dependency is not automatically vulnerable.
Likewise, the absence of an alert does not mean a dependency is secure or free from vulnerabilities.
But when a project is no longer maintained, one question becomes legitimate:
Who will fix the next vulnerability if one is discovered?
This is where dependency maintenance becomes directly relevant to security.
Vulnerabilities do not only come from the code we write ourselves, they can also exist in the different components we add to our environments and projects.
With the number of packages, libraries, extensions, and development tools a modern environment can accumulate, it becomes increasingly difficult to remember exactly what is still installed and whether every component is still maintained.
Why is it open source?
Because when it comes to security, I prefer being able to see what a tool actually does.
Dependency Security Checker runs locally, its alert databases are visible, its sources can be checked, and its behavior can be inspected directly in the code.
It does not need to send your list of packages or VS Code extensions to a remote service to perform the scan.
Today, with software failures, compromised dependencies, abandoned projects, and supply-chain security issues becoming increasingly difficult to ignore, security should not be treated as something we think about only after a problem occurs.
Making the project open source also means something important:
You do not have to simply trust the tool.
You can inspect it.
You can verify its data.
You can contribute.
You can report incorrect information or submit another officially deprecated or abandoned dependency with a public source.
You do not need to be a developer to understand the result
I also wanted to avoid building something that only makes sense to someone who spends every day working in a terminal.
A developer can use it as a quick check of their environment, but a less technical user can also run the checker and understand the essential result.
No known alert found, nothing installed matched the current database.
An alert appears, something deserves your attention.
Then you get the status, the reason, a suggested replacement when one exists, and most importantly, the source.
No mysterious score.
No invented risk level.
No automatic decision.
The information remains understandable.
A database designed to evolve
The first version already contains hundreds of documented alerts across Python packages and VS Code extensions.
But the database is not intended to pretend it is exhaustive.
New projects will be abandoned.
Others will be archived.
Some libraries will be renamed or replaced.
The project can therefore evolve over time with one simple principle:
An alert should be backed by a source.
The objective is not to build the biggest list possible, but to maintain a database reliable enough for an alert to actually mean something when it appears.
A few seconds to look at what we are using
Software security can become extremely complex.
Here, the principle is intentionally simple.
You run the checker.
It looks at what is installed.
It compares it against its local database.
If it finds something, it tells you.
Then you investigate.
Because before deciding whether a dependency should still be part of your environment, you first need to know that it deserves your attention.
The project is available here:
Dependency Security Checker, GitHub
