Read a security forecast as an opinion with a track record, not a measurement. Good ones state what would change their mind, separate trends already in data from guesses, and can be checked later. Most predictions fail that test, so treat them as prompts for your own planning.
What a forecast is
A forecast combines observed trends with judgement about what happens next. The observed part can be checked. The judgement part cannot, until time passes. When both are blended in one confident sentence, readers cannot tell which they are reading.
Five tests for a prediction
- Is it specific? "Attacks will increase" cannot be wrong. "Exploitation of a certain class of flaw will appear in the known exploited list more often" can be checked.
- Is there a time frame? Without one, any outcome counts as a hit.
- Is the basis stated? Look for a named dataset, a method, or at least a stated reason.
- Does the author say what they got wrong last time? Few do. Those who do are worth more attention.
- Does the prediction conveniently sell something? That does not make it false, but it should lower your trust.
Use real forecasting tools correctly
Some forecasts are quantitative, and they come with instructions. FIRST describes EPSS as a model estimating the chance that a published CVE will be exploited in the next 30 days, and it warns that scores are not severity, not a complete risk score, and not a record of past exploitation. Confirmed exploitation is what CISA's Known Exploited Vulnerabilities catalog is for. A forecast and an observation answer different questions.
How to use a prediction anyway
- Extract the assumption. If the claim is that a technique will spread, ask what you would do differently if it did, and whether that action is cheap now.
- Check whether you already cover it. Predictions are useful as a gap list.
- Do not rebuild a roadmap around one source. Compare two or three that disagree.
How to write your own
If you publish a forecast, put the method in the first paragraph, give each claim a time frame and a check date, and keep a public list of past calls. Do not invent figures to make a point sound firm.
A note on dates
Forecasts age quickly. Note the publication date when you cite one, and treat anything older than a year as history.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Are vendor predictions worthless?
No. They often rest on telemetry only that vendor has. Read them for the data they reveal and discount the product conclusions.
What is the most useful way to use a forecast?
Turn each claim into a question about your own controls, then fix the cheap gaps first.
Sources
Last reviewed: 19 October 2026.
