Security by design belongs in the backlog

Security is work

Most teams do not ignore security because they dislike it. They ignore it because, structurally, it does not exist in their world. There is no ticket for it, no owner, no definition of done. It lives in a policy document nobody opens and a pre-release checklist everyone resents.

Meanwhile the actual work of security — authorization tests, secret rotation, dependency hygiene, audit trails, rate limits — is ordinary engineering work. It has scope, it has acceptance criteria, it can be estimated, reviewed, and shipped. The moment you accept that framing, security stops being a compliance ritual and becomes something a delivery team can genuinely own.

Why the late checklist fails

The common approach is a security review gate at the end: a penetration test before launch, a checklist before a major release, an annual audit. I have sat on both sides of these reviews, and the pattern is consistent — they find real problems at the moment when fixing them is most expensive.

• The architecture is frozen. A missing tenant boundary discovered a week before launch is not a bug fix; it is a redesign nobody has time for. So it ships with a compensating control and a promise.
• The knowledge does not transfer. An external report lands as a PDF of findings. The team patches the specific instances and learns nothing structural, so next quarter's code repeats the same class of flaw.
• The incentive is to pass, not to improve. When security is a gate, the rational move is to satisfy the gate with minimum change. When it is backlog work, the rational move is to actually reduce risk, because that closes the ticket.

None of this argues against pen tests or audits — they are valuable verification. It argues against using them as the primary mechanism, because verification cannot compensate for absent design work.

Threat modeling that actually ships

Threat modeling has a reputation for being heavyweight: workshops, STRIDE matrices, diagrams that take longer than the feature. What I actually do in production teams is much smaller, and it survives because it is small. For every design that touches money, identity, personal data, or a trust boundary, we answer four questions in writing:

1. What are we building, in one paragraph and one diagram?
2. What can go wrong here? (Ten minutes of honest brainstorming beats an empty matrix.)
3. What are we doing about the things that can go wrong?
4. Did we write the answers down where the ticket lives?

The output is a threat-model note attached to the design or the epic — half a page, not a document. Its real value is not completeness; it is that risks now have names, and named risks can become tickets.

Turn risks into backlog items

A useful security backlog maps concrete risks to concrete engineering work. Not "improve security" — that is a wish, not a ticket. The mapping I use ties every risk to a control, a signal, and a review mechanism:

risk: cross-tenant data access
control: tenant-scoped queries + authorization tests on every read path
signal: audit event for privileged reads, alert on cross-tenant query shape
review: PR checklist item + threat model note linked in the epic

risk: leaked service credentials
control: secrets in a managed vault, no secrets in env files or CI logs
signal: secret-scanning in CI, vault access audit log
review: rotation runbook tested quarterly

risk: dependency with known CVE reaching production
control: lockfile + automated dependency scanning blocking on critical
signal: scanner report in every pipeline run
review: weekly triage of non-blocking findings

Written this way, security work is estimable and prioritizable next to feature work — which is exactly the point. A product owner can weigh "audit events for privileged actions" against a feature because both are now legible units of work with visible value.

A security definition of done

The backlog handles known risks. The definition of done handles the default posture — the checks that apply to normal work without anyone having to remember them. It must be short enough to fit real delivery; a twenty-item list will be ignored by week three.

• Authorization path covered by tests — including the negative case, not just the happy path.
• New secrets documented, stored in the vault, and rotatable without a deploy.
• Audit event emitted for every privileged or destructive action.
• Input at trust boundaries validated and size-limited.
• Operational dashboard or alert updated when the change introduces a risky flow.

Five items. Everything else graduates into the backlog as explicit work. In my experience the short list gets applied consistently, and consistency beats coverage — a modest control applied always outperforms a thorough control applied sometimes.

Controls that live in the pipeline

Anything that can be checked mechanically should be checked mechanically, because pipeline controls are the only ones that do not decay when the team is busy. The baseline I set up on new platforms:

• Secret scanning on every push — cheap, high signal, catches the most embarrassing incident class before it exists.
• Dependency scanning with a blocking threshold for critical vulnerabilities and a triage rhythm for the rest. A scanner without triage just generates noise people learn to dismiss.
• Static analysis tuned to the rules the team actually cares about. Fifty warnings nobody reads are worse than five that block the merge.
• Infrastructure as code review — security groups, IAM bindings, and public-bucket checks reviewed like application code, because they are application code.

The trade-off here is friction versus decay. Every blocking check adds friction; every advisory check decays into wallpaper. I bias toward few, blocking, and well-tuned — then expand slowly as the team's tolerance grows.

Production considerations

• Audit events need a reader. Emitting them is half the work; the other half is a place where someone can actually query "who accessed this record in March". Design the query path when you design the event.
• Rotation that was never rehearsed does not exist. A secret is rotatable when rotation has been performed, timed, and documented — not when the architecture theoretically allows it.
• Rate limits are a product decision. Set them with product, publish them in the API docs, and alert before users hit them — or the first sign of your protection working will be a support escalation.
• Incidents feed the backlog. Every security-relevant incident should end with at least one backlog item that removes the class of failure, not just the instance. That loop is what makes the whole system self-improving.

Summary

• Security fails structurally, not morally — give it owners, tickets, and acceptance criteria.
• Late gates find problems at the most expensive moment; design-time work prevents the class, not the instance.
• Threat model in four questions, half a page, attached to the epic.
• Map every risk to a control, a signal, and a review mechanism — that shape makes it estimable.
• Keep the security definition of done at five items; consistency beats coverage.
• Push mechanical checks into the pipeline: few, blocking, well-tuned.