Чому 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.
Зверніть увагу, що робить середній стовпець. Кожен рядок вимагає документ, який або існує, або ні, і це перетворює думку на результат, який хтось може надати або відхилити.
Відокремте клієнт від сервісу
Угода про підтримку клієнтського застосунку не є зобов'язанням щодо сервера, до якого доходить ваш трафік. Перш ніж подавати докази, позначте, які частини шляху експлуатує партнер, а які ви експлуатуєте від його імені. Змішування обох створює пакет документів, що виглядає ґрунтовно і ні на що не відповідає.
Якщо розгортання ваше, партнеру, можливо, потрібно довіряти лише ідентичності та правилу доступу, що є значно меншим запитом, ніж довіра до всього вашого ланцюга постачання програмного забезпечення. Якщо розгортання його, бажаний вами клієнт може бути несуттєвим, і темою стає конфігурація шлюзу. З'ясування того, у якому ви випадку, до другої зустрічі економить один цикл розгляду.
Потім перевірте операційні питання, на яких перевірки справді провалюються: хто видаляє обліковий запис, як швидко і які докази залишаються після цього. Гарно задокументована оцінка без процедури видалення залишається відкритою знахідкою.
Завершіть рішенням, а не суперечкою
Завершіть обмін письмовим результатом: прийнята версія, пов'язані з нею контролі, названі оператори, докази, яких ще бракує, і дата, до якої їх мають надати. Усе невирішене слід зафіксувати як умову, а не поглинати в загальну заяву про схвалення.
Якщо політика називає конкретний схвалений продукт, використовуйте шлях винятку, а не будуйте паралельну домовленість, яку ніхто не санкціонував. Переконливий технічний аргумент не дає дозволу, а неофіційне розгортання — це знахідка, що чекає на виявлення.
Якщо вимогу справді неможливо виконати, перейдіть до схваленої альтернативи і скажіть чому. Мета вправи — встановити, на що організація може покладатися, і чітке «ні» — кращий результат, ніж схвалення, яке потім ніхто не зможе захистити.