अपने एसडीएलसी पर नीतियां लागू करने के लिए वैलेंट का उपयोग करना

साक्ष्य बनाने, प्रबंधित करने, हस्ताक्षर करने और सत्यापित करने के लिए वैलिन्ट मुख्य स्क्राइब टूल है। में एक पिछले पोस्ट, हमने आपके सीआई/सीडी पाइपलाइन की सुरक्षा को सत्यापित करने में मुख्य उपकरण के रूप में हस्ताक्षर करने और साक्ष्य को सत्यापित करने के सिद्धांत को कवर किया है। एक संक्षिप्त अनुस्मारक के रूप में, स्क्राइब के प्रस्तावित मॉडल में कई बिल्डिंग ब्लॉक शामिल हैं जिन्हें आपकी आवश्यकताओं के अनुरूप किसी भी तरह से घुमाया और ढेर किया जा सकता है। बिल्डिंग ब्लॉक्स में एकत्रित साक्ष्य शामिल हैं (एसओबीओएम, एसएलएसए उद्गम, कोई भी तृतीय पक्ष परीक्षण परिणाम जिसे आप शामिल करना चाहते हैं), एकत्र किए गए साक्ष्य का पर्यावरणीय संदर्भ (इसे किसने बनाया, कहां, कब, आदि), और वह नीति जिसे आप उस साक्ष्य पर लागू करना चाहते हैं।

चूंकि आप जिन नीतियों को अपने साक्ष्य पर लागू करना चाहते हैं, वे इस मॉडल में एक महत्वपूर्ण कारक हैं, हमने सोचा कि हम जिस नीति इंजन की पेशकश करते हैं उसकी संभावनाओं का अधिक विस्तार से पता लगाने के लिए हम एक ब्लॉग पोस्ट समर्पित करेंगे।

इस लेख में, हम अपने द्वारा तैयार की गई सबसे बुनियादी नीति पर चर्चा करेंगे (जानकारी पर हस्ताक्षर करें और सत्यापित करें)। हम कवर करेंगे कि अधिक जटिल नीति का टेम्प्लेट कैसा दिखता है और नीतियों के लिए कुछ मानक उदाहरण देंगे जैसे कि कैसे सत्यापित करें कि एक विशिष्ट उपयोगकर्ता वह था जिसने अंतिम 'मुख्य' शाखा बनाई थी, या कैसे सत्यापित करें कि आपकी पाइपलाइन चलती है इसमें एक तृतीय पक्ष टूल परीक्षण शामिल है जिसे अवश्य शामिल किया जाना चाहिए।

यहां प्रारंभ करें: साक्ष्य पर हस्ताक्षर करना और सत्यापन करना

वैलिंट एक बहुत ही बहुमुखी उपकरण है लेकिन इस लेख को सरल रखने के लिए हम उदाहरण के तौर पर मुख्य रूप से वैलिन्ट के सीएलआई इंटरफ़ेस का उपयोग करेंगे।

पहला कदम वैलेंट डाउनलोड करना होगा:

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

रिपॉजिटरी या छवि से एसबीओएम बनाने का आदेश 'बॉम' है। तो, उदाहरण के लिए, यदि आप चाहते हैं bom की छवि busybox:latest कमांड इस तरह दिखेगा:

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

ध्यान दें कि attest के लिए एक उपनाम है attest-cyclonedx-json.

डिफ़ॉल्ट रूप से, वैलेंट का उपयोग किया जा रहा है सिगस्टोर स्क्राइब की कोकोसाइन लाइब्रेरी में अंतर्निहित हस्ताक्षर तंत्र के पीछे इंजन के रूप में इंटरैक्टिव प्रवाह। यह लाइब्रेरी हस्ताक्षर और सत्यापन के लिए डिजिटल हस्ताक्षर से संबंधित है। एक बार जब आप आदेश लागू कर देते हैं तो आपको पहले यह स्वीकृत करना होगा कि आप Y/[N] विकल्प के साथ साक्ष्य पर हस्ताक्षर करना चाहते हैं:

आप हस्ताक्षर करने के लिए मानक PKI का भी उपयोग कर सकते हैं (हम x509 प्रमाणपत्रों का समर्थन करते हैं)। हस्ताक्षर कुंजी संग्रहीत करने के लिए कई विकल्प हैं - उदाहरण के लिए केएमएस, गिटहब गुप्त स्टोर, और आप अपनी इच्छानुसार किसी भी हस्ताक्षर तंत्र का उपयोग करने के लिए वैलेंट को आसानी से कॉन्फ़िगर कर सकते हैं।

यह मानते हुए कि आपने हस्ताक्षर को मंजूरी दे दी है, आपको अपने ब्राउज़र में सिगस्टोर पर निर्देशित किया जाएगा जहां आपको अपने GitHub खाते, अपने Google खाते या अपने Microsoft खाते का उपयोग करके लॉग इन करना होगा:

एक बार साइन इन करने के बाद आप देखेंगे कि लॉगिन सफल रहा:

उस बिंदु पर आप ब्राउज़र को बंद कर सकते हैं और अपने शेल पर वापस जा सकते हैं जहां आप देख सकते हैं कि साक्ष्य सफलतापूर्वक बनाया गया था।

सत्यापन डिफ़ॉल्ट रूप से स्थानीय कैश में लिखा जाता है जिसका स्थान इसके द्वारा प्रदान किया जाता है --output-directory कॉन्फ़िगरेशन फ़ाइल ध्वज में ध्वज. आप भी उपयोग कर सकते हैं -आउटपुट फ़ाइल सत्यापन के लिए एक कस्टम पथ प्रदान करने के लिए ध्वज।

अब जब हमने एक हस्ताक्षरित सत्यापन बना लिया है, तो आइए यह सत्यापित करने का प्रयास करें कि यह मौजूद है और हस्ताक्षरित है। साक्ष्य सत्यापित करने का आदेश है verify. इसे इस्तेमाल करने का तरीका लगभग एक जैसा ही है bom कमांड, सिवाय इसके कि हम ध्वज का उपयोग करेंगे -iजिसके लिए कम है --input-format और इसके लिए डिफ़ॉल्ट है, जैसे कि bom, attest-cyclonedx-json. सत्यापित कमांड सबसे पहले वैलेंट द्वारा उपयोग किए गए डिफ़ॉल्ट स्थान पर आवश्यक साक्ष्य की तलाश करेगा। यदि आप साक्ष्य को सहेजने और बाद में उसे खोजने दोनों के लिए एक अलग स्थान निर्दिष्ट कर सकते हैं।

इसलिए, यदि हम सत्यापित करना चाहते हैं busybox:latest छवि सत्यापन हमने पिछले उदाहरण में तैयार और हस्ताक्षरित किया है, कमांड इस तरह दिखेगा:

$HOME/.scribe/bin/valint verify busybox:latest -i attest

यह मानते हुए कि आपने सब कुछ ठीक किया, परिणाम इस तरह दिखना चाहिए:

आप उन ईमेल की सूची देख सकते हैं जिनमें मूल सत्यापन पर हस्ताक्षरकर्ता ईमेल शामिल है और आप सत्यापन का प्रकार भी देख सकते हैं जिसे सत्यापित किया गया था, इस मामले में, साइक्लोनडएक्स-जेसन। 

बहुत सीधा लगता है ना? आइए इसे एक पायदान ऊपर उठाएं।

नीति टेम्पलेट्स

A नीति का एक सेट शामिल है मॉड्यूल। नीति को सत्यापित किया जाता है यदि इसमें शामिल सभी मॉड्यूल का मूल्यांकन और सत्यापन किया जाता है। यदि कोई सबूत मिलता है जो मॉड्यूल कॉन्फ़िगरेशन और सेटिंग का अनुपालन करता है तो एक मॉड्यूल सत्यापित किया जाता है।  

नीतियों को नीति अनुभाग के अंतर्गत वैलेंट की कॉन्फ़िगरेशन फ़ाइल के भाग के रूप में कॉन्फ़िगर किया गया है। यह वैलेंट कॉन्फ़िगरेशन फ़ाइल के भाग का एक उदाहरण है, संभावित नीतियों वाला भाग। 

याद रखें कि आपको अपने प्रोजेक्ट में कॉन्फ़िगरेशन फ़ाइल शामिल करने की ज़रूरत नहीं है - केवल डिफ़ॉल्ट विकल्प सक्षम होने पर वैलेंट ठीक काम कर सकता है। इसके अतिरिक्त, चूँकि इस फ़ाइल में सब कुछ वैकल्पिक है, ऐसी फ़ाइल का होना पूरी तरह से मान्य है जिसमें केवल आपकी नीतियाँ शामिल हों। 

कॉन्फ़िगरेशन फ़ाइल, जिसे डिफ़ॉल्ट रूप से .valint.yaml नाम दिया गया है, को आपके रिपॉजिटरी के मूल में शामिल किया जाना चाहिए। जब आप कमांड चलाते हैं तो आप इस फ़ाइल में जो भी नीतियाँ शामिल करते हैं उसके आधार पर valint verify यह उन सभी नीतियों और मॉड्यूलों को चलाएगा जो सक्षम हैं। क्योंकि मूल 'सत्यापन' नीति डिफ़ॉल्ट है, आपको इसके लिए कुछ भी कॉन्फ़िगर करने की आवश्यकता नहीं है verify .valint.yaml फ़ाइल के बिना भी ठीक से काम करने का आदेश।

कॉन्फ़िगरेशन फ़ाइल में आप जो भी नीति जोड़ते हैं, वह साक्ष्य की तलाश पर निर्भर होती है। डिफ़ॉल्ट रूप से, जब आप अपनी पाइपलाइन में 'बॉम' कमांड चलाते हैं तो परिणामी साक्ष्य स्क्राइब साक्ष्य स्टोर पर अपलोड कर दिए जाएंगे। इसी तरह, जब आप 'सत्यापन' कमांड चलाते हैं, तो यह स्क्राइब साक्ष्य भंडार में साक्ष्य की तलाश करेगा। आप इस डिफ़ॉल्ट को बदल सकते हैं और अपने साक्ष्य भंडार के रूप में ओसीआई या कैश का उपयोग कर सकते हैं, लेकिन इस लेख के लिए, हम मान लेंगे कि डिफ़ॉल्ट का उपयोग किया गया है और सभी साक्ष्य अपलोड किए गए हैं और स्क्राइब साक्ष्य भंडार से खींचे गए हैं।

तो, इस उदाहरण के आधार पर आइए एक नीति के घटकों को देखें। नीति निम्नलिखित क्षेत्रों का समर्थन करता है:

• नाम, पॉलिसी का नाम (आवश्यक)।
• सक्षम, मॉड्यूल सक्षम करें (डिफ़ॉल्ट गलत है)।
• मॉड्यूल, नीति मॉड्यूल कॉन्फ़िगरेशन की सूची।  

 

RSI मॉड्यूल अनुभाग निम्नलिखित क्षेत्रों का समर्थन करते हैं:

• नाम, नीति मॉड्यूल नाम (आवश्यक)।
• सक्षम, मॉड्यूल सक्षम करें (डिफ़ॉल्ट गलत है)।
• टाइप, मॉड्यूल का प्रकार, वर्तमान में समर्थन सत्यापन-विरूपण साक्ष्य और गिट-मालिक.
• मैच, एक विशिष्ट संदर्भ के साथ साक्ष्य का मिलान करें।
• निवेश, मॉड्यूल-विशिष्ट कॉन्फ़िगरेशन।

एक नीति में कई मॉड्यूल हो सकते हैं और आपके द्वारा 'सत्यापित' कमांड निष्पादित करने के बाद सभी सक्षम मॉड्यूल चलाए जाएंगे। 

चूँकि मुझे पता है कि फ़ील्ड की सूखी सूची बहुत जानकारीपूर्ण नहीं है, आइए सीधे अगले अनुभाग, नमूना नीतियों पर जाएँ।

नमूना नीतियाँ

छवि सत्यापन नीति

आइए सबसे सरल नीति से शुरू करें, जो वैलेंट साइन-सत्यापन प्रवाह को व्यक्त करती है। 

प्रमाणित करें: कोकोसाइन: नीतियां: - नाम: सत्यापित_पॉलिसी सक्षम करें: वास्तविक मॉड्यूल: - नाम: हस्ताक्षरित_एसबॉम प्रकार: सत्यापन-विरूपण साक्ष्य सक्षम: सही इनपुट: हस्ताक्षरित: सही प्रारूप: सत्यापित-साइक्लोनएक्स-जेसन पहचान: ईमेल: - barak@scribesecurity.com

फिर से, इस नीति को आपके भंडार के मूल में .valint.yaml फ़ाइल में शामिल किया जाना चाहिए। इसे काम करने के लिए आपको पहले से ही एक हस्ताक्षरित एसबीओएम चलाकर तैयार करना होगा valint bom आज्ञा। एक बार जब आप इसे सत्यापित करने के लिए तैयार हों तो आपको इसे चलाने की आवश्यकता होगी valint verify आदेश।

इस उदाहरण को देखकर हम देख सकते हैं कि नीति सक्षम है और इसमें एक प्रकार का सक्षम मॉड्यूल है ‘verify-artifact‘. मॉड्यूल जाँचता है कि इनपुट हस्ताक्षरित है, प्रारूप का है ‘attest-cyclonedx-json’, और यह ईमेल द्वारा दर्शाई गई पहचान द्वारा हस्ताक्षरित था ‘barak@scribesecurity.com’.

इस नीति को चलाने के लिए हमें इसे क्रियान्वित करने की आवश्यकता होगी verifyहमारी पाइपलाइन में कमांड इस प्रकार है:

valint verify busybox:latest

के बाद से verify कमांड अब हमारे द्वारा प्रदान की गई नीति पर आधारित है, यह एक की तलाश करेगा busybox:latest आपके स्क्राइब साक्ष्य भंडार में साक्ष्य का टुकड़ा। यह प्रारूप के हस्ताक्षरित एसबीओएम की तलाश करेगा `cyclonedx-json` और यह जांच करेगा कि एसबीओएम पर हस्ताक्षर करने वाली पहचान पॉलिसी में निर्धारित ईमेल का उपयोग करती है `barak@scribesecurity.com`.

आप कह सकते हैं कि उस साक्ष्य भंडार में ऐसी कई छवियां हो सकती हैं और आप सही हैं। यहीं पर संदर्भ सामने आता है। डिफ़ॉल्ट रूप से, verify कमांड उपलब्ध निकटतम मिलान की तलाश करेगा। हालाँकि, आप निर्दिष्ट कर सकते हैं कि कमांड को पाइपलाइन रन आईडी या बिल्ड सिस्टम के संदर्भ से मेल खाना होगा जिसमें आर्टिफैक्ट बनाया गया था। ऐसा करने के लिए आपको फ़ील्ड का उपयोग करने की आवश्यकता होगी match: उपयुक्त संदर्भ प्रकार के साथ. उदाहरण के लिए:

            मिलान: context_type: github git_url: github.com/my_org/myimage.git शाखा: मुख्य

इस मामले में, साक्ष्य जीथब द्वारा, नामित भंडार द्वारा तैयार किया जाना था git_url और द्वारा main उस भंडार की शाखा. यह सुनिश्चित करने के लिए कि आपकी नीतियां बिल्कुल वही सत्यापित करती हैं जो आप उनसे सत्यापित कराना चाहते हैं, जहां आवश्यक हो वहां सही संदर्भ का उपयोग करना महत्वपूर्ण है। 

बाइनरी सत्यापन नीति

आइए एक और उदाहरण देखें. यह नीति यह सत्यापित करने के लिए है कि जिस exe फ़ाइल की हम जाँच कर रहे हैं वह एक विशिष्ट रिपॉजिटरी से आई है और कई ज्ञात व्यक्तियों में से एक द्वारा हस्ताक्षरित है। 

प्रमाणित करें: कोकोसाइन: नीतियां: - नाम: सत्यापित_पॉलिसी सक्षम करें: वास्तविक मॉड्यूल: - नाम: बाइनरी_मॉड्यूल प्रकार: सत्यापन-विरूपण साक्ष्य सक्षम करें: सही इनपुट: हस्ताक्षरित: सही प्रारूप: सत्यापित-साइक्लोनएक्स-जेसन पहचान: ईमेल: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com मिलान: target_type: फ़ाइल context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # पर्यावरण का Git url। इनपुट_नाम: my_binary.exe

इस उदाहरण को देखकर हम देख सकते हैं कि नीति सक्षम है और इसमें एक प्रकार का सक्षम मॉड्यूल है ‘verify-artifact‘ मॉड्यूल जाँचता है कि इनपुट हस्ताक्षरित है, कि यह प्रारूप में है ‘attest-cyclonedx-json’, और यह मॉड्यूल में सूचीबद्ध 1 अनुमत ईमेल में से 3 द्वारा हस्ताक्षरित था। इसके अतिरिक्त, यह जाँच करता है कि verify कमांड को सत्यापित करने के लिए एक इनपुट प्राप्त होता है, कि इनपुट का नाम है ‘my_binary.exe’, कि इनपुट एक फ़ाइल है जो Azure में बनाई गई थी, और यह एक विशिष्ट git URL से आई है: https://dev.azure.com/mycompany/somerepo.

जैसा कि आप देख सकते हैं कि पॉलिसी को सत्यापित करने के लिए इस उदाहरण में बहुत अधिक आवश्यकताएं हैं।

इस नीति को चलाने के लिए हमें इसे क्रियान्वित करने की आवश्यकता होगी verify हमारी पाइपलाइन में कमांड इस प्रकार है:

valint verify file:my_binary.exe

यह सुनिश्चित करने के लिए कि आपके स्क्राइब साक्ष्य स्टोर में इस बाइनरी का एक हस्ताक्षरित संस्करण है, आपको पहले इस तरह साक्ष्य बनाना चाहिए:

valint bom file:my_binary.exe -o attest

तृतीय पक्ष साक्ष्य सत्यापन नीति

अपने अंतिम उदाहरण में आइए देखें कि हम कैसे सत्यापित कर सकते हैं कि हमारे द्वारा उपयोग किया जाने वाला एक तृतीय पक्ष टूल हमारी पाइपलाइन में ठीक से चला है और उसने JSON फ़ाइल के रूप में अपेक्षित परिणाम तैयार किया है। 

प्रमाणित करें: कोकोसाइन: नीतियां: - नाम: सत्यापन_पॉलिसी सक्षम करें: सही मॉड्यूल: - नाम: तृतीय-पक्ष-नियम प्रकार: सत्यापित-विरूपण साक्ष्य सक्षम करें: सही इनपुट: हस्ताक्षरित: गलत प्रारूप: सत्यापित-जेनेरिक पहचान: ईमेल: - बॉब@स्क्राइबसुरक्षा। com मिलान: लक्ष्य_प्रकार: सामान्य संदर्भ_प्रकार: नीला git_url: https://dev.azure.com/mycompany/somerepo git_branch: मुख्य इनपुट_नाम: 3rd-party-scan.json

इस उदाहरण में, हम कल्पना करते हैं कि पाइपलाइन में किसी बिंदु पर, हमने एक तृतीय पक्ष टूल चलाया है, जिसके परिणामस्वरूप, `3rd-party-scan.json` फ़ाइल बनाई गई है। नीति को संतुष्ट करने के लिए वह फ़ाइल Azure DevOps से उत्पन्न होनी चाहिए, जो `https://dev.azure.com/mycompany/somerepo`भंडार और `द्वारा हस्ताक्षरितbob@scribesecurity.com`. 

जिस साक्ष्य की हम तलाश कर रहे हैं उसे उत्पन्न करने के लिए, तीसरे पक्ष के टूल के चलने के तुरंत बाद हमें परिणामी फ़ाइल को कैप्चर करना होगा और वैलिन्ट का उपयोग करके इसे साक्ष्य में बदलना होगा:

वैलेंट बॉम 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

सबूत क्या साबित करते हैं? 

इसलिए हमने देखा है कि हम अपनी पाइपलाइन में विभिन्न चीजों को सत्यापित करने के लिए वेलिन का उपयोग कर सकते हैं। वास्तव में इस क्षमता का उपयोग किस लिए किया जा सकता है?

आइए कल्पना करें कि हमारी पाइपलाइन में सेंध लग गई है और कुछ बुरे लोगों ने इसमें वो काम करना शुरू कर दिया है जो हम नहीं चाहते कि वे करें। यह सत्यापित करके कि पाइपलाइन के विभिन्न चरण अपेक्षा के अनुरूप हुए, अपेक्षित परिणाम मिले, और अनुमोदित कर्मियों द्वारा हस्ताक्षर किए गए, हम बुरे लोगों के लिए हमें धोखा देना बहुत कठिन बना देते हैं।

एक संभावित हमला पाइपलाइन के अंत में बाइनरी फ़ाइल को प्रतिस्थापित करना है ताकि आपके ग्राहकों को मिलने वाला संस्करण आपके मूल के बजाय दुर्भावनापूर्ण हो। अपने संस्करण पर हस्ताक्षर करके और अपने ग्राहकों से उस मास्टर कॉपी के विरुद्ध सत्यापन करने के लिए कहकर आप यह सुनिश्चित कर सकते हैं कि वे सभी आपके द्वारा उत्पादित एक ही फ़ाइल का उपयोग करते हैं और कोई चालाक नकली नहीं।

सबूत तैयार करने और फिर उसे सत्यापित करने का यह मॉडल अभी शुरू ही हो रहा है। हम वैलिंट को और अधिक मजबूत और बहुमुखी बनाने के लिए इसमें अतिरिक्त क्षमताएं जोड़ने के लिए लगातार काम कर रहे हैं। इस बीच, मैं आपको हमारी जाँच करने के लिए प्रोत्साहित करता हूँ दस्तावेज़ीकरण इस बारे में अधिक जानने के लिए कि स्क्राइब क्या पेशकश करता है और आप वैलिंट के साथ और क्या कर सकते हैं। वैलेंट को डाउनलोड करना और उपयोग करना मुफ़्त है, इसलिए वास्तव में आपको इस टूल को आज ही आज़माने से कोई नहीं रोक सकता।