I’m working on a security tool born out of frustration with how most security controls work today.
In many environments, security happens after the fact: scan later, alert louder, hope someone reacts in time.
Most tools also assume network access, dynamic updates, and trust in external services — which breaks down in regulated, air-gapped, or high-assurance environments.
I decided to explore a different approach.
Sentinel Gate
Sentinel Gate is a deterministic security gate that runs before code leaves the developer machine or CI boundary.
Key design choices:
Offline by design
No call-home, no cloud dependency, no remote APIs. Can run fully air-gapped.
Deterministic outcomes
The gate does not score or recommend. Artifacts either pass or are blocked.
Immutable ruleset
No dynamic rule updates, no remote plugins. The ruleset is versioned and explicitly managed to avoid supply-chain surprises.
Pre-commit and CI enforcement
Focused on preventing secrets leakage, CI/CD injection risks, and certain classes of logic/configuration flaws before they propagate.
The goal is simple:
answer with certainty whether an artifact is allowed to exist outside a defined boundary.
This is intentionally a hard control, not a flexible scanner.
Auditor Core (related but separate)
Alongside the gate, I’m building Auditor Core, which serves a different purpose.
Auditor Core focuses on understanding and explaining systems, not blocking them:
Repository and infrastructure topology mapping
Baseline drift detection
Analysis across IaC, CI/CD pipelines, containers, Kubernetes, and cloud configs
Evidence-driven reports aimed at engineers and auditors
I keep these as two separate engines on purpose:
Gates prevent mistakes
Audits explain reality
Trying to merge both usually compromises one of them.
Trade-offs & limitations
This approach is not for everyone:
Deterministic rules mean less flexibility
Offline mode means no shared intelligence feeds
It will block things — sometimes inconveniently — by design
It’s not a replacement for dynamic testing or runtime protection
The target audience is environments where predictability and control matter more than coverage breadth.
Code note:
The implementation is private at the moment. I’m intentionally validating the
architecture, threat model, and assumptions before deciding what to open.
Happy to discuss internals and trade-offs in the comments.
This is still evolving, and I’m actively validating assumptions.
I’d especially appreciate feedback from people working in:
regulated or air-gapped environments
CI/CD security
supply-chain security
or anyone who has strong opinions about deterministic vs adaptive controls
Happy to answer technical questions and criticism.
0 コメント
—
Show HN: Offline Deterministic Security Gate · HackerTrans
I’m working on a security tool born out of frustration with how most security controls work today.
In many environments, security happens after the fact: scan later, alert louder, hope someone reacts in time. Most tools also assume network access, dynamic updates, and trust in external services — which breaks down in regulated, air-gapped, or high-assurance environments.
I decided to explore a different approach.
Sentinel Gate
Sentinel Gate is a deterministic security gate that runs before code leaves the developer machine or CI boundary.
Key design choices:
Offline by design No call-home, no cloud dependency, no remote APIs. Can run fully air-gapped.
Deterministic outcomes The gate does not score or recommend. Artifacts either pass or are blocked.
Immutable ruleset No dynamic rule updates, no remote plugins. The ruleset is versioned and explicitly managed to avoid supply-chain surprises.
Pre-commit and CI enforcement Focused on preventing secrets leakage, CI/CD injection risks, and certain classes of logic/configuration flaws before they propagate.
The goal is simple: answer with certainty whether an artifact is allowed to exist outside a defined boundary.
This is intentionally a hard control, not a flexible scanner.
Auditor Core (related but separate)
Alongside the gate, I’m building Auditor Core, which serves a different purpose.
Auditor Core focuses on understanding and explaining systems, not blocking them:
Repository and infrastructure topology mapping
Baseline drift detection
Analysis across IaC, CI/CD pipelines, containers, Kubernetes, and cloud configs
Evidence-driven reports aimed at engineers and auditors
I keep these as two separate engines on purpose:
Gates prevent mistakes
Audits explain reality
Trying to merge both usually compromises one of them.
Trade-offs & limitations
This approach is not for everyone:
Deterministic rules mean less flexibility
Offline mode means no shared intelligence feeds
It will block things — sometimes inconveniently — by design
It’s not a replacement for dynamic testing or runtime protection
The target audience is environments where predictability and control matter more than coverage breadth.
Code note: The implementation is private at the moment. I’m intentionally validating the architecture, threat model, and assumptions before deciding what to open. Happy to discuss internals and trade-offs in the comments.
This is still evolving, and I’m actively validating assumptions.
I’d especially appreciate feedback from people working in:
regulated or air-gapped environments
CI/CD security
supply-chain security
or anyone who has strong opinions about deterministic vs adaptive controls
Happy to answer technical questions and criticism.