Miksi avoimen lähdekoodin VPN hylätään hankinnassa
Avoimeen lähdekoodiin vastustava arvioija suojaa yleensä vaatimusta, ei lisenssimakua. Kysy mitä, ja tuota sitten asiakirja, joka vastaa siihen.
Avoimeen lähdekoodiin viittaavat hylkäykset harvoin johtuvat lisensoinnista. Arvioija suojaa yleensä vaatimusta: että joku ylläpitää käyttöön otettua julkaisua, että asennettu build on tunnistettavissa, että arviointi kattaa sen, mitä yhdistetään, tai että yhteys voidaan peruuttaa. Seuraava keskustelu vastaa yleensä kysymykseen, jota kukaan ei esittänyt.
Kysy, mikä vaatimus pätee, ennen kuin puolustat lisenssiä. Vastaus ratkaisee, minkä asiakirjan tarvitset.
Tunniste ei ole vaatimus
Luettava lähdekoodi tarkoittaa, että julkaistu toteutus voidaan tarkastaa. Se ei tarkoita, että joku olisi tarkastanut sen, että yhdyskäytävän build vastaa julkaistua tai että ylläpitäjä on velkaa käyttöönotollesi korjauksen. Jokainen näistä on erillinen väite, jolla on erillinen omistaja, eikä arvioija, joka tarvitsee yhden niistä, tule tyydytetyksi muilla. Väitteen ääneen nimeäminen riittää yleensä muuttamaan keskustelun.
Vastakkainen virhe on yhtä yleinen. Kaupallinen lisenssi ei todista, että tuki kattaa toiminnon, johon luotat, että arviointi tutki komponentin, jonka otat käyttöön, tai että toimittaja toimittaa korjauksen ylläpitoikkunasi aikana. Lisensointi kuvaa jakeluehtoja, kun taas hankintapäätökset koskevat luottamusta. Kummassakin tapauksessa lisenssi on vastauksen vähiten informatiivinen osa.
Pidä asiakasohjelma ja palvelu erillään. Työpöytäasiakkaan auditointi ei kerro mitään kumppanin yhdyskäytävän kokoonpanosta, sen identiteetintarjoajasta tai siitä, miten sen operaattorit hoitavat tilien poistamisen. Keräämäsi todisteet on sovitettava siihen rajaan, jota kumppanin pyydetään luottamaan.
Muuta huoli asiakirjaksi
Pyydä hyväksyjää ilmaisemaan vaatimus yhdellä lauseella ja nimeä sitten asiakirja, joka täyttäisi sen. Juuri epämääräinen vakuuttelu muuttaa nämä keskustelut ideologiakiistaksi.
| 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 on hyödyllinen tässä yhdestä kapeasta syystä: se kehystää hankintakeskustelut yhteisen käytäntö- ja toimittajaviestintäsanaston ympärille. Se tukee määriteltyjen todisteiden pyytämistä tunnisteesta väittelemisen sijaan, eikä se ole sertifikaatti, jonka jokin tietty VPN läpäisee.
Huomaa, mitä keskimmäinen sarake tekee. Jokainen rivi pyytää asiakirjaa, joka joko on olemassa tai ei, mikä muuttaa mielipiteen toimitukseksi, jonka joku voi tuottaa tai kieltäytyä antamasta.
Erota asiakasohjelma palvelusta
Asiakassovelluksen tukisopimus ei ole sitoumus palvelimesta, johon liikenteesi päätyy. Ennen kuin esität todisteita, merkitse, mitkä polun osat kumppani ylläpitää ja mitkä sinä ylläpidät hänen puolestaan. Näiden sekoittaminen tuottaa asiakirjapaketin, joka näyttää perusteelliselta eikä vastaa mihinkään.
Jos käyttöönotto on sinun, kumppanin tarvitsee ehkä luottaa vain identiteettiin ja käyttösääntöön, mikä on paljon pienempi pyyntö kuin luottamus koko ohjelmistotoimitusketjuusi. Jos käyttöönotto on hänen, valitsemasi asiakasohjelma voi olla merkityksetön ja yhdyskäytävän kokoonpano nousee aiheeksi. Sen selvittäminen ennen toista tapaamista, kummassa tapauksessa olet, säästää yhden katselmusjakson.
Tarkista sitten toiminnalliset kysymykset, joissa katselmukset todella epäonnistuvat: kuka poistaa tilin, kuinka nopeasti ja mitä todisteita sen jälkeen on olemassa. Kauniisti dokumentoitu arviointi ilman poistomenettelyä on edelleen avoin havainto.
Päätä päätöksellä, älä väittelyllä
Lopeta vaihto kirjalliseen tulokseen: hyväksytty versio, siihen liitetyt valvonnat, nimetyt operaattorit, vielä puuttuvat todisteet ja päivä, jolloin ne erääntyvät. Kaikki ratkaisematon tulisi kirjata ehdoksi sen sijaan, että se imeytyisi yleiseen hyväksymislausumaan.
Jos käytäntö nimeää tietyn hyväksytyn tuotteen, käytä poikkeusreittiä sen sijaan, että rakentaisit rinnakkaisen järjestelyn, jota kukaan ei valtuuttanut. Vakuuttava tekninen perustelu ei anna lupaa, ja epävirallinen käyttöönotto on havainto, joka odottaa löytämistä.
Jos vaatimusta ei todella voida täyttää, siirry hyväksyttyyn vaihtoehtoon ja kerro miksi. Harjoituksen tarkoitus on selvittää, mihin organisaatio voi luottaa, ja selkeä ei on parempi lopputulos kuin hyväksyntä, jota kukaan ei voi myöhemmin puolustaa.