Emphere Engineering

Field notes from
engineering and security

How we keep a security product honest: deterministic fixtures, seeded regressions, kernel-level runners, and the evidence behind every claim. No fluff, just what we built and what it caught.

Latest
NewEngineeringEmphere EngineeringJune 8, 20269 min read

Testing a Security Tool Like It Can Hurt People

A security tool cannot be tested like a normal CLI. We built a standing assurance platform around deterministic fixtures, real-kernel runners, preserved artifacts, and red runs that prove the system can fail loudly.

5 / 22fixtures / invariants0 -> 157caught regression1 -> 0CVE confirmed / cleared
Read the post
On the workbench
02
Infrastructure

Groundzero: Building an Isolated Kernel and Exploit Lab

A bring-up log for the GCP lab where the sensor runs against real kernels: what validated, what broke, and what the first cloud runner exposed.

Drafting
03
Research

Why CVE Counts Are Wrong

Counting vulnerabilities is not the same as measuring risk. A reachability-first view of a real image, with the graph evidence to back it.

Researching
04
Engineering

Determinism by Design: Pinning the Vulnerability Feed

If the feed moves under you, your results are not reproducible. How we pin the database so repeated runs produce identical, provable output.

Queued
05
Exploitability

From Exploit to Confirmation: Vulnerable, Patched, Exercised

Matched fixtures that prove a finding is real, not theoretical, by exercising the path on a vulnerable build and confirming the patch closes it.

Queued
06
AI

Agents That Read Evidence But Never Mint Truth

An AI evaluator that reads deterministic reports and cites them — and the hard line that keeps a probabilistic system from ever becoming the oracle.

Queued
These are in progress and publish only when there is a real artifact behind them. That is the whole point.