Zero Trust Pillars

Zero Trust Pillars

Zero Trust in software engineering means: never assume correctness — verify everything, automatically, before it reaches production.

GherkinForge implements four Zero Trust pillars.

---

Pillar 1 — Zero Trust for the AI Agent

Threat: The AI imports database/sql or net/http directly into the domain aggregate, destroying hexagonal boundaries.

Mitigation: depguard linter configuration enforces domain isolation at the compiler level. If the AI hallucinates a forbidden import, CI fails the build — the .mdc prompt alone is not trusted.

# .golangci.yml (opt-in strict mode)
linters-settings:
  depguard:
    rules:
      domain-isolation:
        files: ["pkg/context/*/domain/**/*.go"]
        deny:
          - pkg: "database/sql"
            desc: "ZERO TRUST: Domain layer — use ports/interfaces."
          - pkg: "net/http"
            desc: "ZERO TRUST: Domain layer — use adapters."
          - pkg: "github.com/gin-gonic/gin"
            desc: "ZERO TRUST: No web frameworks in the domain."

Enable: make lint-go

---

Pillar 2 — Zero Trust for the Human (Product Owner / Developer)

Threat: A product owner writes Given I click the blue submit button in a @business feature file. The AI reads this and generates a brittle, UI-coupled backend test.

Mitigation: gforge lint parses the Gherkin AST. If it detects UI/DOM vocabulary in a @business step, it rejects the file before the AI is allowed to read it.

gforge lint features/
# ZERO TRUST VIOLATION: UI-specific term "click" found in @business tier step

28-term ban list includes: click, button, dropdown, xpath, css selector, browser, dom, modal, scroll, hover, data-testid, and more.

Matching uses whole-word regex (\b) — "dom" does not trigger on "domain event".

---

Pillar 3 — Zero Trust for Application State

Threat: Integration test Scenario A creates an order. Scenario B counts all orders and fails because Scenario A's data is still in the database.

Mitigation: Every @integration godog scenario runs inside a SQL transaction unconditionally rolled back after completion — regardless of pass or fail.

sc.Before(func(ctx context.Context, sc *godog.Scenario) (context.Context, error) {
    tx, _ := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelSerializable})
    return context.WithValue(ctx, txKey{}, tx), nil
})

sc.After(func(ctx context.Context, sc *godog.Scenario, err error) (context.Context, error) {
    tx := ctx.Value(txKey{}).(*sql.Tx)
    tx.Rollback() // unconditional — Zero Trust in test cleanup
    return ctx, nil
})

The database is always assumed compromised between scenarios.

---

Pillar 4 — Zero Trust for Output Fidelity (Mutation Testing)

Threat: The AI generates code that passes all tests, but silently dropped a field or flipped a comparison. The Gherkin specification was too weak to catch it.

Mitigation: Mutation testing. A mutator introduces deliberate bugs (flips < to >, empties strings, removes assignments). If the godog suite still passes with the mutant, the specification was insufficient.

# Install
go install github.com/zimmski/go-mutesting/cmd/go-mutesting@latest

# Run against domain layer
make mutation
# Required score: >= 80%

Mutation-proof specification pattern:

# WEAK — a mutant can satisfy this accidentally
Then the order should be created

# STRONG — a mutant cannot accidentally produce exactly 17947
Then the total order value in pence should be 17947
And an "order.created" domain event is published to the broker
And the order ID should not be empty

Every mathematical invariant in GherkinForge's Golden Packet is verified by hand:

• 2999 × 2 = 5998 ✓
• 2999 × 3 + 8950 × 1 = 17947 ✓