Modern websites are assembled as much as they are written: frameworks, libraries, plugins and packages, most of them open source. That convenience has become a new attack surface. In March 2026, the widely used axios library was compromised on npm. In May, a coordinated campaign hit more than 170 npm packages, including TanStack and Mistral AI libraries. Sonatype logged 21,764 malicious open source packages in the first quarter of 2026 alone, and OpenSSF figures cited by Google show malicious packages rose 1,444% between 2024 and 2025. Understanding this trend is now part of basic cybersecurity in web development.
Open Source Is Not the Problem
Open source remains a sound choice. Public code can be reviewed by thousands of people, and it lets businesses ship faster than building everything from scratch. The danger lies in unmanaged use: installing packages nobody reviews, trusting every update automatically, and forgetting what is deployed. Attackers increasingly abuse trusted maintainer accounts and release pipelines rather than inventing new exploits. Our articles on buy versus build and third-party integrations explain how to weigh that trade-off.
The Hong Kong Picture
Locally, the trend is clear. Hong Kong's Digital Policy Office reported a 66% jump in hacking-related personal data breaches in the first half of 2026, warning that AI is empowering attackers. HKCERT's Cybersecurity Outlook 2026 recorded a 27% annual rise in incidents, named AI-related attacks and supply chain risks as top concerns, and found nearly 30% of enterprises lack dedicated security staff. For smaller firms, our SMB security guide and data privacy in 2026 are practical starting points.
Practical Steps You Can Take
Lock dependency versions with lockfiles, and review updates before applying them instead of auto-updating blindly. Enable multi-factor authentication on npm, GitHub, hosting and CMS accounts; see how two-factor authentication and strong password practices help. Remove packages you no longer use, and keep secrets out of build pipelines wherever possible. Protect your API connections too, since integrations widen exposure. Finally, run regular scans and learn to prioritise fixes so critical issues are handled first. Keeping a small, deliberate set of dependencies is also one reason custom development can be safer than heavily templated builds, a point we explore in free website builders.
Smaller details matter as well. Review who has access to your repositories and hosting accounts, and remove former staff and agencies promptly. Prefer well-maintained packages with active communities over abandoned ones, because neglected projects are easy targets for account takeover. Keep a simple inventory of the libraries your site depends on, so that when a headline breaks you can answer "are we affected?" in minutes rather than days. Pair this with automated backups and a tested recovery plan, as described in our backup automation guide, and with XSS and CSRF protection on every form, so that one compromised component cannot easily become a full breach. If you are weighing a rebuild, our article on custom versus off-the-shelf backends is a useful starting point. Most importantly, assume that one day a dependency will be compromised, and design your processes so the damage stays small.
