TL;DR: Security researchers counted more than 48,000 new CVEs in 2025, roughly 20% above 2024’s record pace, underscoring why vulnerability management must operate continuously rather than as a quarterly checklist, according to Secureframe. The article frames vulnerability management as an operational control loop, not a point-in-time assessment, and that shift now drives both security and compliance outcomes.
NHIMG editorial — based on content published by Secureframe: A step-by-step guide to the vulnerability management process with a policy template
By the numbers:
- In 2025, security researchers counted more than 48,000 new Common Vulnerabilities and Exposures (CVEs) published, a roughly 20% jump over 2024’s record pace of around 40,000.
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when remediation capacity is limited?
A: Prioritise by exposure, business criticality, and the identities attached to the affected asset.
Q: Why do vulnerabilities become identity risks so quickly in modern environments?
A: Because many systems do not just process data, they also carry credentials, tokens, certificates, and service accounts that control other systems.
Q: What do security teams get wrong about vulnerability management in complex environments?
A: They often treat the software flaw as the whole problem.
Practitioner guidance
- Build a continuous remediation queue Feed scanner findings directly into a triaged workflow that assigns owners, severity, remediation SLA, and validation status so the queue stays live between assessment cycles.
- Add identity context to vulnerability prioritisation Flag assets that host service accounts, API keys, certificates, or admin interfaces so exposure scores reflect the identity impact of a compromise, not just the technical CVSS score.
- Harden configuration baselines before deployment Use approved build standards for cloud resources, logging, encryption, and authentication defaults, then verify those baselines as part of release gating instead of post-deployment cleanup.
What's in the full article
Secureframe's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step vulnerability management policy template language for formal programme ownership and review.
- Detailed guidance on automating scanner output, ticketing, and continuous monitoring workflows.
- Practical examples of using Secureframe with AWS Inspector and GitHub integrations for vulnerability tracking.
- The article's FAQ section with process definitions and program-building prompts for compliance teams.
👉 Read Secureframe's step-by-step guide to the vulnerability management process →
Vulnerability management is moving from scanning to continuous control?
Explore further
Continuous vulnerability management is now an access-control problem as much as a patching problem. Vulnerable systems increasingly become the easiest route into identity systems, cloud workloads, and privileged tools. When attackers exploit exposed services or insecure defaults, they often inherit the permissions attached to those systems rather than bypass them. The operational conclusion is that vulnerability workflows must include identity and privilege review, not only software remediation.
A question worth separating out:
Q: What frameworks should vulnerability management programmes align to?
A: Most programmes map cleanly to NIST Cybersecurity Framework, NIST SP 800-53, and CIS Controls v8, with identity-sensitive environments also needing IAM and NHI governance references. The key is to use frameworks to structure ownership, logging, remediation, and validation, not to turn compliance into a substitute for operational risk reduction.
👉 Read our full editorial: Vulnerability management is moving from checklist to continuous control