Security Theater, Now Playing: When Security Is a Sideshow Instead of a Strategy

Mia Kralowetz, who moved into full-time security about five years ago after contract penetration testing and a finance background, describes a pattern common at startups: security gets built in only after a company reaches product-market fit. She recounts a payments-app pivot where her team brought leadership a stack of lengthy risk assessments and threat models. Executives wanted a short summary, the report went largely unread, the feature launched anyway, and security lost its seat in important meetings and some of its budget.

The middle of the talk covers how her team rebuilt trust. They moved from being a department of no to a department of how, joined roadmap discussions early, and timed their feedback so it landed before designs were locked. For less mature engineering teams they published sample repositories and reference architecture, and they used a risk-based multiplier in prioritization so security appeared in product planning. They framed risk in business terms that executives could weigh, and they routed checks through CI/CD so developers saw findings in the tools they already used.

She closes with questions security staff can ask about any new feature: what it does, what it should do, what value it adds, how long the review can take, how attackers could abuse it, and what could go wrong. The practical takeaway is to learn the product well, earn trust rather than assume it, and act as a thought partner. In the Q&A she added that business-defined thresholds make labels like high and medium meaningful.