Vulchain Scanner: 5 basic principles

New Year holidays in Russia lasts 10 days this year! Isn’t it an excellent opportunity to start a new project? So, I decided to make my own active network vulnerability scanner – Vulchain.

Why? Well, first of all, it’s fun. You can make the architecture from scratch, see the difficulties invisible from the user side and try something new in software development as well.

Vulchain modular scanner

Basic principles of the project. This is not a dogma, but rather a general direction.

  1. Data layers. I would like to have this independent sets of data:
    • Raw data collections
    • Software versions detected from the raw data
    • Vulnerabilities detected from the software versions
    • Exploitability assessment data for the detected vulnerabilities
  2. Modularity. Most of functionality will be performed by the independent modules which read some data from one data level, and create some data on other data level.
  3. Transparency. Data is stored constantly on the all levels. You can easily figure out how the data was  processed, track the errors and modify modules.
  4. Neutrality. All modules are independent and easily replaceable. For example:
  5. Rationality. If it is possible to use some security utility, service or product, we will integrate with them, rather than writing our own analogue. We spend resources only on what will give us the maximum profit at a minimum of costs. 😉

And as you can see at Pycharm screenshot above, POC is already working. Data is now stored in JSON because it’s easier to debug. It will be probably stored in some nosql database later.

  1. I create Assets with IP, hostname and description.
  2. http_content and nmap modules collect the raw data for the assets.
  3. Individual modules extract information about software / services from these raw data and save it unified format.
  4. And finally, there is a module, in this case vulners, which takes information about software / services and creates json files with detected vulnerabilities.


  • It is much easier to debug code and add new modules.
  • The loss of data is minimal, it is clear how all of the detections were made.
  • You can perform “scan without scanning”. On service data updates (rules for software and vulnerability detection), you can reprocess only certain data levels. There is no need to actively manipulate with the host each time.


  • Some redundancy in the code and stored data.

In short, the process has begun. :-). I will be happy to answer your comments and questions. Next I am going to make first sketches of API and GUI and add modules for authenticated scanning.

2 thoughts on “Vulchain Scanner: 5 basic principles

  1. Pingback: New Nessus 7 Professional and the end of cost-effective Vulnerability Management (as we knew it) | Alexander V. Leonov

  2. Pingback: Vulchain scan workflow and search queries | Alexander V. Leonov

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.