Automating repetitive tasks means more than saving time – it means greater reliability and consistent operations.
A lightweight, modular workflow for automated vulnerability detection has been implemented using EnergySOAR, combining nmap scanning, Python-based analysis, and conditional email notifications. The solution is designed to operate in production environments with minimal supervision, running cyclically via a scheduled cron trigger.
Scope and Flexibility
The workflow supports scanning any IP address visible from the scan host, with the full list of targets defined in an external CSV file. This input list allows logical grouping and segmentation by organization, asset owner, or infrastructure domain. Hosts can be included with custom port configurations, enabling both broad sweeps and narrow, targeted scans – all within the same logic pipeline.
Process Flow and Implementation
The process is fully visualized and managed in EnergySOAR’s Workflow builder, using discrete logic blocks and branching conditions to enforce control flow. A single execution proceeds through the following stages:
1.NMap scan
the system performs lightweight, passive scans focused on known vulnerabilities exposed on network ports. It’s a non-intrusive approach, well-suited for regular checks without disrupting services. Output is collected in raw form for further processing.
Example of scan output:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| vulners:
| cpe:/a:openbsd:openssh:8.9p1:
| CVE-2023-38408 9.8 https://vulners.com/cve/CVE-2023-38408
| CVE-2023-28531 9.8 https://vulners.com/cve/CVE-2023-28531
2. List processing and iteration
The CSV file is parsed, and an iterator loops over each IP address. The structure allows future scaling to parallelized scanning by subnet or ownership group.
3. Vulnerability extraction
Custom Python scripts extract relevant data from the raw scan, isolating host-port-vulnerability triplets. These are normalized using EnergySOAR’s modules to produce structured, comparable results.
4. Comparison and delta calculation
The new scan is compared with the latest previous result (archived locally), matching vulnerabilities by port and unique vulnerability ID. Differences are evaluated: both new findings and removals are tracked.
5.Conditional branching
Logic conditions determine the next step:
-
- If no differences are found, the pipeline exits silently or with optional cleanup.
- If vulnerabilities were removed, a message is generated (e.g., to track remediation progress).
- If new vulnerabilities are discovered, the scan is saved, and an email alert is triggered.
6. Notification and reporting
Alerts are sent regardless of outcome. Even failed scans result in notifications, which help detect upstream failures or coverage issues. Each email includes information about which host saw a change and what vulnerability appeared or disappeared.
Resilience and Maintenance
Although the current version keeps only recent scans in active storage, log rotation and long-term archival are part of the next development phase. The workflow has built-in fault tolerance – failed executions or missing data do not stop the pipeline and are handled with messaging.
A typical run takes a few minutes, depending on scan size and host count. Scaling to larger scopes or increasing frequency is straightforward due to the modular design.
Outcome and Next Steps
The result is a reliable, autonomous, and scalable solution for passive vulnerability monitoring – suitable for integration with SIEM platforms, ticketing systems, or response playbooks. Most importantly, it removes the need for routine manual effort while maintaining visibility into infrastructure exposure.
The next workflow in development targets host activity monitoring. It will regularly validate whether hosts are still reporting and whether required log streams are being received. While simple in concept, this kind of check often reveals issues like misconfigurations, unexpected reboots, or early signs of service degradation – well before end-user’s notice.
