About

Defensive security tooling, built from evidence.

Systems-oriented work across Linux evidence, product-security workflows, and software supply-chain review. I build narrow, local-first tools that turn system, repository, and dependency evidence into deterministic artifacts, bounded findings, and reproducible review paths.

Building toward: monitoring, detection, and product-security engineering where defensive tools must be explainable, compatible with developer workflows, and reproducible by another engineer.

Current stable releases: LogLens v0.6.0, telemetry-lab v1.2, repo-sentinel-lite v0.8.1, scientific-computing-toolkit v1.1.0, and systems-foundations v0.3.0.

Selected Projects

repo-sentinel-lite

PyPI-published product-security guardrail with redacted output, baseline-backed scans, changed-file gates, and fail-closed configuration.

systems-foundations

Four Linux evidence mini-labs, including a versioned bridge from process and socket diffs to telemetry-lab-compatible JSONL.

sec-writeups-public

A public-safe pattern library: 8 stable security patterns extracted from 10 source notes, with maturity and provenance enforced in CI.

Reusable Security Patterns

Parser uncertainty

Keep unsupported input visible instead of treating parser gaps as negative evidence.

Multi-user probing

Distinguish username spread from ordinary repeated failure by one account.

Alert deduplication

Collapse duplicate alerts while preserving representative evidence and escalation signals.

Bounded correlation

Require a reproducible join key, event sequence, and time window before claiming a chain.

SBOM policy warning

Explain why a dependency diff warned without inventing a package-safety verdict.

Writing

LogLens / Parser Uncertainty as Evidence

Why unsupported input must remain visible instead of silently becoming negative evidence.

telemetry-lab / Evidence Pipeline Contract

How reviewer-facing events, findings, summaries, reports, and audit traces stay schema-validated.

sec-writeups-public / SBOM Policy Warning

How to explain a dependency policy warning without inventing a package-safety verdict.

Contact