Over the past few weeks, Deskpro has been sending multiple advisory emails per week alerting our self-hosted customers to new security patches. It’s not because our platform suddenly got less secure. When we email customers about a security patch, it’s because we’ve fixed something serious and want them to upgrade before our next scheduled release.
Here’s what’s actually happening: like many software companies, we’ve seen an uptick in reports to our vulnerability disclosure program because security researchers are increasingly using AI, and AI has gotten very good at finding security vulnerabilities. For context, the US National Vulnerabilities Database, a repository of documented software security vulnerabilities, is on track to see twice as many reported vulnerabilities in 2026 as in 2025 in large part because of advances in AI.
Any time we receive a vulnerability report, our Engineering team must verify it by reproducing it, and then fix it with a security patch if it’s legitimate. We assess every report on its real risk to our customers, and not every report holds up. AI produces a fair amount of noise, and some reports overstate how severe a finding is, sometimes because a higher rating means a bigger bounty payout, and sometimes because the researcher can’t see the compensating controls we already have in place.
Whenever we verify a vulnerability that requires a security patch outside of our standard release cadence, we email our self-hosted customers. These emails don’t mean something bad has happened and we’re now in the storm. We’re telling our customers, “Something was reported, we verified it, we fixed it, and we did it quickly. We want you to upgrade now.”
We do this out of an abundance of caution. Our normal release cadence is every six weeks, and if we find a critical vulnerability a week after a release, we don’t want to wait another five weeks to release the patch and risk an exploit in that time. We want to get the update out and make sure our customers know about it right away so they can secure their service and their infrastructure.
How we notify customers depends on how they run Deskpro. With cloud-hosted Deskpro instances, we apply security patches immediately because we run the infrastructure, so those customers are upgraded without needing to do anything, and the fix is documented in their release notes. But for self-hosted Deskpro instances, the customer needs to download the security patch and deploy it themselves, since we have no access to their infrastructure by design. This is where proactively communicating about security patches becomes critical, and it’s not an approach every SaaS or self-hosted software provider takes.
In addition to proactively communicating with our customers when we release a security patch, we also have a responsible disclosure policy that prevents security researchers from talking about a vulnerability they’ve found for 90 days, with the right to extend to 180 days for critical vulnerabilities. We do this to ensure our self-hosted customers have time to implement the security patch before a researcher’s vulnerability write-up goes live.
Not every organization that self-hosts Deskpro is in a position to implement a patch within 24-48 hours of us releasing it. They have their own internal patching cycles they have to adhere to, or there might be dependencies on version numbers that stop them from being able to upgrade in a short timeframe. If a security researcher publicizes a vulnerability before an on-premise customer has time to implement the patch, the researcher has published sensitive information hackers could use to exploit that vulnerability. By requiring security researchers to wait 90-180 days to publish, we give our self-hosted customers the time they need to plan for and implement the fix.
Many software vendors fold their security patches into their standard release cadence, or if they do release patches more frequently, they add a note about the patch in the update center of their customer portal rather than proactively sending an advisory. That works when the vendor applies the patch itself, as we do for cloud. It’s less effective when the customer has to act. Unless a customer manually navigated to this section of the portal, they could easily miss it, and therefore delay an update that fixes a critical security issue.
We’ve seen some high-profile examples of what can go wrong with silent patches in the tech industry. For example, in late 2025, the cybersecurity company Fortinet came under fire for shipping a silent patch for a critical vulnerability in its FortiWeb appliances and not issuing an advisory until mid-November, even though attackers were already exploiting the flaw. For more than two weeks after the patch shipped, customers had no official warning about a flaw that let unauthenticated attackers create admin accounts.
That’s exactly the type of serious incident we aim to prevent by issuing advisories whenever we release a critical security patch for self-hosted customers. We know that silent patches leave customers in the dark and can prevent them from taking the steps necessary to protect their data and support operations, especially in a self-hosted environment.
Security advisories matter for compliance, too. Frameworks like ISO 27001 and SOC 2 expect organizations to track vulnerabilities in the software they rely on, act on them promptly, and be able to show that they did. Customers can’t do that if their vendors don’t tell them.
It’s important to remember that software vendors that don’t send out frequent security advisories aren’t inherently more secure. Not every vendor takes the notification approach, and that’s their call. We’d rather be a bit noisy and make sure our customers are aware, rather than stay quiet and leave customers to patch in their own time. If we were the customer, we’d want to know.
As a security and compliance leader, it’s also what I look for in the vendors we rely on.