Security reviews happen the week before launch. Findings are usually rejected as too late to fix. How do you change this?

What the interviewer is testing

Whether you understand the economics of review timing, and whether you can propose a process change that engineering will accept.

The economics

A trust boundary in the wrong place is a design decision; changing it means changing the system. A missing header is a bug. Reviews the week before launch can only catch the second kind, so the programme is finding the cheap issues and missing the expensive ones — and then being blamed for raising them late.

The changes

Move the review to design time, when the architecture is formed but not committed. Trigger it on the design document rather than on the launch date.

Tier by risk so the review capacity goes where it matters. Most changes need no review; a defined set of triggers — new external exposure, new personal data category, new authentication mechanism, a new trust boundary, a change to an existing security control — routes to a review. Everything else proceeds with automated checks only.

Automate the rule-shaped findings so reviewers never spend time on them: TLS configuration, headers, dependency vulnerabilities, secret scanning, network exposure, encryption settings. That frees the review for what only a human can assess.

Make it collaborative rather than a gate. A reviewer engaging with the actual threat model, early, is help; a reviewer arriving an hour before sign-off with a standard checklist produces generic findings and resentment.

Severity-classify findings so a design flaw is distinguishable from a hardening suggestion, and so "fix before launch" versus "fix in the next quarter" is a defensible distinction rather than an argument.

What a strong answer adds

Embedding security expertise in teams rather than centralising it — a security champion per team, trained and supported by the central function, who raises the questions during design. That scales far better than a central review queue and changes the timing naturally.

And measuring the programme on findings raised at design stage versus at launch, which makes the shift visible.

Common weak answers

Adding reviewers to the queue. Escalating rejected findings, which makes the relationship adversarial.