Vì sao VPN mã nguồn mở bị từ chối trong mua sắm
Người phản biện phản đối mã nguồn mở thường đang bảo vệ một yêu cầu, không phải sở thích về giấy phép. Hãy hỏi yêu cầu nào, rồi tạo ra tài liệu trả lời yêu cầu đó.
Những từ chối viện dẫn mã nguồn mở hiếm khi liên quan đến việc cấp phép. Người phản biện thường bảo vệ một yêu cầu: rằng có người duy trì bản phát hành đã triển khai, rằng bản dựng đã cài đặt có thể nhận diện được, rằng một đánh giá bao trùm những gì được kết nối, hoặc rằng kết nối có thể bị thu hồi. Cuộc tranh luận sau đó thường trả lời một câu hỏi mà không ai đặt ra.
Hãy hỏi yêu cầu nào đang áp dụng trước khi bảo vệ giấy phép. Câu trả lời quyết định tài liệu bạn cần.
Nhãn không phải là yêu cầu
Mã nguồn dễ đọc nghĩa là có thể kiểm tra bản triển khai đã công bố. Điều đó không có nghĩa là ai đó đã kiểm tra, rằng bản dựng trên cổng khớp với bản công bố, hay rằng người bảo trì nợ bản triển khai của bạn một bản sửa lỗi. Mỗi điều trong số đó là một tuyên bố riêng với chủ sở hữu riêng, và một người phản biện cần một trong số đó sẽ không hài lòng với những điều còn lại. Nêu tên tuyên bố thành tiếng thường đủ để thay đổi cuộc trò chuyện.
Sai lầm ngược lại cũng phổ biến không kém. Giấy phép thương mại không chứng minh rằng hỗ trợ bao trùm tính năng bạn dựa vào, rằng một đánh giá đã xem xét thành phần bạn triển khai, hay rằng nhà cung cấp sẽ gửi bản sửa trong cửa sổ bảo trì của bạn. Việc cấp phép mô tả các điều khoản phân phối, trong khi quyết định mua sắm liên quan đến sự tin cậy. Dù thế nào, giấy phép là phần ít thông tin nhất trong câu trả lời.
Cũng hãy tách máy khách và dịch vụ. Một cuộc kiểm toán máy khách để bàn không nói gì về cấu hình cổng của đối tác, nhà cung cấp danh tính của họ hay cách người vận hành của họ xử lý việc xóa tài khoản. Bất kỳ bằng chứng nào bạn thu thập đều phải khớp với ranh giới mà đối tác được yêu cầu tin cậy.
Biến nỗi lo thành tài liệu
Đề nghị người phê duyệt phát biểu yêu cầu trong một câu, rồi nêu tên tài liệu sẽ đáp ứng nó. Chính sự trấn an mơ hồ biến những cuộc trò chuyện này thành tranh luận về ý thức hệ.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework hữu ích ở đây vì một lý do hẹp: nó đặt khung các cuộc trò chuyện mua sắm quanh một từ vựng chung về thực hành và giao tiếp với nhà cung cấp. Điều đó hỗ trợ việc yêu cầu bằng chứng xác định thay vì tranh cãi về một nhãn, và đây không phải chứng nhận mà bất kỳ VPN cụ thể nào đạt được.
Hãy để ý cột giữa làm gì. Mỗi hàng yêu cầu một tài liệu hoặc có hoặc không, điều này biến ý kiến thành một sản phẩm bàn giao mà ai đó có thể tạo ra hoặc từ chối.
Tách máy khách khỏi dịch vụ
Hợp đồng hỗ trợ cho một ứng dụng máy khách không phải cam kết về máy chủ mà lưu lượng của bạn đến. Trước khi trình bày bằng chứng, hãy đánh dấu phần nào của đường đi do đối tác vận hành và phần nào do bạn vận hành thay mặt họ. Trộn lẫn cả hai tạo ra một gói tài liệu trông kỹ lưỡng và không trả lời gì.
Nếu việc triển khai là của bạn, đối tác có thể chỉ cần tin vào một danh tính và một quy tắc truy cập, đây là yêu cầu nhỏ hơn nhiều so với việc tin vào toàn bộ chuỗi cung ứng phần mềm. Nếu việc triển khai là của họ, máy khách bạn ưa thích có thể không liên quan và cấu hình cổng trở thành chủ đề. Xác định bạn ở trường hợp nào trước cuộc họp thứ hai giúp tiết kiệm một chu kỳ xem xét.
Sau đó kiểm tra những câu hỏi vận hành mà các cuộc xem xét thực sự thất bại: ai xóa tài khoản, nhanh đến mức nào, và bằng chứng nào tồn tại sau đó. Một đánh giá được ghi chép đẹp đẽ mà không có quy trình xóa vẫn là một phát hiện còn mở.
Kết thúc bằng quyết định, không bằng tranh luận
Kết thúc trao đổi bằng một kết quả bằng văn bản: phiên bản được chấp nhận, các kiểm soát gắn với nó, những người vận hành được nêu tên, bằng chứng còn thiếu và ngày phải nộp. Bất cứ điều gì chưa giải quyết nên được ghi lại như một điều kiện thay vì bị hấp thụ vào một tuyên bố phê duyệt chung.
Nếu chính sách nêu tên một sản phẩm đã được phê duyệt cụ thể, hãy dùng con đường ngoại lệ thay vì dựng một thỏa thuận song song mà không ai cho phép. Một lập luận kỹ thuật thuyết phục không cấp quyền, và một triển khai không chính thức là một phát hiện đang chờ bị phát hiện.
Nếu một yêu cầu thực sự không thể đáp ứng, hãy chuyển sang phương án đã được phê duyệt và nói vì sao. Mục đích của bài tập là xác lập điều tổ chức có thể dựa vào, và một lời từ chối rõ ràng là kết quả tốt hơn một sự phê duyệt mà sau này không ai có thể bảo vệ.