چرا یک VPN متن‌باز در فرآیند خرید رد می‌شود
بازبینی که به متن‌باز اعتراض می‌کند معمولاً از یک الزام دفاع می‌کند، نه از سلیقه‌ای در مجوز. بپرسید کدام، سپس سندی را که به آن پاسخ می‌دهد فراهم کنید.
ردشدن‌هایی که به متن‌باز استناد می‌کنند به‌ندرت به مجوز مربوط می‌شوند. بازبین معمولاً از یک الزام دفاع می‌کند: اینکه کسی نسخهٔ مستقرشده را نگه‌داری کند، اینکه بیلد نصب‌شده قابل شناسایی باشد، اینکه ارزیابی چیزی را که متصل می‌شود پوشش دهد، یا اینکه اتصال قابل پس‌گرفتن باشد. بحثی که در پی می‌آید معمولاً به پرسشی پاسخ می‌دهد که کسی نپرسیده است.
پیش از دفاع از یک مجوز بپرسید کدام الزام اعمال می‌شود. پاسخ تعیین می‌کند به کدام سند نیاز دارید.
برچسب همان الزام نیست
کد منبع خوانا یعنی می‌توان پیاده‌سازی منتشرشده را بازرسی کرد. این به آن معنا نیست که کسی آن را بازرسی کرده، اینکه بیلد روی دروازه با نسخهٔ منتشرشده مطابقت دارد، یا اینکه نگه‌دارنده‌ای به استقرار شما اصلاحی بده‌کار است. هر یک از این‌ها ادعایی جدا با صاحب جداگانه است، و بازبینی که به یکی از آن‌ها نیاز دارد با بقیه راضی نمی‌شود. نام بردن ادعا با صدای بلند معمولاً برای تغییر گفت‌وگو کافی است.
اشتباه معکوس هم به همان اندازه رایج است. مجوز تجاری اثبات نمی‌کند که پشتیبانی قابلیتی را که به آن تکیه دارید پوشش می‌دهد، که ارزیابی مؤلفه‌ای را که مستقر می‌کنید بررسی کرده، یا اینکه فروشنده اصلاحی را در پنجرهٔ نگه‌داری شما ارسال می‌کند. مجوزدهی شرایط توزیع را توصیف می‌کند، در حالی که تصمیم‌های خرید دربارهٔ اتکا هستند. در هر دو حال، مجوز کم‌اطلاع‌ترین بخش پاسخ است.
کلاینت و سرویس را هم جدا نگه دارید. ممیزی یک کلاینت رومیزی هیچ چیزی دربارهٔ پیکربندی دروازهٔ شریک، ارائه‌دهندهٔ هویت آن یا شیوهٔ برخورد اپراتورهایش با حذف حساب نمی‌گوید. هر شاهدی که گردآوری می‌کنید باید با مرزی که از شریک خواسته می‌شود به آن اعتماد کند مطابقت داشته باشد.
نگرانی را به سند تبدیل کنید
از تأییدکننده بخواهید الزام را در یک جمله بیان کند، سپس سندی را که آن را برآورده می‌کند نام ببرید. اطمینان مبهم است که این گفت‌وگوها را به جدال دربارهٔ ایدئولوژی تبدیل می‌کند.
| 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 اینجا به یک دلیل محدود سودمند است: گفت‌وگوهای خرید را حول واژگانی مشترک از رویه‌ها و ارتباط با تأمین‌کنندگان چارچوب‌بندی می‌کند. این از درخواست شواهد مشخص به‌جای جدال دربارهٔ یک برچسب پشتیبانی می‌کند و گواهینامه‌ای نیست که یک VPN خاص آن را بگذراند.
توجه کنید ستون میانی چه می‌کند. هر ردیف سندی را می‌خواهد که یا وجود دارد یا ندارد، و این یک نظر را به تحویل‌دادنی تبدیل می‌کند که کسی می‌تواند تولید یا رد کند.
کلاینت را از سرویس جدا کنید
قرارداد پشتیبانی برای یک برنامهٔ کلاینت تعهدی دربارهٔ سروری نیست که ترافیک شما به آن می‌رسد. پیش از ارائهٔ شواهد، مشخص کنید کدام بخش‌های مسیر را شریک اداره می‌کند و کدام بخش‌ها را شما به نام او اداره می‌کنید. آمیختن این دو بسته‌ای از اسناد می‌سازد که جامع به نظر می‌رسد و به هیچ چیز پاسخ نمی‌دهد.
اگر استقرار از شماست، شریک شاید فقط نیاز داشته باشد به یک هویت و یک قاعدهٔ دسترسی اعتماد کند، که درخواستی بسیار کوچک‌تر از اعتماد به کل زنجیرهٔ تأمین نرم‌افزار شماست. اگر استقرار از اوست، کلاینتی که ترجیح می‌دهید ممکن است بی‌ربط باشد و پیکربندی دروازه موضوع می‌شود. روشن کردن اینکه در کدام حالت هستید پیش از جلسهٔ دوم یک چرخهٔ بازبینی صرفه‌جویی می‌کند.
سپس پرسش‌های عملیاتی‌ای را بررسی کنید که بازبینی‌ها واقعاً در آن‌ها شکست می‌خورند: چه کسی حسابی را حذف می‌کند، با چه سرعتی، و چه شواهدی بعد از آن وجود دارد. ارزیابی‌ای که زیبا مستند شده اما رویهٔ حذف ندارد هنوز یک یافتهٔ باز است.
با تصمیم تمام کنید، نه با جدال
تبادل را با نتیجه‌ای مکتوب پایان دهید: نسخهٔ پذیرفته‌شده، کنترل‌های پیوست آن، اپراتورهای نام‌برده، شواهدی که هنوز باقی است و تاریخی که باید تا آن ارائه شود. هر چیز حل‌نشده باید به عنوان شرط ثبت شود نه اینکه در بیانیه‌ای کلی از تأیید جذب شود.
اگر سیاست محصول تأییدشدهٔ مشخصی را نام می‌برد، از مسیر استثنا استفاده کنید نه اینکه ترتیبی موازی بسازید که کسی مجاز نکرده است. استدلال فنی متقاعدکننده اجازه نمی‌دهد، و استقرار غیررسمی یافته‌ای است که در انتظار کشف شدن است.
اگر الزامی واقعاً برآورده نمی‌شود، به گزینهٔ تأییدشده بروید و بگویید چرا. هدف این تمرین تعیین این است که سازمان به چه چیزی می‌تواند اتکا کند، و «نه»ی روشن نتیجه‌ای بهتر از تأییدی است که بعداً کسی نمی‌تواند از آن دفاع کند.