Security Is Becoming a Modernization Problem

Finding a vulnerability got cheap this year. 

Fixing one didn't, and the gap between those two is where your risk actually sits.

In a healthcare or insurance business that gap has one measure, which is how long it takes to get a change through the system holding your most sensitive data. 

You already know whether that number is good, and you probably know which system it is. Your next client security review is going to find it too. 

That puts your security posture in the hands of the people who maintain your software, which is not where the budget for it lives.

‍

Why are companies getting more vulnerability reports than they used to?

Companies are getting more reports because in April 2026 Anthropic released Claude Mythos Preview, a model that finds zero-day vulnerabilities and writes working exploits for them without a person driving it.

Project Glasswing launched alongside it, putting the model in front of defenders at Google, Microsoft, CrowdStrike, JPMorganChase, and the maintainers behind libraries most of the internet runs on. 

Access is still closed, because by Anthropic's own account no company, itself included, has safeguards strong enough to stop a model like that from being misused.

Across more than a thousand open-source projects, Mythos surfaced 23,019 issues, and 6,202 of those came back rated high or critical. 

Six independent firms audited a sample of 1,752 of the serious ones and more than 90% held up. 

One was a flaw in wolfSSL, a cryptography library running on billions of devices, where the model also wrote an exploit that could forge certificates. wolfSSL is the kind of dependency that sits underneath your application, pulled in by a vendor you chose for something unrelated, so the version you are running is a question your team has to go look up rather than one they can answer.

‍

Why is fixing a vulnerability harder than finding one?

A report lands and your team spends the first week working out whether it even applies to you, and that week is the part of this that got no faster.

Before anything gets patched, your team has to answer:

• Is the finding real in our environment, or only in the library in general
• Does the affected code path run in production
• Which systems and integrations touch it
• Who owns the fix, by name
• What else could break when it changes
• How do we test that before it goes out
• How fast can we deploy it
• What do we tell customers, members, or auditors, and when

Every one of those is a maintenance question about software you already own. 

Anthropic ran into the same wall inside its own program and named open-source maintainers as the bottleneck, because the finding arrives in an afternoon and the patch still takes whatever it took before.

You are on the same side of that gap. The detection half of your spend got dramatically better this year and the remediation half did not move, so a better scanner buys you a longer list reviewed by the same team that was already behind, and your exposure is the time between that list and a deployed fix. 

That number lives in your release process rather than your security stack, which is why it rarely has an owner at budget time.

You don't set the deadline either. Findings stay private for roughly ninety days or until a patch exists, so the clock on something in your stack starts when a researcher opens a ticket with a vendor you may not know you depend on. 

You hear about it when the disclosure lands, with most of the ninety days already spent.

‍

What makes a system hard to patch?

A system is hard to patch when changing it is riskier than leaving it alone, and you can probably name yours without opening a laptop.

The pattern is consistent:

• The stack sits on a version that stopped receiving security updates
• There are no automated tests around the workflows that matter
• Deployment takes a person following steps that live in their head
• One developer or one vendor understands the code
• Nothing documents what else depends on it
• The integrations around it break when anything moves
• It holds customer, patient, claims, or payment data

A twenty-year-old system with tests, documentation, and a monthly release cadence patches faster than a four-year-old one your team won't touch the week before a release.

‍

Why is slow patching worse for healthcare and insurance companies?

The week a finding lands on your provider portal, it stops being a maintenance ticket and becomes a reportable event.

Health-ISAC wrote a bulletin on Mythos with Quest Diagnostics on May 12, 2026, calling it a systemic shift for the sector and comparing the misuse risk to what hospitals lived through when Cobalt Strike and Brute Ratel got turned on defenders. It expects comparable capability out of Chinese firms within six to twelve months, which sets the window you are working inside.

If that portal turns into a breach, the notification goes out with your name on it. The rule gives you sixty calendar days from discovery, and the clock starts when the incident is first known rather than when your investigation finishes. Subtract the week spent confirming the finding applies to you and the month spent getting a change through a system your team avoids, and sixty days stops sounding generous.

For RTI International we designed the mobile app experience for MDI Align, built for people managing a complex daily health regimen and held to the standards expected of a healthcare-focused research organization, where the client had a 100% success rate in their pilot study. 

In healthcare that standard comes from outside your company, so an application built without an audit in mind still gets measured against one.

‍

How do you reduce time to patch on an old system?

You reduce time to patch by reducing what a change can break, which is ordinary engineering work that no security line item pays for.

Here is what actually moves the number:

• Automated tests around the workflows that would hurt most if they failed
• A deployment any developer on the team can run, documented end to end
• Current dependencies, with a standing cadence for upgrading them
• Logging and alerting good enough to answer what happened and when
• Role and permission cleanup, so access matches what people actually do
• A written map of what depends on what
• Phased replacement of the components that no longer get updates

We believe that business is built on transparency and trust, and that good software is built the same way, which on a security finding means you get to see what we changed and what we tested before it went out.

‍

How does Big Pixel test software against real attack techniques?

We break our own software before you ever see it, because when you buy custom development you're also buying every flaw the builder didn't catch.

That never makes it into a contract. You get a demo, you get a handoff, and no real way to know whether the thing was ever seriously attacked before it showed up with your name on it. Usually the first one to try is a researcher or an attacker, months later, when it's already holding your members' records.

We'd rather be first. 

Anthropic clears vetted practitioners for this capability through its Cyber Verification Program, and we went and got cleared so we could point it at our own work. 

The same reasoning that turned up 6,202 high and critical flaws in open-source code gets aimed at the login path and at anything carrying patient or claims data, while the code is still ours and a fix still costs an afternoon instead of an emergency release and a call to your compliance officer.

‍

What should you check before the next vulnerability report arrives?

Pick the system holding your most sensitive data and time how long a one-line change takes to reach production.

Run it through your normal process and write down everywhere it waits, because that number is what a regulator and a client security questionnaire are both asking about.

Then work the same list across the rest:

1. Name the owner. Every system touching sensitive data gets a person, and a backup.
2. Find the unsupported pieces. List what no longer gets security updates and what depends on it.
3. Test the paths that matter. Automated coverage on the workflows a bad patch would break.
4. Rehearse a patch. Push something trivial through the full process and time it.
5. Write down the map. What depends on this system, and what it depends on.

The fair objection is that you can't modernize everything, and this is not what your security budget was approved for. 

Both are true, and neither changes the first move, which is taking the one system holding your most sensitive data and making that one safe to change so every finding that lands on it afterward gets shorter.

Start the clock on one system this week. 

That number is what you'll be quoting to your board after the next finding, and right now you're guessing at it.