I don’t know what you had in mind for “large”, but I can tell you how it’s working out for us. - Most customers write design docs/tickets. This helps because w

I don’t know what you had in mind for “large”, but I can tell you how it’s working out for us. - Most customers write design docs/tickets. This helps because we can suggest alternative approaches early. It’s rare that we tell people that an idea is fundamentally flawed, but it’s common that we suggest a different implementation approach or additional safeguards. - We review individual PRs. Here, we're looking for concrete individual appsec concerns (or infrasec if it’s a Terraform PR for example). Not the right place to have overarching product design conversations. One concern is that there are just too many PRs for a fledgling security team to review every single one. For this we rely on 2 mechanisms: 1) IC opt-in (they tag us on GitHub via @CLIENT/security when they would like a set of eyes on something or if a PR is part of a product change we’ve been involved in) 2) Automated heuristics. These have a hair trigger: lots of false positives. It’s just stuff like “are you adding middleware?”, “are you adding an endpoint?”, et cetera. That’s OK, because we don’t make it a gating part of CI: its job is to turn 100 PRs for us to look at into 10 PRs for us to skim and make a decision if it’s the 1 PR that deserves extensive scrutiny. So, overall: stop thinking of yourself as a gatekeeper and start thinking of yourself as an advisor. Our job is to make sure you understand what you’re doing and what your alternatives are. Security is never the only requirement: you have a business to run.