Dlaczego VPN z otwartym kodem jest odrzucany w zamówieniach
Recenzent, który sprzeciwia się otwartemu kodowi, zwykle chroni wymaganie, a nie gust w kwestii licencji. Zapytaj które, a następnie przedstaw dokument, który na nie odpowiada.
Odrzucenia powołujące się na otwarty kod rzadko dotyczą licencjonowania. Recenzent zwykle chroni wymaganie: że ktoś utrzymuje wdrożone wydanie, że można zidentyfikować zainstalowaną kompilację, że ocena obejmuje to, co jest podłączane, albo że połączenie można wycofać. Następująca debata zwykle odpowiada na pytanie, którego nikt nie zadał.
Zapytaj, które wymaganie obowiązuje, zanim zaczniesz bronić licencji. Odpowiedź decyduje, jakiego dokumentu potrzebujesz.
Etykieta nie jest wymaganiem
Czytelny kod źródłowy oznacza, że opublikowaną implementację można sprawdzić. Nie oznacza to, że ktoś ją sprawdził, że kompilacja na bramie odpowiada opublikowanej albo że opiekun jest winien twojemu wdrożeniu poprawkę. Każde z tych jest osobnym twierdzeniem z osobnym właścicielem, a recenzent, który potrzebuje jednego z nich, nie zostanie zadowolony pozostałymi. Wypowiedzenie twierdzenia na głos zwykle wystarcza, by zmienić rozmowę.
Odwrotny błąd jest równie częsty. Licencja komercyjna nie dowodzi, że wsparcie obejmuje funkcję, na której polegasz, że ocena zbadała komponent, który wdrażasz, ani że dostawca dostarczy poprawkę w twoim oknie utrzymania. Licencjonowanie opisuje warunki dystrybucji, a decyzje zakupowe dotyczą zaufania. W obu przypadkach licencja jest najmniej informacyjną częścią odpowiedzi.
Trzymaj też klienta i usługę osobno. Audyt klienta desktopowego nic nie mówi o konfiguracji bramy partnera, jego dostawcy tożsamości ani o sposobie, w jaki jego operatorzy usuwają konta. Jakiekolwiek dowody zbierzesz, muszą pasować do granicy, której partner ma zaufać.
Zamień obawę w dokument
Poproś zatwierdzającego o sformułowanie wymagania w jednym zdaniu, a następnie nazwij dokument, który by je spełnił. To właśnie niejasne zapewnienie zamienia te rozmowy w spór o ideologię.
| 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 jest tu przydatny z jednego wąskiego powodu: ujmuje rozmowy zakupowe w ramy wspólnego słownika praktyk i komunikacji z dostawcami. Wspiera to proszenie o określone dowody zamiast spierania się o etykietę, i nie jest certyfikacją, którą przechodzi jakikolwiek konkretny VPN.
Zauważ, co robi środkowa kolumna. Każdy wiersz prosi o dokument, który albo istnieje, albo nie, co zamienia opinię w wynik, który ktoś może przedstawić lub odrzucić.
Oddziel klienta od usługi
Umowa wsparcia dla aplikacji klienckiej nie jest zobowiązaniem dotyczącym serwera, do którego dociera twój ruch. Zanim przedstawisz dowody, zaznacz, które części ścieżki obsługuje partner, a które ty obsługujesz w jego imieniu. Mieszanie obu daje pakiet dokumentów, który wygląda na gruntowny i na nic nie odpowiada.
Jeśli wdrożenie jest twoje, partner może potrzebować zaufania tylko do tożsamości i reguły dostępu, co jest znacznie mniejszym żądaniem niż zaufanie całemu łańcuchowi dostaw oprogramowania. Jeśli wdrożenie jest jego, preferowany przez ciebie klient może być nieistotny i tematem staje się konfiguracja bramy. Ustalenie, w którym przypadku jesteś, przed drugim spotkaniem oszczędza jeden cykl przeglądu.
Następnie sprawdź pytania operacyjne, na których przeglądy naprawdę zawodzą: kto usuwa konto, jak szybko i jakie dowody pozostają potem. Pięknie udokumentowana ocena bez procedury usunięcia nadal jest otwartym ustaleniem.
Zakończ decyzją, nie debatą
Zakończ wymianę pisemnym wynikiem: przyjęta wersja, powiązane z nią kontrole, wskazani operatorzy, dowody, których jeszcze brakuje, oraz data, do której mają być dostarczone. Wszystko nierozstrzygnięte należy zapisać jako warunek, zamiast wchłaniać w ogólne oświadczenie o zatwierdzeniu.
Jeśli polityka wskazuje konkretny zatwierdzony produkt, skorzystaj ze ścieżki wyjątku, zamiast budować równoległe uzgodnienie, którego nikt nie autoryzował. Przekonujący argument techniczny nie daje pozwolenia, a nieoficjalne wdrożenie jest ustaleniem czekającym na odkrycie.
Jeśli wymagania naprawdę nie da się spełnić, przejdź do zatwierdzonej alternatywy i powiedz dlaczego. Celem ćwiczenia jest ustalenie, na czym organizacja może polegać, a jasne nie jest lepszym wynikiem niż zatwierdzenie, którego nikt później nie obroni.