Зошто 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.
Забележете што прави средната колона. Секој ред бара документ што или постои или не, што мислењето го претвора во резултат што некој може да го подготви или одбие.
Одвојте го клиентот од услугата
Договорот за поддршка на клиентска апликација не е обврска за серверот до кој стигнува вашиот сообраќај. Пред да презентирате докази, означете кои делови од патеката ги управува партнерот, а кои ги управувате вие во негово име. Мешањето на двете создава пакет документи што изгледа темелно и не одговара на ништо.
Ако распоредувањето е ваше, на партнерот можеби му треба да верува само на идентитет и правило за пристап, што е многу помало барање отколку доверба во целиот вашинг синџир за снабдување со софтвер. Ако распоредувањето е негово, клиентот што го претпочитате може да биде неважен и конфигурацијата на портата станува тема. Откривањето во кој случај сте пред втората средба заштедува еден циклус на разгледување.
Потоа проверете ги оперативните прашања на кои разгледувањата навистина паѓаат: кој отстранува сметка, колку брзо и какви докази остануваат потоа. Убаво документирана проценка без постапка за отстранување сѐ уште е отворено наоѓање.
Завршете со одлука, а не со дебата
Завршете ја размената со писмен резултат: прифатената верзија, контролите поврзани со неа, именуваните оператори, доказите што сѐ уште недостасуваат и датумот до кој треба да се достават. Сѐ нерешено треба да се забележи како услов, наместо да се впие во општа изјава за одобрување.
Ако политиката именува конкретен одобрен производ, користете го патот за исклучок наместо да градите паралелен аранжман што никој не го овластил. Убедлив технички аргумент не дава дозвола, а неофицијалното распоредување е наоѓање што чека да биде откриено.
Ако барањето навистина не може да се исполни, преминете на одобрената алтернатива и кажете зошто. Целта на вежбата е да се утврди на што организацијата може да се потпре, а јасното „не“ е подобар резултат од одобрување што подоцна никој не може да го одбрани.