Защо 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 преминава.
Забележете какво прави средната колона. Всеки ред изисква документ, който или съществува, или не, което превръща мнението в резултат, който някой може да представи или да откаже.
Разделете клиента от услугата
Договор за поддръжка на клиентско приложение не е ангажимент относно сървъра, до който достига трафикът ви. Преди да представите доказателства, отбележете кои части от пътя управлява партньорът и кои управлявате вие от негово име. Смесването на двете създава пакет документи, който изглежда изчерпателен и не отговаря на нищо.
Ако внедряването е ваше, партньорът може да се нуждае само от доверие към идентичност и правило за достъп, което е много по-малка заявка от доверието към цялата ви верига за доставки на софтуер. Ако внедряването е негово, клиентът, който предпочитате, може да е без значение и конфигурацията на шлюза става темата. Да разберете в кой случай сте преди втората среща спестява един цикъл на преглед.
След това проверете оперативните въпроси, на които прегледите всъщност се провалят: кой премахва акаунт, колко бързо и какви доказателства остават след това. Красиво документирана оценка без процедура за премахване все още е отворена констатация.
Приключете с решение, а не с дебат
Завършете размяната с писмен резултат: приетото издание, контролите към него, посочените оператори, доказателствата, които все още липсват, и датата, до която се очакват. Всичко нерешено трябва да се запише като условие, вместо да се погълне в общо изявление за одобрение.
Ако политиката посочва конкретен одобрен продукт, използвайте пътя за изключение, вместо да изграждате паралелна уредба, която никой не е упълномощил. Убедителният технически аргумент не дава разрешение, а неофициалното внедряване е констатация, която чака да бъде открита.
Ако изискване наистина не може да бъде изпълнено, преминете към одобрената алтернатива и кажете защо. Целта на упражнението е да установи на какво организацията може да разчита, а ясното „не“ е по-добър резултат от одобрение, което по-късно никой не може да защити.