De ce un VPN cu sursă deschisă este respins în achiziții
Un recenzent care se opune sursei deschise protejează de obicei o cerință, nu o preferință de licențiere. Întrebați care, apoi produceți documentul care îi răspunde.
Respingerea care invocă sursa deschisă rareori se referă la licențiere. Recenzentul protejează de obicei o cerință: că cineva întreține versiunea implementată, că build-ul instalat poate fi identificat, că o evaluare acoperă ceea ce se conectează sau că conexiunea poate fi retrasă. Dezbaterea care urmează răspunde de obicei la o întrebare pe care nimeni nu a pus-o.
Întrebați care cerință se aplică înainte de a apăra o licență. Răspunsul decide de ce document aveți nevoie.
Eticheta nu este cerința
Codul sursă lizibil înseamnă că implementarea publicată poate fi inspectată. Nu înseamnă că cineva a inspectat-o, că build-ul de pe gateway corespunde celui publicat sau că un întreținător datorează o corecție implementării dumneavoastră. Fiecare dintre acestea este o afirmație separată cu un proprietar separat, iar un recenzent care are nevoie de una dintre ele nu va fi mulțumit de celelalte. Spunerea afirmației cu voce tare este de obicei suficientă pentru a schimba conversația.
Greșeala inversă este la fel de frecventă. O licență comercială nu dovedește că suportul acoperă funcția pe care vă bazați, că o evaluare a examinat componenta pe care o implementați sau că furnizorul va livra o corecție în fereastra dumneavoastră de mentenanță. Licențierea descrie termenii de distribuție, în timp ce deciziile de achiziție privesc încrederea. În ambele cazuri, licența este partea cea mai puțin informativă a răspunsului.
Țineți clientul și serviciul separat. Un audit al unui client desktop nu spune nimic despre configurația gateway-ului partenerului, despre furnizorul său de identitate sau despre modul în care operatorii săi gestionează eliminarea conturilor. Orice dovezi adunați trebuie să corespundă limitei în care partenerul este rugat să aibă încredere.
Transformați îngrijorarea într-un document
Rugați aprobatorul să formuleze cerința într-o singură propoziție, apoi numiți documentul care ar satisface-o. Tocmai asigurarea vagă transformă aceste conversații într-o dezbatere despre ideologie.
| 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 este util aici dintr-un motiv îngust: încadrează conversațiile de achiziție în jurul unui vocabular comun de practici și comunicare cu furnizorii. Aceasta susține cererea de dovezi definite în locul unei dispute despre o etichetă și nu este o certificare pe care o trece un anumit VPN.
Observați ce face coloana din mijloc. Fiecare rând cere un document care fie există, fie nu, ceea ce transformă o opinie într-un rezultat pe care cineva îl poate produce sau refuza.
Separați clientul de serviciu
Un contract de suport pentru o aplicație client nu este un angajament privind serverul la care ajunge traficul dumneavoastră. Înainte de a prezenta dovezi, marcați ce părți ale traseului operează partenerul și ce părți operați dumneavoastră în numele său. Amestecarea celor două produce un pachet de documente care pare temeinic și nu răspunde la nimic.
Dacă implementarea este a dumneavoastră, partenerul poate avea nevoie să aibă încredere doar într-o identitate și o regulă de acces, ceea ce este o cerere mult mai mică decât încrederea în întregul lanț de aprovizionare software. Dacă implementarea este a lui, clientul pe care îl preferați poate fi irelevant, iar configurația gateway-ului devine subiectul. Stabilirea cazului în care vă aflați înainte de a doua întâlnire economisește un ciclu de revizuire.
Apoi verificați întrebările operaționale la care revizuirile eșuează de fapt: cine elimină un cont, cât de repede și ce dovezi există după aceea. O evaluare frumos documentată fără o procedură de eliminare rămâne o constatare deschisă.
Încheiați cu o decizie, nu cu o dezbatere
Încheiați schimbul cu un rezultat scris: versiunea acceptată, controalele asociate, operatorii numiți, dovezile încă lipsă și data la care sunt scadente. Orice rămâne nerezolvat trebuie înregistrat ca o condiție, în loc să fie absorbit într-o declarație generală de aprobare.
Dacă politica numește un anumit produs aprobat, folosiți calea excepției în loc să construiți o înțelegere paralelă pe care nimeni nu a autorizat-o. Un argument tehnic convingător nu acordă permisiune, iar o implementare neoficială este o constatare care așteaptă să fie descoperită.
Dacă o cerință nu poate fi cu adevărat îndeplinită, treceți la alternativa aprobată și spuneți de ce. Scopul exercițiului este să stabilească pe ce se poate baza organizația, iar un nu clar este un rezultat mai bun decât o aprobare pe care nimeni nu o va putea apăra mai târziu.