Safeguard
Best Practices

Ransomware defense strategy for engineering teams

Ransomware hit 44% of breaches in Verizon's 2025 DBIR, up from 32% a year prior. Here's the backup, access, and detection playbook that actually stops it.

Safeguard Research Team
Research
6 min read

Ransomware showed up in 44% of the breaches Verizon analyzed for its 2025 Data Breach Investigations Report, up from 32% the year before, drawn from a dataset of more than 22,000 incidents and 12,000-plus confirmed breaches — the largest sample the DBIR has ever published. The same report found ransomware present in 88% of breaches at small and medium businesses, versus 39% at large enterprises, which tells you this is not a problem only the biggest companies need to plan for. Meanwhile CISA's Known Exploited Vulnerabilities catalog grew from 1,239 entries at the end of 2024 to 1,484 by the end of 2025 — a roughly 20% jump — and CISA flagged 24 of the 2025 additions as vulnerabilities known to be used in ransomware campaigns, including CVE-2025-5777 ("CitrixBleed 2") and a set of Oracle E-Business Suite flaws tied to the Cl0p extortion group. None of this is exotic tradecraft: it is patchable bugs, over-broad access, and backup systems that turn out to be reachable from the same network the attacker already owns. This post lays out a defense playbook built on three layers engineering teams control directly: what gets into the environment, what an attacker can reach once they're in, and how fast you notice.

What's actually driving the record ransomware numbers?

The DBIR's jump from 32% to 44% of breaches involving ransomware isn't a story about smarter malware — it's a story about volume and target selection. Verizon's 2025 analysis, built from over 22,000 incidents, attributes much of the increase to ransomware-as-a-service crews increasingly targeting smaller organizations that lack dedicated security staff: 88% of SMB breaches in the dataset involved ransomware, compared to 39% at large enterprises. That gap matters for engineering leaders at growth-stage companies in particular, because it means the "we're not a big enough target" assumption is backwards — smaller, less-instrumented environments are disproportionately represented in the breach data, not protected by their size.

Which vulnerabilities are ransomware crews actually walking through?

CISA's KEV catalog is the clearest public record of what's being exploited in the wild, and it grew from 1,239 entries at the end of 2024 to 1,484 by the end of 2025. An analysis of the 2025 additions by threat-intelligence firm Cyble found CISA explicitly tagged 24 of them as tied to ransomware activity, including CVE-2025-5777 ("CitrixBleed 2") and Oracle E-Business Suite vulnerabilities linked to the Cl0p group's extortion campaigns. The three most common weakness categories among 2025 KEV additions were OS command injection (CWE-78, 18 entries), unsafe deserialization (CWE-502, 14 entries), and path traversal (CWE-22, 13 entries) — all bug classes a standard SAST/SCA pipeline and a disciplined patch cadence catch before an attacker ever gets a foothold. The pattern holds across years: ransomware's initial access is overwhelmingly a known, patchable flaw, not a novel technique.

Why isn't "we have backups" enough anymore?

Because ransomware operators now target the backups first. CISA's #StopRansomware Guide recommends the 3-2-1 rule as a baseline — three copies of data, on two different media types, with one copy offsite — and explicitly calls for maintaining offline, immutable backups and regularly testing restores, since modern operators routinely compromise backup consoles and admin credentials before triggering encryption so they can delete or encrypt recovery copies along with production data. The backup industry's common shorthand for this hardened posture is 3-2-1-1-0: on top of the 3-2-1 baseline, add one immutable or air-gapped copy that cannot be altered or deleted even with valid admin credentials, plus a "zero" standard — zero errors on a verified, regularly tested restore. Immutability has to be enforced at the storage layer (object-lock retention, offline tape, or a separate trust boundary) rather than by an access-control flag in the same identity system an attacker could compromise — otherwise the backup is only as safe as the credentials protecting it.

How does least privilege stop an intrusion from becoming an outage?

Ransomware needs to move laterally from initial access to something worth encrypting — often backup infrastructure, domain controllers, or shared file servers — and tiered, least-privilege access is what makes that movement slow and loud instead of instant and silent. CISA's guidance calls for separating admin credentials by tier (workstation admin, server admin, domain admin should never be the same account), disabling or tightly scoping local admin rights on endpoints, and enforcing MFA on any account that can reach backup or virtualization management consoles specifically, since those are the systems ransomware operators target before deploying payloads. For engineering orgs, the practical version of this is auditing who can reach your backup and cloud-infrastructure admin panels today, and cutting that list to the people who use it weekly — not the list that accumulated over three years of "just in case."

What does detection look like before the encryption event itself?

Effective detection treats the ransomware payload as the last step of an intrusion, not the first sign of one — the precursor activity (credential dumping, disabling of security tooling, use of living-off-the-land binaries, and unusual authentication to backup or admin systems) typically happens hours to days earlier. That's why CISA and vendor incident-response guidance consistently push behavioral and EDR-style detection over signature-based antivirus alone: signatures catch known payload hashes, but they don't catch an attacker using legitimate admin tools to map your network. For engineering teams, the actionable version is instrumenting and alerting on the precursor behaviors your own admin and backup systems would show under attack — unexpected privilege escalation, backup-job configuration changes, and mass file-permission or deletion activity — rather than waiting for a payload signature to fire.

How Safeguard helps

Safeguard's engineering-facing controls reduce the initial-access side of this equation, which is where the KEV data shows most ransomware intrusions still begin. Continuous scanning identifies known-exploited CVE classes like the command-injection, deserialization, and path-traversal weaknesses that dominated 2025's KEV additions, and self-healing containers close that window automatically — rebuilding and redeploying a patched image, typically within an hour of a CVE being published, instead of leaving a known-exploited flaw sitting in production while a manual patch PR waits for review. Griffin AI explains each finding in plain language and can open an auto-fix pull request for the underlying code, so the vulnerabilities that ransomware crews are actively scanning for get closed before they become someone's initial-access story. Backup immutability and tiered admin access remain infrastructure and IAM decisions your team owns directly — Safeguard's role is making sure the vulnerable code and containers that give an attacker a foothold in the first place don't stay exposed long enough to matter.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.