Phần mềm nguồn mở là không an ninh? Giới thiệu các vấn đề

Is open source software insecure? An introduction to the issues

By Rowan Wilson, Published: 25 June 2008, Reviewed: 11 June 2012

Theo: http://www.oss-watch.ac.uk/resources/securityintro

Bài được đưa lên Internet ngày: 11/06/2012

Lời người dịch: Một lần nữa bài viết đặt ra câu hỏi: phần mềm nguồn đóng hay nguồn mở là an ninh hơn? Bản chất của việc mất an ninh trong quá trình phát triển và duy trì phần mềm nằm ở chỗ nào và các triết lý có liên quan. Bạn hãy đọc hết bài để có câu trả lời.

Ghi chép tóm lược này có ý định trả lời cho các câu hỏi mà những người mới tới với phần mềm nguồn mở (PMNM) có thể có về an ninh của nó. Chúng tôi trước tien xác định các cách thức chính trong đó phần mềm có thể sẽ là không an ninh, rồi chúng tôi thảo luận các tiếp cận chung cho việc làm giảm nhẹ đi sự không an ninh của phần mềm, và phần cuối cùng so sánh các phương pháp luận phát triển của phần mềm nguồn đóng và nguồn mở để làm sáng tỏ thông tin từ các phần trước đó.

Mã nguồn và mã đối tượng

Theo định nghĩa, PMNM là phần mềm có mã nguồn sẵn sàng cho bất kỳ ai. Mã nguồn có thể được nghĩ như một đạng thiết kế cho phần mềm, một dạng là lý tưởng cho việc giành được sự hiểu biết về cách mà một chương trình làm việc hoặc việc sửa đổi thiết kế của nó. Mã nguồn của một chương trình trong nhiều trường hợp được chương trình khác, được gọi là một 'trình biên dịch', xử lý, trình biên dịch tạo ra tệp thực sự chạy trong máy tính của người sử dụng đầu cuối. Tệp này được gọi là mã đối tượng (Object code) (hoặc thực thi được – executable), và chính điều này mà một người sử dụng nhận được khi mua phần mềm nguồn đóng, sở hữu độc quyền theo truyền thống nhu Microsoft Word. So sánh với mã nguồn của nó, mã đối tượng của một chương trình rất khác cho con người để lĩnh hội hoặc sửa đổi. Vì thế, PMNM có thể được nói là mời và tạo thuận lợi cho sự sửa đổi, trong khi phần mềm nguồn đóng có xu thế không làm thế. Những đặc tính kỹ thuật đó cũng thường được mang theo thông qua các giấy phép đi kèm: các giấy phép nguồn mở cho phép sửa đổi và phân phối lại đối với người sử dụng, trong khi các thỏa thuận cấp phép cho người sử dụng đầu cuối của nguồn đóng có xu hướng ngược lại, ràng buộc người sử dụng phải kiềm chế không sửa đổi hoặc phân phối lại phần mềm mà chúng đề cập tới.

Phần mềm không an ninh theo các cách thức nào?

Một mẩu phần mềm thường sẽ được viết để làm thỏa mãn một tác vụ nhất định. Để thực hiện tác vụ này, phần mềm sẽ được phép thực hiện các hành động nhất định từ phần mềm cốt lõi của máy tính (được biết tới như là nhân), như việc ghi các tệp vào ổ đĩa cứng hoặc khởi động các chương trình khác. Trong hầu hết các mẫu máy tính hiện hành, bản thân chương trình có trách nhiệm cho việc đảm bảo rằng những hành động được phép đó chỉ diễn ra theo cách thức được mong đợi, vì những mục đích được vạch sẵn từ thiết kế và chức năng của nó. Tuy nhiên, thực sự khó để viết phần mềm mà sẽ luôn vận hành theo cách thức được mong đợi. Hầu hết các phần mềm phải xử lý các dữ liệu từ các nguồn bên ngoài mà là nằm ngoài tầm kiểm soát của nó, như đầu vào của người sử dụng từ bàn phím hoặc các dữ liệu nhận được qua mạng. Chính trong sự tương tác bên ngoài đó mà đa số lớn các lỗi về an ninh đã bộc lộ ra.

Các lỗi trong thiết kế chương trình

Hãy nhì vào một ví dụ của một lỗi an ninh như vậy: khi chấp nhận đầu vào từ một nguồn bên ngoài, thông thường để xác định có bao nhiêu ký tự sẽ được xử lý, và để chuẩn bị một không gian hoặc 'bộ nhớ tạm' (buffer) trong bộ nhớ của máy tính để nhận chúng trước khi xử lý chúng. Thường thì trách nhiệm của lập trình viên để kiểm tra liệu bộ nhớ đệm đó có bị tràn hay không hoặc bị tải với các dữ liệu không phù hợp hoặc hỏng. Ở nơi bộ nhớ tạm bị tràn, các dữ liệu có thể kết thúc bằng việc được ghi vào một mẩu bộ nhớ mà không bao giờ từng có ý định để nhận nó, có khả năng một mẩu bộ nhớ có chứa bản thân chương trình. Ở những nơi mà một bộ nhớ tạm bị sử dụng quá diễn ra, thì kết quả có thể là sự hỏng hoàn toàn chương trình. Khi bản thân chương trình bị ghi đề một phần vì đầu vào quá lớn, điều này có thể bị người xấu khai thác để thay thế mã chương trình đó, và vì thế giành được sự kiểm soát của một qui trình đang chạy trên máy tính. Tương tự, các dữ liệu mà bị hỏng hoặc dị hình có thể gây tổn thương cho hoạt động của một chương trình nếu nó không bị từ chối, và một số đầu vào dị hình có chủ đích có thể, nếu không được dò tìm ra, gây ra sự hỏng phần mềm mà gây tổn thương cho an ninh của máy tính.

Cấu hình an ninh

Thậm chí nếu mẩu phần mềm là có an ninh như là kết quả của một lỗi từ những lập trình viên ban đầu, nó thường có thể được trả về không an ninh bằng việc thiết lập không đúng. Việc sửa đổi một mẩu phần mềm đối với một hệ thống nơi mà nó sẽ chạy, thường sẽ liên quan tới việc thiết lập một chính sách an ninh cho sự vận hành của phần mềm, xác định, ví dụ, những người sử dụng nào có thể và không thể sử dụng nó, và các máy tính khác nào trong mạng có thể kết nối tới nó. Đôi khi một mẩu phần mềm sẽ được phân phối với một cấu hình mặc định mà là 'mở rộng rãi' - với ý nghĩa là nó cho phép bất kỳ ai truy cập tới nó - và các nhà quản trị hệ thống không có kinh nghiệm có thể không dò tìm ra và tinh chỉnh được chính sách mở cửa này. Để dàn xếp vấn đề đó, nó có thể định để lại một cấu hình an ninh mở hơn so với cần thiết nghiêm ngặt, khi điều này thường gây ra ít kêu ca hơn về những kết nối bị từ chối hoặc sự ủy quyền bị hỏng từ những người sử dụng.

Phần mềm 'Trojan'

Trong khi các vấn đề an ninh gây ra từ những lỗi hoặc những cấu hình sai không như mong đợi, thì một số vấn đề là hoàn toàn có ý định. Phần mềm có thể được thiết kế để trao sự kiểm soát cho các bên thứ 3 không được phép, hoặc để thực hiện các chức năng gây hại có thể và thù địch. Cái gọi là các chương trình phần mềm 'Trojan' hoặc 'Cửa hậu' tạo thành thành phần khác của mất an ninh máy tính. Các chương trình như vậy có thể được chèn vào trong một hệ thống theo một số cách thức. Một người sử dụng có quyền có thể làm bật nhanh không có chủ ý cài đặt của chúng thông qua một thư điện tử bị lây nhiễm hoặc một gói cài đặt bị chỉnh sửa. Một người sử dụng xấu có thể cài đặt chúng có chủ đích. Các lỗi về an ninh giống như các lỗi được mô tả ở trên có thể cho phép một người sử dụng không có phép thay thế phần mềm hợp pháp bằng một sự thay thế 'có trojan', vì thế tạo ra sự truy cập vĩnh viễn của chúng đối với hệ thống.

An ninh tuyệt vời?

Vì thế, an ninh hoàn hảo là cực kỳ khó đạt, và được chấp nhận rộng rãi rằng các lỗi an ninh phần mềm là một thực tế bất tiện của cuộc sống, ít nhất trong thế giới điện toán sử dụng chung. Phần mềm hiện đại - cả nguồn mở và nguồn đóng - được các đội các lập trình viên xây dựng, đôi khi kết hợp các mẩu phần mềm từ những nguồn bên ngoài, và nhiều trong các chức năng và an ninh cuối cùng của nó sẽ được xác định bằng cấu hình của nó do các nhà quản trị thực hiện tại chỗ. Việc đảm bảo năng lực đầy đủ và thiện ý của chuỗi những người này thể hiện một thách thức khó khăn. An ninh phần mềm đã đẻ ra một nền công nghiệp rộng lớn các chuyên gia trong việc xác định các lỗi về an ninh. Một phần hợp pháp của nền công nghiệp này là nhìn thấy được, và bao gồm các nhà tư vấn an ninh phần mềm, những người sẽ xác định các lỗi và làm việc với các lập trình viên phần mềm để sửa chúng. Có lẽ đáng lo ngại hơn là phần không nhìn thấy được, những người xác định các lỗi và bán thông tin về chúng cho bất kỳ ai với tiền và một lợi ích giành được sự truy cập không được phép tới các tài nguyên thông tin và tính toán của những người khác.

Những tiếp cận nào tồn tại để giúp đảm bảo an ninh cho phần mềm?

Đối với những lỗi trong thiết kế chương trình, có các công cụ để giúp xác định và chỉnh sửa vấn đề. Kiểm tra đầu vào phù hợp thất bại có thể - ở mức độ nào đó - được xác định bằng việc phân tích mã nguồn chương trình bằng việc sử dụng phần mềm được thiết kế để giám sát các cờ. Bản thân các lập trình viên có thể phát triển các bộ công cụ sẽ kiểm thử chức năng mong đợi của phần mềm của họ theo cách thức tự động, và xây dựng các công cụ đó trong một gói có đảm bảo chất lượng. Các công cụ khác tồn tại để mở ra mã thực thi kết quả của phần mềm đối với đầu vào ngẫu nhiên trong khi đo đếm hiệu ứng lên phần mềm đó. Qui trình này, được biết tới như là 'làm mờ', rất hiệu quả trong việc xác định các trường hợp ở đó phần mềm bị lỗi. Tất nhiên, như một công cụ cho việc xác định các hỏng hóc phần mềm có khả năng khai thác tiềm tàng, cũng rất hữu dụng cho những người tìm cách truy cập không phép. Một khi được cài đặt, cấu hình phần mềm cũng có thể được các công cụ kiểm tra như các máy quét cổng, chúng kiểm thử tính sẵn sàng của chức năng phần mềm đối với các thực thể bên ngoài.

Bổ sung thêm vào sự giám sát tự động, sự giám sát của con người là một yếu tố sống còn trong việc dò tìm ra các lỗi về an ninh. Sự điều tra mã nguồn của các lập trình viên có năng lực có thể là cách duy nhất để chỉ ra một số vấn đề, như chức năng mất an ninh được giới thiệu có chủ ý giống như các cửa hậu. Việc ghi chú tốt (kết hợp của làm tài liệu theo ngôn ngữ con người theo chủ đề trong bản thân mã nguồn) có thể giúp nhiều cho qui trình kiểm tra mã nguồn bằng con người, khi mà nó trao sự giám sát lớn hơn trong những gì mà mã nguồn định làm. Tài liệu bên ngoài mà chỉ định thiết kế và mục đích tổng thể của phần mềm cũng là cực kỳ hữu ích.

Liệu nguồn mở có ít an ninh hơn so với nguồn đóng hay không?

Khi chúng ta nói về 'mở so với đóng' về mã nguồn, sự khác biệt cơ bản chúng ta đang xác định là một khác biệt về cấp phép, như được nhắc trong phần trước. Tuy nhiên, các ngụ ý về tính sẵn sàng được cấp phép (hoặc không) của mã nguồn thường mở rộng trong dạng cộng đồng bao quanh một mẩu phần mềm, và dạng các hoạt động mà cộng đồng này cam kết tham gia vào.

Tính sẵn sàng của mã nguồn

Hệ quả trực tiếp của tính sẵn sàng mã nguồn nói chung chính xác là bất kỳ ai cũng có thể đọc được mã nguồn của bạn. Các lỗi trong mã nguồn của bạn vì thế sẽ dễ dàng phát hiện ra hơn, cả đối với những người muốn giúp cho phần mềm của bạn trở thành an ninh hơn và cả cho những người muốn khai thác những khiếm khuyết của nó. Sự xem xét theo số đông này thường tham chiếu tới như là nguyên tắc của 'nhiều con mắt', ngụ ý rằng tính sẵn sàng nói chung của mã nguồn sẽ dẫn tới sự giám sát và kiểm soát chất lượng tốt hơn.

Sửa đổi mã nguồn

Hệ quả trực tiếp khác của cấp phép nguồn mở - trao quyền để sửa đổi mã nguồn và phân phối các sửa đổi – có nghĩa là bất kỳ ai với kỹ năng đủ cũng có thể sửa các vấn đề với mã nguồn, và phân phối hoặc một bản vá (một mẩu nhỏ mã nguồn mà chỉnh sửa vấn đề đó) hoặc toàn bộ chương trình được sửa đổi và sửa chữa. Ngược lại, các lập trình viên xấu có thể đưa ra các lỗi an ninh vào trong phần mềm của bạn thông qua các bản vá hoặc phân phối các phiên bản mới, bị tổn thương. Theo mô hình nguồn đóng, những chỗ bị tổn thương không thể bị phát hiện bằng việc xem xét mã nguồn, khi mà nó không có sẵn. Tất nhiên, điều này không có nghĩa là phần mềm không có những chỗ bị tổn thương, chỉ ra nơi mà chúng tồn tại thì các bên bên ngoài phải phát hiện ra chúng thông qua các biện pháp không trực tiếp như làm mờ (xem ở trên). Một khi được phát hiện, các lỗi đó chỉ có thể được những người tạo ra ban đầu phần mềm đó sửa được, vì không ai khác có mã nguồn hay có quyền phân phối phần mềm hoặc các sửa đổi cho nó. Mô hình này thường được tham chiếu tới như là 'an ninh thông qua sự tù mù'.

Kích cỡ thị trường

Ngoài những khác biệt đó, các vấn đề an ninh thường giống cho cả sự phát triển của phần mềm đóng và nguồn mở. Mức độ mà ở đó một mẩu phần mềm được đưa ra được nhằm tới từ những kẻ khai thác thường được xác định không bằng chính sách cấp phép của nó mà bằng sự thâm nhập thị trường của nó. Microsoft, một nhà cung cấp nguồn đóng, đã có trong nhiều năm một uy tín về sự mất an ninh. Trong khi đã từng có nhiều chỗ bị tổn thương cao cấp bị phát hiện và bị khai thác trong các sản phẩm của Microsoft, thật cực kỳ khó để xác định liệu điều này có là vì phần mềm của nó đã bị lỗi đặc biệt hay được triển khai rộng rãi như thế hay không. Một lỗi trong một mẩu phần mềm phổ biến rõ ràng sẽ ảnh hưởng tới nhiều người hơn và vì thế lôi cuốn sự chú ý nhiều hơn. Bổ sung thêm, những người muốn khai thác phần mềm để giành được một cách bất hợp pháp các thông tin hoặc sự truy cập sẽ nhằm vào những nỗ lực của họ ở các phần mềm mà - khi bị tổn thương - sẽ trao cho họ số lượng lớn nhất các máy tính có tiềm năng khai thác được. So sánh với Microsoft, Apple, một nhà cung cấp nguồn đóng lớn khác, có một uy tín tốt về an ninh phần mềm, nhưng cũng có tỷ lệ nhỏ hơn nhiều trong thị trường. Trong sự có ưu thế hơn về phần mềm của họ hoặc hoặc liệu họ đơn giản là một nhà cung cấp nhỏ hơn và vì thế ít đáng giá nhằm vào đối với cuộc tấn công chăng? Đáng tiếc không có cách thức tin cậy nào biết được chắc chắn.

Trong ngữ cảnh đặc biệt này, PMNM là không khác gì so với phần mềm nguồn đóng. Các dự án thành công như máy chủ httpd của Apache và nhân Linux cam kết trong việc kiểm thử an ninh mạnh mẽ trước từng phiên bản vì chúng được triển khai rộng rãi. Các nhà cung cấp phần cứng lớn bán các máy tính với các mẩu phần mềm đó được cài đặt sẵn, và điều đó nằm trong những lợi ích của họ để đóng góp và hỗ trợ nỗ lực làm cho các phần mềm như vậy an ninh hơn. Các dự án nguồn mở nhỏ hơn với ít người sử dụng hơn vừa ít có khả năng có được các tài nguyên để thực hiện việc kiểm thử mạnh mẽ, và vừa ít có khả năng sẽ bị tấn công.

Kết luận

Trong phân tích cuối cùng, an ninh phần mềm phụ thuộc vào những người duy trì phần mềm đó trong quá trình phát triển và cài đặt. Khi áp dụng nguồn đóng, một tổ chức chọn tin cậy vào một nhà cung cấp duy nhất và ít có khả năng tham gia vào sự duy trì an ninh của riêng nó, dù là để tốt hơn hay xấu hơn. Tuy nhiên, khi áp dụng nguồn mở, một tổ chức có khả năng chọn nhà cung cấp phù hợp nhất và (bản dịch tiếng Việt), ở những nơi tài nguyên cho phép, cam kết tham gia với các qui trình an ninh của riêng mình. Có nhiều ví dụ an ninh cao độ sử dụng cả phần mềm nguồn mở và nguồn đóng và chúng tôi tin tưởng không có câu trả lời duy nhất cho câu hỏi cái nào an ninh hơn.

This briefing note is intended to answer questions that those new to open source software may have about its security. We first identify the chief ways in which software can be insecure, then we discuss general approaches to mitigating software insecurity, and the final section compares closed and open source development methodologies in the light of the information from the preceding sections.

Source code and object code

By definition, open source software is software for which the source code is available to anyone. Source code can be thought of as a kind of blueprint for the software, a form that is ideal for gaining understanding of how a program works or modifying its design. A program’s source code is in many cases processed by another program called a ‘compiler’, which creates the actual file that runs on an end-user’s computer. This file is called the object code (or executable), and it is this that an end-user receives when buying traditional proprietary, closed-source software like Microsoft Word. In comparison to its source code, the object code of a program is very difficult for a human being to comprehend or modify. Thus, open source software can be said to invite and facilitate modification, while closed source software tends not to. These technical characteristics are also generally carried through into the accompanying licences: open source licences permit modification and redistribution by the user, while closed source end-user licence agreements tend to contractually bind the user to refrain from modifying or redistributing the software that they cover.

In what ways can software be insecure?

A piece of software will generally be written to fulfil a specific task. In order to perform this task, the software will be permitted to perform certain actions by the computer’s core software (known as the kernel), such as writing files to the hard drive or starting other programs. In most current models of computer, the program itself is responsible for ensuring that these permitted actions only take place in the intended manner, for the purposes envisaged by its design and function. However, it is notoriously difficult to write software that will always operate in the intended manner. Most software has to process data from external sources that are outside its control, such as user input at the keyboard or data received over a network. It is in these external interactions that the vast majority of security flaws are exposed.

Errors in program design

Let’s look at an example of such a security flaw: when accepting input from an external source it is customary to define how many characters will be processed, and to prepare a space or ‘buffer’ in computer memory to receive these prior to processing them. It is generally the responsibility of the programmer to check that the buffer is not over-filled (or ‘overrun’) or loaded with inappropriate or corrupt data. Where the buffer is over-filled, data can end up being written into a piece of memory that was never intended to receive it, possibly a piece of memory containing the program itself. Where such a buffer overrun does take place, the result can be complete failure of the program. When the program itself is partially overwritten by the over-large input, this can be exploited by a malicious person to replace the program’s code, and thus gain control of a running process on the computer. Similarly, data that is corrupt or malformed can compromise a program’s operation if it is not rejected, and some deliberately malformed input may, if undetected, result in a software failure that compromises the computer’s security.

Security configuration

Even if a piece of software is not insecure as a result of an error by the initial programmers, it can often be rendered insecure by being set up incorrectly. The tailoring of a piece of software to a system where it will run, often referred to as ‘configuration’, allows great scope for error. The process of configuration will often involve the setting of a security policy for the software’s operation, defining for example which users can and cannot use it, and which other computers on a network may connect to it. Sometimes a piece of software will be distributed with a default configuration that is ‘wide open’ - in the sense that it allows anyone to access it - and inexperienced system administrators may fail to detect and refine this open-door policy. To compound the problem it can be tempting to leave a security configuration more open than strictly necessary, as this generally results in fewer complaints of rejected connections or failed authorisations from users.

‘Trojan’ software

While many security problems result from unintended flaws or misconfigurations, some problems are fully intended. Software can be designed to hand over control to unauthorised third parties, or to perform unadvertised and possibly damaging functions. These so-called ‘Trojan’ or ‘Backdoor’ software programs form another component of computer insecurity. Such programs can be inserted into a system in a number of ways. An authorised user may unintentionally trigger their installation via an infected email or altered install package. A malicious user might install them on purpose. Security flaws like the ones described above might permit an unauthorised user to replace legitimate software with a ‘trojanned’ replacement, thus perpetuating their access to the system.

Perfect security?

Complete security is, therefore, extremely difficult to achieve, and it is widely accepted that software security flaws are an uncomfortable fact of life, at least in the world of general-use computing. Modern software - both open and closed source - is constructed by teams of programmers, sometimes incorporating pieces of software from external sources, and much of its eventual functionality and security will be determined by its configuration by administrators on-site. Ensuring the complete competence and good faith of this chain of people presents a difficult challenge. Software security has spawned a large industry of specialists in identifying security flaws. The legitimate portion of this industry is the most visible, and comprises software security consultants who will identify flaws and work with software developers to repair them. Perhaps more worrying is the invisible portion, who identify flaws and sell information about them to anyone with money and an interest in gaining unauthorised access to the information and computing resources of others.

What approaches exist to help ensure software security?

For errors in program design, there are tools to help identify and rectify the problem. Failures to properly check input can - to a certain extent - be identified by analysing the program’s source code using software designed to flag oversights. Programmers themselves can develop suites of tools that will test the desired functionality of their software in an automated way, and build these tools into a quality assurance package. Other tools exist to expose the resulting software’s executable code to random input while measuring the effect on the software. This process, known as ‘fuzzing’, is very effective at identifying cases in which software fails. Of course, as a tool for identifying potentially exploitable software failures, it is also very useful to people seeking unauthorised access. Once installed, the configuration of software can also be checked by tools such as port-scanners, which test the availability of the software’s funtionality to external entities.

In addition to automated oversight, human oversight is a crucial element in detecting security flaws. Inspection of source code by competent programmers can be the only way to show up some problems, such as deliberately introduced insecure functionality like backdoors. Good commenting (incorporation of topical human-language documentation into the source code itself) can greatly aid the process of human source-code checking, as it gives greater insight into what the code is intended to do. External documentation that specifies the software’s overall design and purpose is also extremely helpful.

Is open source less secure than closed source?

When we talk about ‘open vs closed’ in terms of source code, the essential difference we are identifying is one of licensing, as mentioned in the first section. However, the implications of the licensed availability (or not) of source code often extend into the type of community that surrounds a piece of software, and the kind of activities this community engages in.

Availability of source code

The most direct consequence of general source code availability is precisely that anyone can read your code. Errors in your code are thus going to be more easily discoverable, both by those who wish to help your software become more secure and those who wish to exploit its weaknesses. This mass-examination is often referred to as the principle of ‘many eyes’, implying that general availability of source code will lead to greater oversight and quality control.

Modifying source code

Another direct consequence of open source licensing - the granting of the right to modify the code and distribute modifications - means that anyone with sufficient skill can also fix problems with your code, and distribute either a patch (a small piece of code that rectifies the problem) or the entire modified and repaired program. Conversely, malicious coders could introduce security flaws into your software via patches or the distribution of new, compromised versions. In the closed source model, vulnerabilities cannot be discovered by examining source code, as it is not available. This does not, of course, mean that the software has no vulnerabilities, merely that where they exist external parties must discover them through more indirect means such as fuzzing (see above). Once discovered, these flaws can only be repaired by the software’s originators, as no-one else has either the source code or the right to distribute the software or modifications to it. This latter model is often referred to as ‘security through obscurity’.

Market size

These distinctions aside, the problems of security are generally alike for closed and open source software development. The extent to which a given piece of software is targeted by potential exploiters is generally determined not by its licensing policy but by its market penetration. Microsoft, a closed source vendor, had for many years, a reputation for insecurity . While there have been many high-profile vulnerabilities discovered and exploited in Microsoft products, it is extremely difficult to determine whether this is because its software was peculiarly flawed or so widely deployed. A flaw in a popular piece of software will clearly affect more users and thus attract more attention. In addition, those who wish to exploit software to unlawfully gain information or access will target their efforts at the software that - when compromised - will give them the greatest number of potentially exploitable computers. In comparison to Microsoft, Apple, another largely closed source vendor, has a good reputation for software security, but also a far smaller proportion of the market. Is their software superior or are they simply a smaller and therefore less worthwhile target for attack? Unfortunately there is no reliable way of knowing for sure.

In this particular context, open source software is no different from closed source software. Successful projects such as the Apache httpd server and the Linux kernel engage in rigorous security testing before each release because they are widely deployed. Large hardware vendors sell computers with these pieces of software pre-installed, and it is in their interests to contribute to and support the effort to make such software more secure. Smaller open source projects with fewer users are both less likely to have the resources to do rigorous testing, and less likely to be attacked.

Conclusion

In the final analysis, the security of software depends upon the maintainers of that software during development and during installation. When adopting closed source, an organisation chooses to trust a single supplier and is less able to participate in the maintenance of its own security, for better or worse. However, when adopting open source, one is able to select the most appropriate supplier and, where resources allow, to engage with one’s own security processes. There are many examples of highly secure uses of both open and closed software and we believe there is no single answer to the question of which is more secure.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com