Bitcoin Core ფუნქციონირებს, როგორც ორ ტრილიონ დოლარზე მეტი ღირებულების მონეტარული ქსელის ხერხემალი. ფსონები უზარმაზარია და კოდის ბაზის დიდ ნაწილებს შეუძლიათ მაღალი ზემოქმედების შეცდომების შემცველობა. კონსენსუსის ძრავა, peer-to-peer (p2p) შეტყობინებების დამუშავების კოდი და კრიპტოგრაფიული ბიბლიოთეკები არის ის სფეროები, სადაც მოწყვლადობამ შეიძლება გამოიწვიოს ქურდობა, ქსელის გაჩერება ან სისტემისადმი ნდობის ფუნდამენტური შერყევა. ტრადიციული ფინანსური პროგრამული უზრუნველყოფისგან განსხვავებით, რომელიც დაზღვევითა და სამართლებრივი საშუალებებით არის გამყარებული, ბიტკოინის უსაფრთხოება მთლიანად დამოკიდებულია მისი კოდის ხარისხზე და იმ პროცესებზე, რომლებიც ამ ხარისხს ინარჩუნებენ. Bitcoin Core-ში უსაფრთხოებისადმი მიდგომა ფორმალურად არ არის განსაზღვრული, არამედ წარმოადგენს პრაქტიკის განვითარებად ერთობლიობას, რომელიც დროთა განმავლობაში გაუმჯობესდა. განხილვის პროცესები უფრო საფუძვლიანი გახდა, ტესტირების ინფრასტრუქტურა მნიშვნელოვნად გაფართოვდა და პროექტი მთლიანობაში უფრო კონსერვატიული და გააზრებული გახდა პროგრამული უზრუნველყოფის ცვლილებებთან დაკავშირებით. ეს ნელი ტემპი თავისთავად უსაფრთხოების ზომაა, რომელიც ამცირებს ახალი შეცდომების შემოტანის რისკს ნაჩქარევი მოდიფიკაციების გზით. ეს ნაწილი იკვლევს რამდენიმე ძირითად ასპექტს, თუ როგორ უდგება Bitcoin Core უსაფრთხოებას: ეს პრაქტიკები ერთად მუშაობს, თუმცა არა როგორც ერთიანი დიდი სტრატეგია, არამედ როგორც თავდაცვის დამატებითი ფენები, რომლებიც განვითარდა პროექტის მომწიფებასთან ერთად. Bitcoin Core, როგორც პროგრამული უზრუნველყოფის პროექტი, არ უზრუნველყოფს ავტომატური განახლების ფუნქციონალობას მის მიერ გამოშვებული პროგრამული უზრუნველყოფისთვის, რაც წარმოადგენს მომხმარებლების დაცვის ზომას მისი დეველოპერებისგან, და ყველა გამოშვებული ბინარული ფაილის გადამოწმება შესაძლებელია გამოქვეყნებულ საწყის კოდთან შესაბამისობაზე რეპროდუცირებადი აწყობის მეშვეობით. კვანძის ოპერატორები პასუხისმგებელნი არიან გადაწყვიტონ, პროგრამული უზრუნველყოფის რომელი ვერსია გაუშვან და როდის განაახლონ. უსაფრთხოების მოწყვლადობის კონტექსტში, ეს სერიოზულ დილემას წარმოადგენს. გამოსწორებები უნდა იყოს ღია წყარო განხილვის პროცესისთვის გამოშვებამდე, თუმცა სრული გამჟღავნება უნდა გადაიდოს, რათა მომხმარებლებს მიეცეთ განახლებისთვის გონივრული დრო, იმის გათვალისწინებით, რომ მოწყვლადობის დეტალების გამოქვეყნების შემდეგ, თავდამსხმელებს შეუძლიათ მისი ექსპლუატაცია. ისტორიულად, პროექტის მიერ უსაფრთხოების კრიტიკული მოწყვლადობების საჯარო გამჟღავნება, მიუხედავად იმისა, გარედან იყო მოხსენებული თუ კონტრიბუტორების მიერ აღმოჩენილი, არაადეკვატური იყო. ამან გამოიწვია სიტუაცია, როდესაც ბევრი მომხმარებელი Bitcoin Core-ს აღიქვამდა, როგორც არასდროს შეცდომების მქონეს, რაც საშიში და არაზუსტი აღქმაა. დაახლოებით წელიწადნახევრის წინ, ამ საკითხებით მოტივირებულმა, პროექტმა გადახედა და ფორმალურად განსაზღვრა უსაფრთხოების საკითხების დამუშავება ყოვლისმომცველ გამჟღავნების პოლიტიკად და საკონსულტაციო პროცესად. მიზნები იყო მეტი გამჭვირვალობის უზრუნველყოფა, უსაფრთხოების მკვლევრებისთვის მკაფიო მოლოდინების დადგენა (მათთვის სტიმულის მიცემა მოწყვლადობების პოვნისა და პასუხისმგებლობით გამჟღავნებისთვის), მოძველებული ვერსიების გაშვების რისკების უკეთ კომუნიკაცია და უსაფრთხოების შეცდომების ხელმისაწვდომობა კონტრიბუტორების უფრო ფართო ჯგუფისთვის გამჟღავნების შემდეგ, რათა დაეხმაროს მათ სწავლაში და მომავალი შეცდომების თავიდან აცილებაში. როდესაც პროექტს ეცნობება მოწყვლადობის შესახებ, ის ჯერ მოწმდება და ფასდება Bitcoin Core-ის „უსაფრთხოების გუნდის“ მიერ, რომელიც არის მცირე ჯგუფი გრძელვადიანი კონტრიბუტორებისა, რომლებსაც აქვთ უსაფრთხოების შეცდომების პოვნის ან გამოსწორების გამოცდილება. პროექტი მოწყვლადობებს ყოფს ოთხ სიმძიმის დონედ: კრიტიკული (ქსელის მთლიანობის საფრთხეები, როგორიცაა მონეტების ქურდობა ან ინფლაცია), მაღალი (მნიშვნელოვანი ზემოქმედება, დისტანციურად ექსპლუატირებადი), საშუალო (მუშაობის გაუარესება ან შეზღუდული მასშტაბი) და დაბალი (ძნელად ექსპლუატირებადი მცირე ზემოქმედებით). თუ სერიოზულად დადასტურდა, გამოსწორება შემუშავდება და საფუძვლიანად იტესტება პირადად. შემდეგ გამოსწორება წარდგენილია, როგორც pull request, ისევე როგორც ნებისმიერი სხვა კოდის ცვლილება, მაგრამ PR-ის აღწერა და დისკუსია აბუნდოვნებს გამოსწორების ნამდვილ ბუნებას. ის შეიძლება ჩამოყალიბდეს, როგორც რეფაქტორინგი, მუშაობის გაუმჯობესება ან პოტენციური პრობლემებისგან დაცვა. ეს საშუალებას აძლევს გამოსწორებას გაიაროს ნორმალური კოდის განხილვა, ხოლო მოწყვლადობის დეტალები კონფიდენციალურად რჩება. ეს მიდგომა მოიცავს რეალურ კომპრომისებს და მისი შენარჩუნება ნამდვილად რთული ბალანსირების აქტია. კრიტიკოსებმა შეიძლება იკამათონ, რომ ეს პატერნალისტურია ან რომ ის ზედმეტ ძალაუფლებას აკონცენტრირებს რამდენიმე დეველოპერის ხელში, რომლებმაც იციან მოწყვლადობების შესახებ საზოგადოებამდე. ეს შეშფოთებები სერიოზულ განხილვას იმსახურებს, მაგრამ დაუყოვნებელი საჯარო გამჟღავნების ალტერნატივა შეიძლება კატასტროფული იყოს. მოწყვლადობის დეტალების გამოქვეყნება მომხმარებლების უმეტესობის განახლებამდე არსებითად აწვდის თავდამსხმელებს როგორც სამიზნე სიას (განუახლებელი კვანძები), ასევე იარაღს (ექსპლოიტის კოდი). ფაზინგი არის ტესტირების ტექნიკა, რომელიც პროგრამულ უზრუნველყოფას აწვდის შემთხვევით, არასწორად ფორმირებულ ან მოულოდნელ შეყვანებს შეცდომების მოსაძებნად. ძირითადად, ის უწყვეტად ავტომატურად წარმოქმნის და ცვლის სატესტო შემთხვევებს, აწვდის მათ პროგრამას და აკვირდება მოულოდნელ ქცევას, როგორიცაა კრაშები, გაჭედვები, ლოგიკური შეცდომები და ა.შ. თანამედროვე ფაზერები იყენებენ ევოლუციურ ალგორითმებს იმის გასარკვევად, თუ რომელი შეყვანები იწვევს საინტერესო კოდის გზებს, შემდეგ კი ცვლიან ამ შეყვანებს პროგრამაში უფრო ღრმად შესასწავლად. ეს არის ეფექტური გზა ისეთი კიდეების შემთხვევების შეცდომების მოსაძებნად, რომელთა აღმოჩენა თითქმის შეუძლებელი იქნებოდა ხელით ტესტირებით ან კოდის განხილვით იმავე სიჩქარით. იმის გამო, რომ ფაზერი უზრუნველყოფს ამ ტესტირებისთვის შეყვანებს, დეველოპერს არ შეუძლია პირდაპირ დაადასტუროს მოსალოდნელი შედეგები (მაგ., შეყვანა A უნდა იძლეოდეს გამოსავალ B-ს). ამის ნაცვლად, ისინი აკეთებენ განცხადებებს ზოგადი თვისებების შესახებ, რომლებიც პროგრამულმა უზრუნველყოფამ უნდა შეინარჩუნოს. ეს უაღრესად ღირებულია, რადგან ის საშუალებას გვაძლევს ავაშენოთ უფრო ფართო ნდობა სასურველი ქცევის მიმართ ისეთი თვისებების ტესტირებით, როგორიცაა კვანძის კრაშის თავიდან აცილება ან მონეტების მიწოდების არასდროს გაზრდის უზრუნველყოფა მოსალოდნელზე მეტად. სისწორის, სიმტკიცის და უსაფრთხოების კრიტიკული საჭიროების გამო, Bitcoin Core ფართოდ იყენებს ფაზინგს სხვადასხვა მიდგომით. Bitcoin Core-ის ისტორიის განმავლობაში, ფაზ ტესტირების ძალისხმევა იზრდებოდა. ძალიან პრიმიტიული ფაზინგის ყველაზე ადრეული ხსენებები 2012 წლით თარიღდება და მარტივი ფაზინგის ფრეიმვორკის ინტეგრაცია მოხდა 2016 წელს, რომელიც დღევანდელ ყოვლისმომცველ ფრეიმვორკად გადაიქცა 200-ზე მეტი ინდივიდუალური ფაზ ტესტით, რომელიც მოიცავს კოდის ბაზის კრიტიკულ ინდივიდუალურ კომპონენტებსა და ფუნქციებს. სტანდარტული ერთეულის ტესტებისგან განსხვავებით, ფაზ ტესტებს არ აქვთ განსაზღვრული „გავლის“ წერტილი, ანუ თქვენ არ ატარებთ მათ ერთხელ და არ იღებთ „გავლილი“ ან „ჩავარდნილი“ სტატუსს სანაცვლოდ. იმის გამო, რომ ფაზინგი მიმდინარე შემთხვევითი პროცესია, შედეგების შესახებ ნებისმიერი განცხადება (როდესაც ხარვეზები არ არის ნაპოვნი) შეიძლება იყოს მხოლოდ ალბათობითი. ფაზ ტესტი შეიძლება გაგრძელდეს 5000 საათის განმავლობაში შეცდომის პოვნის გარეშე, თუმცა შემდეგმა 5000 საათმა შეიძლება აღმოაჩინოს ერთი. შესაბამისად, ეფექტურობისთვის, ფაზ ტესტები უწყვეტად უნდა შესრულდეს. მიუხედავად იმისა, რომ Bitcoin Core ეყრდნობა Google-ის oss-fuzz ინფრასტრუქტურას თავისი ფაზ ტესტების გასაშვებად, ის ასევე დიდ ინვესტიციას ახორციელებს საკუთარის მშენებლობაში, რამდენიმე კონტრიბუტორი უწყვეტად ატარებს ფაზინგს საკუთარი დაყენებებით. მაგალითად, Brink-ის ინფრასტრუქტურა მარტო უზრუნველყოფს წელიწადში 1 მილიონზე მეტ CPU საათს Bitcoin Core-ის ფაზინგისთვის. მიუხედავად იმისა, რომ Bitcoin Core-ის რეპოზიტორიუმს აქვს მრავალი ფაზ ტესტი კომპონენტის/ფუნქციის დონეზე, რამდენიმე გარე პროექტი იყენებს განსხვავებულ ფაზინგის სტრატეგიებს. Cryptofuzz, რომელიც ახლა პენსიაზეა გასული, ფოკუსირებული იყო დიფერენცი