რატომ უარყოფენ ღია კოდის 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 გაივლის.
ყურადღება მიაქციეთ, რას აკეთებს შუა სვეტი. თითოეული სტრიქონი ითხოვს დოკუმენტს, რომელიც ან არსებობს ან არა, და ეს აზრს აქცევს შედეგად, რომლის წარმოდგენაც ან უარყოფაც ვინმეს შეუძლია.
გამოყავით კლიენტი სერვისისგან
კლიენტური აპლიკაციის მხარდაჭერის ხელშეკრულება ვალდებულება არ არის იმ სერვერზე, რომელსაც თქვენი ტრაფიკი აღწევს. მტკიცებულებების წარდგენამდე მონიშნეთ, გზის რომელ ნაწილებს მართავს პარტნიორი და რომელ ნაწილებს — თქვენ მისი სახელით. ორივეს შერევა ქმნის დოკუმენტების პაკეტს, რომელიც საფუძვლიანად გამოიყურება და არაფერს პასუხობს.
თუ განლაგება თქვენია, შესაძლოა პარტნიორს მხოლოდ იდენტობისა და წვდომის წესის ნდობა დასჭირდეს, რაც გაცილებით მცირე მოთხოვნაა, ვიდრე მთელი პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის ნდობა. თუ განლაგება მისია, თქვენ მიერ სასურველი კლიენტი შეიძლება უმნიშვნელო იყოს და კარიბჭის კონფიგურაცია გახდება თემა. იმის გარკვევა, რომელ შემთხვევაში ხართ, მეორე შეხვედრამდე დაზოგავს განხილვის ერთ ციკლს.
შემდეგ შეამოწმეთ ოპერაციული კითხვები, რომლებზეც განხილვები რეალურად ვარდება: ვინ შლის ანგარიშს, რამდენად სწრაფად და რა მტკიცებულება რჩება შემდეგ. ლამაზად დოკუმენტირებული შეფასება წაშლის პროცედურის გარეშე მაინც ღია აღმოჩენად რჩება.
დაასრულეთ გადაწყვეტილებით, არა დებატებით
დაასრულეთ გაცვლა წერილობითი შედეგით: მიღებული ვერსია, მასზე მიმაგრებული კონტროლი, დასახელებული ოპერატორები, ჯერ კიდევ დარჩენილი მტკიცებულებები და ვადა, როდის უნდა წარმოადგინონ ისინი. ყველაფერი გადაუწყვეტელი უნდა ჩაიწეროს პირობად და არა შეიწოვოს ზოგად დამტკიცების განაცხადში.
თუ პოლიტიკა ასახელებს კონკრეტულ დამტკიცებულ პროდუქტს, გამოიყენეთ გამონაკლისის გზა და არ ააშენოთ პარალელური შეთანხმება, რომელიც არავის უფლებამოსილებია. დამაჯერებელი ტექნიკური არგუმენტი ნებართვას არ იძლევა, და არაოფიციალური განლაგება აღმოჩენაა, რომელიც აღმოჩენას ელოდება.
თუ მოთხოვნის დაკმაყოფილება ნამდვილად შეუძლებელია, გადადით დამტკიცებულ ალტერნატივაზე და თქვით რატომ. ამ სავარჯიშოს მიზანია დაადგინოს, რას შეიძლება დაეყრდნოს ორგანიზაცია, და მკაფიო „არა“ უკეთესი შედეგია, ვიდრე დამტკიცება, რომელსაც მოგვიანებით ვერავინ დაიცავს.