New in the Hexward line: TenantWatch.

Most teams live entirely in Microsoft 365 or Google Workspace and have never audited the security settings. TenantWatch connects read-only and reports what actually gets organisations breached — admins without MFA, over-permissioned third-party apps, mailboxes auto-forwarding outside the org, admin sprawl, "anyone with the link" sharing, and spoofable domains (SPF/DKIM/DMARC). Findings are prioritised and self-resolving: fix the setting and it clears on the next scan. Self-hosted, single binary, no telemetry — nothing leaves your network.

Honest by design: anything it can't assess with the permissions granted shows as a "manual review" note, never a false all-clear.

• Free edition (1 tenant): github.com/nizartuanku/tenantwatch

• Pro / Team (more tenants, longer history, alerts) — 14-day trial: https://whop.com/nizar-tuanku/tenantwatch

Expiry is the failure everyone monitors, because it is the only one with a date attached. The quieter ones do not announce themselves — they wait until a client stricter than your browser tries to connect.

A hostname that does not match. A chain missing its intermediate, which your browser papers over from cache and a Java client refuses outright. A weak key or a SHA-1 signature that survived a renewal nobody actually reviewed. A host still accepting TLS 1.0 while presenting a perfectly valid certificate.

"Not expired" is the lowest bar a certificate can clear. Most monitoring stops there.

CertLight (formerly CertWatch — same product, new name) watches yours from your own server and audits the configuration the uptime tools ignore:

• Staged expiry alerts at 30 / 14 / 7 / 1 days

• Configuration grading — protocols, ciphers, key strength, signature algorithms

• Broken and incomplete chain detection, hostname mismatch, unexpected self-signed certs

• Legacy protocol probe — catches servers still accepting TLS 1.0/1.1 even when browsers negotiate 1.3

• Findings arrive with the fix attached, deduplicate across scans, and auto-resolve when you fix the cause

• Notifications batch into one worst-first digest instead of a flood

Free edition — Apache-2.0:

https://github.com/nizartuanku/certlight

sha256sum -c SHA256SUMS
tar -xzf certlight-free-*-linux-amd64.tar.gz
./certlight
# dashboard on http://127.0.0.1:8422 — add your first host

Pro $19/mo — 100 hosts, custom scan interval, scan-now, Slack/Telegram/webhook, 1-year history.

Team $49/mo — unlimited hosts and history, priority support.

14-day trial: https://whop.com/nizar-tuanku/certlight-tls-monitor

Honest limits.

• It observes from wherever you run it. A host reachable only from inside a segment needs a probe inside that segment.

• It monitors; it does not renew. Your ACME client keeps that job.

• Grading is opinionated. Disagree with a grade and the underlying facts are still on screen — check those, not the letter.

• It will not find hosts you did not tell it about. That is a different tool — see the Attack Surface Monitor post.

The list of hostnames you monitor is itself sensitive. It stays on your infrastructure; nothing phones home.

Every mailbox provider that receives mail claiming to be from your domain will send you a daily report naming every source that tried. That is what DMARC aggregate (RUA) reports are.

Almost nobody reads them, because they arrive as zipped XML in a mailbox no one opens. So domains sit at p=none for years, spoofed mail keeps landing, and the one dataset that answers "is anyone impersonating us?" rots unread.

Why so many domains are stuck there. Google, Yahoo and Microsoft now require bulk senders to publish DMARC — Google's threshold is 5,000 messages a day to Gmail. But Google's own guideline states the enforcement policy can be set to none. So the compliant minimum is a record that instructs receivers to do nothing differently. It satisfies the gatekeeper and blocks no spoofing at all.

DmarcWatch reads the reports and answers four questions: who sends as this domain, is anyone spoofing it at volume, did a new sender appear this week, and is the evidence strong enough to tighten the policy.

It also watches the failure mode nobody watches for: reports that stop arriving. A broken rua= address or a dead mailbox looks exactly like "all clear" until you check.

Alignment is the part people skip. An SPF pass is not a DMARC pass. That is how a marketing platform reports healthy SPF while contributing nothing to your posture — it authenticates its own domain, not yours. In the report it shows as a source with an SPF pass and an alignment failure, easy to skim past, and usually the reason a domain cannot leave p=none.

The specification moved this year. DMARC is now RFC 9989 (Proposed Standard, May 2026), obsoleting RFC 7489, with aggregate reporting split into RFC 9990. The pct tag is gone — staged rollouts planned around pct=25 need rewriting. A new np tag covers non-existent subdomains. Receivers now walk DNS upward instead of consulting the Public Suffix List. Most DMARC material online still cites 7489.

Free edition — Apache-2.0:

https://github.com/nizartuanku/dmarcwatch

One domain, 30-day history. Upload the report files exactly as they arrive — .xml, .xml.gz or .zip, up to 50 per upload, duplicates detected so re-uploading a folder is safe.

sha256sum -c SHA256SUMS
tar -xzf dmarcwatch-free-*-linux-amd64.tar.gz
./dmarcwatch
# dashboard on http://127.0.0.1:8429

Pro $19/mo — 10 domains, 365-day history, email/Slack/Telegram, on-demand rescan.

Team $49/mo — unlimited domains and history, PagerDuty/Teams, multi-user.

14-day trial: https://whop.com/nizar-tuanku/dmarcwatch

Honest limits. Ingestion is upload-only in v0 — no IMAP polling yet, so getting files out of the mailbox is still manual. Aggregate reports only: no forensic (RUF) reports, no enrichment of source IPs. Thresholds are fixed in v0. It reads reports; it does not change your DNS — moving to p=quarantine is your edit, through your change process.

Small SIEM deployments rarely die loudly. They die in one of three quiet ways: the ingest bill outgrows the value, alert fatigue trains everyone to ignore the channel, or a detector silently stops concluding anything and nobody notices because silence and safety look identical.

Mine died the third way once. One field was never filled: the timestamp on each parsed line. "Five failures in two minutes" quietly became "five failures, ever, since the beginning of time." The cooldown inverted. The chain that should have escalated never reached its window. Nothing errored. It ran, it processed, it reported healthy — it just never concluded anything.

That is the question worth asking of any detection stack you run: not "does it false-positive?" but "can I prove it is still able to fire?"

Loglight ingests syslog (UDP/TCP, RFC 3164 and 5424), file tail, journald, Docker and Windows events, and runs five curated detections: brute force, credential stuffing, port scan, exfil volume, and new admin.

The part that matters more than the detections: cross-source kill-chain correlation. A port scan, then brute force, then a successful login from the same address becomes one incident with the timeline attached — not three unrelated alerts you join up yourself at 2am.

Every other Hexward tool can emit its findings to Loglight as syslog with a single flag: -syslog loglight.internal:5514. A Decoy trip from an address Loglight already saw scanning arrives as one critical incident. No glue code, and it works on the free tier.

Free edition — Apache-2.0, same detection engine as paid:

https://github.com/nizartuanku/loglight

One source, all five detections, webhook notifications, 3-day retention.

sha256sum -c SHA256SUMS
tar -xzf loglight-free-*-linux-amd64.tar.gz
./loglight
# dashboard on http://127.0.0.1:8427

Pro $29/mo — 10 sources, custom thresholds, scan-now, email/Slack/Telegram, 30-day retention.

Team $99/mo — unlimited sources, multi-user, PagerDuty/MS Teams, unlimited retention.

14-day trial: https://whop.com/nizar-tuanku/loglight

Honest limits. Loglight is a detection tool, not a forensics platform and not a searchable log archive. It keeps bounded recent events for context, not a long-term store. If you need to answer "what happened on this host six months ago", that is a different product and you should run one.

CVSS answers "how bad would this be if exploited?" It does not answer "is anyone exploiting it?" Those are different questions, and patching by the first one is how a 9.8 that nobody has ever weaponised jumps the queue ahead of a 7.5 that is being used against people this week.

Patchlight ranks your actual inventory by CISA KEV (confirmed exploited in the wild) and EPSS (probability of exploitation in the next 30 days), with CVSS as one input among three rather than the verdict. Every finding shows the matched CPE, the version range, and the raw numbers — not a black-box score.

A failure mode worth knowing about, whether or not you use this tool. Ask an exploit-prediction API for six hundred CVEs in one request and it answers with the first page. The ones never returned are not marked missing — they are read as zero. Then the zero gets cached, so the mistake does not disappear on the next scan. It hardens.

A small inventory never shows this. It appears exactly where prioritisation matters most. The fix is to separate "the score is zero" from "no answer came", and never cache the second one.

Free edition — Apache-2.0:

https://github.com/nizartuanku/patchlight

25 inventory items, full ranking engine.

sha256sum -c SHA256SUMS
tar -xzf patchlight-free-*-linux-amd64.tar.gz
./patchlight
# dashboard on http://127.0.0.1:8425

Pro $29/mo — 500 inventory items, SBOM import (CycloneDX/SPDX), custom scan interval, scan-now, offline/air-gapped mirror, 1-year history.

Team $99/mo — unlimited items, PagerDuty/MS Teams, unlimited history.

14-day trial: https://whop.com/nizar-tuanku/patchlight-cve-prioritizer

Honest limits.

• Patchlight prioritises; it does not scan hosts to discover what is installed. You supply inventory — manually, by CPE, or via SBOM.

• Accuracy depends on NVD's CPE data and on your inventory's precision. Every finding shows the matched CPE and version range so you can sanity-check it.

• KEV is curated, not exhaustive. EPSS is a probability, not a prediction. Both are shown as numbers.

• Not a patch-deployment tool, and not a replacement for a host vulnerability scanner — a prioritiser that complements one.

Air-gapped environments are supported through mirrored feeds, because the estates that most need patch prioritisation are often the ones that cannot reach the internet to get it.

Your attack surface is not what you deployed. It is what you forgot to decommission.

The staging host from a launch two years ago. The subdomain still pointing at a service you stopped paying for. Nobody monitors them, because nobody remembers they exist — which is precisely why they are still reachable.

Attackers enumerate from the outside. They do not consult your inventory; they build their own. Which means their list is more accurate than yours. That is the whole problem.

The one that turns into someone else's foothold: a dangling DNS record. A CNAME still pointing at a cloud service you released. Anyone who can claim that service name now serves content on your domain — with your name in the address bar and, depending on your cookie scope, more than that.

ASM enumerates your verified domains the way a stranger would, on a schedule, and diffs the result daily: new ports, new subdomains, newly exposed panels, and records pointing at nothing.

It scans only domains you have proven you own — DNS TXT or HTTP ownership check before the first scan. That is a deliberate constraint, not a missing feature.

Free edition — Apache-2.0:

https://github.com/nizartuanku/attack-surface-monitor

One verified domain. Note the binary is asm:

sha256sum -c SHA256SUMS
tar -xzf asm-free-*-linux-amd64.tar.gz
./asm
# dashboard on http://127.0.0.1:8423

Pro $29/mo — 10 domains, custom scan interval, scan-now, email/Slack/Telegram, 1-year history.

Team $99/mo — unlimited domains, PagerDuty/MS Teams, unlimited history.

14-day trial: https://whop.com/nizar-tuanku/attack-surface-monitor

Honest limits.

• ASM finds exposure, not exploitable vulnerabilities. Pair it with a vulnerability scanner for the "is it exploitable?" question.

• Passive discovery is not exhaustive: assets absent from Certificate Transparency and DNS will not be found by default. ASM shows which sources contributed, so the coverage claim stays honest.

• It sees only what is reachable from where it runs. For internal-only assets, run a second instance inside that segment.

• It scans only domains you have verified.

A complete map of your own exposure is exactly the document you least want sitting in someone else's cloud. This one stays on your machine.