Mar 2026
Lim May-Ann
France made headlines in 2025 for becoming the first government to endorse the UN Open Source Principles, and further in April 2026 announced its decision to migrate its government systems off Windows to Linux software. Linux was originally developed in Finland, but the software is open source, and anyone can use, modify, and share it.
The Benefits of Open Source: TCO, Transparency, Innovation
There are a number of benefits to open source technologies, such as cost savings by eliminating licensing/subscription costs and reducing the Total Cost of Ownership (TCO), possible improvements to security through transparency thanks to “many eyes” on the code, and enhanced flexibility and code adaptability, interoperability, and community-driven innovation. That said, recent advancements in AI used in cybersecurity uncovered a 27-year-old vulnerability in OpenBSD and a 16-year-old vulnerability in FFmpeg, putting to question whether long term availability of open source code necessarily translates to more security.
The Risks of Open Source: The Trojan Horse in the Library
The risk lies in “transitive dependency” of code development. In many instances, a developer in one country may import a single open-source package for a routine task, with or without knowing that they often inadvertently pull in dozens of other sub-libraries managed by other code developer volunteers. This “chain of trust” is malleable and thus susceptible to manipulation.
For example, in 2024, a critical vulnerability (CVE-2024-3094) in XZ Utils (compression library) used in Linux distributions was found, specifically a sophisticated backdoor vulnerability. Because this library was embedded in the standard software builds for many organisations around the world, the vulnerability was “pushed” to millions of end-users before a single line of malicious code was even executed by the hackers. The vulnerability was discovered by chance and rectified, but highlights the importance of ensuring code oversight, particularly when deploying open source systems.
Open source deployments also open up unique risks to organisations and developers, such as to the risk of typosquatting, where bad actors upload packages with names that are VISUALLY similar to popular ones, except with typoerrors e.g. “reqests” instead of “requests”, or rnicrosoft.com where “R-N” in lowercase is used instead of “m” as it looks visually similar. How the risk operates in the open source environment is:
- The bad actor starts by finding a popular open source package,
- Duplicating the package and adding some form of malicious code.
- Renaming the malware-infected package and uploading it to a public repository in the hope that developers will mistype and download it rather than the valid package.
In 2024, a typosquat of a popular Python library “fabric” was packaged on PyPI, a widely used repository for Python libraries, as “fabrice”, and before discovery, had racked up thousands of downloads for over three years while stealing developers’ AWS credentials. Specifically, fabrice was designed to execute shell commands remotely over SSH.
AI and Vibe-Coding: Accelerating Security Risks
This insecurity from open source is compounded by the current trend of vibe coding, i.e. coding using AI coding assistants. While these tools allow a junior programmer to write code at the speed of a senior architect, some studies have observed almost 3x as many security flaws than human-written code.
Strengthening the Chain: A Regional Mandate
There is no single approach that can address all cybersecurity risks. Moving to open source technologies can be a boon to code adaptability and transparency, but can also open up a new attack surface vulnerability. CCAPAC proposes that to secure our software supply chain, APAC could consider implementing three pillars of “Software Transparency”:
- The SBOM Mandate: Just as food products require a list of ingredients, software should be accompanied by
must come witha Software Bill of Materials (SBOM) that includes external open source libraries and resources that are relied on. Regulators in Singapore and Japan are already leading the way, suggesting that any vendor selling to the government must provide a machine-readable inventory of every open-source component used. - Vetting the “Free” Lunch: Enterprises should consider the nuances of considering OSS as a risk-free resource, such as deploying other resources to ensure that the security of the OSS. For example, it could mean implementing “Open Source Program Offices” (OSPOs). An OSPO is a unit or team located within an organisation that facilitates the use and sharing of open-source software. OSPOs are designed to help institutions adopt open-source tools, manage software licensing and build the digital skills needed to work with open-source software systems and digital communities. One approach would be to have the OSPO use AI-enabled automated tools to scan for risks such as “aged” or “single-maintainer” libraries that are ripe for takeover by bad actors.
- Binary Authorisation: Another consideration for regional consideration is to move to a deployment model where no code is deployed unless it has a verifiable digital signature proving it was built in a secure environment.
As AI-driven vulnerability discovery accelerates, the reliance on manual human intervention in open-source maintenance is becoming unsustainable. To prevent maintainer burnout and ensure the integrity of the global software supply chain, organizations need to shift toward autonomous remediation. They should prioritize the implementation of autonomous patching pipelines—incorporating automated testing, staged rollouts, and rollback capabilities—to bridge the critical gap between disclosure and deployment.
By leveraging machine-readable inventory management (SBOMs) and adopting automated, class-based remediation, organizations can secure their infrastructure without placing an undue burden on the maintainers who sustain it. Ultimately, investing in collaborative, AI-augmented security ecosystems is essential to building a resilient foundation for our digital infrastructure.
Conclusion
With moves towards digital and data sovereignty becoming popular, there may be a knee-jerk reaction to move immediately to open source technologies. However, regulators and system implementors should move with full understanding of the new software supply chain threats that come along with open source technologies. Strong approaches towards verification and trust mechanisms, and rigorous vetting processes are needed, to ensure a secure software supply chain for the region.