Security budgets tend to go toward the dramatic scenarios, because those are the ones that get written about. The incidents that actually happen to mid-sized engineering teams are far duller: a former contractor whose access was never revoked, a library three major versions behind, a storage bucket that was opened up for a one-off migration and left that way.
Know what is running, and who can reach it
You cannot secure what you have not enumerated. Before buying tooling, produce two lists: every system that holds or processes data, and every account, key or token that can reach one. Most teams find the second list is longer than they expected and contains names of people who left.
Reviewing that list on a schedule catches more real risk than any scanner, because it addresses the failure mode that actually recurs.
- Accounts belonging to people who have left, or to projects that ended
- Long-lived API keys with no expiry and no owner
- Service accounts with broader permissions than the service needs
- Anything reachable from the public internet that does not need to be
Patch on a cadence, not on a panic
Dependency updates are unglamorous and easy to defer, which is precisely why they accumulate. A team that updates continuously applies small, boring changes. A team that defers ends up doing a major version jump under time pressure during an incident, which is when mistakes happen.
Put updates on the schedule like any other work. The goal is not to be on the newest version of everything - it is to never be so far behind that catching up is itself a risky project.
Make the secure path the easy path
If getting a secret the right way takes twenty minutes and pasting it into a config file takes twenty seconds, the config file wins. That is not a discipline problem, it is a design problem. Secret management, short-lived credentials and scoped access have to be quicker to use than the shortcut, or they will be routed around.
Rehearse the response
Decide in advance who is called, who can revoke access, who talks to customers, and where the evidence is collected. Writing that down during the incident costs hours you do not have. Practise it once a quarter against a scenario nobody has seen in advance.
None of this is sophisticated. It is a list of things that are individually easy and collectively neglected, and it prevents far more incidents than the tooling that gets more attention.