Bakit tinatanggihan ang open source na VPN sa pagbili
Ang isang tagasuri na tumututol sa open source ay karaniwang nagpoprotekta ng isang pangangailangan, hindi ng panlasa sa lisensya. Itanong kung alin, at pagkatapos ay ihanda ang dokumentong sumasagot dito.
Ang mga pagtanggi na nagbabanggit ng open source ay bihirang tungkol sa paglilisensya. Karaniwang nagpoprotekta ang tagasuri ng isang pangangailangan: na may nagpapanatili ng naka-deploy na release, na makikilala ang naka-install na build, na may pagsusuri na sumasaklaw sa kung ano ang konektado, o na maaaring bawiin ang koneksyon. Ang debate na sumusunod ay karaniwang sumasagot sa isang tanong na walang nagtanong.
Itanong kung aling pangangailangan ang naaangkop bago ipagtanggol ang isang lisensya. Ang sagot ang magpapasya kung aling dokumento ang kailangan mo.
Ang label ay hindi ang pangangailangan
Ang nababasang source code ay nangangahulugang maaaring siyasatin ang inilathalang implementasyon. Hindi ito nangangahulugang may sumiyasat dito, na tumutugma ang build sa gateway sa inilathala, o na may utang na pagwawasto ang isang tagapangalaga sa iyong deployment. Bawat isa sa mga ito ay hiwalay na pahayag na may hiwalay na may-ari, at ang tagasuring nangangailangan ng isa sa mga ito ay hindi makukuntento sa iba. Ang pagsabi ng pahayag nang malakas ay karaniwang sapat upang baguhin ang usapan.
Ang kabaligtarang pagkakamali ay kasing karaniwan. Ang isang komersyal na lisensya ay hindi nagpapatunay na sinasaklaw ng suporta ang tampok na iyong pinagkakatiwalaan, na sinuri ng isang pagsusuri ang bahaging iyong ide-deploy, o na magpapadala ang vendor ng pagwawasto sa loob ng iyong window ng maintenance. Ang paglilisensya ay naglalarawan ng mga tuntunin ng distribusyon, samantalang ang mga desisyon sa pagbili ay tungkol sa pagtitiwala. Sa alinmang kaso, ang lisensya ang pinakamaliit na nagbibigay-kaalaman na bahagi ng sagot.
Paghiwalayin din ang kliyente at ang serbisyo. Ang isang audit ng desktop client ay walang sinasabi tungkol sa configuration ng gateway ng kasosyo, sa provider ng identity nito, o sa paraan ng paghawak ng mga operator nito sa pagtanggal ng account. Anumang ebidensyang tipunin mo ay dapat tumugma sa hangganang hinihiling sa kasosyo na pagkatiwalaan.
Gawing dokumento ang pag-aalala
Hilingin sa nag-aapruba na sabihin ang pangangailangan sa isang pangungusap, pagkatapos ay pangalanan ang dokumentong tutugon dito. Ang malabong katiyakan ang nagiging dahilan upang maging debate tungkol sa ideolohiya ang mga usapang ito.
| 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 ay kapaki-pakinabang dito sa isang makitid na dahilan: binabalangkas nito ang mga usapan sa pagbili sa paligid ng isang karaniwang bokabularyo ng mga kasanayan at komunikasyon sa mga supplier. Sinusuportahan nito ang paghingi ng tinukoy na ebidensya sa halip na makipagtalo tungkol sa isang label, at hindi ito isang sertipikasyon na pinapasa ng anumang partikular na VPN.
Pansinin ang ginagawa ng gitnang hanay. Ang bawat hilera ay humihingi ng dokumentong mayroon o wala, na ginagawang resulta ang isang opinyon na maaaring gawin o tanggihan ng isang tao.
Paghiwalayin ang kliyente at ang serbisyo
Ang kontrata ng suporta para sa isang client application ay hindi pangako tungkol sa server na naaabot ng iyong trapiko. Bago magpakita ng ebidensya, markahan kung aling bahagi ng landas ang pinapatakbo ng kasosyo at aling bahagi ang pinapatakbo mo sa ngalan nito. Ang paghahalo ng dalawa ay gumagawa ng isang pakete ng mga dokumento na mukhang masinsin at walang sinasagot.
Kung sa iyo ang deployment, maaaring kailanganin lamang ng kasosyo na magtiwala sa isang identity at isang patakaran sa pag-access, na isang mas maliit na kahilingan kaysa magtiwala sa buong supply chain ng software. Kung sa kanya ang deployment, maaaring hindi naaangkop ang kliyenteng gusto mo at ang configuration ng gateway ang nagiging paksa. Ang pag-alam kung aling kaso ang nasa iyo bago ang ikalawang pulong ay nakakatipid ng isang cycle ng pagsusuri.
Pagkatapos ay suriin ang mga operational na tanong kung saan talagang nabigo ang mga pagsusuri: sino ang nagtatanggal ng account, gaano kabilis, at anong ebidensya ang natitira pagkatapos. Ang isang magandang naidokumentong pagsusuri na walang pamamaraan sa pagtanggal ay nananatiling bukas na natuklasan.
Tapusin sa desisyon, hindi sa debate
Tapusin ang pagpapalitan sa isang nakasulat na resulta: ang tinanggap na bersyon, ang mga kontrol na nakalakip dito, ang mga pinangalanang operator, ang ebidensyang kulang pa, at ang petsa kung kailan ito dapat isumite. Anumang hindi pa nalutas ay dapat itala bilang kondisyon sa halip na isipsip sa isang pangkalahatang pahayag ng pag-apruba.
Kung pinangalanan ng patakaran ang isang partikular na aprubadong produkto, gamitin ang daan ng pagbubukod sa halip na bumuo ng parallel na kasunduan na walang pinahintulutan. Ang isang nakakumbinsing teknikal na argumento ay hindi nagbibigay ng pahintulot, at ang isang hindi opisyal na deployment ay isang natuklasang naghihintay na matuklasan.
Kung ang isang pangangailangan ay talagang hindi matugunan, lumipat sa aprubadong alternatibo at sabihin kung bakit. Ang layunin ng pagsasanay ay itatag kung ano ang maaaring asahan ng organisasyon, at ang malinaw na hindi ay isang mas mabuting resulta kaysa sa isang pag-apruba na walang maipagtatanggol mamaya.