loading

Prismetic

Security by design

Security work is often treated as a gate at the end. That is expensive and brittle. We fold security into the same rituals as design and architecture so teams ship quickly without painting themselves into a corner.

Threat modelling in small loops

We run lightweight STRIDE-style sessions per feature area, not monolithic audits. The output is a short list of mitigations tied to tickets — encryption boundaries, authZ checks, logging — owned by the same squad shipping the code.

  • One session per bounded feature slice, with notes that live next to the spec.
  • Mitigations written as acceptance criteria, not vague “harden later” tasks.
  • Revisit when the data model or trust boundaries change.

The goal is not a thick report — it is fewer surprises on launch day.

— security working as a design partner, not a speed bump
Supply chain and secrets hygiene

Modern apps are mostly dependencies. We standardise lockfiles, scanning in CI, and secret handling so “one bad merge” does not become “one bad headline”. Rotation and least-privilege are boring — and that is the point.

  • Pin and scan; treat upgrades as planned events.
  • Secrets out of repos, with rotation paths someone owns.
  • Least privilege per environment — dev is not production’s twin.
Observability as a security control

You cannot respond to what you cannot see. We align audit logs, anomaly detection, and incident runbooks with product metrics so security and reliability share the same signals.

Logs nobody reads are decoration. Alerts nobody trusts get muted — then you are blind again.

  • High-signal events: auth, admin actions, data exports.
  • Runbooks linked from dashboards, not buried in a wiki.
  • Game days that include security scenarios, not only uptime.