DEV Community: Hugo | DevOps | Cybersecurity

Why One Source Is Never Enough: How We Decide a Vulnerability Is Fixed

Hugo | DevOps | Cybersecurity — Tue, 20 Oct 2026 14:15:04 +0000

Every vulnerability record on this platform answers one practical question: is there a fix, or not? The honest answer is often harder to establish than it looks — because the first entity to say "this is fixed" is frequently the one with the least independent standing to confirm it.

Our position is simple and it does not change: no single source is treated as final. A vendor, a CNA, or an automated advisory feed stating that a version is fixed is a claim. We record that claim, we show it to you plainly — and we mark the record PATCH UNDER REVIEW until an independent, separate-origin source (a Linux distribution's own security team, an enterprise errata feed, or an ecosystem database that did its own analysis) confirms the fix. Only then does a record turn green.

This is not caution for its own sake. The history of security is full of cases where the first "it's fixed" was wrong — sometimes by accident, sometimes on purpose.

A trusted source can be wrong — or hostile: xz-utils (CVE-2024-3094)

In March 2024, a backdoor was discovered in xz-utils, a compression library present in nearly every Linux distribution. It carried the maximum severity score of 10.0. What makes this case essential is how it got there.

The backdoor was not the work of an outside attacker breaking in. It was introduced by a project maintainer — an identity operating as "Jia Tan" that had spent roughly two years building trust, contributing legitimately, and applying pressure through sock-puppet accounts until it was handed maintainer rights to the project. The malicious code was then shipped in the released source tarballs, while being absent from the project's public Git repository. An observer trusting the maintainer's published releases would have seen a normal, trusted, actively-maintained project.

It was caught not by trusting the source, but by independent scrutiny: a Microsoft engineer, Andres Freund, investigating an unrelated performance oddity in a Debian development build. Linux distributions — Debian, Red Hat, SUSE — then independently reverted the affected packages, and the hosting platform temporarily disabled the project's repository.

The lesson: the entity publishing a release is not, by itself, proof that the release is safe or that its claims are true. Confirmation has to come from somewhere that did its own work.

The first "fixed" is often not the real fix: Log4Shell (CVE-2021-44228)

In December 2021, Log4Shell became one of the most severe vulnerabilities ever disclosed, affecting an enormous share of Java applications worldwide. A fix was published quickly — version 2.15.0.

Except 2.15.0 was not the end of it.

Version	Issue	New CVE
2.15.0	Incomplete fix in certain configurations	CVE-2021-45046
2.16.0	Denial-of-service issue	CVE-2021-45105
2.17.0	Further remote-code-execution issue	CVE-2021-44832
2.17.1	Real, stable fix	—

If a platform had simply recorded "fixed in 2.15.0" the moment that version shipped — because the upstream project said so — it would have told its users they were safe when they were not, three times over. The real, stable fix was established only through independent testing and disclosure over the following weeks.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Wazuh SIEM: Open Source Threat Detection Deployment

Hugo | DevOps | Cybersecurity — Mon, 19 Oct 2026 14:15:05 +0000

The PagerDuty pager went off 300 times between 02:00 and 06:00 on a Saturday. The on-call sysadmin — a good one, two months into the job — muted the channel at 03:40 and went back to sleep. Nobody blamed him. The root cause was a default Wazuh install forwarding every level-7 alert to PagerDuty, with no suppression, no tuning, and no ISM policy. That deployment was ripped out six weeks later and the org bought a commercial SIEM they couldn't afford. The tool wasn't the problem. The deployment was.

This guide is for infrastructure and security engineers who are deploying Wazuh for real — not labbing it. By the end you'll know how to size it honestly, deploy it with TLS from day one, tune rules so you don't drown, wire up the integrations that pay for themselves, and keep it running past the 18-month mark when most open source SIEM installs quietly rot.

:::note[TL;DR]

Wazuh is a real SIEM + HIDS + compliance stack, but only if you separate the indexer from the manager past ~50 agents — the all-in-one installer is a lab toy.
Set ISM retention on the indexer before you ingest a single alert. Default is forever; you will fill a disk.
Custom rules go in the 100000+ ID range, always. Never edit stock rules in place.
Don't forward everything to PagerDuty. Level ≥ 10 only, and only after a week of tuning.
The tuning tax is real: budget 2-4 hours a week for the first quarter, then ~1 hour a week ongoing. :::

Prerequisites

Two or more Linux hosts (Ubuntu 22.04 LTS or RHEL/Rocky 9 are safe bets) with root or sudo
Minimum 8 vCPU / 16 GB RAM / 200 GB SSD for a lab; see sizing section for prod
A DNS name or IP plan for manager, indexer, dashboard, and agents
Open ports per the table below (firewall both sides)
Basic familiarity with systemctl, openssl, and reading XML without crying

Why Wazuh Exists (And Why You Should Care)

Most orgs can't afford Splunk at scale. Elastic's move to SSPL in 2021 burned a lot of people who'd built on the ELK stack. Wazuh is the FOSS answer that actually ships, and it bundles three things you'd otherwise buy separately: host-based intrusion detection (file integrity, rootkit, log analysis), SIEM correlation, and compliance evidence collection. The common failure mode is people install it, forget to tune it, and drown in 40k alerts a day.

The OSSIM Problem and the Agent-Based Advantage

OSSIM (AlienVault's open source SIEM) died a slow death after AT&T acquired AlienVault, and its agentless, network-scanning model was already losing to agent-based telemetry for endpoint detection. Agents see file changes, process executions, and registry modifications that a network tap never will. Wazuh's architecture reflects this: an agent on each endpoint forwards events to a manager that evaluates rules and correlates, which writes to an indexer (OpenSearch fork) that the dashboard queries.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Ceph Standalone: RADOS, RBD, CephFS Without Proxmox

Hugo | DevOps | Cybersecurity — Sun, 18 Oct 2026 14:15:03 +0000

A monitor got wedged at 03:14 on a Tuesday. The Proxmox cluster was fine — quorum held, VMs were running — but ceph -s from the host returned a HEALTH_WARN nobody on the team could interpret, because nobody on the team had ever run ceph -s outside the GUI. The pveceph wrapper had hidden the monmap, the wrapper had baked opinionated defaults into a config file that was actually a symlink into /etc/pve, and the recovery procedure in the vendor KB started with "edit ceph.conf" on a file that was being regenerated by a daemon every thirty seconds. We lost four hours to a problem that a standalone cluster would have surfaced in a single ceph mon dump.

This guide is for the admin who has outgrown the hypervisor-managed storage layer — or is about to build storage from scratch and wants to do it properly. By the end you'll have bootstrapped a standalone Ceph cluster with cephadm, built RADOS pools with sane placement, served RBD images to clients via systemd units, mounted CephFS with a standby MDS, and wired up the monitoring and backup paths that actually matter. No Proxmox, no wrappers, no config-file roulette.

:::note[TL;DR]

Proxmox's pveceph integration hides the RADOS layer you need when things break; standalone cephadm gives you the real control surface.
Three nodes is the floor, not the target — plan for at least four with a dedicated cluster network.
RADOS is the foundation: get pools, PGs, and CRUSH right before you touch RBD or CephFS.
RBD and CephFS are clients — tune them like clients, back them up like clients.
Replication is not backup. Write the rbd export script before you need it. :::

Prerequisites

Three or more physical or VM nodes running a modern Debian/Ubuntu or RHEL-family release, all on the same L2 network segment for the public and cluster networks.
Root or passwordless sudo on every node.
At least one dedicated block device per node for OSDs (not a partition on the OS disk).
Two network interfaces per node (public + cluster), or a single interface with VLAN separation if you're brave and documented.
chrony installed and pointed at a reliable time source.
SSH key-based access from the bootstrap node to every other node.

Why You Should Stop Letting Proxmox Drive Your Ceph Cluster

Proxmox's Ceph integration is genuinely good at one thing: making a hyperconverged cluster boot in an afternoon. It wraps ceph commands in pveceph, generates a ceph.conf that lives as a symlink under /etc/pve/, and applies defaults that assume you want a small cluster with minimal tuning. That's fine until the defaults aren't fine, and then you're debugging through a layer that was never designed to be debugged.

Here's the telltale fingerprint of a Proxmox-generated config:

# /etc/pve/ceph.conf — note this is a symlink, not a regular file
[global]
     auth_client_required = cephx
     auth_cluster_required = cephx
     auth_service_required = cephx
     cluster_network = 10.15.0.0/24
     fsid = 4f0d2a8e-...
     mon_allow_pool_delete = true
     mon_host = 10.15.0.11 10.15.0.12 10.15.0.13
     ms_bind_ipv4 = true
     osd_pool_default_min_size = 2
     osd_pool_default_size = 3
     public_network = 10.15.0.0/24

That mon_allow_pool_delete = true is a Proxmox default you probably don't want on a production cluster. The symlink means any hand-edit gets clobbered. And the comparison between the wrapper and the real thing is stark:

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Linkerd vs Istio: Choosing the Right Service Mesh

Hugo | DevOps | Cybersecurity — Mon, 12 Oct 2026 14:15:04 +0000

A platform team I worked with burned six weeks rolling Istio across an 800-pod cluster, then discovered their on-call rotation couldn't debug a broken request path without three istioctl proxy-config incantations and a Kiali dashboard nobody had learned to read. The mesh worked. The humans didn't. They ripped it out and installed Linkerd in an afternoon.

That story isn't an argument that Istio is bad. It's an argument that the mesh decision is a team decision, not a feature decision. The wrong mesh at the wrong scale is technical debt you pay for in 3 AM pages.

This guide is for platform engineers, SREs, and DevOps leads running Kubernetes somewhere between 10 and 5,000 pods. After reading it you'll be able to size the real cost of each mesh, benchmark the latency tax honestly, and make a defensible call — including the option of running neither.

:::note[TL;DR]

Both meshes deliver mTLS and L7 observability. Istio additionally delivers method/path-level authorization, egress control, and mature multi-cluster — at a real operational cost.
Per-sidecar memory is the hidden budget killer: Linkerd's Rust proxy is typically far lighter than Envoy, and it compounds across every pod you run.
If you can't articulate a concrete need for L7 authz or multi-cluster, Linkerd is the correct default. Istio is a commitment, not a checkbox.
Cilium Service Mesh deserves evaluation if you already run Cilium as your CNI — sometimes the answer is neither of the two big names. :::

Prerequisites

A working Kubernetes cluster (1.27+ recommended; tested against 1.29 as of this writing) with kubectl and Helm 3 configured.
Cluster-admin rights to install CRDs and control-plane components.
A non-production namespace you're willing to break. Do not run your first mesh install against prod.
Basic familiarity with mTLS, SPIFFE identities, and how sidecar injection works.
Optional but recommended: fortio or wrk2 for load generation, and a Prometheus/Grafana stack already scraping your cluster.

The Service Mesh Lie You've Been Sold

A service mesh does exactly three things well: it gives you mTLS everywhere without app changes, it gives you L7 observability (request rates, error codes, latency percentiles) at the network layer, and it gives you traffic policy — retries, timeouts, circuit breaking, shifting, mirroring. That's it.

It does not do authorization policy for your application. It does not do business logic. It does not fix your broken service discovery, and it will not make a badly designed service topology resilient. If you install a mesh hoping it will "secure the cluster," you've outsourced a problem you haven't defined.

The Real Cost Model Nobody Talks About

The vendor blog posts show you a latency chart with a p50 delta of "under a millisecond" and call it negligible. p50 is a lie. What matters is p99 under load, because that's the number your users feel and your SLOs measure.

Then there's the resource tax. Every sidecar consumes CPU and memory on every node. At 50 pods this is background noise. At 500 pods it's a line item. At 5,000 pods it's a capacity planning exercise that will surprise your finance team.

A war story worth internalizing: on an 800-pod cluster running Istio's sidecar mode, the Envoy proxies consumed roughly 20-25% of total node memory budget. Nobody had modeled that. The cluster was over-provisioned to compensate, which meant paying for nodes that existed solely to host proxies.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Longhorn vs Rook-Ceph: Kubernetes Storage Compared

Hugo | DevOps | Cybersecurity — Sun, 11 Oct 2026 14:15:03 +0000

Every platform team eventually gets the ticket. It reads something like: "The Postgres pod won't schedule after the node rebooted, and now the whole staging environment is down." You dig in and find the database was pinned to a hostPath volume, the node got cordoned for a kernel patch, and nobody wrote down that the PVC was effectively single-node. That's the moment persistent storage stops being an app team's problem and becomes a platform decision.

This guide is for the engineer who has to make that decision and live with it for the next five years. By the end you'll understand how Longhorn and Rook-Ceph actually move bytes to disk, where each one breaks under pressure, and how to pick the one your team can operate at 3 AM — not the one that wins a synthetic benchmark on someone's blog.

It assumes you already run Kubernetes, you have opinions about StorageClass, and you're tired of the "just use NFS" crowd.

:::note[TL;DR]

Longhorn is an opinionated, iSCSI-backed, replica-per-volume system built for operational simplicity. Great under ~50 nodes, painful above it.
Rook-Ceph is the full RADOS/Ceph stack under a Kubernetes operator. More performance and more features, but you're adopting an ecosystem, not a CSI driver.
Neither is "install and forget." Both fail in interesting ways, and both need off-cluster backups.
Pick based on the team you have, not the benchmark you envy. :::

Prerequisites

You should have a working Kubernetes cluster (v1.27+ is a reasonable floor as of this writing), kubectl with cluster-admin, helm v3, and fio available for testing. For the S3 backup examples you'll need credentials to an object store. For Ceph, expect to provision raw block devices — loopback files will teach you nothing useful.

The Storage Problem Nobody Wants to Own

Stateful workloads on Kubernetes are still painful because the abstraction leaks. A PersistentVolumeClaim looks like a simple API object, but underneath it's a promise about durability, latency, and failure semantics that the API can't express. When that promise breaks, it breaks loudly and at scale.

There are three tiers of production storage, and they fit different problems:

Cloud provider CSI — managed, expensive, and vendor-locked. Fine if you're all-in on one cloud and the bill is acceptable.
Network filesystems (NFS, CIFS) — fine for shared config and read-mostly data, catastrophic for databases. If you're running Postgres on NFS, stop.
Distributed storage you run yourself — Longhorn, Rook-Ceph, OpenEBS, Portworx. This is the tier that gives you control and takes your weekends.

"Distributed storage" means data is replicated across failure domains so a single disk or node loss doesn't lose data. What vendors pretend it means is "we put a CSI driver on top of a single server and called it distributed." Check where the replicas actually live before you trust the word.

A war story worth internalizing: a team I worked with ran their primary Postgres on a hostPath volume with a nodeAffinity rule. It worked for eleven months. Then a NIC failed on that node, the pod couldn't reschedule because the data was on a disk attached to a dead machine, and the recovery window was four hours of restoring from a nightly pg_dump. The lesson isn't "don't use hostPath" — it's that storage topology is a platform concern, and if you don't own it, you're borrowing someone else's outage.

Longhorn — The Opinionated Upstart

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ZimaBlade PCIe Expansion: Custom NAS and Router Combo

Hugo | DevOps | Cybersecurity — Wed, 07 Oct 2026 14:15:03 +0000

The 2am phone call was a zpool scrub. The BGP session had flapped four minutes earlier, the failover to the backup ISP did not happen because the backup circuit was on the same box, and the on-call rotation had my number because I was the only one who claimed to understand the hardware. That is the story of every "one box to rule them all" build that survives past month three.

The ZimaBlade is a $70-ish single-board computer with a real PCIe slot, and that slot is the entire reason anyone cares. This guide is for homelabbers, sysadmins, and network engineers who want to know whether you can genuinely run a NAS and a router on the same silicon — and more importantly, whether you should. By the end you will know which PCIe cards are worth buying, how to size ZFS on 8GB of soldered DDR3L, which router OS actually fits an N3350, and where the failure domains will bite you.

Prerequisites

A ZimaBlade 7700 (or 3760 — verify the PCIe electrical lanes before buying, they differ)
8GB RAM variant preferred; 4GB is workable for a router-only role
A PCIe 2.0 x4 card that physically fits the half-height slot
Boot media: SATA SSD or USB, not the onboard eMMC for anything you care about
A serial console adapter (USB-TTL) for headless recovery
Working knowledge of ZFS, Linux networking, and at least one firewall OS

:::note[TL;DR]

The ZimaBlade's PCIe 2.0 x4 slot (~2 GB/s theoretical) is fine for 2.5GbE and a 4-bay SATA HBA. It is not a 10GbE or NVMe RAID platform.
Two build paths: single-purpose (NAS or router) or split-purpose (both, virtualized or bare metal with cgroups).
Running NAS + router on one box is a bad idea for most people and a great idea for a narrow set of lab/cabin/RV scenarios.
Verify NIC chipset before purchase — Intel i211 vs. Realtek changes your entire driver story. :::

Why the ZimaBlade Is a Weird, Wonderful Little Box

Most SBCs give you GPIO pins and a dream. The ZimaBlade gives you a physical PCIe slot, dual NICs, and SATA — which is a completely different product category. That slot is why this thing has a cult following despite shipping with a 2016-era Celeron.

What You Actually Get for ~$70

Intel Celeron N3350 (dual-core, 1.1–2.4 GHz) or N3450 (quad-core) depending on SKU
8GB DDR3L soldered (some SKUs 4GB — check before buying)
PCIe 2.0 x4 physical slot, electrically x1 on some board revisions — this is the single most important spec to verify
Dual gigabit NICs (Intel i211 on some revisions, Realtek RTL8111 on others — this matters enormously for FreeBSD)
SATA via ASM1061 controller, USB 3.0, eMMC boot

The PCIe Slot Is the Whole Point

PCIe 2.0 x4 gives you roughly 2 GB/s of theoretical bandwidth. That sounds thin until you realize 2.5GbE is ~312 MB/s and a 4-disk SATA HBA will never saturate it. Where it falls apart: 10GbE needs ~1.25 GB/s sustained, and NVMe RAID wants multiples of that. If you saw a YouTube thumbnail promising 10GbE on a ZimaBlade, that thumbnail was lying to you.

Verify the link negotiation before you trust any of this:

# Confirm the actual negotiated link width and speed, not the marketing spec
lspci -vv | grep -A2 "LnkCap\|LnkSta"
# Expected on a good board: LnkSta: Speed 5GT/s, Width x4
# If you see Width x1, you bought the wrong revision

If LnkSta reports Width x1, your 2.5GbE card will still work but you have less headroom for an HBA on the same bus. Plan accordingly.

What This Box Is Not

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

iSCSI Storage for Hypervisors: TrueNAS, LIO, Multipath

Hugo | DevOps | Cybersecurity — Sat, 03 Oct 2026 14:15:03 +0000

Two paths, one dead for three weeks, nobody noticed. That's the story I keep running into. A cluster of a dozen VMs ran fine on a single surviving iSCSI path until a switch firmware reboot took the second one down at 02:00. Every VM froze for five minutes, then errored out. The monitoring was green the entire time because nobody was watching path state — only "is the LUN up." This guide is about making sure that doesn't happen to you.

This is for sysadmins and platform engineers running KVM-based hypervisors (Proxmox VE, plain libvirt, XCP-ng) who need block storage that behaves under failure. After reading, you'll be able to design an iSCSI fabric, build a target on TrueNAS SCALE or raw LIO, write a multipath.conf that isn't cargo-culted, and verify failover before you trust it with production VMs.

:::note[TL;DR]

Block storage wins for VM workloads because there's no double-caching and no file-locking pathologies — but only if you build it right.
TrueNAS SCALE wraps the same kernel LIO target you'd get with targetcli, just with a GUI and guardrails. Pick based on who's on call at 3am.
A single path is a SPOF with a nice name. Multipath is not optional.
Tune no_path_retry and dev_loss_tmo, or your VMs will hang for minutes on path failure.
Monitor path state, not LUN state. Save your targetcli config every time. :::

Prerequisites

Two servers: one target (TrueNAS SCALE or Debian/Ubuntu/RHEL with targetcli), one or more initiators.
Dedicated NICs or VLANs for iSCSI traffic. Do not share with VM traffic.
open-iscsi and multipath-tools installed on every initiator.
targetcli-fb (or targetcli) on raw LIO targets.
Root/sudo on both sides and a maintenance window for the first failover test.

Why Block Storage Still Wins (And When It Doesn't)

The reflex is "just use NFS, it's simpler." Sometimes that's correct — shared filesystems, template stores, and anything where multiple hosts need the same file are NFS territory. But for VM disk images, block wins, and it's not close.

The Case For iSCSI Over NFS for Hypervisors

With iSCSI, the client is stateless. The hypervisor sees a LUN, puts XFS or LVM-thin or ZFS on it, and the target has no idea what filesystem lives inside. That means no client-side cache coherency to reason about, no NFSv4.1 session trunking to debug, and no file-locking pathologies when a VM does something stupid with flock().

NFSv4.1 sessions are not multipathing. They give you trunking across multiple connections to the same server, but if that server dies, everything dies. Real multipath gives you two independent paths to two independent controllers, and the kernel picks one.

I moved a cluster off NFS after a coherency incident: two KVM hosts mounted the same NFS export, one host's page cache went stale after a network blip, and a VM wrote a corrupted qcow2 over a file the other host had just modified. iSCSI with a properly sized LUN per VM eliminated the class of problem entirely.

When You Should Absolutely Not Do This

If you have one initiator, one target, one switch, and one cable — you've built a SPOF with extra steps. iSCSI without multipath is worse than NFS because at least NFS will give you a clean I/O error. A dead iSCSI path with default timeouts will hang your VM for minutes before anything surfaces.

The "I'll add multipath later" crowd always adds it after the first outage. Do it now.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Dark Web Reality Check: What I Found After 3 Weeks

Hugo | DevOps | Cybersecurity — Tue, 29 Sep 2026 14:15:04 +0000

The first thing I found wasn't a drug market. It wasn't a carding forum. It was a Jenkins instance.

I was three days into a four-week enumeration project, running a Python scraper against a list of .onion addresses pulled from Ahmia, when a response came back that shouldn't have existed on Tor: a Jenkins login page, running version 2.289.1, exposed via a hidden service with no authentication on the /script endpoint. The hostname in the page title belonged to a Fortune 500 subsidiary. Someone in their dev org had spun up a Tor hidden service "for remote access" during a 2020 lockdown and never told security. That CI pipeline had production AWS credentials in its environment variables.

If you're a defender, that's the dark web. Not the monster under the bed — the mirror showing you what you already leaked.

This guide is for sysadmins, security engineers, and threat intel analysts who want to understand what's actually out there, how to enumerate it without getting owned, and — most importantly — how to find your own shadow assets before someone else does. I'm not going to teach you to buy drugs. I'm going to teach you to do OSINT on Tor like an adult with a change-management process.

:::note[TL;DR]

The "dark web" is 90% dead links, scams, and mirrors of clearnet services. The interesting 10% is mostly accidental exposure and leak sites.
Never browse Tor from your daily driver. Whonix or Tails, full stop.
Blocking Tor at the firewall is theater. Detect and log it instead.
The real risk to your org isn't hackers on Tor — it's the sysadmin who spun up a hidden service and forgot.
Treat leak sites as a data source, not a destination. Automate, don't interact. :::

Prerequisites

Before you touch any of this, you need:

A dedicated research VM or physical host (not your work laptop — I'll explain why in the opsec section)
Whonix Gateway + Workstation, or Tails on a USB stick
Python 3.9+ with stem, requests[socks], and beautifulsoup4
Basic familiarity with iptables/nftables and Linux namespaces
A legal review from your org's counsel if you're doing this on company time (seriously)

What "The Dark Web" Actually Is (And What It Isn't)

Words matter here, because people conflate three different things constantly. The deep web is anything not indexed by search engines — your intranet, your bank portal, your O365 tenant. The dark web is content hosted on overlay networks like Tor, I2P, and Freenet that requires specific software to reach. Tor is the transport; the dark web is an application layer on top of it.

Tor uses onion routing — traffic is wrapped in three layers of encryption and bounced through three relays (guard, middle, exit). I2P uses garlic routing, which bundles multiple messages together and is optimized for internal services (eepsites) rather than exit traffic. Freenet is a distributed datastore, mostly academic at this point. ZeroNet is effectively dead. If someone tells you they're "on the dark web" and they mean ZeroNet, they're either confused or lying.

Why "Just Block Tor at the Firewall" Is a Losing Strategy

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

OSSEC vs Wazuh: FIM and Active Response Compared

Hugo | DevOps | Cybersecurity — Mon, 28 Sep 2026 14:15:03 +0000

OSSEC vs Wazuh: File Integrity Monitoring and Active Response

OSSEC and Wazuh share roughly 80% of their codebase and 100% of their spelling of ossec.conf. The 20% divergence is where your architecture decision lives — and it is not a small 20%. It is the difference between a scanner that writes flat files and a platform that expects an OpenSearch cluster with a JVM heap you have to size.

Here is the thesis up front: OSSEC is a fragile, brilliant, near-frozen engine. Wazuh is the same engine with a database, an API, and a compliance story bolted on — and a resource bill to match. Both will page you at 03:00. Only one of them will still have a CVE-patched release next quarter.

This guide covers FIM and Active Response specifically, because those are the two modules people actually migrate for. Everything else — log decoders, rootcheck, SCA — is either identical or not worth the migration on its own.

:::note[TL;DR]

Syscheck's engine is the same code in both projects. The divergence is in change attribution (whodata), storage, and the API.
Real-time FIM on Linux is inotify-based in both. Wazuh adds auditd-backed whodata for attribution; OSSEC's implementation is older and thinner.
Active Response is the single most dangerous module in either product. firewall-drop at [location]server[/location] will block your own agents.
OSSEC's floor is a 1–2 GB VM. A useful Wazuh deployment is realistically 8–16 GB across manager plus indexer.
Migrating is a config porting exercise for syscheck and a near-rewrite for anything that touched the OSSEC database output. :::

Prerequisites

A working OSSEC 2.9.x/3.x or Wazuh 3.x/4.x manager, and at least one agent registered.
Root (or equivalent sudo) on the manager and agents — syscheck reads /etc, and Active Response scripts run as root by design.
auditd installed on Linux hosts if you want whodata attribution.
For Wazuh 4.x: the indexer and dashboard up, since that is where FIM events land.
A staging host you are willing to lock out of the network. Seriously.

Two Codebases, One Ancestor

Wazuh started as a fork of OSSEC and had its first standalone release in 2015. Since then, upstream OSSEC's cadence has been measured in years, not months; the 2.9.x line went effectively quiet and the 3.x line is carried by Atomicorp as a vendor-maintained branch. Wazuh ships on a much faster cycle and, critically, publishes CVEs and fixes for the whole stack.

The uncomfortable truth is that the fork is the product, not a bug. The original OSSEC codebase was never designed for a manager that stores every FIM event, an API with RBAC, or a multi-node cluster. Wazuh didn't just add features — it rearchitected the data plane, and that rearchitecture is exactly what costs you RAM.

First thing to do on any inherited box: find out which engine you are actually running, because "OSSEC" appears in paths regardless of which project you deployed.

# Wazuh still installs to /var/ossec — the path lies. Check the version.
/var/ossec/bin/wazuh-control info 2>/dev/null || /var/ossec/bin/ossec-control status

# Both projects write VERSION into ossec-init.conf on install
grep -E '^VERSION' /var/ossec/etc/ossec-init.conf

# Confirm which binaries exist — this is the fastest fork fingerprint
ls -1 /var/ossec/bin/ | grep -E 'wazuh|ossec' | head -20

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ZimaBoard as a Home Server: N3450 Pushed to Its Limits

Hugo | DevOps | Cybersecurity — Fri, 25 Sep 2026 14:15:03 +0000

Every few months someone posts a ZimaBoard in a 3D-printed rack, running Pi-hole, and the comments fill up with people asking where to buy one. Eleven months later that same board is sitting in a drawer because /dev/mmcblk0 hit end-of-life, the 32GB eMMC silently corrupted the Proxmox root filesystem, and the only backup was a snapshot on a USB drive that hadn't been mounted in six weeks. The hardware didn't fail. The person running it treated a 6W single-board computer like a datacenter node and skipped every flash-endurance and thermal decision that makes the difference.

This guide is for homelab operators who already own a ZimaBoard 432 or 832 — or are about to buy one — and want to run real workloads on it: Proxmox, a media stack, a reverse proxy, a WireGuard gateway, and a handful of containers. By the end you will have a measured baseline for the N3450, a storage architecture that does not eat itself, a PCIe expansion path you actually committed to, VPN throughput numbers you can reproduce, and a written list of triggers that tell you when to migrate off the platform.

The thesis, and everything below follows from it: the Celeron N3450 is a fine low-power server for I/O-bound workloads and a terrible one for crypto-bound and CPU-bound workloads. Miss that distinction and you will spend a weekend tuning a box that was never going to do what you asked.

:::note[TL;DR]

The N3450 has no AES-NI, no AVX, no TSX, and single-channel soldered non-ECC DDR3L. That single fact dictates WireGuard over OpenVPN, rules out ZFS root, and caps TLS termination.
Boot from eMMC, store on SATA/NVMe, and move /var/log to tmpfs immediately. Default journald on eMMC is a documented way to kill the board in under a year.
The open PCIe 2.0 x4 slot is the only real differentiator against an N100 mini-PC. Pick one expansion path — SATA, NIC, or NVMe — and commit.
Buy the 832 (8GB). The 216 ships 2GB of soldered RAM; that is not a virtualization host, it is a paperweight with two NICs. :::

Prerequisites

You need a ZimaBoard 432 or 832 with a 12V/2A (minimum) power supply, a Debian 12 or Proxmox VE 8 install target, physical access to the PCIe slot, and a second machine to run iperf3 against. Install sysbench, mmc-utils, smartmontools, ethtool, lm-sensors, cpupowerutils, and zram-tools before you start. Everything below was written against Proxmox VE 8.x on Debian 12; package names shift over time, so check your distro if something is missing.

What the Celeron N3450 Actually Is (and Isn't)

Before you tune anything, you need to know what physics allows. The N3450 is Apollo Lake / Goldmont: 4 cores, 4 threads, 1.1 GHz base, 2.2 GHz burst, 6W TDP, single-channel DDR3L-1866 soldered to the board with no ECC option. No SMT, so four cores is four threads, full stop.

The headline is what is missing: no AES-NI, no AVX, no TSX, no AVX2. On the Celeron SKUs Intel fused off the AES extensions that the Goldmont core design otherwise carries. This is not a footnote you skim past. It determines your VPN protocol, your disk-encryption throughput, your TLS handshake capacity, and whether WireGuard's 400 Mbps is a benchmark result or a fantasy. Every "ZimaBoard is great for X" post that doesn't mention the missing AES-NI was written by someone who never ran a benchmark.

Measure your own board before you trust anyone's numbers — including mine:

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ValtersIT CVE + Threat-IP API: Integration Guide for Firewalls, SIEM and CI/CD

Hugo | DevOps | Cybersecurity — Tue, 22 Sep 2026 11:39:17 +0000

Your firewall vendor publishes a critical advisory. Days later NVD assigns a score, a PoC lands on GitHub, and CISA adds it to KEV. Correlating those sources by hand is a tooling problem, not a knowledge problem.

The ValtersIT API puts CVE records (150,000+) and a threat-IP dataset (290,000+ addresses) behind one REST interface with one authentication scheme. This guide shows five integrations end to end. Every API request and response shape below was checked against the live API, including the failures.

What you get

Data	Details
CVE records	150,000+. `cvss`, `cvss_vector`, `epss`, `severity`, `cisa_kev` (boolean), `has_exploit`, `has_patch`, `poc_status`, `poc_url`, `cwe_id`, `mitre_tactic`, `shodan_dorks`, `affected_version`, `patch_details`
Detection content	`yara_rule`, `wazuh_rule`, `elastic_rule` on paid plans where a rule exists. `sigma_rule` and `poc_code` are Pro only
Threat IPs	290,000+ addresses. `ip`, `threat_type`, `confidence`, `sources`, `cve_ids`, `malware_families`, `country_code`, `asn`, `org`, `ports`, `is_tor`, `is_vpn`
Data honesty	`pending_fields` lists what NVD has not filled in yet, `backfilled_fields` lists what we filled in after the fact

Base URL: https://api.valtersit.com/api/v1

Authentication: Authorization: Bearer <your key> on every request. Keys look like vit_v1_....

Threat IP types you can filter on: scanner, mixed, malware_dist, botnet_c2, phishing, tor, exploit_host, c2_server, spam, brute_force. Confidence scores are conservative: only a small number of IPs score 75 or above, so start with min_confidence=50.

Try it in 30 seconds

The public sandbox key needs no signup and costs nothing. It serves ten synthetic CVE records (CVE-2026-90001 to CVE-2026-90010) so you can test your parsing before you pay for anything.

# List all ten sandbox records
curl -s https://api.valtersit.com/api/v1/cve \
  -H "Authorization: Bearer vit_sandbox_free_demo_key_2026" \
  | jq '.data[] | {cve_id, vendor, cvss, severity, cisa_kev, poc_status}'

# One record
curl -s https://api.valtersit.com/api/v1/cve/CVE-2026-90001 \
  -H "Authorization: Bearer vit_sandbox_free_demo_key_2026" \
  | jq '{cve_id, vendor, cvss, severity, cisa_kev, poc_status, pending_fields}'

{
  "cve_id": "CVE-2026-90001",
  "vendor": "SandboxSoft Firewall Pro",
  "cvss": 9.8,
  "severity": "critical",
  "cisa_kev": true,
  "poc_status": "Public",
  "pending_fields": []
}

The sandbox has no IP feed. For real data, register for a free key at api.valtersit.com and top up, or subscribe.

Ground rules used in every example

Put the key in an environment variable: export VIT_API_KEY=vit_v1_...
GET /cve needs at least one filter (vendor, severity, cvss_min, cvss_max, epss_min, has_exploit, has_patch, changed_since, published_since). Pages hold at most 100 records. (The sandbox key is exempt from the filter rule.)
Single lookups such as GET /cve/CVE-2026-26084 return the record itself, not a data wrapper. List endpoints return {"data": [...], ...}.
Errors: 401 bad or missing key, 402 out of credits, 403 plan does not allow it, 404 unknown CVE, 422 bad parameter, 429 rate limit. Every metered response carries X-RateLimit-Limit and X-RateLimit-Remaining.
Pay-as-you-go spends one credit per CVE record returned. Standard and Pro track every CVE you look up, and re-checking one you have already fetched is free.

Use case 1: Firewall blocklist from the threat-IP feed

Browsing the feed by criteria needs Standard or Pro (Standard returns up to 500 rows per request, Pro up to 1,000). Pay-as-you-go can look up specific addresses with ?ips=1.2.3.4,5.6.7.8 (up to 10 per request) but cannot pull the list.

Pick your filters from the data, not from hope. At the time of writing:

Filter	IPs returned
`type=botnet_c2&min_confidence=50`	about 10,800
`type=malware_dist&min_confidence=50`	about 31,000
`type=scanner&min_confidence=50`	about 125,000 (usually too broad to block outright)

#!/usr/bin/env python3
"""Pull botnet C2 IPs and write an nftables batch file."""
import ipaddress
import os
import subprocess

import requests

API = "https://api.valtersit.com/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}
PAGE = 500  # Standard cap. Pro allows 1000. A larger limit is clamped, not rejected.


def fetch(threat_type: str, min_confidence: int = 50) -> list[str]:
    ips, offset = [], 0
    while offset is not None:
        r = requests.get(
            f"{API}/ip/feed",
            headers=HEADERS,
            timeout=30,
            params={"type": threat_type, "min_confidence": min_confidence,
                    "limit": PAGE, "offset": offset},
        )
        r.raise_for_status()
        body = r.json()
        ips += [row["ip"] for row in body["data"]]
        offset = body["next_offset"]  # None on the last page
    return ips


def build_batch(ips: list[str]) -> str:
    v4 = [i for i in ips if ipaddress.ip_address(i).version == 4]
    v6 = [i for i in ips if ipaddress.ip_address(i).version == 6]
    lines = ["add table inet filter"]
    for name, family, members in (("vit_block4", "ipv4_addr", v4), ("vit_block6", "ipv6_addr", v6)):
        lines.append(f"add set inet filter {name} {{ type {family}; }}")
        lines.append(f"flush set inet filter {name}")
        for i in range(0, len(members), 1000):
            chunk = ", ".join(members[i:i + 1000])
            lines.append(f"add element inet filter {name} {{ {chunk} }}")
    return "\n".join(lines) + "\n"


if __name__ == "__main__":
    ips = sorted(set(fetch("botnet_c2")))
    path = "/var/lib/vit/blocklist.nft"
    os.makedirs(os.path.dirname(path), exist_ok=True)
    with open(path, "w") as f:
        f.write(build_batch(ips))
    subprocess.run(["nft", "-f", path], check=True)  # one atomic transaction
    print(f"loaded {len(ips)} addresses")

Add the drop rules once, and run the script from cron (*/30 * * * *). Because it rebuilds the sets on every run, addresses that leave the feed age out on their own.

nft add rule inet filter input ip saddr @vit_block4 drop
nft add rule inet filter input ip6 saddr @vit_block6 drop

pfSense / OPNsense: the API requires an authentication header, so a firewall cannot fetch the feed directly as a URL table alias. Run the fetch on any Linux host, write one address per line to a file you serve on your internal network, and point the alias at that internal URL.

Use case 2: Enrich SIEM alerts with CVE context

An IDS alert carries a CVE ID and nothing else. This helper turns it into a priority decision using fields that exist on every record.

import os
import time

import requests

API = "https://api.valtersit.com/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}


def enrich(cve_id: str) -> dict | None:
    for attempt in range(3):
        r = requests.get(f"{API}/cve/{cve_id}", headers=HEADERS, timeout=10)
        if r.status_code == 429:               # rate limited: wait and retry
            time.sleep(2 ** attempt)
            continue
        if r.status_code == 404:               # not in the database
            return None
        r.raise_for_status()                   # 401 / 402 / 5xx should be loud
        c = r.json()                           # the record itself, no "data" wrapper
        priority = "P1" if c["cisa_kev"] or (c["has_exploit"] and (c["cvss"] or 0) >= 9) else \
                   "P2" if c["has_exploit"] or (c["cvss"] or 0) >= 7 else "P3"
        return {
            "cve_id": c["cve_id"], "vendor": c["vendor"], "cvss": c["cvss"],
            "epss": c["epss"], "cisa_kev": c["cisa_kev"], "has_exploit": c["has_exploit"],
            "has_patch": c["has_patch"], "pending_fields": c["pending_fields"],
            "priority": priority,
        }
    raise RuntimeError("rate limited after 3 attempts")

Print the result as JSON and this works as a scripted lookup, an n8n or Shuffle step, or a Splunk adaptive response action. For Elastic, the Logstash http filter does the same inline:

filter {
  if [cve_id] {
    http {
      url => "https://api.valtersit.com/api/v1/cve/%{[cve_id]}"
      headers => { "Authorization" => "Bearer ${VIT_API_KEY}" }
      target_body => "vit"
    }
    if [vit][cvss] {
      mutate {
        add_field => {
          "[threat][cvss]"     => "%{[vit][cvss]}"
          "[threat][epss]"     => "%{[vit][epss]}"
          "[threat][kev]"      => "%{[vit][cisa_kev]}"
          "[threat][exploit]"  => "%{[vit][has_exploit]}"
        }
      }
    }
  }
}

Put a cache in front of the lookup (Logstash memcached filter, Redis, or a translate table). Alerts repeat the same CVE constantly, and on pay-as-you-go every fresh record costs a credit.

Use case 3: CI/CD prioritization gate

The API is not a scanner and it does not match package versions. Let your scanner (Trivy, Grype, OSV-Scanner) find the CVE IDs, then use the API to decide which ones should actually stop a build: known-exploited, exploit-available, or unpatched and severe.

#!/usr/bin/env python3
"""Fail the build on CVEs that are actively dangerous. Input: trivy JSON on stdin."""
import json
import os
import sys

import requests

API = "https://api.valtersit.com/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}
MAX_LOOKUPS = 50  # each new CVE costs a credit on pay-as-you-go

report = json.load(sys.stdin)
ids = sorted({v["VulnerabilityID"]
              for res in report.get("Results", [])
              for v in res.get("Vulnerabilities") or []
              if v["VulnerabilityID"].startswith("CVE-")})[:MAX_LOOKUPS]

blocked = []
for cve_id in ids:
    r = requests.get(f"{API}/cve/{cve_id}", headers=HEADERS, timeout=15)
    if r.status_code == 404:
        continue                                # unknown to us: leave it to the scanner
    if r.status_code == 402:
        sys.exit("::error::out of API credits, gate could not run")
    r.raise_for_status()
    c = r.json()
    if c["cisa_kev"] or (c["has_exploit"] and not c["has_patch"] and (c["cvss"] or 0) >= 9):
        blocked.append(f"{cve_id} cvss={c['cvss']} kev={c['cisa_kev']} exploit={c['has_exploit']} patch={c['has_patch']}")

if blocked:
    print("::error::blocking CVEs found:")
    print("\n".join(f"  {b}" for b in blocked))
    sys.exit(1)
print(f"gate passed ({len(ids)} CVEs checked)")

- name: CVE gate
  env:
    VIT_API_KEY: ${{ secrets.VIT_API_KEY }}
  run: |
    trivy fs --format json --quiet . | python3 scripts/cve_gate.py

You can also ask the API directly for the worst offenders of a vendor you depend on:

curl -s "https://api.valtersit.com/api/v1/cve?vendor=Fortinet&cvss_min=9&has_exploit=true&has_patch=false&limit=5" \
  -H "Authorization: Bearer $VIT_API_KEY" | jq '.total_count, (.data[] | {cve_id, cvss})'

Use case 4: Change tracking

CVE data matures over days: NVD scores arrive late, patches appear, a PoC goes public. Three tools cover it.

Poll for changes. changed_since takes an ISO-8601 date or datetime. Store the time of your last run and ask for everything newer:

curl -s "https://api.valtersit.com/api/v1/cve?vendor=Microsoft&changed_since=2026-09-18T00:00:00Z&limit=50" \
  -H "Authorization: Bearer $VIT_API_KEY" \
  | jq '.total_count, (.data[] | {cve_id, cvss, has_exploit, updated_at})'

Use Z for UTC. A +02:00 offset must be URL-encoded as %2B02:00, because a bare + in a query string turns into a space and the API answers 422.

Read pending_fields. Every record says which values are still missing, so you know when a result is provisional:

"pending_fields": ["license_model", "origin_country"]

Re-check a record later and the list shrinks. backfilled_fields reports values we filled in after you paid for the record.

Push instead of poll (Pro). A watchlist entry sends a webhook when a matching CVE is published or updated:

curl -s -X POST https://api.valtersit.com/api/v1/watchlist \
  -H "Authorization: Bearer $VIT_API_KEY" -H "Content-Type: application/json" \
  -d '{"vendors": ["Fortinet"], "min_severity": "high", "webhook_url": "https://example.com/hooks/cve"}'

Your endpoint receives a POST with cve_id, vendor, cvss, summary and url. Webhook URLs must be public http(s) endpoints (private and internal addresses are refused), up to 50 entries per account. Delivery is best-effort: a failed POST is not retried, so treat the webhook as a nudge and use changed_since as your source of truth.

Use case 5: Detection rules and PoC status in one call

import os

import requests

r = requests.get("https://api.valtersit.com/api/v1/cve/CVE-2026-26084",
                 headers={"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}, timeout=15)
r.raise_for_status()
c = r.json()

print(c["cve_id"], c["vendor"], "cvss", c["cvss"], "| PoC:", c["poc_status"], c["poc_url"] or "")

for field, ext in (("yara_rule", "yar"), ("wazuh_rule", "xml"), ("elastic_rule", "txt")):
    if c.get(field):
        with open(f"{c['cve_id']}.{ext}", "w") as f:
            f.write(c[field])
        print("wrote", f"{c['cve_id']}.{ext}")

if c["sigma_rule_locked"]:
    print("a Sigma rule exists for this CVE but needs the Pro plan")

Not every CVE has every rule, so always check for null. Treat every rule as a starting point: read it, test it against known-good traffic in a lab, and only then deploy. poc_status and poc_url are on every plan. The poc_code field (sanitized exploit code where publicly available) and sigma_rule are Pro only.

Quick reference

Endpoint	Purpose
`GET /cve`	Search CVEs (at least one filter, up to 100 per page)
`GET /cve/{id}`	One CVE record
`GET /ip/feed`	Threat IPs: `type`, `min_confidence`, `country`, `cve`, `changed_since`, `ips`, `limit`, `offset`
`GET /ip/{ip}`	One IP (`404` if unknown, `400` for private ranges)
`POST /watchlist`, `GET /watchlist`	Webhook alerts (Pro)
`GET /history`	CVEs you have looked up, with change flags
`GET /usage`	Credits and rate-limit status
`GET /status`	Public service status

Plan	Credits / month	Rate limit	API keys	IP feed
Pay-as-you-go	top-up, €0.08 per credit	10 / min	1	look up specific IPs (`ips=`, up to 10 per request)
Standard	5,000	30 / min	1	full browsing, 500 rows per request
Pro	20,000	100 / min	5	full browsing, 1,000 rows per request, plus proprietary sources

Why Security Teams Are Replacing Manual CVE Tracking With the ValtersIT API

Hugo | DevOps | Cybersecurity — Mon, 21 Sep 2026 21:00:00 +0000

Every security team has a CVE problem. Not a shortage of CVE data — a surplus of it, scattered across sources that disagree, update at different rates, and give you no way to prioritize.

NVD publishes 200–400 CVEs per day. CISA adds entries to KEV on its own schedule. GitHub shows PoC exploit code hours before any official feed picks it up. Your SIEM fires on a CVE ID. You need CVSS, the exploit status, whether a patch exists, and a detection rule — immediately, not after two browser tabs and a grep through three CSVs.

The ValtersIT API is the single endpoint that gives you all of that, per CVE, on demand.

What the free sources actually cost you

The common response to "we need CVE enrichment" is to stitch together free sources: NVD API, CISA KEV CSV, OSV.dev, ExploitDB. This works. It also means maintaining four integrations, handling rate limits on all four, reconciling data that contradicts itself (NVD says CVSS 7.5, an advisory says 9.8), and re-running the chain every time you need fresh data.

Source	What it gives you	What it doesn't give you
NVD API	CVSS, CWE, CPE	EPSS, real exploit status, patch confirmation, detection rules
CISA KEV	Active exploitation flag	CVSS, EPSS, technical detail, detection content
OSV.dev	Package-level vuln records	Normalized severity, MITRE tactic, PoC code
ExploitDB	PoC code	Machine-readable CVE linkage, CVSS, KEV status
GitHub CVEProject	Raw JSON from CNAs	No enrichment, no structured severity, no detection content

Correlating these manually takes 15–30 minutes per CVE. Automating it takes weeks of engineering time and ongoing maintenance.

A typical security engineer costs €60–100/hr fully loaded. One hour of manual CVE research per week is €3,000–5,000/year. The ValtersIT Standard plan is €19/month.

What one API call returns

curl -s https://api.valtersit.com/api/v1/cve/CVE-2024-3400 \
  -H "Authorization: Bearer vit_v1_YOUR_KEY" | jq

{
  "cve_id": "CVE-2024-3400",
  "vendor": "Palo Alto Networks",
  "severity": "critical",
  "cvss": 10.0,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
  "epss": 0.9744,
  "has_exploit": true,
  "has_patch": true,
  "cisa_kev": true,
  "poc_status": "Public",
  "cwe_id": "CWE-77",
  "mitre_tactic": "T1190",
  "shodan_dorks": ["product:\"GlobalProtect\"", "http.title:\"GlobalProtect\""],
  "affected_version": "PAN-OS 10.2, 11.0, 11.1 below specific versions",
  "patch_details": "Fixed in PAN-OS 10.2.9-h1, 11.0.4-h1, 11.1.2-h3",
  "yara_rule": "rule CVE_2024_3400 { ... }",
  "wazuh_rule": "<group name=\"vulnerability,...\"> ... </group>",
  "elastic_rule": "process where process.args : \"*/...AAAA*\"",
  "pending_fields": [],
  "credits_used": 1
}

That is one HTTP request. Everything needed to triage, alert, and respond — no joins, no secondary lookups, no format reconciliation.

The EPSS number changes everything

CVSS scores are assigned once and rarely change. A CVE with CVSS 7.5 from 2023 sits in the same bucket as a CVE with CVSS 7.5 from last week, even if one has active exploits in the wild and the other has never been touched.

EPSS (Exploit Prediction Scoring System) is updated daily and measures the probability of exploitation in the next 30 days based on real-world data. The ValtersIT API returns it as a decimal float (0.0–1.0) on every CVE record, normalized — no string parsing needed.

Practical prioritization:

import requests

resp = requests.get(
    "https://api.valtersit.com/api/v1/cve",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"severity": "critical", "has_exploit": "true", "limit": 20}
)

for cve in resp.json()["data"]:
    # EPSS >0.5 = 50%+ chance of exploitation in next 30 days
    if cve["epss"] and cve["epss"] > 0.5:
        print(f"{cve['cve_id']} | CVSS {cve['cvss']} | EPSS {cve['epss']:.1%} | {cve['vendor']}")

This query runs in under 300ms. The same result from NVD + EPSS API requires two separate authenticated calls, rate limit awareness, and field normalization.

Detection content included — not add-on priced

Every CVE that has had detection content generated ships it in the API response with no extra call. YARA rules, Wazuh rules, and Elastic EQL/KQL queries are included on every paid plan. Sigma rules and raw PoC code are Pro only.

Getting detection content from free sources requires a Sigma rule repository (often months behind), manual YARA authoring, or a paid subscription to a different vendor. The ValtersIT API includes it in the same response you're already making.

The data honesty contract

Free CVE feeds hide their gaps behind null values that look identical to "this field genuinely doesn't apply." The ValtersIT API separates the two cases explicitly:

{
  "cve_id": "CVE-2026-99999",
  "cvss": null,
  "pending_fields": ["cvss", "epss", "mitre_tactic"]
}

pending_fields means NVD hasn't assigned these values yet (CVSS typically arrives 2–14 days after publication). When they do, the field moves out of pending_fields. On Pay-As-You-Go, the backfill is free — you're not charged twice because NVD caught up.

Pricing: less than one analyst-hour per month

Plan	Price	Credits/mo	Sigma + PoC code
Sandbox	Free	— (10 synthetic records)	—
Standard	€19/mo	10,000	—
Pro	€65/mo	50,000	✓
Pay-as-you-go	€5/1,000 credits	—	—

One credit per CVE record returned. Already-fetched CVEs on Standard/Pro are always free to re-check.

Start in 30 seconds — no credit card

The sandbox key is public. Ten synthetic CVE records, full response shape, immediate testing:

curl -s "https://api.valtersit.com/api/v1/cve" \
  -H "Authorization: Bearer vit_sandbox_free_demo_key_2026" \
  | jq '.data[0] | {cve_id, vendor, cvss, epss, cisa_kev, has_exploit, pending_fields}'

When ready for real data: api.valtersit.com

The gap the ValtersIT API closes

Between "CVE is published" and "your team acts on it" there are four steps: find it, enrich it with CVSS/EPSS/KEV/exploit status, write or find detection content, distribute to whoever needs it. Free tools require a human to do all four manually. The ValtersIT API collapses steps two and three into a single HTTP call.

That's not a small efficiency gain. It's the difference between a CVE being actionable in 5 minutes and actionable in 5 days.