Pse një VPN me kod të hapur refuzohet në prokurim
Një recensent që kundërshton kodin e hapur zakonisht mbron një kërkesë, jo një shije licencimi. Pyetni cilën, pastaj përgatitni dokumentin që i përgjigjet.
Refuzimet që përmendin kodin e hapur rrallë kanë të bëjnë me licencimin. Recensenti zakonisht mbron një kërkesë: që dikush të mirëmbajë versionin e vendosur, që ndërtimi i instaluar të identifikohet, që një vlerësim të mbulojë atë që lidhet, ose që lidhja të mund të tërhiqet. Debati që vijon zakonisht përgjigjet një pyetjeje që askush nuk e bëri.
Pyetni cila kërkesë zbatohet përpara se të mbroni një licencë. Përgjigjja vendos cilin dokument ju nevojitet.
Etiketa nuk është kërkesa
Kodi burimor i lexueshëm do të thotë që zbatimi i publikuar mund të inspektohet. Nuk do të thotë që dikush e ka inspektuar, që ndërtimi në portë përputhet me atë të publikuar, ose që një mirëmbajtës i detyrohet një korrigjim vendosjes tuaj. Secila prej tyre është një pohim i veçantë me pronar të veçantë, dhe një recensent që ka nevojë për njërin prej tyre nuk do të kënaqet me të tjerët. Të thuash pohimin me zë zakonisht mjafton për të ndryshuar bisedën.
Gabimi i kundërt është po aq i zakonshëm. Një licencë komerciale nuk dëshmon që mbështetja mbulon funksionin ku mbështeteni, që një vlerësim ka shqyrtuar komponentin që vendosni, ose që furnizuesi do të dërgojë një korrigjim brenda dritares tuaj të mirëmbajtjes. Licencimi përshkruan kushtet e shpërndarjes, ndërsa vendimet e prokurimit kanë të bëjnë me besimin. Në të dyja rastet, licenca është pjesa më pak informuese e përgjigjes.
Mbani klientin dhe shërbimin të ndarë. Një auditim i një klienti desktopi nuk thotë asgjë për konfigurimin e portës së partnerit, ofruesin e tij të identitetit ose mënyrën se si operatorët e tij trajtojnë heqjen e llogarive. Çdo provë që mblidhni duhet të përputhet me kufirin që partnerit i kërkohet të besojë.
Kthejeni shqetësimin në dokument
Kërkoni nga miratuesi ta formulojë kërkesën në një fjali, pastaj emërtoni dokumentin që do ta plotësonte. Është pikërisht sigurimi i paqartë ai që i kthen këto biseda në debat për ideologjinë.
| 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 është i dobishëm këtu për një arsye të ngushtë: i kornizon bisedat e prokurimit rreth një fjalori të përbashkët praktikash dhe komunikimi me furnizuesit. Kjo mbështet kërkesën për prova të përcaktuara në vend të një grindjeje për një etiketë, dhe nuk është një certifikim që kalon ndonjë VPN e caktuar.
Vini re çfarë bën kolona e mesme. Çdo rresht kërkon një dokument që ose ekziston ose jo, gjë që e kthen një mendim në një rezultat që dikush mund ta prodhojë ose ta refuzojë.
Ndani klientin nga shërbimi
Një kontratë mbështetjeje për një aplikacion klienti nuk është angazhim për serverin ku arrin trafiku juaj. Përpara se të paraqisni prova, shënoni cilat pjesë të rrugës operohen nga partneri dhe cilat pjesë operohen nga ju në emër të tij. Përzierja e të dyjave prodhon një paketë dokumentesh që duket e plotë dhe nuk përgjigjet asgjëje.
Nëse vendosja është e juaja, partnerit mund t'i duhet të besojë vetëm një identitet dhe një rregull aksesi, që është një kërkesë shumë më e vogël sesa t'i besohet gjithë zinxhirit tuaj të furnizimit me software. Nëse vendosja është e tij, klienti që preferoni mund të jetë i parëndësishëm dhe konfigurimi i portës bëhet tema. Përcaktimi se në cilin rast jeni përpara takimit të dytë kursen një cikël rishikimi.
Pastaj kontrolloni pyetjet operative në të cilat rishikimet dështojnë vërtet: kush heq një llogari, sa shpejt dhe çfarë provash ekzistojnë më pas. Një vlerësim i dokumentuar bukur pa procedure heqjeje mbetet një gjetje e hapur.
Përfundoni me një vendim, jo me një debat
Përfundoni shkëmbimin me një rezultat të shkruar: versioni i pranuar, kontrollet e lidhura me të, operatorët e emërtuar, provat që mungojnë ende dhe data kur duhet të dorëzohen. Çdo gjë e pazgjidhur duhet të regjistrohet si kusht në vend që të përthithet në një deklaratë të përgjithshme miratimi.
Nëse politika emërton një produkt specifik të miratuar, përdorni rrugën e përjashtimit në vend që të ndërtoni një marrëveshje paralele që askush nuk e autorizoi. Një argument teknik bindës nuk jep leje, dhe një vendosje jozyrtare është një gjetje që pret të zbulohet.
Nëse një kërkesë vërtet nuk mund të plotësohet, kaloni në alternativën e miratuar dhe thoni pse. Qëllimi i ushtrimit është të përcaktohet se ku organizata mund të mbështetet, dhe një jo i qartë është rezultat më i mirë sesa një miratim që askush nuk mund ta mbrojë më vonë.