Zero-Day Vulnerability

A zero-day vulnerability is a hole in software that has just been found and has no fix yet. The name comes from the number of days the people who wrote the code have had to repair it. Zero. It is not a sign that you chose the software badly. Every app is built from parts written by other people, and the hole is usually in one of those parts.

Picture the lock on your front door. One morning someone shows that a certain model can be opened with a bent card. Your door has that model. You did nothing wrong, and the door stays open until the maker produces a new part. Software is the same, except the news travels around the planet in hours and thieves read it too.

A website is the easier case. The company that looks after your site replaces the part, and every visitor gets the repaired version the moment the page loads. A phone app is slower, and this catches businesses out. The fix has to be built, sent to Apple and Google, reviewed by them, and then downloaded by every member of staff who has the app. Review takes a day or several. Some people will not update for weeks. So the same hole stays open far longer on a phone than on a website.

Ask your supplier the questions before the trouble comes, not after. How do you learn that a part you use has a hole. How fast can you send out a fix, measured in hours and days rather than a vague promise. Can you switch a broken feature off from your side without a new store release. Do you keep a list of every part the app is built from. That list is the difference between checking one page and searching for a week. Linkysoft keeps one for every app it builds, and it is the first thing we open when a warning appears.

None of this removes the risk completely, and a supplier who says otherwise is selling you something. What you can control is the time between the news and the repair. That is why patch speed belongs in the contract, and why Linkysoft treats it as part of the security work on every mobile app it delivers.