Here’s a question worth asking about every app you have installed right now: when was the last time it fixed a security flaw, and how would you know?
For almost everything on your phone and in your browser, the honest answer is you wouldn’t. Updates arrive silently. The app store note says “bug fixes and performance improvements,” which is the software equivalent of “no comment.” Somewhere in that update might be a patch for a vulnerability that exposed your messages, your password vault, or your payment details for the past six months. Or not. You have no way to tell.
We spend a lot of energy telling people to “keep your apps updated,” and it’s good advice. But it skips a step. Updating blindly is an act of faith, and the thing that turns faith into verification is a boring, unglamorous page most companies can’t be bothered to maintain: the changelog.
The gap between fixed and disclosed
When a breach or vulnerability makes headlines, coverage follows a familiar arc: the flaw, the exposure window, the vendor’s statement. What happens after the news cycle moves on is the part that affects you. Did the fix actually ship? In which version? Are you running it?
Vendors are often legally required to disclose breaches. They are almost never required to publish a readable history of what they’ve fixed. So the disclosure ends up in a press release written by lawyers, while the fix ends up in version 4.2.1 with release notes that say nothing. Security researchers can diff binaries to figure out what changed. Everyone else gets “improvements and bug fixes.”
This is exactly backwards. A public, dated record of changes is the cheapest transparency mechanism software has. Every user has the same question after a scare: is this handled? A changelog answers it with a verifiable line item instead of a shrug.
An update history is a background check
There’s a second, quieter reason to care about changelogs, and it’s the one that applies before you ever install an app: an update history is the closest thing software has to a background check.
Think about how scam and abandonware apps actually operate. They launch, they get a burst of downloads, and then they coast, harvesting subscriptions or data while the code rots. The marketing page stays polished forever. Screenshots don’t age. The one thing that can’t be faked cheaply is a consistent, dated trail of real changes over months and years.
So before trusting an app with money or data, look for the changelog the way you’d look for reviews. No changelog at all is a yellow flag. A changelog that stopped nine months ago is a red one. Either the product is abandoned, or the team ships without telling anyone, and neither is comforting from a security standpoint. Unpatched dependencies pile up fast; an app that hasn’t visibly shipped in a year is an app whose libraries are a year behind the CVE feed.
The inverse is also true. A product that publishes frequent, specific entries is showing you its work: “patched a session-handling issue,” “upgraded our encryption library,” “fixed a bug that could expose email addresses in shared links.” Specificity is the tell. Vague notes cost nothing; specific ones require the team to actually know and admit what changed.
Why the changelog died, and what’s reviving it
If changelogs are this useful, why are most of them empty or dead? Because of an awkward shift in how software gets built.
AI coding tools have made shipping dramatically faster. Teams that released monthly now push changes several times a week; solo developers ship at a pace that used to need a whole team. But every one of those changes needs a human to stop, translate “refactored auth middleware” into “we fixed a login security issue,” and publish it. When you ship four times a year, that’s easy. When you ship thirty times a month, it’s the chore that always loses to the next feature. So the code accelerates and the communication flatlines. That’s how you get products that are genuinely well-maintained but look, from the outside, identical to abandonware.
The fix turning up now is the same technology that caused the problem. A new class of tools reads a project’s actual code changes and generates the human-readable release notes automatically. ReleasePad, for example, is a changelog tool that connects to a company’s GitHub repository and uses AI to turn each batch of commits into a plain-English, published changelog, so the record exists even when no one has time to write it. Whatever tool a vendor uses, the practical effect for users is the same: “we didn’t have time to write release notes” is stopping being a valid excuse.
The next audience reading patch notes isn’t human
One more reason this page suddenly matters: people are increasingly asking AI assistants questions like “is this app safe?” or “did they ever fix that vulnerability?” The assistant has to find that answer somewhere. A dated, well-structured changelog is precisely the kind of source it can read and cite. Some changelog platforms are already leaning into this: ReleasePad publishes a machine-readable version of each changelog alongside the human one, built specifically so AI assistants can pull accurate answers from it. A product with no public update history doesn’t just look sketchy to cautious humans anymore; it’s effectively invisible to the AI layer that’s starting to mediate software recommendations. Vendors haven’t fully woken up to this, but the incentive is brutal: publish a verifiable record of what you fix, or let a chatbot guess.
A 60-second habit worth adopting
The practical takeaway fits in one paragraph. Before you install or pay for an app, find its changelog. It’s usually at /changelog, /releases, or behind a “What’s New” link in the footer. Check three things: does it exist, is the latest entry recent, and are the entries specific enough to mean something. After any breach story involving software you use, go back and look for the entry that addresses it, including the version number, then confirm that’s the version you’re running. And if a product you pay for has no public update history at all, ask them why. It’s a fair question.
None of this requires technical skill. It’s the same instinct you already apply to expiry dates and padlock icons, just aimed at the one page where software can’t easily lie about itself.
