Locking down Jira tickets isn’t enterprise sec, so that’s not what I’m referring to. This risks that happen that lead into bad exploits for startups and the co

Locking down Jira tickets isn’t enterprise sec, so that’s not what I’m referring to. This risks that happen that lead into bad exploits for startups and the controls available: - SaaS vendor is breached and doesn’t tell you for a week: okta allows you to cleanly kill perks for that SaaS, and impacted users - dev downloads a database access package on vscode, puts in prod creds, the package is calling home bc it’s surprise malware: EDR catches it - dev has prod passwords on their MacBook note sheets, or accessing prod from a home computer: process enforcement, password manager, secrets vault - customer service employee is phished, pivots into customer data: IR plans and email security tools - product m API is “move fast and break things” and full of vulns: except for the worst of them, get a WAF/cloud flare to cover and be careful about public endpoints beyond that. The above secures a product with limited bandwidth and a small security team, if you’re thinking defense in depth (which you should be). It’s important for sec engs to code, no doubt. Two things to note that I think you’re missing, putting aside issues if your sec team is doing Jira ticket focuses vs the above. - code vulns are paired with exploit paths. If a WAF is there, and the code doesn’t pivot into prod DBs and so on, these can wait to remediate. - Have you tried remediating code vulns or getting application logs for security, at a product-focused startup? Devs are the worst enemy here. Anything touching the code is “slowing the product” usually. Security is a political job and this is an easy way to burn all your social capital if you chase each of vuln. In short, you’re thinking about vulns, but not threat models. Startup sec program is all about smart thread modeling.