The Anti-virus Times

2026年5月29日星期五

If you’re interested in information technologies and computer security in particular, you've probably heard of the following terms: "open-source code," "Open Source," and "open software". Open-source programs are widely considered a security standard, and among IT experts, their promotion and use are considered to be good manners. And it's not just about free and openly distributed software (which is not always the case). Open-source code and system security are often equated. However, the technical essence of the issue is lost behind loud slogans about "free software". Why is open-source access considered critical to system security? Is openness an automatic guarantee of security, or is it just another tool in the developer's hands? In today's issue of the Antivirus Times, we'll delve into the core of how software works to understand what happens at the machine-instruction level and where security truly originates.

What is open- and closed-source code?

To probe deeper into the issue and understand how open source ultimately impacts our security, we need to understand the form in which software exists on our devices. The fact is that no processor is capable of "reading" program text the way a human does. For a silicon chip, the concepts of "algorithm," "logic," "GUI", or even "programming language" do not exist. All of the programs on your device, as well as the files they use, are essentially just sequences of bits—0s and 1s. This is easy to verify by opening any file in a binary editor. All of the complex syntax that developers work on disappears during the compilation process, turning into a dry set of elementary commands in the case of executable files or structured data arrays in the case of auxiliary files. Thus, a compiled program is a "black box": we see what it does on the surface, but without the source code, we cannot be sure how exactly it does this at the machine instruction level.

For example, executable files (EXE files) and DLL libraries are binary file formats that pack the compiled machine code so that the operating system knows how to load it into the memory and pass it to the processor for execution. However, reconstructing the original program logic and the true intentions of the program's developer, based on a completed EXE file, is a monumental challenge. It is precisely this "black box" that virus analysts are forced to peer into during the course of their work. Lacking access to the source code, they use reverse engineering methods, attempting to reconstruct the program's algorithm, using indirect signs and fragments of machine commands. This is a very resource-consuming process: where a code author spends seconds reading a clear line, an analyst can spend hours decrypting the logic of a single suspicious action.

For clarity, let's use a popular analogy: if a compiled program or a binary file is a ready-made dish, the source code is its detailed recipe. Essentially, it is the program text written in a programming language that has a key property: it is human-readable. Unlike impersonal 0s and 1s, the source code contains, or can contain, a logical structure, meaningful variable names, and, what’s important, author comments. By studying such a text, a security specialist can much more easily understand why a program is accessing the system registry or a network gateway—all of the author's decisions are recorded in the algorithm. However, it's important to note: source code isn't always crystal clear. There's a concept called obfuscation—the deliberate muddying of code. Typical obfuscation techniques include replacing variable names with meaningless character sets and artificially complicating a program’s logic. All of this makes it difficult to analyze a program's operation, despite the availability of the source code. Furthermore, analysts also encounter examples of poor coding style, in which a useful algorithm can be hidden behind a clutter of chaotic functions and non-obvious workarounds.

This brings us right to the difference between open- and closed-source code. Continuing our analogy, open-source code is a recipe that is made publicly available. In theory, anyone can examine the ingredients and ensure that nothing extra has been added. This principle underlies the appeal of open-source software in the context of security—it allows anyone to openly audit and review code.

Closed-source code is the same recipe, but it's held under lock and key in the developer's safe. The user receives only the ready-made product and can only guess at the inner processes. So-called proprietary software has closed-source code, in particular, to protect against modification and use that circumvents licensing agreements. Closed-source code ensures that users cannot view, modify, or study a program's algorithms without reverse engineering (which is also generally legally prohibited). This secrecy forms the foundation for the commercial model: a company sells not just a set of instructions, but a guaranteed result on which it stakes its name and reputation. Legal prohibitions that apply to decompilation and closed-source code are measures taken by the beneficiary to control the product and monetize their activities. It's important to note that this is precisely why hacker attacks on development companies often aim to steal source code. And if they are successful, this can have even more serious consequences than the theft of databases or technical downtime.

However, for Open Source ideologists, these closed doors are the main source of mistrust. The eternal debate arises: what is more reliable—the approaches of a commercial company or the transparent walls of a community?

About open-source software security

As stated above, the attractiveness of open-source software in the context of security is built on the principle of transparency. One of the giants of the faith for open-source security is the so-called Linus's Law, formulated by Linus Torvalds, the creator of the open-source Linux kernel. This law is better known as the "Enough Eyeballs" theory. Its essence is simple: the more people have access to the source code, the higher the likelihood is that any bug or intentional backdoor will be quickly detected and removed. In this process, the community of volunteer-maintainers acts as a form of community immunity, continuously filtering code for threats. It would seem that the choice is obvious: open code can be verified, while with closed code, one can only trust the developer. But in practice, this logic breaks down against the technical reality of software development. The main trap of open software is the word "can". The fact that code can be reviewed by anyone doesn't mean it has actually been reviewed. In practice, thousands of libraries that power critical systems can contain vulnerabilities for years simply because their source code is too dull or too complex for voluntary auditing. The result is a situation where each participant assumes that the code has been reviewed by someone else, someone more qualified. Thus, the "Enough Eyeballs" theory only works when these "eyeballs" are present—for example, during the development of a new feature for a popular browser or when the next Linux kernel update is being prepared. Meanwhile, modern comprehensive software resembles an iceberg: the user sees the tip, but hundreds of highly specialized libraries responsible for encryption, font processing, or mathematical calculations are hidden beneath the water. These components can be in open repositories for years without any audit. As a result, critical code responsible for the safety of millions of users is studied for years, not by "thousands of eyeballs" of volunteers, but by just a couple of full-time developers. History knows many examples of fundamental vulnerabilities in such libraries (for example, OpenSSL or Log4j) remaining undetected for decades, despite their completely open nature.

The second critical aspect is the legal vacuum. In the Open-Source world, responsibility for a specific bug is often limited to the "community" as a whole.

If a vulnerability discovered in an open library leaks the data of millions of users, the victims won't be able to file a suit against a group of volunteers. In the proprietary software sector, the situation is different: a commercial company bears direct reputational and legal responsibility to its clients, which forces it to build quality control and technical support systems. The effectiveness of internal audits often far exceeds the "community immunity" of open software, as companies spend significant amounts of money on staff experts and external audits. This is done not for altruistic reasons; rather it is part of a pragmatic approach in a competitive market: the security of closed code is supported by legal agreements (SLAs) and insurance.

There's another important technical factor to keep in mind when considering the security of open-source software. Even assuming the source code is perfectly clean and has been verified by thousands of experts, the average user never runs this code directly. Users download from the Internet and use a ready-made program made up of instructions compiled for the CPU. No guarantee exists that the target file was built from that transparent source code. During the build process, malicious or simply undeclared features can be implemented into the program through an infected compiler or a developer’s compromised infrastructure. This problem is so serious that in the open software world, there exists a separate movement for Reproducible Builds. Its goal is to allow anyone to verify that a binary file matches the source code. However, for most projects, such verification remains an unaffordable luxury, making open source only partial protection.

Finally, all of the above arguments about auditing and transparency, as well about the risks, crash up against this simple reality: the vast majority of users do not possess the skills of a systems programmer or a virus analyst. For the average person, discussion about code openness is purely of a theoretical nature. Ultimately, the openness isn't a personally verified technical fact, but rather a belief in the community's honesty; just as it is belief in a corporation's reputation in the case of closed software. Thus, for the everyday user, the difference between transparent code and a "black box" is practically erased: in both cases, they are forced to completely delegate their security to third parties, without the physical ability to verify their work.

Security through obscurity

It's important to remember that code openness is a double-edged sword. The availability of a "recipe" to the community means it's also fully accessible to cybercriminals. Virus writers don't have to spend months on reverse engineering, comparing assembly instructions, and guessing bytes—the algorithm, architectural features, and logical errors that are potential vulnerabilities are right there in front of them. As for closed-source software, hackers first need to "crack the safe" to simply understand how the protection works, whereas with open-source software, they can spend years studying the source code in search of a single loophole. By the way, this is why the vast majority of antivirus programs have closed-source code.

Modern comprehensive antivirus software is a multi-module product with the broadest range of features, running on a system with elevated privileges. This also determines the cost of a mistake. If the source code of all of the modules of such a program is open, malware creators will have a much easier time adapting their creations to bypass security mechanisms or even using the vendor's developments to create new malware modifications.

In this context, the closedness is not only about protecting intellectual property but also a strategic necessity in the constant struggle between shield and sword.

To be fair, it's worth noting that open-source antivirus solutions do exist, for example, the famous ClamAV. However, its popularity and openness don't contradict the above points, but only confirm them. ClamAV is not the ultimate shield, but rather an effective, coarse filter. It is not designed to combat sophisticated methods for bypassing the security features in the average user's operating system. Its main task is to quickly match files with a database of known signatures on servers and mail gateways. However, despite its effectiveness in its field, it often becomes a testing ground for virus writers.

Conclusion

In summary, the debate between "openness" and "closedness" in the context of security is a choice between two different trust models.

Open source is a powerful tool of transparency for those who are willing to invest time in doing audits or trust the community's expertise. After all, the Open Source ideology is the pillar of the entire IT industry and the driving force of digital development. But it's important to remember that this is not a magic talisman that automatically makes a program secure.

Closed-source code is a choice in favor of commercial guarantees, brand reputation, and strategic algorithmic secrecy, which is critical for many products on the market, including antivirus software.

Security in general is not a static property of a code or a compiled file. It is a continuous process, supported equally by community enthusiasm and transparency, as well as by commercial responsibility and proven development approaches within private companies. For the end user, the choice between these two is always a matter of trust: either the "collective wisdom" of the maintainers, or the professional reputation and capital of a particular developer.