Automated diffing of the fix: About 2 hours (Source: JFrog, jfrog.com/blog/the-new-rules-of-patching (September 28, 2026))
The fix is now part of the perimeter
A JFrog post published September 28, 2026 points at something worth naming in a budget conversation: the patch itself. JFrog argues that the patch, its distribution channel and the vendor's accompanying instructions become part of the security boundary, and so a potential target. JFrog's argument is that the difficulty did not shrink when fixes shipped; it relocated to the gap between a fix being published and a fix being installed.
What JFrog says happens after a fix ships
JFrog describes today's standard practice: a vendor finds a zero-day, builds a fix, publishes the CVE and detailed release notes, and ships the patched binary. Attackers have long compared the fixed version against a vulnerable one to build an exploit. JFrog's argument is that access to advanced AI models now lets them do it at "inhuman speed", before customers have a chance to update. It offers what it calls a conservative timeline:
Read these as JFrog's scenario, not a measurement. The post cites no specific incident or dataset behind the figures, and it says simpler vulnerabilities and binaries could see the timeline cut to single hours. The post also ties AI models to a growing volume of serious zero-day discoveries in vendor code, though it offers no figure. JFrog sells software supply chain security, so this is a vendor's position. It is still a useful model to test your own operations against.
Who carries the risk: the team that self-manages
The exposure falls unevenly. For services the vendor runs itself, JFrog sees no such window: the fix goes live centrally, all customers gain protection together, and attackers have no shipped fix to pick apart. Self-managed software works differently. JFrog says the lag between publication and installation is sometimes hours, often days or weeks.
In JFrog's telling, that lag was once tolerable because defenders and attackers moved at similar speeds. It contends that by the time exploitation begins at scale, plenty of corporate patch pipelines are still mid-testing. Picture the platform team midway through a validation cycle while the clock, by JFrog's account, has been running for a day. That is the person this argument is about.
Disclosure changes, but secrecy is not the answer
JFrog says the security community treated maximum transparency as positive because it assumed both sides moved at roughly the same speed. That assumption, it argues, no longer holds, and responsible disclosure "now functions as a head start for the wrong side." Its remedy is not withholding fixes, which it says would trade fast exploitation for zero protection. Instead it wants to vary what is revealed and when: the public skimming release notes and a customer about to deploy the fix should receive different levels of detail.
JFrog puts equal weight on fix speed. It argues that grouping fixes into scheduled releases suited a period when attackers were no faster than defenders, and it wants even lower-severity fixes to arrive sooner because vulnerabilities can be chained together. It is explicit that this is not a case for shipping untested patches, because a broken fix creates its own risk.
Questions to put to your team
JFrog frames how quickly you apply patches as a security measure in its own right, beyond routine IT maintenance, and says boards and regulators are beginning to see it the same way. Measure it accordingly:
1. For self-hosted systems, what is our measured time from a vendor publishing a fix to that fix running in production? Is it tracked against a service level, or only reported anecdotally?
2. Do we still batch upgrades into monthly or quarterly windows? JFrog's view is that this rhythm suited an era of slower threats and no longer fits.
3. Are we enrolled in each vendor's authenticated channels, where sensitive disclosures and patches may reach customers first?
4. Are the platforms themselves current, not just their components? JFrog notes outdated tooling caps how fast you can move. Have anonymous permissions been removed?
5. Where the answers are uncomfortable, is the right response more automation in the patching pipeline, or moving that workload to SaaS? JFrog raises both options, and the trade-off is a business decision, not a foregone conclusion.
The lesson: a changelog now has two audiences, and the one that reads it fastest sets the deadline for the other.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: JFrog.
