Taking FOSS Security Seriously
By Jack M. Germain
LinuxInsider
08/07/09 4:00 AM PT
08/07/09 4:00 AM PT
Bài được đưa lên Internet ngày: 07/08/2009
Lời người dịch: Người ta vẫn cứ tranh cãi mãi không dứt về việc phần mềm nguồn mở hay sở hữu độc quyền thì an ninh hơn. Trong số vô vàn các lời giải thích, có một cái như sau: “Một lập trình viên nguồn mở giống như một nhà điêu khắc mà được thuê để tạo ra một bức tượng để được đặt ở giữa thành phố. Vì ai cũng nhìn thấy nó, nên nó cần phải là thứ gì đó mà anh hoặc chị ta có thể tự hào về nó. Quan điểm này về chất lượng mã nguồn làm giảm những chỗ có thể bị tổn thương đầy tràn theo truyền thống một cách đột ngột”. Có lẽ, điểm mấu chốt là nằm ở tính mở nên nhiều con mắt lúc nào cũng có thể soi để làm cho phần mềm nguồn mở sáng hơn chăng?
Các lập trình viên của các dự án phần mềm nguồn mở cũng phải quan tâm tới an ninh như bất kỳ ai phát triển một ứng dụng sở hữu độc quyền. Tuy nhiên, bản chất tự nhiên của 2 quá trình phát triển này có thể rất khác nhau ở thời gian, và tranh luận vẫn dữ dội về cái nào vốn là an ninh hơn – một mã nguồn bí mật được giữ bởi một công ty, hay một mã nguồn công khai mà tất cả mọi con mắt có thể thấy. Chỉ quan trọng là cách mà mỗi cộng đồng phản ứng một khi có vấn đề xảy ra.
Những người săn lùng đang chủ tâm vào với tần suất lớn hơn đối với việc lập trình có lỗi mà có thể mở ra các lỗ hổng về an ninh trong các phần mềm tự do nguồn mở (FOSS).
Báo cáo Nguồn Mở 2008 và Báo cáo Thư viện Kiến trúc, được thực hiện bởi Coverity cho Dự Án Tăng cường Nguồn mở cho An ninh Không gian mạng của Bộ An ninh Quốc nội Mỹ, chỉ ra hơn 10,000 lỗi được sửa kể từ khi dự án này được khởi động vào tháng 03/2006.
Báo cáo này, được phân phối vào tháng 07 tại OSCON 2009 (Hội nghị Nguồn mở) tập hợp, được sử dụng cùng các công cụ phân tích và cấu trúc khuôn dạng như Scan Benchmark 2006. Những kết quả dựa trên các phân tích của hơn 55 triệu dòng mã lệnh từ hơn 250 dự án nguồn mở mà chúng đại diện cho 14,238 phân tích dự án riêng rẽ độc lập cùng chạy. Tổng cộng tất cả, gần 10 triệu dòng mã lệnh đã được phân tích.
Bằng những đường thực thi mã nguồn có thể hiểu được, các lỗi sẽ được xác định và được hạn chế bởi các lập trình viên nguồn mở, theo tác giả của báo cáo, David Maxwell, Nhà chiến lược Nguồn mở cho Coverity. Sự phân tích mã nguồn đã sử dụng Coverity Prevent, một công cụ phân tích mã nguồn tĩnh mà nó đưa ra các mô phỏng đường, phân tích dòng chảy của dữ liệu và việc lược tỉa đường lỗi.
“Đây là trách nhiệm của mỗi người mà làm việc trong hệ thống phần mềm để điều tra việc thử nghiệm và các vấn đề về an ninh. Mọi người với một trí tuệ của các kỹ sư muốn phân rã vấn đề an ninh. An ninh là một vấn đề vật lý về mặt bản chất tự nhiên. Bạn phải phân tích toàn bộ sự việc”, Maxwell nói với LinuxInsider.
Developers of open source software projects should be just as concerned about security as anyone developing a proprietary app. However, the nature of the two development processes can be very different at times, and debate still rages about which is inherently more secure -- a secret code kept by a company, or a public one that all eyes can see. Just as important is how each community reacts once a problem is spotted.
Code hunters are spotting with greater frequency defective coding that could open security holes in free and open source (FOSS) software.
The Open Source Report 2008 and the Architecture Library Report, conducted by Coverity for the U.S. Department Homeland Security Cybersecurity Open Source Hardening Project, shows more than 10,000 defects fixed since project launch in March 2006.
The report, delivered in July at the OSCON 2009 (Open source Convention) gathering, used the same analysis tools and configurations as the Scan Benchmark 2006. The results are based on analysis of over 55 million lines of code from more than 250 open source projects that represent 14,238 individual project analysis runs. All totaled, nearly 10 billion lines of code were analyzed.
By understanding possible code execution paths, defects are identified and eliminated by open source developers, according to the report's author, David Maxwell, Open Source Strategist for Coverity. The code analysis used Coverity Prevent, a static code analysis tool that delivers path simulation, data flow analysis and false path pruning.
"It is the responsibility of everyone who works in software system to investigate testing and security issues. People with an engineer's mindset want to break down security. Security is a physical problem by nature. You have to analyze the whole thing," Maxwell told LinuxInsider.
Về tổng thể, những người kiểm lỗi cho mã nguồn mà tìm ra được mật độ ở vào 16% trong 2 năm vừa qua. Mật độ lỗi là số lượng các lỗi cho 1,000 dòng mã lệnh. Ví dụ, một mật độ lỗi 1.0 nghĩa là một lỗi trong 1,000 dòng mã lệnh. Một mật độ 0.5 có nghĩa là một lỗi trong 2,000 dòng mã lệnh.
Nhiều cho tơi 314 lỗi đã được tìm ra trong một cơ sở mã nguồn cụ thể. Lỗi mã nguồn y như vậy có thường xảy ra hay không sẽ có liên quan trực tiếp tới tần suất của dạng vận hành mà mã nguồn đó chạy. Ví dụ, Sự tôn trọng Con trỏ KHÔNG (NULL Pointer Deference) đã được theo dõi trong 6,448 trường hợp cho 27,95% tần suất. Một sự rò rỉ tài nguyên đã xảy ra trong 5,852 lỗi cho một tần suất 25,73%.
Lỗi tích cực có liên quan tới một số phần trăm nhỏ hợp lý của các kết quả. Hiện hành, lỗi tích cực là dưới 14%.
Việc xem xét về an ninh là khác nhau
Không có bất kỳ ai có liên quan trong việc xây dựng phần mềm cân đo được yếu tố an ninh với cùng mật độ. Trên thực tế, thực sự có một loạt cách mà an ninh nghiêm túc được thừa nhận, theo Maxwell.
Ví dụ, một số lãnh đạo dựa án hạn chế việc truy cập tới chỉ các nhân viên an ninh. Những người khác có một quá trình xem xét lại rộng mở. Một số dự án sử dụng những bài thử khổng lồ về phần mềm trước khi tung nó ra, ông giải thích.
“Khi làm việc với các dự án nguồn mở, một số vấn đề về an ninh là mẫu tự do quản lý. Những dựa án khác lại dựa trên việc duy trì một uy tín cộng đồng được xây dựng lên”, Maxwell nói.
Overall, code testers found that defect density dropped 16 percent over the past two years. Defect density is the number of defects per 1,000 lines of code. For example, a defect density of 1.0 means one defect in 1,000 lines of code. A defect density of 0.5 means one defect in 2,000 lines of code.
As many as 314 defects were found in one particular code base. How often the same code defect occurs may be directly related to the frequency of the type of operations the code runs. For example, a NULL Pointer Deference was tracked in 6,448 incidents for 27.95 percent frequency. A resource leak occurred in 5,852 defects for a frequency of 25.73 percent.
False positives involved a reasonably small percentage of the results. Currently, false positives are below 14 percent.
Security View Varied
Not everyone involved in building software weighs security factors with the same intensity. In fact, there is quite a variety of how seriously security is received, according to Maxwell.
For instance, some project leaders restrict access to security staff only. Others have a wide-open review process. Some projects use huge tests of the software before releasing, he explained.
"When dealing with open source projects, some security issues are handled free-form. Others are based on maintaining a built-up community reputation," said Maxwell.
Các tiêu chuẩn hay thay đổi
Để phát hiện ra mã nguồn có lỗi mà có thể dẫn tới các vấn đề an ninh, những người kiểm tra mã nguồn đó phải có mục đích tìm kiếm một vấn đề. Nhiều thứ tương tự trong an ninh tồn tại với cả các sản phẩm phần mềm nguồn mở và sở hữu độc quyền.
Các kỹ sư mà đi theo một tập hợp các tiêu chuẩn trong ngày làm việc của họ đối với các hãng sở hữu độc quyền có thể theo cùng các nguyên lý đó vào buổi tối khi phát triển các phần mềm của riêng họ. Sự khác biệt chủ yếu phát sinh từ trường hợp người quản lý mà phải tuân theo một tập hợp mà công ty đặt ra, Maxwell nói.
“Lý thuyết 'nhiều con mắt hơn' thường đúng. Nhiều người hơn có thể tham gia, nhưng không phải tất cả đều làm nó. Cần đủ người với một mức độ quan tâm nào đó để tìm kiếm những sai sót về an ninh”, Maxwell nói.
Khoá kiểm lỗi chăng?
Vấn đề về an ninh của phần mềm hiện diện trên cả 2 phía của công nghiệp phần mềm – sở hữu độc quyền và nguồn mở.
Tuy nhiên, số lượng việc kiểm thử được hoàn tất và ai làm nó có xu hướng rõ ràng hơn trong cộng đồng nguồn mở.
“[Việc kiểm lỗi] rõ ràng là sống còn, và tầm quan trọng ngày một gia tăng. Những gì đã thay đổi là việc kiểm thử được sử dụng sẽ hầu hết là khu vực chuyên biệt của những người kiểm thử mà, theo định nghĩa, sẽ không gần gũi với mã nguồn đó. Bây giờ, các lập trình viên được thấy sẽ có trách nhiệm ngang nhau về an ninh và được mong đợi thuyết phục được sự thẩm định nghiêm khắc về mã nguồn của họ trước khi nó có thể được đưa ra cho một nhóm thử nghiệm. Đó là một sự chuyển biến tiến hoá lớn cho nhiều đội phát triển, nhưng dứt khoát là một thay đổi lành mạnh ở nơi mà an ninh trở nên là một trách nhiệm của tổ chức và không chỉ có tầm ảnh hưởng đối với đội kiểm thử”, Gwyn Fisher, CTO của Klocwork, đã nói với LinuxInsider. Klocwork phát triển công nghệ phân tích mã nguồn tĩnh được sử dụng bởi các lập trình viên phần mềm và các tổ chức đảm bảo chất lượng (QA).
Kiểm thử an ninh phải không là tiếp cận duy nhất để có được việc viết mã nguồn tốt hơn. Trên thực tế, việc kiểm thử mã nguồn sẽ không xảy ra các kỹ thuật thiết kế tốt tập trung vào an ninh, Dave Robert, phó chủ tịch về chiến lược cho Vyatta, lưu ý. Hãng này phát triển bộ định tuyến nguồn mở và các sản phẩm về an ninh.
“Dễ dàng hơn để thiết kế phần mềm an ninh hơn bằng việc sử dụng một phương pháp thiết kế tốt hơn so với việc phải tránh nghĩ về an ninh trước và cố tìm các vấn đề thông qua kiểm thử. Có một loạt các thư viện và công vụ sử dụng thông thường mà làm dễ dàng hơn cho các lập trình viên để viết phần mềm an ninh từ đầu và tránh các vấn đề cùng một lúc. Tuy nhiên, những thư viện và công cụ này không là tuyệt vời, và vì thế bạn vẫn cần tìm kiếm các vấn đề khó thấy một khi phần mềm đã hoàn thiện, nhưng chúng phải tránh những sai lầm hiển nhiên”, Roberts nói với LinuxInsider.
Fluid Standards
In order to spot defective code that can lead to security issues, those checking the code have to be intent on finding a problem. Many similarities in security exist with both open source and proprietary software products.
Engineers who follow one set of standards during their day jobs for proprietary firms might follow those same principles at night while developing their own software. The major difference stems from the case manager who has to follow a set company line, said Maxwell.
"The 'more eyes' theory is often valid. More people can participate, but not all do it. There needs to be enough people with a level of interest to look for security flaws," said Maxwell.
Testing Key?
The issue of software security is present on both sides of the software industry -- proprietary and open source. However, the amount of testing done and who does it tends to be more manifest in the open source community.
"[Testing's] obviously critical, and it's growing in importance. What's changed is that testing used to be almost exclusively the domain of testers who, by definition, aren't that close to the code. Now, developers are seen to have equal responsibility for security and are expected to pursue rigorous verification of their code before it's ever given to a test team. That's a big paradigm shift for many development teams, but definitely a healthy change where security becomes an organizational responsibility and not just the purview of the test team," Gwyn Fisher, CTO of Klocwork, told LinuxInsider. Klocwork develops static code analysis technology used by software developers and quality assurance (QA) organizations
Security testing should not be the sole approach to getting better code writing. In fact, security testing should not take the place of good security-focused design techniques, noted Dave Roberts, vice president of strategy for Vyatta. The company develops open source router and security products.
"It's easier to design more secure software using a better design methodology than it is to avoid thinking about security up front and try to find problems through testing. There are a variety of libraries and tools in common use that make it easier for developers to write secure software from the start and avoid issues altogether. The libraries and tools are not perfect, however, and so you still need to look for subtle problems once the software is complete, but they do avoid the blatant gaffes," Roberts told LinuxInsider.
Những quả táo đối nghịch với những quả cam chăng?
Các chuyên gia an ninh vẫn còn cãi nhau về việc liệu mã nguồn của nguồn mở hay sở hữu độc quyền là an ninh hơn. Câu trả lời phụ thuộc vào một số công việc ước đoán, cũng như ước lượng về sự nóng bỏng manh màu sắc tôn giáo.
“Câu trả lời chân thành là việc không ai biết, và nếu ai đó nói bạn khác đi, họ chỉ phỏng đoán. Đã từng có một số nghiên cứu mà mong muốn đặc tả một thứ an ninh hơn thứ kia. Nhưng hầu hết những thứ đó được cung cấp bởi các nhà cung cấp về an ninh với một nghị trình”, Fisher đã gợi ý.
Tất nhiên, an ninh là quan trọng cho cả phần mềm nguồn mở và sở hữu độc quyền. Nhưng với phần mềm sở hữu độc quyền, có thể ít hơn sự kiểm soát vì mọi người có thể phải chịu trách nhiệm, Mandeep Khera, CMO cho nhà cung cấp về an ninh cho ứng dụng Web Cenzic, nói.
“Bạn cũng có thể cung cấp việc đào tạo về an ninh cho các lập trình viên của bạn, nhưng đối với nguồn mở, đây là một trò chơi hoang dã. Bạn phải rất cẩn thận”, Khera đã nói cho LinuxInsider.
Tuy nhiên, lý co nhiều mắt soi mã nguồn mang tầm ảnh hưởng đáng kể trong sự tranh cãi. Nguồn mở sản xuất ra nhiều phần mềm an ninh hơn so với sự phát triển sở hữu độc quyền, Chander Kant, CEO của Zmanda, nói. Zmanda là một lập trình viên phần mềm sao lưu và phục hồi nguồn mở.
“Thực tế rằng bất kỳ vấn đề an ninh nào cũng có thể được xem bởi hàng ngàn con mắt, trong thực tế, làm cho nó dễ dàng tìm mra và sửa các vấn đề về an ninh. Nếu bạn có phần mềm sở hữu độc quyền, chỉ vì chỗ có thể bị tổn thương về an ninh có thể không được nhìn thấy trong sự mở sẽ không làm cho mã nguồn an ninh hơn”, Kant đã nói với LinuxInsider.
Apples Vs. Oranges?
Security experts still bicker over whether open source or proprietary code is more secure. The answer depends on some guess work, as well as a measure of religious fervor.
"The honest answer is that nobody knows, and if anybody tells you otherwise, they're just guessing. There have been some studies that attempt to characterize one being more secure than another. But most of those are provided by security vendors with an agenda," suggested Fisher.
Of course, security is important for both open source and proprietary software. But with proprietary software, there may be a little more control because people can be held accountable, noted Mandeep Khera, CMO for Web application security vendor Cenzic.
"You can also provide security training for your developers, but for open source, it's a wild game. You have to be extra careful," Khera told LinuxInsider.
However, the more-eyes-on-the-code reasoning carries considerable influence in the debate. Open source produces more secure software than proprietary development, proffers Chander Kant, the CEO of Zmanda. Zmanda is an open source backup and recovery software developer.
"The fact that any security issue can be seen by thousands of eyes, in fact, makes it easy to find and fix security issues. If you got proprietary software, just because the security vulnerability may not be seen in the open doesn't make the code more secure," Kant told LinuxInsider.
Câu hỏi sai
Việc hỏi các chuyên gia về an ninh để tranh cãi giá trị của an ninh giữa các chủng loại có lẽ là lạc lối. Trên thực tế, Roberts nghĩ việc hỏi cái nào là an ninh hơn là câu hỏi sai, chấm hết. Một câu hỏi tốt hơn sẽ hỏi, ông nói, là cộng đồng quản lý mọi thứ như thế nào một khi một vấn đề được phát hiện. Trên một điểm đó bạn sẽ thấy một sự khách biệt lớn giữa cộng đồng nguồn mở và các công ty sở hữu độc quyền.
“Không có lý do để nghĩ rằng hoặc phần mềm nguồn mở hoặc phần mềm sở hữu độc quyền cái này là tốt hơn cái kia khi liên quan tới quá trình phát triển cơ bản. Trong khi mọi người thích động vào các vấn đề về an ninh của Microsoft ở phía những thứ sở hữu độc quyền, thực tế là việc các lập trình viên có hiểu biết giống như một đường cong của quả chuông. Các lập trình viên làm việc về nguồn mở là không thông minh hơn, nói chung, so với các lập trình viên của sở hữu độc quyền, và cả 2 tập hợp các lập trình viên sẽ giới thiệu những sai sót về an ninh không được mong đợi trong các cơ sở mã nguồn tương ứng”, Roberts nói.
Câu chuyện khác biệt
Tiêu chí phân biệt đầu tiên giữa các phần mềm sở hữu độc quyền và nguồn mở là cam kết của thứ sau (phần mềm nguồn mở) đối với việc tìm kiếm, việc sửa lỗi và việc thảo luận các vấn đề về an ninh với cơ sở những người sử dụng của mình, Roberts nói. Có một ý nghĩa rằng không có gì để dấu. Các vấn đề xảy ra, bạn sửa chúng, bạn làm cho những người sử dụng nhận thức được rằng một sự sửa lỗi tồn tại, và sau đó bạn đi tiếp, ông nói. Không như thế đối với mã nguồn của sở hữu độc quyền.
“Thư y như vậy không thể được nói về các nhà sản xuất phần mềm sở hữu độc quyền, nói chung. Trong khi các công ty sở hữu độc quyền đang thấy rằng họ phải làm tốt hơn với các vấn đề về an ninh, thì có nhiều trường hợp chúng ta đã thấy những nơi mà các công ty này sẽ chờ đợi hàng tháng trời sau một sự khai thác được họ chú ý tới để phát triển và sửa lỗi đầy đủ”, ông nói.
Khác với thứ đó, chủ đề về phần mềm nào là an ninh hơn là đủ thường xảy ra để bắt đầu một viện lý hoàn toàn nóng bỏng, Sampo Nurmentaus, giám đốc kỹ thuật tại Movial, đồng ý. Hãng này phát triển các thiết bị di động dựa trên Linux.
Với ông, tính mở của nguồn mở dẫn tới việc phần mềm tốt hơn và an ninh hơn. Các lập trình viên nguồn mở có một quan điểm khác hoàn toàn đối với mã nguồn của chương trình.
“Một lập trình viên nguồn mở giống như một nhà điêu khắc mà được thuê để tạo ra một bức tượng để được đặt ở giữa thành phố. Vì ai cũng nhìn thấy nó, nên nó cần phải là thứ gì đó mà anh hoặc chị ta có thể tự hào về nó. Quan điểm này về chất lượng mã nguồn làm giảm những chỗ có thể bị tổn thương đầy tràn theo truyền thống một cách đột ngột”, Nurmentaus đã nói với LinuxInsider.
Wrong Question
Asking security experts to debate the merits of security between the species may be missing the point. In fact, Roberts thinks asking which one is more secure is the wrong question, period. A better question to ask, he said, is how the community handles things once a problem is discovered. On that one point you see a big difference between the open source community and proprietary companies.
"There is no reason to think that either open source software or proprietary software is better than the other when it comes to the fundamental development process. While everybody likes to pick on Microsoft's (Nasdaq: MSFT) security problems on the proprietary side of things, the reality is that developers have intellects that look like a bell curve. The developers working on open source are no smarter, on average, than the proprietary developers, and both sets of developers will introduce unintended security flaws into the respective code bases," said Roberts.
Tell-Tale Difference
The primary distinguishing criteria between proprietary and open source software is the latter's commitment to finding, fixing and discussing security issues with its user base, Roberts said. There is a sense that there is nothing to hide. Problems happen, you fix them, you make users aware that a fix exists, and then you move on, he said. Not so for proprietary code.
"The same thing can't be said of proprietary software manufacturers, on average. While proprietary companies are finding that they must get better about dealing with security issues, there are many cases we have seen where the companies will wait months after an exploit is brought to their attention to develop and adequate fix," he said.
Other than that, the topic of which software flavor is more secure is oftentimes enough to start quite a heated argument, agreed Sampo Nurmentaus, technical director at Movial. The company develops Linux-based mobile devices.
For him, the openness of open source leads to better, more secure software. Open source developers have a totally different attitude toward the program code.
"An open source developer is like a sculptor that is hired to create a statue to be placed the middle of the city. Since everybody will see it, it needs to be something he or she can be proud of. This attitude toward code quality reduces the traditional overflow vulnerabilities dramatically," Nurmentaus told LinuxInsider.
Dịch tài liệu: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.