---
name: bare-metal-security-defaults-audit
description: Use this skill when the user wants to audit or design their application's security posture using Bare Metal Software's "four attackers" model and crown-jewels framework, including mapping defaults to a regulated buyer's security questionnaire. Triggers on requests like "run a security audit using the four attackers model," "what are our crown jewels," "help us answer this security questionnaire," "check our defenses against prompt injection," "are we ready for an enterprise security review," or "map our security defaults to HIPAA."
---

# Bare Metal Security Defaults Audit
This skill is Labor as Code™ for "Four Kinds of Attackers Matter, and the Defaults Answer Each One" and "Answering the Regulated Buyer" in *Bare
Metal Software*'s "Run It for Years" chapter. Read those sections for
the reasoning; this skill only executes the audit and drafts the
mapping. It does not decide what this project's crown jewels actually
are, whether the project handles regulated data, or whether a gap it
finds is acceptable to ship with — those are the user's calls.

## Before running

Confirm before starting. The book's own answers to these three
questions describe *its own* reference architecture (one Rust program
in one container, SQLite on a volume, TLS and request limits inside the program) — do not silently assume the user's project matches
that architecture:

1. **What this project's crown jewels actually are.** The book names
   five for its own architecture: the customer database files, the
   files folder, the secrets file, the signing key for binaries and
   licenses, and the domain registrar account. The user's project may
   have different or additional ones (a source-of-truth database, an
   encryption key, an admin credential, a training dataset). Ask; do
   not reuse the book's list unexamined.
2. **What the user's actual stack is**, at least at the level of: what
   sits at the internet-facing front door, where secrets live, what
   the session mechanism is, and whether there's an audit trail today.
   The checklist below is organized around the book's own defaults;
   for each item, ask whether the project's actual architecture has an
   equivalent control, rather than assuming it does or grading the
   project against a stack it doesn't run.
3. **Does the project handle regulated data** (health information,
   payment data, other regulated PII), and under which specific
   regulation? Only run the "Answering the Regulated Buyer" section
   if the user confirms this and names the regulation — do not invent
   a compliance framework the user didn't ask about.
4. **Does the runtime include a model reading untrusted input** (a
   document, an email, a spreadsheet, user-supplied text) at
   production time? This determines whether the fourth attacker
   category below applies at all.

## The four attackers and the crown jewels

State the crown jewels list first (from "Before running this," item
1) — everything below exists to protect that specific list, so name it
before auditing defenses against it.

Then work through each attacker category. For each, the question is
the same: does the project's actual architecture have an equivalent
control, and if not, is that a gap or a deliberately accepted risk?

### 1. Scanners — criminals who scan the internet for any open service or known bug, indiscriminately

Check for:

- Only one thing on the machine listens to the internet. In the book's
  default that is the program itself, terminating TLS with a mature
  library (rustls) and enforcing rate limits, size limits, and timeouts
  in middleware; a separate reverse proxy is equally acceptable. The
  container publishes no port beyond 80 and 443, since published ports
  can go around the host firewall.
- A firewall allowing only the ports actually needed (the book's own
  default: three — SSH, HTTP, HTTPS).
- SSH accepts keys only, never passwords.
- The operating system installs security updates automatically.
- The application process runs as a service account that can write
  only to its own data directory, not system-wide.
- Disks are encrypted at the OS level (full-disk encryption), so a
  stolen or discarded drive holds nothing readable — this replaces an
  in-application encrypted-database library, not on top of it.

### 2. The targeted attacker — someone going after this project specifically, because of the data it holds

Check for:

- CSRF protection: every form submission carries a token proving it
  came from the application's own page.
- A content security policy naming the only places scripts may load
  from.
- Sessions are revocable server-side (rows in a database an admin can
  delete), not just a signed cookie with no server-side record.
- Uploaded files are validated by their actual content (first bytes),
  not by their claimed file extension.
- Secrets live in exactly one place readable only by the service
  account, never in source code and never in the application database,
  and each secret has a stated rotation schedule.

### 3. Insiders and former insiders with a credential that still works

Check for:

- An append-only audit trail: who did what, when, before and after
  values, written in the same transaction as the change itself.
- Role-based access actually enforced through one shared permission
  check, not scattered ad hoc checks.
- The harness that writes code never holds production credentials —
  production runs only images the build process produced, never a
  direct deploy from a developer's or an agent's own machine. Any
  harness session that operates production does it only through named
  ops scripts that a restricted deploy account runs (its SSH key
  limited to one wrapper), never reads the secrets file, and waits for
  a person's approval before every change to production.
- Offboarding a person (employee or contractor) revokes their
  credentials and rotates any secret they could have seen, the same
  day, not on a delayed schedule.

### 4. Prompt injection — anyone who can put text in front of software that reads it with a model (only if "Before running this" item 4 confirmed this applies)

If this doesn't apply, say so and skip this section rather than
auditing for it anyway.

If it does apply, the book's defense is structural, not a filter to
tune, so check for the structural properties directly:

- The runtime model **never has write access** to anything — it
  cannot change a record, send a message, or call another system
  directly. This is the single load-bearing control; if the model
  (or the code path around it) has any write capability, flag this as
  the top-priority finding regardless of what else the audit finds.
- Every model response is validated against a defined schema before
  anything else acts on it; anything that doesn't fit is rejected and
  queued for a person, not silently coerced into shape.
- Model output is checked against the project's actual business rules
  before another part of the program acts on it — the same rules a
  constitutional/protected test suite would protect.
- Every prompt and response is written to the audit table, so any
  downstream action can be traced back to what the model actually saw.

## Answering the regulated buyer (only if confirmed applicable)

Only produce this if the user confirmed regulated data and named the
regulation in "Before running this." Do not default to HIPAA just
because it's the book's own example — build the mapping around the
regulation the user actually named, using this shape (the book's own
HIPAA Security Rule technical-safeguards table as the pattern):

| Safeguard | What the rule asks for | What this project's actual defaults provide |
| --- | --- | --- |
| Access control | | |
| Audit controls | | |
| Integrity | | |
| Authentication | | |
| Transmission security | | |

For HIPAA specifically, the book's own reference mapping (adapt if the
project's actual controls differ from these):

| Safeguard | What the rule asks for | What the Bare Metal defaults provide |
| --- | --- | --- |
| Access control | Unique user identification, emergency access, automatic logoff, encryption | Per-person sign-in, role-based access, session expiry, full-disk encryption, TLS |
| Audit controls | Record and examine activity in systems holding protected data | Append-only audit table written in the same transaction as every change; exportable |
| Integrity | Protect data from improper alteration or destruction | Content-hashed files, before/after audit values, forward-only migrations, a rehearsed restore drill |
| Person/entity authentication | Verify that a person seeking access is who they claim | Passkeys, or a standard identity-federation protocol to the customer's own identity provider |
| Transmission security | Guard against unauthorized access to data in transit | TLS everywhere; signed webhooks; an appropriate secure channel for the data type |

Also draft the vendor list the buyer will ask for: every vendor that
touches the regulated data and therefore needs a signed data-protection
or business-associate agreement — the hosting provider, the backup
storage provider, the email provider (if any message carries regulated
data), and the model vendor (if the runtime model reads it). Confirm
this list against the project's actual vendors; don't assume the
book's own short list applies unchanged.

## Output

Present findings grouped by attacker category (plus the regulated-buyer
mapping if applicable), each finding stated as: which attacker it
defends against, what the book's default control is, whether the
project's actual architecture has an equivalent, and — if not — whether
that's a gap to close or a risk the user is knowingly accepting. A
finding with no named attacker is not a finding this skill should
produce; see the check below.

## The check that catches this chapter's own failure mode

Before presenting the audit, reread it against the book's own opening
line: "A security section that only says 'do not write your own
cryptography' has not said who it is defending against." Every finding
must be tied to one of the four named attackers — not generic
"best practice" or "industry standard" language with no attacker
attached. If the audit surfaces a finding you can't tie to scanners,
the targeted attacker, an insider, or prompt injection, either connect
it explicitly or drop it; this skill is auditing against this book's
specific threat model, not producing a generic security checklist.
Separately, if the project has a runtime model reading untrusted input
and this audit did not explicitly confirm the model has no write
access, treat that as an incomplete audit, not a minor omission — it
is the one control the book treats as load-bearing for that entire
attacker category.