NetVendor: Turning Network Device Discovery Into Your First Line of Defense Against Cyber Threats10/31/2025
Updated October 5, 2026 · Formerly NetVendor
ShadowVendor turns exported MAC address lists, switch MAC tables and ARP tables into vendor inventories, interactive dashboards and reports that security teams can investigate. My open-source Python tool runs locally and supports formats from Cisco, HP/Aruba, Juniper, Extreme, Brocade and other equipment. Start with the data you already have. ShadowVendor analyzes supplied files; it does not actively scan the network or prove that a device is safe. Its value is making vendor composition and changes easier to see. Get ShadowVendor and its current documentation →
Why device visibility matters
Before a team can investigate unfamiliar equipment, review segmentation or plan an upgrade, it needs a useful inventory. ShadowVendor adds manufacturer information to observed MAC addresses and retains VLAN and port information where the input provides it. That gives analysts a starting point for questions such as: Which vendors appear in this segment? What has changed since the previous export? Which switch port should we investigate? The results describe the supplied snapshot—not every device an organization owns. Repeatable collection from relevant network segments is part of the workflow.
How ShadowVendor works
1. Import. Save a MAC address list, a switch MAC address table or an ARP table as a file. ShadowVendor detects and parses supported formats. 2. Identify vendors. It normalizes addresses and checks a local OUI cache. An OUI is the manufacturer-assigned prefix of a MAC address. On a cache miss, normal operation can query external vendor services using the prefix, not the full MAC address. 3. Produce reports. Standard outputs include a device CSV, output/vendor_distribution.html and output/vendor_summary.txt. A port CSV is generated for MAC-table inputs; it is not a standard output for ARP tables or simple lists. VLAN and interface details depend on what the input contains. 4. Compare snapshots. Optional history archives store vendor summaries with run, site and change-ticket metadata. Drift analysis compares vendor counts and percentages over time. 5. Feed your monitoring workflow. Optional CSV and JSONL exports provide records for a security information and event management system (SIEM). Your ingestion pipeline and correlation rules turn these records into monitoring and alerts. A practical first run Follow the repository’s installation instructions, then try the included sample file before using a network export: python3 ShadowVendor.py --offline tests/data/test-mac-table.txt Review the device CSV and vendor summary in output/. The HTML dashboard visualizes vendor distribution. The current generated HTML references Plotly’s CDN, so viewing its charts in an air-gapped browser needs separate handling; offline analysis does not make that HTML report self-contained. For your own saved export: python3 ShadowVendor.py --offline my_switch.txt Choose the right entry point. Use python3 ShadowVendor.py for advanced flags. The shadowvendor command and python3 -m shadowvendor are basic input-file wrappers. A separate shadowvendor.analyze_file Python API supports integration in scripts.
Security use cases
History and SIEM integration
This example analyzes an export, records vendor history and produces SIEM files: python3 ShadowVendor.py --offline --history-dir history --analyze-drift --siem-export --site DC1 --environment prod --change-ticket CHG-12345 my_switch.txt The SIEM files are output/siem/shadowvendor_siem.csv and output/siem/shadowvendor_siem.json. Despite its extension, the latter contains JSONL: one JSON object per line. Records contain timestamp, site, environment, mac, vendor, device_name, vlan, interface, input_type and source_file. The timestamp is the export’s UTC time. A device name can be derived from its MAC address; it is not necessarily a discovered hostname. The current schema does not include first_seen or last_seen. Configure collection, scheduling, ingestion and rules in your operational environment. ShadowVendor’s exports support those systems; the tool does not automatically configure a SIEM, quarantine devices or provide continuous monitoring on its own. Read the integration guide.
Privacy and limits
Local processing: input files and full MAC addresses are processed on your machine. Default cache misses may send OUI prefixes to external lookup APIs. --offline disables those lookups; uncached vendors appear as Unknown. This describes the analysis process, separately from the dashboard’s CDN dependency. Attribution is not identity: MAC addresses may be spoofed, randomized or locally administered. A vendor label does not establish the exact device, its owner, its trustworthiness or its security state. Coverage follows collection: absent, powered-down or unobserved equipment may not appear. Gather appropriate edge-switch and segment data, and compare results with endpoint, asset and network-management systems. Use complementary controls: authenticated inventories, endpoint detection, packet analysis, active discovery and network access control answer questions that vendor-prefix analysis cannot. ShadowVendor is an inventory and analysis aid, not an EDR, vulnerability scanner or enforcement system.
The Quantum Shield connection
Device visibility can support post-quantum migration planning by identifying infrastructure that needs further assessment. A vendor inventory is not a cryptographic inventory: it does not identify deployed algorithms, certificates, firmware support or quantum readiness. Combine its findings with those assessments before making migration decisions. The same boundary applies to the Cerberus framework: ShadowVendor can supply contextual inventory evidence, but does not itself detect quantum attacks, implement an AI council or detect harvest-now-decrypt-later activity.
Next step
Run the sample, inspect the output and establish a repeatable collection process. Add history or SIEM exports when you have a clear use for comparisons and alerts. The goal is a better-supported investigation—not automatic trust in a vendor label.
About the Author
Stewart Alexander is an experienced cybersecurity strategist focusing on AI-powered threat detection and quantum-resistant defenses. He provides practical insights and expert guidance to protect digital assets against emerging cyber threats. His work on the Quantum Shield Initiative explores the intersection of quantum computing, artificial intelligence, and cybersecurity strategy for the coming decade. Sources
0 Comments
Leave a Reply. |
Stew AlexanderExperienced cybersecurity strategist focusing on AI-powered threat detection and quantum-resistant defenses. Providing practical insights and expert guidance to protect digital assets against emerging cyber threats, see bio for more |

RSS Feed