Several beliefs hold small teams back: that attackers ignore small targets, that a high score always means urgent, that dev dependencies never matter, or that a clean scan means safe. Each is partly wrong. The facts below come from public guidance and suggest cheaper, calmer habits.
Myth versus fact
| Myth | Fact |
|---|---|
| We are too small to be a target | Flaws are exploited whatever the size of the owner. Check the exploited list for what you run |
| Highest score first | FIRST says the Base score should not be used alone to assess risk. Add exploitation and exposure |
| We need a security team first | You need named roles and a weekly slot. A rota of three people can cover it |
| Dev dependencies do not matter | Many are low impact, but build tools run with your tokens. Judge each case |
| A clean scan means safe | A scan reports known advisories. It does not find unknown flaws or logic bugs |
| EPSS times CVSS gives risk | The EPSS FAQ says multiplying them is never a good idea |
| Rewrite git history after a leak | GitHub says rotating the secret is the first step and history rewriting may not be warranted |
Myth: "We are too small"
The CISA exploited list exists because real attackers use known flaws in the wild, and it lists them by product, not by victim size. If you run an affected product, you are in scope. Small teams often have less monitoring, which makes the effect worse, not better.
Myth: "Highest score first"
Score tells you about the flaw's intrinsic qualities. It does not know your environment. FIRST's user guide says Base scores should be supplemented with environmental and threat analysis. The practical ranking is exploited and exposed first.
Myth: "A clean scan means safe"
A scanner matches your dependencies to published advisories. A new flaw, a malicious package that has not been reported, a misconfiguration and a leaked key all pass through a clean scan. Treat the result as one signal in your routine.
Myth: "Fix everything"
You cannot, and you do not need to. Defer with reasons, review on a date and spend your hours on the items that can hurt you. A short honest register is better than a long one nobody updates.
What to do with this
Pick one myth you believed this week and change one habit. For most teams that is adding the exploited-list check to the weekly routine.
Quick check
Is a small team less at risk than a big one?
Not in any way I could source. Risk depends on what you run, how exposed it is and how fast you react.
What is a good first habit?
A fixed weekly slot to read new alerts and check the exploited list. It is the habit that makes others possible.
Safeguard policies and the free scan at gold.safeguard.sh/scan can support that routine.
Sources
- FIRST CVSS v4.0 user guide
- FIRST EPSS FAQ
- CISA Known Exploited Vulnerabilities Catalog
- GitHub Docs, removing sensitive data from a repository
Last reviewed: 19 October 2026.
