Bare Metal Security Defaults Audit

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.

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):

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

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.