VIPER Public Preview 0.1.0V - Red Venom

VIPER Public Preview 0.1.0 code named Red Venom is out for public testing. Preview code is NOT ready for production.

Finally long after due VIPER code refactoring has been completed.

So what got changed, updated, improved?

Refer to the change log on GitHub for exact change details.

Changed

VIPER is no longer just a single file, it has been modularized for better code readability an maintainability. This also means that new features and updates can be easily implemented in a modular way without having to deal with changing the whole code base.

There are now 3 files to VIPER,

• viper.py
• notification_service.py
• message_builder.py

Like before viper.py is the main file and this is where you configure your API keys and log file location.

The other two files are quite self explanatory,

notification_service.py is in-charge of sending the notifications to Slack, when it receives a message to be sent from the message builder module. Improved error handling and making it it's own module makes expansion of supported notification platforms easier in the future.

message_builder.py is in-charge of building the notification before it is to be sent out via slack. It was made modular as the more types of alerts that VIPER supports the more different types of alerts need to be sent.

Improved

This modular restructuring wasn't just about splitting files—it laid the groundwork for substantial improvements across the entire system. Let's dive into what's been enhanced:

First, we've implemented a dedicated NotificationService class that's a beast when it comes to handling alerts. It now features connection pooling to efficiently manage network resources, a robust retry mechanism for those pesky network hiccups, message queuing to prevent notification loss, and full asynchronous capabilities to keep VIPER running smoothly even when Slack is having a bad day.

The new SecurityMessageBuilder allows for creating clean, consistent alerts. It uses a modular approach to building messages section by section, which means you can easily customise alert formats without wading through spaghetti code. Also added comprehensive type hints throughout the codebase - your IDE will thank you for this one.

Error handling got a serious upgrade. The old version would sometimes just give up when faced with API timeouts or connection issues. Now, VIPER gracefully handles exceptions, implements retry mechanisms with exponential backoff, and provides detailed error logging so you can actually figure out what went wrong.

HTTP connections are now handled properly with connection pooling via HTTPAdapter, making the whole system more efficient and less likely to hit rate limits. Speaking of which, I've also improved rate limiting management so VIPER plays nice with external APIs.

The centralised logging configuration is another major improvement. All logs now follow a consistent format across modules, with the log file path configured in one place - viper.py.

• NotificationService logs notification attempts, queue processing status, and both failures and successes
• MessageBuilder tracks the building process for each section and validates inputs

The new asynchronous message processing capabilities are a significant step forward. VIPER can now queue up multiple alerts and process them efficiently without blocking the main thread, making the entire system more responsive.

I've also completely revamped the code organization. The old monolithic structure was becoming unwieldy, but now everything has its place in a clean, modular architecture. This separation of concerns not only makes the code more maintainable but also makes it much easier to test individual components.

Notes

Like I said at the top this blog the code is still in testing, I would highly appreciate your input on the new code and any testing you can help with.

I hope to ship Integrations with AbuseIPDB & GreyNoise within the Red Venom release, the current code does not have these integrations.