A credential was committed to a public repository and removed nine minutes later. Nobody used it. You rotated it, and that was the end of it.
No incident was declared, no postmortem was written, and nothing changed. In six months it will happen again, and the only reason it did not become a breach the first time is that nine minutes was short enough.
Near misses are the cheapest information a security programme can get, and almost nobody collects them. This post is why, and how to run the practice without it becoming a punishment. For whoever would have to write the report.
What counts as a near miss
Something that could have caused harm and did not, for a reason that was not a control you designed.
- A secret committed and removed before anyone found it.
- A production database deleted, restored from a backup that happened to be recent.
- A permissive access grant that existed for two weeks and was not used.
- A malicious package installed on one developer machine, caught because it was noisy.
- A phishing link clicked, with credentials not entered because the page looked wrong.
- An
rm -rfin the wrong directory, on a machine that happened not to matter.
The common element: the outcome was decided by luck, timing, or an unrelated accident, not by anything you built. That is exactly what makes it informative. A control that worked tells you something works. A near miss tells you where you have no control at all, at zero cost.
Why nobody writes them up
There is no trigger. Incident processes start when something breaks. Nothing broke.
Admitting one feels like confessing. The person best placed to report it is the person who nearly caused it, and the incentive points at silence, especially in a company where incidents get discussed in front of executives.
It looks like wasted effort. Writing a report about something that did not happen is a hard sell against shipping.
The relief is the end of it. The emotional arc completes when the credential is rotated. Nobody feels the pull to analyse a story that already resolved.
Make it cheap and safe
Both, or it will not happen.
Cheap: five fields, five minutes, in whatever tool people already use.
What nearly happened:
What actually stopped it: <- the important one
Would that stop it next time? <- yes / no / only sometimes
What would have made it impossible:
Who noticed, and how:
The second and third fields do the work. If what stopped it was a person noticing quickly, then it will not reliably stop it next time, and you have found a gap. If what stopped it was a control firing, that is not a near miss, that is your system working.
Safe: the report names systems, not people. No blame language, no performance consequence, ever, and that has to be visibly true rather than stated in a policy. The first time somebody is criticised for filing one, the practice ends permanently and quietly.
The fastest way to establish it is for a senior engineer to file the first few about their own mistakes, publicly. That does more than any amount of stated intent.
What to do with them
Review them in a batch, monthly, and look for the pattern rather than the instance.
Three near misses involving secrets in commits is not three careless engineers. It is a missing pre-commit hook, and it is one afternoon of work to close all three and every future one.
The specific question to ask of each: what would have made this impossible, rather than unlikely? Training makes things less likely. A hook, a default, a constraint, a permission that does not exist makes them impossible. Prefer the second, every time, because the first decays and the second does not.
Also track whether they are found late. A near miss discovered a month afterwards, by accident, is telling you about detection as much as about the original risk.
The numbers worth knowing
Volume, rising. Counterintuitive and important: more reports is good, because the underlying rate is fixed and what changes is how many you hear about. A team reporting zero is not safe, it is quiet. Treat a rising count as the practice working, and say so out loud, or people will read it as things getting worse.
How they were caught. If most are caught by a person happening to notice, your detection is luck. If most are caught by tooling, the tooling is working and the gap is prevention.
Repeats. The same near miss twice means the first report produced nothing, which is a failure of the review rather than of the reporter.
The connection to real incidents
Near misses and incidents are the same events with different endings. The chain that produces a breach has several links, and a near miss is that chain with one link happening to hold.
Which means the analysis is more useful, not less: you get the full causal story without the cost, the customer impact, the disclosure, or the pressure to conclude quickly. It is the only kind of incident analysis you can do calmly.
The concession
There is a real risk of over-collection. A team that reports every minor surprise generates a queue nobody reviews, and an unreviewed queue is worse than no queue because it creates the impression of a practice.
So bound it: a near miss is something where the potential outcome was serious, meaning customer data, production availability, or credential compromise. A typo caught in review is not one. And if you cannot commit to reviewing them monthly, do not ask for them, because soliciting reports and ignoring them teaches people that reporting is pointless, which is harder to undo than never having started.
The implication
Your incident history is a biased sample. It contains only the events where luck ran out, which is a small and unrepresentative fraction of the times your defences were actually tested.
The near misses are the rest of the sample, and they are free. All that stands between you and them is a five-field form and a credible promise that filing one is safe.
