Armory // Independent security lab

Every system, hardened, shielded, protected and secured.

Armory is a lab for hardening systems, building defenses and testing them until they hold. What goes in stays protected: the doctrine, the tooling and the work behind them.

Status: sealed Third-party requests: 0 Cookies set: 0 Transport: TLS only
0102030405060708090 SEALED
§01 / Doctrine

Six rules.
No exceptions.

Security is mostly the discipline of saying no. These are the combinations every build in the lab answers to, from a laptop to a production edge.

  1. Deny by default

    Nothing is allowed until it is needed and named: ports, permissions, scripts, origins, people. Everything else stays shut, and the list of exceptions is short enough to read.

  2. Least privilege, always

    Every account, token and service gets the smallest key that does the job, for the shortest time it needs it. Standing admin access is a finding, not a convenience.

  3. Defense in depth

    No single wall. Controls are layered so they fail independently, and one breach is a contained incident rather than the whole keep.

  4. Assume breach

    Plan for the day something gets in. Segment what matters, log what happens, and practise recovery before it is needed.

  5. Verify, don’t trust

    Identity, integrity, inputs and claims all get checked, including our own. A setting that has not been tested is an assumption.

  6. Shrink the attack surface

    Less code, fewer dependencies, fewer doors. What isn’t there can’t be exploited, so removing things is the cheapest fix there is.

§02 / Arsenal

Six boxes.
One vault.

The disciplines the lab keeps under lock: each one a layer, all of them aimed at systems that stay shut when someone leans on the door.

Box 01

Hardening

Baselines for operating systems, servers, browsers and cloud accounts. Every setting justified, every change tested rather than assumed.

  • baselines
  • configs
  • drift checks
Box 02

Threat modeling

Work out what is worth protecting, who would want it and how they would get in, before the first line of code.

  • assets
  • adversaries
  • attack paths
Box 03

Secure infrastructure

Edge-first hosting, strict headers, least-privilege access, and secrets kept out of code and out of logs.

  • edge
  • zero trust
  • secrets
Box 04

Detection

Logs that answer questions, alerts that mean something, and runbooks written before the bad day instead of during it.

  • telemetry
  • alerting
  • runbooks
Box 05

Cryptography & keys

Keys, certificates and vaults handled properly: scoped, rotated, backed up and recoverable.

  • tls
  • pki
  • rotation
Box 06

Adversarial testing

Attack our own builds with misconfiguration hunts, fuzzing and red-team drills. Whatever breaks gets fixed and written up.

  • fuzzing
  • red team
  • write-ups
§03 / Contact

Open a secure
channel.

Questions, collaboration, or a vulnerability to report. Messages are sealed in transit and delivered straight to the lab’s inbox.

  • Sent over TLS and forwarded by email. Nothing is stored on this site.
  • No mailing list. Your address is used to reply and for nothing else.
  • Reporting a security issue? Pick Disclosure and include steps to reproduce.
What’s it about?

How messages are handled: privacy note.