Rozhanitsy Devlog 3

And this version comes to an end
So, i just added some features to get extra space to write this devlog, amongst these are:

• Gravatar check cuz why not
• Authentik sso because it is something i would have wanted
  Anyway, time to explain the naming just in case anyone is wondering, Rozhanitsy are the slavic equivallent of Morai, a.k.a the faiths and Svetovit is the god of war so like, rozhanitsy see it happen, svetovit detects and then helps us end it. Kinda a fun little meaning.
  Anyway, the thing is now in production ready state and i am working on svetovit, hopefully it will be slightly less vibecoded in the v1 phase but meh, i will redo it anyways when i will have more time. The plan is to support detection for wp, drupal and joomla + plugins. Also, i never mentioned it on here i think but the entire meaning of this project was to detect tenants on shared servers that don’t maintain their stuff and get us crypto miners lolsies
  Anyway, thanks for reading, imma ship now

Rozhanitsy Devlog 2

Vuln intel service — feed it installed software, get back which CVEs actually apply to it. 27 commits, empty lockfile to a dockerized app with a working sync pipeline and admin panel.Started with the schema: CpeMap, Product, Vendor, Vulnerability, VulnerabilityRange, ScanHost, Source, SyncState. That’s basically the whole app in one commit — vendors/products are a catalog I curate, CVEs link to them through ranges, hosts get matched against those ranges via CPE strings. Seeded sources instead of hardcoding “nvd” everywhere, since I figured I’d want other feeds eventually.Added scan_logs and unmatched_lookups, folded the 2FA columns migration into the users table migration instead of leaving it bolted on separately. Wrote VersionComparator, gave NVD explicit precedence over whatever else might get added later.Pulled in Sanctum, cleaned out migration cruft, updated models to match.Core loop went in next: SyncNvdVulnerabilities command, VulnCheckController, rate limiting, POST /api/vulns/check. CPE lookup → range join → version comparison → vulnerable list, with unmatched stuff parked in its own table so I can go add it to the catalog later instead of it just vanishing. Wrote a pile of tests right after — factories for everything, sync tests, vuln check tests, CPE resolver tests, rate limit tests.Small cleanup pass: slugs in the seeder, more test coverage. Then went back and tore hardcoded NVD assumptions out of the sync command and controller — added a migration so sources can carry their own driver config instead of assuming NVD forever. Wanted that fixed before the app grew around the assumption.Docker next — Dockerfile, compose, entrypoint, opcache config, a CreateScanHost command for provisioning from the CLI. Then the whole frontend in one go: dashboard, a tokens page so scan hosts can self-serve Sanctum tokens, admin dashboard, admin user management, GrantAdmin command, rewrote Welcome (cut it by more than half, mostly bloat). Wired up HandleInertiaRequests so props actually reach the frontend.Wrote the wiki same day as the features it documents — API reference, CLI reference, deployment, schema, operations. Doing it same-day beats doing it a month later once I’ve forgotten why something works the way it does.Found and fixed a memory leak in the sync command — only showed up once I ran it against the real NVD feed instead of test fixtures. Built out actual vendor/product matching: RelinkVulnerabilityRanges command, an admin products page for curating the catalog through the UI, vendor/product seeders with a real starter set.Then a commit I titled, honestly, “deshittified plugin detection.” Pulled the matching logic out of the sync command into its own VulnerabilityRangeBuilder, added an OR-group clause to vulnerability_ranges so one CVE can express “affects 1.2–1.5 OR 2.0–2.3” without hacks, added RebuildVulnerabilityRanges to regenerate ranges without re-hitting NVD. Every project has one of these commits where you fix the thing you hated three days ago.Simplified SECURITY.md, moved the wiki over to GitHub’s wiki and trimmed the in-repo copies to a README with links, merged, added CI and dependabot. Then put the full wiki files back in the repo right after — GitHub wikis are a separate repo under the hood and they drift, didn’t want to rely on it alone.Last commit: made the vuln-check API return a confidence level when it can’t pin down a version instead of silently guessing. Better to say “not sure, but here’s our best guess” than fake precision.Net result: NVD ingest → CPE resolution → version ranges → match API, admin UI to curate the catalog, dockerized, test coverage across the sync command, comparator, API, rate limits, and admin auth.

Rozhanisty devlog #1: laying the foundation

Started Rozhanisty today — a tool that pulls vulnerability data from the NIST NVD API and lets a CLI scanner check local software for known CVEs against installed versions.

Spent most of today on the database schema instead of anything flashy, but this is the part that has to be right before anything else works:

• vendors / products — normalized so a vendor (e.g. wordpress) can have multiple products (core, plugin, theme, etc.), since NVD data is a mess of vendor/product pairs that need de-duping.
• cpe_maps — maps NVD’s CPE vendor/product strings to my normalized vendor/product, with exact vs fuzzy match types since NVD naming is inconsistent and I’ll need fuzzy matching for products that don’t map 1:1.
• vulnerabilities — the actual CVE records: CVSS score/vector/version, description, published/modified dates, and the raw CPE config as JSON so I don’t lose data while I figure out matching logic.
• vulnerability_ranges — the important one. Each CVE can affect multiple version ranges per component, so this breaks it out with version_start/version_end (inclusive flags included, because NVD ranges are sometimes open-ended) and a match_confidence enum so the scanner can flag “we’re not 100% sure this applies to you.”

Stack is Laravel on the backend (queues will probably handle the NVD pulls later) with Vue for whatever dashboard/UI ends up existing for making API keys.

Next up: writing the ingestion job that actually pulls from the NVD API and populates these tables.