Ngăn ngừa vụ Heartbleed tiếp sau và làm cho FOSS an toàn hơn

Preventing the next Heartbleed and making FOSS more secure

Posted 22 Jul 2016 by Mark Bohannon

Theo: https://opensource.com/life/16/7/interview-david-wheeler-making-foss-more-secure

Bài được đưa lên Internet ngày: 22/07/2016

 

Lời người dịch: Bài viết này trước hết dành cho bất kỳ ai, bất kỳ công ty phần mềm nguồn mở nào muốn làm việc được trong môi trường CNTT chính phủ. Nó cũng dành cho bất kỳ quan chức chính phủ nào có trách nhiệm về mua sắm phần mềm và/hoặc ra các chính sách về phần mềm của quốc gia để hiểu về các vấn đề có liên quan tới phần mềm nguồn mở.

 

David Wheeler là lãnh đạo lâu năm trong việc tư vấn và làm việc với chính phủ Mỹ về các vấn đề có liên quan tới phần mềm nguồn mở (PMNM). Trang web của cá nhân ông thường xuyên trích dẫn nguồn về các tiêu chuẩn mở, PMNM, và an toàn máy tính. David đang lãnh đạo một dự án mới, dự án Huy hiệu Thực hành Tốt nhất CII, nó là một phần của Sáng kiến Hạ tầng Cốt lõi - CII (Core Infrastructure Initiative) của Quỹ Linux Foundation cho việc thúc đẩy an toàn các PMNM. Trong phỏng vấn này ông nói về điều này ngụ ý gì cho cả chính phủ và những người sử dụng khác.

Hỏi và Đáp

Hãy bắt đầu với vài điều cơ bản. Dự án huy hiệu là gì và nó đã ra đời như thế nào?

Vào năm 2014, chỗ bị tổn thương Heartbleed đã được thấy trong OpenSSL, thư viện mật mã. Đáp lại, Quỹ Linux Foundation đã tạo ra Sáng kiến Hạ tầng Cốt lõi (CII) để cấp vốn và hỗ trợ cho PMNM mà chúng là các yếu tố sống còn của hạ tầng thông tin toàn cầu. CII đã nhận diện và cấp vốn cho các dự án quan trọng nhất định, nhưng nó không thể cấp vốn cho tất cả các dự án PMNM. Vì thế, CII cũng đang cấp vốn cho một vài tiếp cận để cải thiện chung an toàn của PMNM.

Dự án mới nhất CII tập trung vào việc cải thiện sự an toàn nói chung, là dự án được gắn huy hiệu các thực tiễn tốt nhất. Tôi là lãnh đạo kỹ thuật của dự án này. Chúng tôi nghĩa rằng các dự án PMNM tuân theo các thực tiễn tốt nhất có khả năng nhiều hơn là lành mạnh và để tạo ra phần mềm tốt hơn, bao gồm cả việc có sự an toàn tốt hơn. Nhưng điều đó đòi hỏi là mọi người biết những thực tiễn tốt nhất đó là gì, và liệu có hay không một dự án được đưa ra là tuân theo chúng.

Để giải quyết điều này, chúng tôi trước hết đã xem xét nhiều tài liệu và dự án PMNM để nhận diện được tập hợp các thực tiễn tốt nhất về PMNM được thừa nhận rộng rãi. Chúng tôi sau đó đã phát triển một website nơi mà các dự án PMNM có thể báo cáo liệu có hay không chúng áp dụng các thực tiễn tốt nhất đó. Trong một số trường hợp chúng tôi có thể xem xét website dự án và tự động điền vào vài thông tin. Chúng tôi sử dụng thông tin đó (dù tự động hay không) để xác định liệu dự án đó có tuân thủ đúng các thực tiễn tốt nhất hay không. Nếu dự án đó đang tuân thủ đúng các thực tiễn tốt nhất, thì dự án đó nhận được một huy hiệu “qua được kiểm tra”.

Tôi sẽ lưu ý ở đây rằng dự án gắn huy hiệu bản thân nó là một dự án PMNM. thấy Bạn có thể site của dự án đó. Chúng tôi muốn có thậm chí nhiều sự tham gia hơn, nên hãy ra nhập với chúng tôi! Để trả lời cho câuhỏi rõ ràng, vâng, nó giành được huy hiệu của riêng nó. Các dự án PMNM khác mà đã giành được huy hhiệu bao gồm nhân Linux, curl, Node.js, GitLab, OpenBlox, OpenSSL, và Zephyr. Ngược lại, OpenSSL trước khi có Heartbleed đã không qua được nhiều tiêu chí, gợi ý rằng các tiêu chí đang nắm bắt được các yếu tố quan trọng về các dự án.

Nếu bạn tham gia trong một dự án PMNM, tôi khuyến khích bạn có một huy hiệu. Nếu bạn đang nghĩ về việc sử dụng một dự án PMNM, tôi khuyến khích bạn xem liệu dự án đó có huy hiệu hay không. Bạn có thể thấy nhiều thông tin hơn ở Chương trình Huy hiệu các Thực hành Tốt nhất CII.

Bạn có thể nói cho tôi nhiều hơn về các tiêu chí của huy hiệu?

Chắc rồi. Tất nhiên, không tập hợp các thực tiễn nào có thể đảm bảo rằng các phần mềm sẽ không bao giờ có lỗi hoặc chỗ bị tổn thương. Nhưng vài thực tiễn khuyến khích sự phát triển tốt, điều tới lượt nó làm gia tăng khả năng có chất lượng tốt, và đó là những gì chúng tôi hướng tới.

Để tạo ra các tiêu chí chúng tôi đã rà soát lại nhiều tài liệu về các dự án nào nên làm; nguồn có ảnh hưởng nhiều nhất và duy nhất, có lẽ là cuốn sách của Karl Fogel: Sản xuất PMNM (Producing Open Source Software). Chúng tôi cũng đã xem một số dự án thành công đang tồn tại. Chúng tôi cũng nhận được các chỉ trích rất hữu ích bản phác thảo các tiêu chí từ nhiều người, bao gồm cả Karl Fogel, Greg Kroah-Hartman (dự án nhân Linux), Rich Salz (OpenSSL), và Daniel Stenberg (curl).

Một khi các tiêu chí ban đầu đã được xác định, chúng đã được nhóm thành các tiêu chí sau: cơ bản, kiểm soát thay đổi, báo cáo, chất lượng, an toàn, và phân tích (basics, change control, reporting, quality, security, and analysis). Chúng tôi kết thúc với 66 tiêu chí. Mỗi tiêu chí có một mã nhận diện và văn bản. Ví dụ, tiêu chí floss_license đòi hỏi rằng, “phần mềm PHẢI được phát hành như là phần mềm tự do nguồn mở (PMTDNM)”. Tiêu chí know_common_errors đòi hỏi rằng, “Ít nhất một trong các lập trình viên ban đầu PHẢI biết các dạng lỗi chung dẫn tới các chỗ bị tổn thương ở dạng này của phần mềm, cũng như ít nhất một phương pháp được tính tới hoặc làm giảm nhẹ từng trong số chúng”. Các tiêu chí là có sẵn trên trực tuyến, và một bài báo trên LWN.net thảo luận về các tiêu chí đó chi tiết hơn. Chỉ cần bỏ ra khoảng 1 giờ đồng hồ đối với một dự án điển hình PMNM để điền vào mẫu, một phần vì chúng tôi tự động điền vào vài thông tin. Nhiều trợ giúp hơn trong việc tự động hóa này được đánh giá cao.

Các tiêu chí sẽ thay đổi chậm, có lẽ theo hàng năm, khi dự án gắn huy hiệu có được nhiều hơn phản hồi và tập hợp các thực tiễn tốt nhất đang sử dụng thay đổi. Chúng tôi cũng có ý định bổ sung thêm các mức huy hiệu cao hơn vượt ra khỏi mức “qua được kiểm tra” như hiện nay, dự kiến có các mức “vàng” và “bạch kim”. Tuy nhiên, đội dự án đã quyết định tạo ra các tiêu chí theo các giai đoạn; nhiều khả năng hơn chúng tôi sẽ tạo ra các tiêu chí tốt một khi chúng tôi có kinh nghiệm với tập hợp các tiêu chí hiện hành. Một danh sách vài tiêu chí mức cao hơn được đề xuất đã được đưa lên rồi; nếu bạn có các ý tưởng, xin hãy đưa lên một ví dụ hoặc ra nhập danh sách thư dự án gắn huy hiệu của chúng tôi.

Khi đào sâu vào lĩnh vực này, điều gì đã gây ngạc nhiên nhất cho bạn trong những phát hiện của chúng tôi?

Có lẽ điều gây ngạc nhiên nhất là nhiều dự án PMNM không mô tả cách báo cáo các chỗ bị tổn thương về an toàn. Tất nhiên, cũng có nhiều dự án có làm. Nhiều dự án, như Mozilla Firefox, mô tả cách báo cáo các chỗ bị tổn thương tới một địa chỉ thư điện tử chuyên dùng và đưa ra một khóa PGP để gửi thư điện tử được mã hóa. Vài dự án, như Cygwin, có chính sách rõ ràng rằng tất cả các báo cáo lỗi phải được nêu công khai (trong trường hợp của họ thông qua một danh sách thư), và họ rõ ràng cấm báo cáo qua thư riêng tư. Tôi không phải là fan hâm mộ của các chính sách “mọi điều đều công khai” (vì chúng có thể trao cho những kẻ tấn công một sự khởi đầu), nhưng khi mọi người biết các quy định đó, là dễ dàng hơn để giải quyết các chỗ bị tổn thương. Tuy nhiên, nhiều dự án hoàn toàn không nói cho mọi người làm thế nào để báo cáo các chỗ bị tổn thương. Điều đó dẫn tới nhiều câu hỏi. Liệu báo cáo của một nhà nghiên cứu về an toàn về một chỗ bị tổn thương bằng việc sử dụng trình theo dõi vấn đề hoặc danh sách thư một cách công khai, hay có làm thứ gì đó khác hay không? Nếu dự án muốn nhận được các báo cáo riêng tư bằng việc sử dụng mã hóa, làm thế nào thông tin đó được mã hóa? CÁc khóa nào sẽ được sử dụng? Báo cáo và xử lý chỗ bị tổn thương có thể bị chậm lại nếu dự án không nghĩ về nó trước.

Có vài lý do gây ngạc nhiên về điều này. Trước hết, là đáng ngạc nhiên rằng các lập trình viên không biết trước sẽ có các chỗ bị tổn thương trong mã của họ và rằng họ nên được chuẩn bị để giải quyết chúng. Tin tức được làm đầy với các báo cáo về các chỗ bị tổn thương! Thứ 2, là ngạc nhiên dễ giải quyết vấn đề này trước về thời gian; hãy giải thích trên website dự án cách báo cáo các chỗ bị tổn thương. Điều đó chỉ mất 3 câu! Tất nhiên, việc viết điều đó xuống đòi hỏi các thành viên của dự án nghĩ về cách học sẽ xử lý các chỗ bị tổn thương, và điều đó là có giá trị. Là tốt hơn nhiều để quyết định cách xử lý các chỗ bị tổn thương trước khi chúng được báo cáo.

Điều gì không làm bạn ngạc nhiên, nhưng có thể gây ngạc nhiên cho những người khác?

Vài điều có thể gây ngạc nhiên cho bạn là:

1. Vẫn còn có các dự án (hầu hết là các dự án cũ) không hỗ trợ kho phiên bản được kiểm soát công khai (như, việc sử dụng Git), gây khó khăn cho những người khác để theo dõi những thay đổi hoặc cộng tác.

2. Vẫn có những dự án (hầu hết là các dự án cũ) không có bộ kiểm tra (hữu dụng) được tự động hóa hoặc được xây dựng tự động. Điều này làm khó hơn nhiều để thực hiện các cải tiến, và dễ dàng hơn nhiều cho các lỗi bị bỏ qua không được dò tìm ra. Nó cũng là khó để nâng cấp các phụ thuộc khi một chỗ bị tổn thương được tìm thấy trong chúng, vì không có cách dễ dàng nào để thẩm định rằng sự thay đổi đó hầu như chắc chắn vô hại.

3. Có nhiều dự án (hầu hết là các dự án cũ) mà nhiều người nghĩ là PMNM, nhưng chúng không hợp pháp để sử dụng vì chúng không có giấy phép nào cả. Phần mềm không có giấy phép hoặc đánh dấu nào khác thường là không hợp pháp để sử dụng, phân phối, hoặc sửa đổi ở hầu hết các quốc gia. Điều này đặc biệt là vấn đề trên GitHub. Bài trình bày năm 2015 của Ben Balter: Open source licensing by the numbers (Cấp phép nguồn mở theo các con số) đã thấy rằng trên GitHub, 23% các dự án với 1.000 hoặc nhiều sao hơn đã không có giấy phép hoàn toàn. Đúng là trước năm 1976, các tác phẩm ở Mỹ không có các dấu bản quyền được gắn vào từng không bị hạn chế bới bản quyền, nhưng điều đó từng lâu lắm rồi. Ngày nay, luật ở hầu hết tất cả các nước đòi hỏi rằng các lập trình viên cấp phép cho phần mềm trước khi nó có thể được những người khác sử dụng hợp pháp, và điều đó có lẽ không thay đổi. Thậm chí nếu bạn nghĩ luật không áp dụng cho bạn, thì việc bỏ qua giấy phép của PMTDNM có xu hướng ngăn cấm sự sử dụng, đồng phát triển, và rà soát lại dự án (bao gồm cả rà soát lại an toàn).

4. Hầu hết các lập trình viên vẫn còn không biết các nguyên lý cơ bản của việc phát triển phần mềm an toàn, hoặc những sai lầm phổ biến dẫn tới các chỗ bị tổn thương là gì.

Chúng tôi hy vọng rằng chương trình gắn huy hiệu sẽ giúp giải quyết các vấn đề như vậy.

Đối tới các chính phủ đang vật lộn với sử dụng PMNM, có các bài học nào từ sáng kiến này không?

Có 2 dạng các tổ chức lớn: các tổ chức mà biết họ đang sử dụng PMNM, và các tổ chức không biết họ đang sử dụng PMNM. Không có dạng thứ 3. Nếu bạn trả tiền cho các giấy phép phần mềm sở hữu độc quyền, nếu bạn nhìn vào bên trong, bạn sẽ thấy nhiều PMNM trong hầu hết tất cả các phần mềm sở hữu độc quyền. Các phần mềm tùy biến thường được xây dựng trên đỉnh và bởi PMNM.

Nhiều nhà quản lý vật lộn vì họ không hiểu sự thay đổi đã xảy ra rồi trong nền công nghiệp máy tính, ấy là, PMNM là lực lượng chính trong điện toán và nằm ở đây. Thay vì ôm lấy sự thay đổi, vẫn còn có những nhà quản lý muốn giả vờ rằng sự thay đổi còn chưa xảy ra, hoặc đang cố gắng quay lại vài “những ngày xưa tốt lành” hoang đường mà thực sự không từng tốt lành như vậy. Đối với những ai đang cố cản trở tất cả sử dụng PMNM, tôi khuyến cáo một liều thuốc bổ: Hãy dừng cố gắng quay ngược kim đồng hồ, và thay vào đó, hãy ôm lấy sự thay đổi đã xảy ra rồi.

Sự vật lộn khác nhau là những người mà chấp nhận một phần thực tế này, nhưng muốn quản lý rủi ro và không biết làm thế nào. Mục tiêu là đúng, nhưng các tiếp cận của họ thường lạc hướng. Tôi thường xuyên nghe thấy “nhưng bạn không biết ai đã phát triển PMNM”, ví dụ thế. Trong hầu hết các trường hợp điều này là sai, vì những người đã viết từng dòng lện thường là vấn đề của hồ sơ công khai (nó được đưa vào dữ liệu của hệ thống kiểm soát phiên bản). Thật ngớ ngẩn, cũng chính những người đó hạnh phúc để lấy các phần mềm sở hữu độc quyền thậm chí dù họ không có bất kfy ý tưởng nào về ai đã viết các dòng mã lệnh đó. Vấn đề có liên quan là nhiều người muốn sử dụng ự đăng ký vị trí của một công ty như là biện pháp rủi ro duy nhất đối với mã độc, và đó là mộti sai lầm. Ví dụ, một công ty có thể được đăng ký ở Mỹ, nhưng điều đó không có nghĩa là các lập trình viên và những người kiểm thử của nó nằm ở Mỹ hoặc là các công dân Mỹ. Đăng ký của công ty giống như đăng ký của con thuyền; điều này là viễn tưởng không có liên quan gì tới thực tế cả. Ngoài ra, bạn có thể là một công dân của một quốc gia và vẫn tạo ra mã độc để tấn công chính phủ nước đó. Những kiểm thử đơn giản như “điều này là từ công ty ở nước tôi” sẽ rất không hữu ích cho việc quản lý rủi ro; chúng ta cần các cách thức tốt hơn.

Đối với những người đang xem xét mang PMNM vào, nhưng cũng muốn quản lý rủi ro của chúng, thì sáng kiến này chắc chắn sẽ đưa ra vài điều giúp họ. Chúng tôi thay vì tập trung vào các thực tiễn tốt nhất khác nhau mà có khả năng nhiều hơn là để sản xuất các phần mềm tốt, thay vì tập trung vào những điều hoang đường về pháp lý như đăng ký quốc gia. Những người sử dụng tiềm nưng có thể thấy, qua dự án cấp huy hiệu, các thực tiễn tốt nhất và cách một dự án nhất định đang làm.

Tất nhiên, dự án cấp huy hiệu cho các thực tiễn tốt nhất không thể giải quyết được tất cả các vấn đề. Chúng tôi không thể nói cho bạn liệu vài PMNM nào đó sẽ giải quyết được vấn đề bạn có hay không; chỉ bạn có thể hiểu các nhu cầu của bạn. Có nhiều mô hình hỗ trợ PMNM khác nhau; trong một số trường hợp sự tải về đơn giản và sự phụ thuộc vào cộng đồng là một tiếp cận tốt, trong khi trong các trường hợp khác, bạn thực sự nên sử dụng một công ty mà cung cấp sự hỗ trợ chuyên nghiệp. Chúng tôi đang làm việc để cung cấp vài thông tin mọi người cần để đưa ra các quyết định tốt hơn.

Trong 1 lưu ý khác, khi chúng tôi đã nói lần trước, bạn đã chỉ ra rằng rủi ro của các dự án rẽ nhánh của chính phủ Mỹ từng là một vấn đề lớn. Các anh thấy tình trạng đó bây giờ thế nào?

Trước hết, sự làm rõ nhanh. Tôi sử dụng khái niệm “rẽ nhánh” để ngụ ý bất kỳ việc sao chép nào một dự án với ý định sửa đổi nó. Việc rẽ nhánh là tốt nếu bạn có kế hoạch đệ trình sửa đổi ngược về dự án chính. Vấn đề là một “rẽ nhánh dự án”, nó là một rẽ nhánh với ý định để tạo ra một dự án mới độc lập. Các rẽ nhánh dự án cản trở tới mức ngăn cấm sự cộng tác, thay vì khuyến khích nó, và điều đó giải thích vì sao các rẽ nhánh dự án là vấn đề.

Chính phủ Mỹ không theo dõi các rẽ nhánh dự án nó cấp vốn, nên tôi không thể trả lời câu hỏi đó với sự tin cậy. Nói đùa, tôi nghĩ vấn đề đó đã giảm đôi chút, nhưng vẫn còn là vấn đề lớn. Một điều mà đã giúp làm giảm việc rẽ nhánh dự án trong các dự án chính phủ cấp vốn là việc gia tăng sử dụng các kho công khai, đặc biệt là GitHub. Các kho công khai, và kỳ vọng là một kho sẽ được sử dụng, gia tăng đáng kể sự minh bạch. Nếu một công ty biết rằng nó sẽ bị ép buộc phải làm cho rẽ nhánh dự án của nó nhìn thấy được công khai, thì nó sẽ lo ngại đúng là nó có thể bị yêu cầu bảo vệ điều không thể bảo vệ được. Để giải thích chân lý này, Louis Dembitz Brandeis cho rằng, sự minh bạch thường là thuốc trừ độc tốt nhất. Hơn nữa, nếu chính phủ ép một công ty làm cho rẽ nhánh của họ sẵn sàng như là PMNM, thì vài sáng kiến kinh tế cho việc rẽ nhánh dự án sẽ biến mất, và những cải thiện của nó có thể được trộn ngược trở lại vào dự án chính (một quy trình được gọi là “chữa” bệnh rẽ nhánh).

Tuy vậy, vẫn có quá nhiều sáng kiến ngoan cố trong chính phủ. Một ví dụ rõ ràng là các nhà thầu kiếm được lợi nhuận cao hơn đáng kể nếu họ phát triển các phần mềm từ không có gì thay vì việc sử dụng lại phần mềm đang có. Nhiều dự án tái tạo lại cái bánh xe, vì chúng được trả tiền để làm như thế, và những người đóng thuế sẽ phải trả cho hóa đơn đó.

Thậm chí chính xác hơn, các nhà cung cấp biết rằng họ có thể moi được các hợp đồng hàng đống tiền nhiều hơn nếu học có thể khóa các khách hàng của họ vào các sản phẩm của họ. Nếu không có cách gì để thoát ra khỏi sản phẩm hoặc dịch vụ đó, thì nhà cung cấp có thể cứ nâng giá mà không có khó khăn gì, và nhà cung cấp không có sự khuyến khích nào để cung cấp công nghệ mới hoặc hỗ trợ tốt cả. Toàn bộ hệ thống mua sắm của chính phủ được cho là là có sự cạnh tranh mở cho công việc và công việc trong tương lai, và về lý thuyết đưa ra một lực đối kháng. Trong thực tế, điều đó thường không tồn tại.

Trong điện toán, các quyền dữ liệu (là các quyền sở hữu trí tuệ hoặc các quyền dữ liệu kỹ thuật) là đồng nghĩa với sức mạnh. Bạn không thể thay đổi phần mềm, hoặc có đấu thầu cạnh tranh cho người duy trì lựa chọn thay thế trong tương lai, trừ phi bạn có các quyền dữ liệu, thậm chí nếu bạn ban đầu đã trả tiền rồi cho sự phát triển của phần mềm đó. Vâng nhiều nhân viên chính phủ không hiểu điều đó. Các nhà thầu không hiểu điều đó, và được khuyến khích khai thác các nhân viên ngây thơ của chính phủ không hiểu điều đó. Các quyền dữ liệu được coi là quan trọng hơn nhiều so với các yêu cầu, vì các yêu cầu luôn thay đổi, trong khi các quyền dữ liệu xác định ai có thể sửa phần mềm để đáp ứng cho các yêu cầu mới đó. Các nhà thầu sẽ yêu cầu các quyền độc quyền đối với phần mềm thậm chí dù họ đã không trả tiền cho hầu hết sự phát triển của nó, hoặc sử dụng mánh khóe như tạo ra “các tuyến giao tiếp” sở hữu độc quyền mà mục đích đầu tiên của chúng là để khóa chính phủ vào nhà thầu đó. Nếu một nhà thầu có được các quyền độc quyền, thì chính phủ đánh mất vĩnh viễn khả năng của mình để có được sự cạnh tranh có hiệu quả cho sự duy trì của nó. Tương tự, các nhà cung cấp phần mềm bên thứ 3 thường có các giao diện sở hữu độc quyền, hoặc tạo ra các mở rộng sở hữu độc quyền cho các giao diện tiêu chuẩn, để cấm những người sử dụng khỏi việc thay đổi sang một nhà cung cấp cạnh tranh khác. Điều đó không để nói rằng tất cả các nhà thầu hoặc các nhà cung cấp bên thứ 3 là quỷ dữ, hoặc rằng tất cả các nhân viên chính phủ là không hiểu gì; còn lâu mới thế. Chính phủ cần những người đó! Nhưng các khuyến khích cố chấp, kết hợp với sự ngây ngô ở phía chính phủ, thường dẫn tới các tình huống ở đó chính phủ bị khóa trói vào một nhà thầu hoặc nhà cung cấp bên thứ 3, những người có thể sau đó lấy giá tùy thích cho các kết quả tồi. Gợi ý của tôi là nếu chính phủ thực sự có thể có sự cạnh tranh mở và đầy đủ về phần mềm, thì nó có thể tiết kiệm được hàng chục tỷ USD mỗi năm. Con số chính xác là ít có vấn đề hơn bản thân vấn đề đó; chúng ta rõ ràng có vấn đề cần sửa.

Tôi nghĩ sự trợ giúp lớn cho điều này có thể là yêu cầu phần mềm được phát triển bằng việc sử dụng nguồn cấp vốn của chính phủ sẽ phải được phát hành công khai như PMNM, trừ phi có nhu cầu thuyết phục để làm khác. Điều đó có thể làm giảm đáng kể sự khuyến khích tái tạo ra mọi điều từ đầu, hoặc việc cố khóa trói chính phủ vào một nhà thầu duy nhất. Chúng ta cũng có thể đặt ra các khoản phạt về tài chính lên những ai không nghiên cứu thị trường để tìm ra các lựa chọn thay thế; điều này được luật và hợp đồng yêu cầu, nhưng thường không được thực hiện. Tôi chắc chắn có những điều khác sẽ phải làm; mấu chốt là hệ thống hiện hành có nhiều vấn đề.

Những điều nào khác mà mọi người có liên quan tới chính phủ Mỹ nên biết?

Như tôi đã nêu lần trước, một trong những vấn đề lớn nhất là hầu hết các nhân viên mua sắm không hiểu rằng thực tế tất cả các PMNM là phần mềm thương mại. Theo luật Mỹ, Quy định Mua sắm của Liên bang - FAR (Federal Acquisition Regulation), và Bổ sung FAR của Bộ Quốc phòng - DFARS (DoD FAR Supplement), thì phần mềm là thương mại nếu nó có sử dụng phi chính phủ và được cấp phép cho công chúng. Đặc biệt, xem Tiêu đề 41 Phần 103 Luật Mỹ (U.S. Code Title 41 Section 103), nó định nghĩa khái niệm “khoản thương mại”.

Vì gần như tất cả các PMNM đáp ứng được định nghĩa về phần mềm thương mại, gần như tất cả PMNM là phần mềm thương mại. Một khi bạn hiểu được điều này, thì bạn hiểu rằng sử dụng PMNM bạn cũng tuân theo các quy định về phần mềm thương mại y hệt, và rằng ưu tiên của luật Mỹ cho các khoản thương mại (10 USC 2377) bao gồm cả PMNM. Sự hiểu biết này làm cho nhiều quyết định rất thẳng, nhưng nó vẫn còn chưa được hiểu rộng rãi.

David A. Wheeler làm việc cho Viện Phân tích Quốc phòng - IDA (Institute for Defense Analyses), nhưng trong cuộc phỏng vấn này ông không nói về IDA, chính phủ Mỹ, hay Quỹ Linux Foundation.

David Wheeler is a long-time leader in advising and working with the U.S. government on issues related to open source software. His personal webpage is a frequently cited source on open standards, open source software, and computer security. David is leading a new project, the CII Best Practices Badging project, which is part of the Linux Foundation's Core Infrastructure Initiative (CII) for strengthening the security of open source software. In this interview he talks about what it means for both government and other users.

Q&A

Let's start with some basics. What is the badging project and how did it come about?

In 2014, the Heartbleed vulnerability was found in the OpenSSL cryptographic library. In response, the Linux Foundation created the Core Infrastructure Initiative (CII) to fund and support open source software (OSS) that are critical elements of the global information infrastructure. The CII has identified and funded specific important projects, but it cannot fund all OSS projects. So the CII is also funding some approaches to generally improve the security of OSS.

The latest CII project, which focuses on improving security in general, is the best practices badge project. I'm the technical lead of this project. We think that OSS projects that follow best practices are more likely to be healthy and to produce better software, including having better security. But that requires that people know what those best practices are, and whether or not a given project is following them.

To solve this, we first examined a lot of literature and OSS projects to identify a set of widely accepted OSS best practices. We then developed a website where OSS projects can report whether or not they apply those best practices. In some cases we can examine the website of a project and automatically fill in some information. We use that information (automatic and not) to determine whether the project is adequately following best practices. If the project is adequately following best practices, the project gets a "passing" badge.

I should note here that the badging project is itself an OSS project. You can see its project site. We'd love to have even more participation, so please join us! To answer the obvious question, yes, it does earn its own badge. Other OSS projects that have earned a badge include the Linux kernel, curl, Node.js, GitLab, OpenBlox, OpenSSL, and Zephyr. In contrast, OpenSSL before Heartbleed fails many criteria, which suggests that the criteria are capturing important factors about projects.

If you participate in an OSS project, I encourage you to get a badge. If you're thinking about using an OSS project, I encourage you to see if that project has a badge. You can see more information at CII Best Practices Badge Program.

Can you tell me more about the badge criteria?

Sure. Of course, no set of practices can guarantee that software will never have defects or vulnerabilities. But some practices encourage good development, which in turn increases the likelihood of good quality, and that's what we focused on.

To create the criteria we reviewed many documents about what FLOSS projects should do; the single most influential source, was probably Karl Fogel's book Producing Open Source Software. We also looked at a number of existing successful projects. We also got very helpful critiques of the draft criteria from a large number of people including Karl Fogel, Greg Kroah-Hartman (the Linux kernel), Rich Salz (OpenSSL), and Daniel Stenberg (curl).

Once the initial criteria were identified, they were grouped into the following categories: basics, change control, reporting, quality, security, and analysis. We ended up with 66 criteria. Each criterion has an identifier and text. For example, criterion floss_license requires that, "the software MUST be released as FLOSS." Criterion know_common_errors requires that, "At least one of the primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them." The criteria are available online, and an LWN.net article discusses the criteria in more detail. It only takes about an hour for a typical OSS project to fill in the form, in part because we automatically fill in some information. More help in automating this would be appreciated.

The criteria will change slowly, probably annually, as the badging project gets more feedback and the set of best practices in use changes. We also intend to add higher badge levels beyond the current "passing" level, tentatively named the "gold" and "platinum" levels. However, the project team decided to create the criteria in stages; we're more likely to create good criteria once we have experience with the current set. A list of some proposed higher-level criteria is already posted; if you have thoughts, please post an issue or join the badging project mailing list.

In digging into this area, what surprised you the most in your findings?

Perhaps most surprising is that many OSS projects do not describe how to report security vulnerabilities. Many do, of course. Many projects, like Mozilla Firefox, describe how to report vulnerabilities to a dedicated email address and provide a PGP key for sending encrypted email. Some projects, like Cygwin, have a clear policy that all defect reports must be publicly reported (in their case via a mailing list), and they expressly forbid reporting via private email. I'm not a fan of "everything public" policies (because they can give attackers a head start), but when everyone knows the rules it's easier to handle vulnerabilities. However, many projects don't tell people how to report vulnerabilities at all. That leads to a lot of questions. Should a security researcher report a vulnerability using a public issue tracker or mailing list, or do something else? If the project wants to receive private reports using encryption, how should the information be encrypted? What keys should be used? Vulnerability reporting and handling can be slowed down if a project hasn't thought about it ahead of time.

There are several reasons to be surprised about this. First, it should be surprising that developers don't anticipate that there are vulnerabilities in their code and that they should be prepared to address them. The news is filled with vulnerability reports! Second, it's surprisingly easy to solve this problem ahead of time; just explain on a project website how to report vulnerabilities. It only takes one to three sentences! Of course, writing that down requires project members to think about how they will handle vulnerabilities, and that's valuable. It's much better to decide how to handle vulnerabilities before they are reported.

What didn't surprise you, but might surprise others?

Some things that might surprise you are:

1. There are still projects (mostly older ones) that don't support a public version-controlled repository (e.g., using Git), making it difficult for others to track changes or collaborate.

2. There are still projects (mostly older ones) that don't have a (useful) automated build or automated test suite. This makes it much harder to make improvements, and much easier for defects to slip through undetected. It also makes it hard to upgrade dependencies when a vulnerability is found in them, because there's no easy to way to verify that the change is almost certainly harmless.

3. There are many projects (mostly newer ones) that many people think are OSS, but they aren't legal to use because they have no license at all. Software without a license or other marking isn't normally legal to use, distribute, or modify in most countries. This is especially a problem on GitHub. Ben Balter's 2015 presentation Open source licensing by the numbers found that on GitHub, 23% of the projects with 1,000 or more stars had no license at all. It's true that before 1976, works in the U.S. without affixed copyright markings were not restricted by copyright, but that was a long time ago. Today, law in almost all countries requires that developers license software before it can be legally used by others, and that is unlikely to change. Even if you think the law doesn't apply to you, omitting a FLOSS license tends to inhibit project use, co-development, and review (including security reviews).

4. Most developers still don't know the basic principles of developing secure software, or what the common mistakes that lead to vulnerabilities are.

We're hoping that the badging program will help counter problems like these.

For governments struggling with the use of open source software, are there lessons from this initiative?

There are two kinds of large organizations: those who know they're using OSS, and those who don't know they're using OSS. There is no third kind. If you pay for proprietary software licenses, if you look inside, you'll find a lot of OSS in almost all proprietary software. Custom software is usually built on top of, and by, OSS.

Many managers struggle because they don't understand the change that has already happened in the computer industry, namely, that OSS is a major force in computing and here to stay. Instead of embracing change, there are still managers who want to pretend that the change hasn't happened, or are trying to return to some mythical "good old days" that really weren't that good. For those trying to prevent all use of OSS, I recommend a simple tonic: Stop trying to turn back the clock, and instead, embrace the change that's already happened.

A different struggle is people who partly accept this reality, but want to manage risk and don't know how. The goal is right, but their approaches are often misguided. I repeatedly hear "but you don't know who developed the OSS," for example. In most cases this is false, since who wrote each line is often a matter of public record (it's included in the version control system data). Absurdly, these same people are happy to take proprietary software even though they do not have any idea who wrote the code. A related problem is that many people want to use a company's location registration as the sole risk measure for malicious code, and that's a mistake. For example, a company may be registered in the U.S., but that doesn't mean that its developers and testers are in the U.S. or are U.S. citizens. Company registration is like ship registration; it's a legal fiction unrelated to reality. Besides, you can be a citizen of a country and still create malicious code to attack that country's government. Simple tests like "is this from a company in my country" aren't very helpful for managing risk; we need better ways.

For people who are looking at bringing in OSS, but also want to manage their risk, this initiative should definitely provide some help. We instead focus on various best practices that are more likely to produce good software, instead of focusing on legal fictions like country registration. Potential users can see, through the badging project, the best practices and how well a particular project is doing.

Of course, the best practices badging project can't solve all problems. We can't tell you if some given OSS will solve the problem you have; only you can understand your needs. There are many different OSS support models; in some cases a simple download and depending on community is a good approach, while in others, you really should be using a company that provides professional support. We're working to provide some of the information people need to make better decisions.

On a different note, when we last spoke, you indicated that the risk of the U.S. government forking projects was still a big problem. What's your take on the state of this today?

First, a quick clarification. I use the term "fork" to mean any copying of a project with the intent to modify it. Forking is great if you plan to submit the modification back to the main project. The problem is a "project fork," which is a fork with the intent to create a new independent project. Project forks inhibit collaboration, instead of encouraging it, and that's why project forks are a problem.

The U.S. government doesn't track project forks it funds, so I can't answer that question with confidence. Anecdotally, I think the problem has slightly reduced, but it's still a big problem. One thing that's helped reduce project forking in government-funded projects is the increasing use of public repositories, particularly on GitHub. Public repositories, and the expectation that one will be used, greatly increase transparency. If a company knows that it will be compelled to make its project fork publicly visible, it will correctly worry that it might be asked to defend the indefensible. To paraphrase Justice Louis Dembitz Brandeis, transparency is often the best disinfectant. In addition, if the government forces a company to make their project fork available as OSS, some of the economic incentives for project forking disappear, and its improvements might be merged back into the main project (a process called "healing" a fork).

That said, there are still too many perverse incentives in the government. An obvious one example is that the contractors get significantly higher profits if they develop software from scratch instead of reusing existing software. Many projects reinvent the wheel, because they're paid to do so, and taxpayers pick up the bill.

Even more seriously, suppliers know that they can extort orders of magnitude more money if they can lock their customers into their products. If there's no way to escape the product or service, the supplier can just keep raising prices without restraint, and the supplier has no incentive to provide new technology or good support. The government's entire acquisition system presumes that there's open competition for work and future work, and in theory that provides a countervailing force. In practice, it often doesn't.

In computing, data rights (aka intellectual rights or technical data rights) are a synonym for power. You can't change software, or have a competitive bid for an alternative future maintainer, unless you have the data rights , even if you originally paid for the development of that software. Yet many government employees don't understand that. Contractors do understand that, and are incentivized to exploit the naïve government employees who don't. Data rights are arguably much more important than requirements, because requirements constantly change, while data rights determine who can modify the software to respond to the new requirements. Contractors will ask for exclusive rights to software even though they didn't pay for most of its development, or use tricks like creating proprietary "communication buses" whose primary purpose is to lock the government into that contractor. If a contractor gets exclusive rights, then the government loses forever its ability to have effective competition for its maintenance. Similarly, third-party software suppliers often have proprietary interfaces, or create proprietary extensions to standard interfaces, to inhibit users from changing to a competing supplier. That's not to say that all contractors or third-party suppliers are evil, or that all government employees are clueless; far from it. The government needs these people! But perverse incentives, combined with naiveté on the government side, often leads to situations in which the government is locked into a contractor or third-party supplier, who can then charge arbitrary prices for poor results. My guess is that if the government could actually have full and open competition on software, it would save at least tens of billions of dollars a year. The exact number matters less than the problem; we clearly have a problem that needs fixing.

I think a big help to this would be to require software developed using government funding to be released to the public as open source software, unless there's a compelling need to do otherwise. That would greatly reduce the incentive to recreate everything from scratch, or trying to lock the government into a single contractor. We might also want to impose financial penalties on those who fail to do market research to find alternatives; this is required by law and contract, but often not done. I'm sure there are other things that should be done; the key is that the current system has many problems.

What are other things that people involved with the U.S. government should know?

As I mentioned last time, one of the biggest problems is that most acquisition personnel don't understand that practically all OSS is commercial software. Under U.S. law, the Federal Acquisition Regulation (FAR), and the DoD FAR Supplement (DFARS), software is commercial if it has a non-government use and is licensed to the public. In particular, see U.S. Code Title 41 Section 103 which defines the term "commercial item."

Because nearly all OSS meets the definition for commercial software, nearly all OSS is commercial software. Once you understand this, you understand that to use OSS you just follow the rules for commercial software, and that the U.S. law's preference for commercial items (10 USC 2377) includes OSS. This understanding makes a lot of decisions very straightforward, but it's still not widely understood.

David A. Wheeler works for the Institute for Defense Analyses (IDA), but in this interview he is not speaking for IDA, the U.S. government, or the Linux Foundation.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com