Vulnerability Management

Vulnerabilities are being found faster than ever, and exploited faster than ever. You can't win by predicting which bug will matter: tens of thousands of CVEs are published every year, most will never touch you, and the one that does will look like all the others until someone exploits it. You win by being able to patch anything, quickly, as a routine change, so that the question "how fast can we ship a fix?" always has the same boring answer.

Why Speed Is the Strategy

• Exploitation is faster. Mandiant measured the average time from disclosure to exploitation at 63 days in 2018 and 2019, 32 days in 2021 and 2022, and 5 days in 2023. Most exploited vulnerabilities that year were exploited as zero-days, before a patch existed.
• Discovery is accelerating. AI-assisted research and fuzzing now find real bugs: Google's Big Sleep agent found an exploitable memory-safety bug in SQLite before it reached a release. The same tools are available to attackers, so assume the gap between "bug exists" and "bug is exploited" keeps shrinking.

Put those together and the math is simple. If exploitation follows disclosure within days, a process that takes a month to ship a patch is a process that's exposed for most of every month. The only lever you fully control is your own time to remediate.

Prioritize by Risk, Not Score

Severity alone sorts badly. CVSS measures how bad a vulnerability would be if exploited, not how likely that is, and most "critical" CVEs are never exploited at all. A team that treats every critical as an emergency burns out on false alarms and starts ignoring the queue, which is worse than any single unpatched bug. Combine three signals instead:

Signal	Answers	Source
CVSS	How bad if exploited?	FIRST CVSS v4.0
EPSS	How likely to be exploited in the next 30 days?	FIRST EPSS
KEV	Is it being exploited right now?	CISA Known Exploited Vulnerabilities

Then factor in exposure. The same CVE is an emergency in an internet-facing service and a routine update in a build-time dependency that never runs in production. Reachability matters too: a vulnerable function your code never calls is real but not urgent.

Remediation Targets

The clock starts when the vulnerability is known to affect you. Targets exist so that "when do we fix this?" is answered once, in advance, instead of negotiated per ticket while the risk sits there.

Risk	Fix within
In KEV, or exploited in the wild, on an exposed system	3 days, and look for signs it was already used
Critical, or high EPSS on an exposed system	7 days
High	30 days
Medium	90 days
Low, or not reachable	Next routine update

CISA's federal rules point the same way. BOD 22-01 gave every KEV entry two weeks (six months for CVEs assigned before 2021). Its replacement, BOD 26-04 (June 2026), sets deadlines by KEV status, exposure, whether exploitation can be automated, and technical impact: as short as three days, with forensic triage, for a KEV vulnerability that gives total control, and 14 days for most other KEV entries.

Finding Them

• Dependency alerts from Dependabot or Renovate on every repository, triaged weekly at minimum, same day for KEV. See Dependency Management.
• Image scanning in CI and on a schedule, because a container that passed last month can be vulnerable today. See Containers.
• An SBOM per build, in CycloneDX or SPDX, so "are we affected?" is a query, not an investigation. When the next Log4Shell lands, the teams that answer in minutes are the ones that already know every version of every library in every deployed artifact.
• External reports through a published channel (below).

Fixing Them: Rebuild and Redeploy

The patch mechanism should be the deploy you already do every day. Bump the dependency or the base image, let CI run, merge, and continuous deployment ships it. No hand-patching servers, no special emergency process.

Emergency processes are the problem. A path that only runs during a crisis is a path nobody has exercised, so it fails exactly when it's needed: the runbook is stale, the person who knew it left, the manual steps get skipped under pressure. A patch that rides the normal pipeline has been tested by every deploy before it.

If shipping a patch is harder than shipping a feature, fix that first. See Staying Current.

Exceptions

Sometimes a fix has to wait: no patch exists, or the upgrade is breaking. Exceptions are fine; permanent ones aren't, because the risk an exception accepts tends to grow while everyone forgets it was accepted. An exception is allowed when it has:

• A compensating control (a WAF rule, disabling the feature, network isolation).
• An owner.
• An expiry date, after which it's reviewed again, not silently renewed.

Receiving Reports

• Publish /.well-known/security.txt (RFC 9116) with a Contact and an Expires date, the two required fields.
• Publish a disclosure policy: what's in scope, a safe-harbor statement for good-faith research, and how quickly you'll respond.
• Acknowledge reports within a few business days, and credit the reporter when it's fixed. Researchers who are ignored go public; researchers who are thanked come back with the next finding.

This Site

syntaqx.com publishes /.well-known/security.txt pointing reporters at its contact page, with an Expires date a year out. Dependabot opens grouped dependency updates weekly, and because every merge to main rebuilds and redeploys the whole site, a merged fix is in production within minutes. There's no long-lived server to patch.

References

Specifications

• RFC 9116: security.txt, where to publish a security contact and the required fields
• FIRST: CVSS v4.0, severity scoring
• FIRST: EPSS, probability of exploitation in the next 30 days
• CycloneDX, SBOM format
• SPDX, SBOM format

Reference

• CISA: Known Exploited Vulnerabilities Catalog, vulnerabilities exploited in the wild
• CISA: BOD 26-04, risk-based federal remediation timelines
• CISA: BOD 22-01 (revoked), the earlier two-week KEV deadline
• CISA: Vulnerability Disclosure Policy Template, a starting point for a disclosure policy
• CISA: Apache Log4j vulnerability guidance, Log4Shell (CVE-2021-44228) and the scramble to find affected systems
• GitHub: About Dependabot alerts, dependency vulnerability alerts
• Trivy, scanning container images and dependencies

In practice

• Mandiant: Time-to-Exploit Trends 2023, exploitation in five days on average
• Google Project Zero: From Naptime to Big Sleep, an AI agent finding an exploitable bug in SQLite
• Tenable: BOD 26-04 FAQ, the BOD 26-04 remediation tiers
• securitytxt.org, generating a security.txt file