खरेदी प्रक्रियेत ओपन सोर्स VPN का नाकारला जातो
ओपन सोर्सला आक्षेप घेणारा पुनरावलोकक सामान्यतः एक आवश्यकता रक्षित करतो, लाइसन्सची आवड नव्हे. कोणती ते विचारा, नंतर त्याला उत्तर देणारा दस्तऐवज तयार करा.
ओपन सोर्सचा उल्लेख करणारे नकार क्वचितच लाइसन्सिंगशी संबंधित असतात। पुनरावलोकक सामान्यतः एक आवश्यकता रक्षित करतो: एखाद्याने तैनात केलेली आवृत्ती सांभाळावी, स्थापित बिल्ड ओळखता यावे, मूल्यांकन जे जोडले जाते ते व्यापावे, किंवा जोडणी मागे घेता यावी। त्यानंतरची चर्चा सामान्यतः कोणीही न विचारलेल्या प्रश्नाचे उत्तर देते।
लाइसन्सचा बचाव करण्यापूर्वी कोणती आवश्यकता लागू होते ते विचारा। उत्तर ठरवते की तुम्हाला कोणता दस्तऐवज हवा आहे।
लेबल ही आवश्यकता नाही
वाचनीय स्रोत कोड म्हणजे प्रकाशित अंमलबजावणीची तपासणी करता येते। याचा अर्थ असा नाही की कोणी ती तपासली, गेटवेवरील बिल्ड प्रकाशित बिल्डशी जुळते, किंवा एखादा देखभालकर्ता तुमच्या तैनातीला दुरुस्ती देणे लागतो। यातील प्रत्येक वेगळ्या मालकासह वेगळा दावा आहे, आणि यातील एक आवश्यक असलेला पुनरावलोकक बाकीच्यांनी समाधानी होणार नाही। दावा मोठ्याने म्हणणे सामान्यतः संभाषण बदलण्यासाठी पुरेसे असते।
उलटी चूकही तितकीच सामान्य आहे। व्यावसायिक लाइसन्स हे सिद्ध करत नाही की आधार तुम्ही अवलंबून असलेले वैशिष्ट्य व्यापते, मूल्यांकनाने तुम्ही तैनात करत असलेला घटक तपासला, किंवा विक्रेता तुमच्या देखभाल कालावधीत दुरुस्ती पाठवेल। लाइसन्सिंग वितरणाच्या अटी वर्णन करते, तर खरेदीचे निर्णय विश्वासाशी संबंधित असतात। दोन्ही बाबतीत लाइसन्स हा उत्तराचा सर्वात कमी माहितीपूर्ण भाग असतो।
क्लायंट आणि सेवा वेगळे ठेवा। डेस्कटॉप क्लायंटचे ऑडिट भागीदाराच्या गेटवे कॉन्फिगरेशन, त्याच्या ओळख पुरवठादाराबद्दल किंवा त्याचे ऑपरेटर खाते काढणे कसे हाताळतात याबद्दल काहीही सांगत नाही। तुम्ही गोळा करता तो कोणताही पुरावा भागीदाराला विश्वास ठेवण्यास सांगितलेल्या सीमेशी जुळला पाहिजे।
काळजीचे दस्तऐवजात रूपांतर करा
मंजुरी देणाऱ्याला आवश्यकता एका वाक्यात सांगायला सांगा, नंतर ती पूर्ण करणाऱ्या दस्तऐवजाचे नाव सांगा। अस्पष्ट आश्वासनच या संभाषणांचे विचारसरणीच्या वादात रूपांतर करते।
| 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 येथे एका संकुचित कारणासाठी उपयुक्त आहे: ते खरेदीच्या संभाषणांना पद्धती आणि पुरवठादारांशी संवाद यांच्या सामायिक शब्दसंग्रहाभोवती चौकटबद्ध करते। हे लेबलबद्दल वाद घालण्याऐवजी निर्दिष्ट पुरावे मागण्यास पाठबळ देते, आणि हे कोणत्याही विशिष्ट VPN ला उत्तीर्ण होणारे प्रमाणपत्र नाही।
मधला स्तंभ काय करतो ते पहा। प्रत्येक ओळ अशा दस्तऐवजाची मागणी करते जो आहे किंवा नाही, आणि हे मताचे अशा परिणामात रूपांतर करते जो कोणी तयार करू किंवा नाकारू शकतो।
क्लायंट आणि सेवा वेगळे ठेवा
क्लायंट अनुप्रयोगासाठीचा आधार करार तुमचा रहदारी ज्या सर्व्हरवर पोहोचतो त्याबद्दलची वचनबद्धता नाही। पुरावे सादर करण्यापूर्वी मार्गाचे कोणते भाग भागीदार चालवतो आणि कोणते भाग तुम्ही त्याच्या वतीने चालवता ते चिन्हांकित करा। दोन्ही मिसळल्यास बारकाईने दिसणारे पण कशाचेही उत्तर न देणारे दस्तऐवज संच तयार होतो।
जर तैनाती तुमची असेल, तर भागीदाराला फक्त एक ओळख आणि एक प्रवेश नियमावर विश्वास ठेवण्याची गरज पडू शकते, जी तुमच्या संपूर्ण सॉफ्टवेअर पुरवठा साखळीवर विश्वास ठेवण्यापेक्षा खूपच लहान विनंती आहे। जर तैनाती त्याची असेल, तर तुम्हाला आवडणारा क्लायंट अप्रासंगिक ठरू शकतो आणि गेटवे कॉन्फिगरेशन विषय बनते। दुसऱ्या बैठकीपूर्वी तुम्ही कोणत्या स्थितीत आहात हे निश्चित करणे एक पुनरावलोकन चक्र वाचवते।
नंतर ज्या कार्यरत प्रश्नांवर पुनरावलोकने खरोखर अपयशी ठरतात ते तपासा: कोण खाते काढते, किती लवकर, आणि नंतर कोणता पुरावा अस्तित्वात असतो। काढण्याची प्रक्रिया नसलेले सुंदरपणे दस्तऐवजीकृत मूल्यांकनही खुले निरीक्षणच राहते।
वादाने नाही, निर्णयाने संपवा
देवघेव लिखित निकालाने संपवा: स्वीकारलेली आवृत्ती, तिच्याशी जोडलेले नियंत्रण, नामनिर्देशित ऑपरेटर, अजूनही प्रलंबित पुरावे आणि ते देण्याची तारीख। न सुटलेले काहीही सामान्य मंजुरीच्या विधानात विलीन करण्याऐवजी अट म्हणून नोंदवले पाहिजे।
जर धोरण विशिष्ट मंजूर उत्पादनाचे नाव घेते, तर कोणीही अधिकृत न केलेली समांतर व्यवस्था उभारण्याऐवजी अपवाद मार्ग वापरा। प्रभावी तांत्रिक युक्तिवाद परवानगी देत नाही, आणि अनधिकृत तैनाती शोधली जाण्याच्या प्रतीक्षेत असलेले निरीक्षण आहे।
जर एखादी आवश्यकता खरोखर पूर्ण करता येत नसेल, तर मंजूर पर्यायाकडे जा आणि का ते सांगा। या सरावाचा उद्देश संस्था कशावर विसंबून राहू शकते हे निश्चित करणे आहे, आणि स्पष्ट नाही हा नंतर कोणीही समर्थन करू न शकणाऱ्या मंजुरीपेक्षा चांगला निकाल आहे।