# Security checklist — <Project>

```
Status: Current
Owner: <who maintains this>
Last reviewed: <YYYY-MM-DD>
Governs: the checks run before a release, and what each one proves
Review trigger: A new class of input, a new external service, or a finding that got past this list
```

## Why this is separate from SECURITY.md

`SECURITY.md` is the threat model: what is being protected and from whom. It is
read carefully once and revisited rarely.

This is the list somebody actually works through. Keeping them apart means the
model can stay stable while the checks change, and it means a release checklist
is short enough to finish rather than a document to skim.

## Before a release

<Each entry states what it proves, not just what to do. A check whose purpose is
unstated gets skipped the first time it is inconvenient.>

- [ ] <Check> — proves <what>
- [ ] <Check> — proves <what>

## Standing checks

- [ ] No secret in the repository, in a log line, or in an error message
- [ ] Every externally reachable endpoint is either authenticated or deliberately public, and the deliberate ones are listed
- [ ] Every input that reaches a query or a filesystem path is validated at the boundary
- [ ] Dependencies audited, and any accepted advisory recorded with a reason

## What got past this list

<Add an entry whenever a real finding was not caught here, and then add the check
that would have caught it. A checklist that never grows is one nobody is honest
with.>

| When | What was missed | The check now added |
| --- | --- | --- |
| <> | <> | <> |