अपडेट पर वापस जाएँ
New releaseSep 1, 2026

allstar v4.6

सुरक्षा नीतियों को सेट और लागू करने के लिए GitHub ऐप

साझा करें

OpenSSF Scorecard

Allstar

[!IMPORTANT] OpenSSF-होस्टेड Allstar GitHub ऐप को सेवानिवृत्त कर दिया गया है। Allstar, जो OpenSSF Scorecard उपप्रोजेक्ट है, स्वयं बनाए रखा जा रहा है — अब आपको इसे स्वयं चलाना होगा, या तो GitHub Action के रूप में या सेवा डेमन के रूप में

अधिक विवरण के लिए ossf/allstar#881 देखें।

यदि आपका संगठन होस्टेड ऐप पर निर्भर था, तो देखें होस्टेड ऐप से माइग्रेट करना

अवलोकन

Allstar में नया क्या है

अवांछित समस्याओं को अक्षम करना

आरंभ करना

नीतियाँ और क्रियाएँ

उन्नत

योगदान करें



अवलोकन

Allstar क्या है?

Allstar एक GitHub ऐप है जो GitHub संगठनों या रिपॉजिटरी की सुरक्षा सर्वोत्तम प्रथाओं के पालन के लिए निरंतर निगरानी करता है। यदि Allstar किसी सुरक्षा नीति उल्लंघन का पता लगाता है, तो यह रिपॉजिटरी या संगठन के स्वामी को सचेत करने के लिए एक समस्या (issue) बनाता है। कुछ सुरक्षा नीतियों के लिए, Allstar उस प्रोजेक्ट सेटिंग को स्वचालित रूप से बदल भी सकता है जिसके कारण उल्लंघन हुआ था, उसे अपेक्षित स्थिति में वापस ला सकता है।

Allstar का लक्ष्य आपको उन फ़ाइलों और सेटिंग्स पर सूक्ष्म नियंत्रण देना है जो आपके प्रोजेक्ट की सुरक्षा को प्रभावित करती हैं। आप चुन सकते हैं कि संगठन और रिपॉजिटरी दोनों स्तरों पर किन सुरक्षा नीतियों की निगरानी करनी है, और नीति उल्लंघनों को कैसे संभालना है। आप नई नीतियाँ विकसित या योगदान भी कर सकते हैं।

Allstar को OpenSSF Scorecard प्रोजेक्ट के भाग के रूप में विकसित किया गया है।

Allstar में नया क्या है

अवांछित समस्याओं को अक्षम करना

यदि आपको Allstar द्वारा बनाई गई अवांछित समस्याएँ मिल रही हैं, तो बाहर निकलने के लिए इन निर्देशों का पालन करें।

आरंभ करना

पृष्ठभूमि

Allstar अत्यधिक कॉन्फ़िगर करने योग्य है। नियंत्रण के तीन मुख्य स्तर हैं:

  • संगठन स्तर: संगठन प्रशासक Allstar को इन पर सक्षम करना चुन सकते हैं:
    • संगठन की सभी रिपॉजिटरी;
    • अधिकांश रिपॉजिटरी, कुछ को छोड़कर जो ऑप्ट-आउट हैं;
    • केवल कुछ रिपॉजिटरी जो ऑप्ट-इन हैं।

ये कॉन्फ़िगरेशन संगठन की .allstar रिपॉजिटरी में किए जाते हैं।

  • रिपॉजिटरी स्तर: ऐसे संगठन में रिपॉजिटरी अनुरक्षक जो Allstar का उपयोग करता है, अपनी रिपॉजिटरी को संगठन-स्तरीय प्रवर्तनों में ऑप्ट-इन या ऑप्ट-आउट करना चुन सकते हैं। ध्यान दें: ये रिपॉजिटरी-स्तरीय नियंत्रण केवल तभी कार्यात्मक होते हैं जब संगठन-स्तरीय सेटिंग्स में "रिपॉजिटरी ओवरराइड" की अनुमति हो। ये कॉन्फ़िगरेशन रिपॉजिटरी की .allstar निर्देशिका में किए जाते हैं।

  • नीति स्तर: प्रशासक या अनुरक्षक चुन सकते हैं कि विशिष्ट रिपॉजिटरी पर कौन सी नीतियाँ सक्षम हैं और नीति उल्लंघन होने पर Allstar कौन सी क्रियाएँ करता है। ये कॉन्फ़िगरेशन संगठन की .allstar रिपॉजिटरी (प्रशासक) या रिपॉजिटरी की .allstar निर्देशिका (अनुरक्षक) में एक नीति yaml फ़ाइल में किए जाते हैं।

संगठन-स्तरीय विकल्प

संगठन स्तर पर Allstar स्थापित करने से पहले, आपको यह तय करना चाहिए कि आप लगभग कितनी रिपॉजिटरी पर Allstar चलाना चाहते हैं। यह आपको ऑप्ट-इन और ऑप्ट-आउट रणनीतियों के बीच चयन करने में मदद करेगा।

  • ऑप्ट-इन रणनीति आपको उन रिपॉजिटरी को मैन्युअल रूप से जोड़ने की अनुमति देती है जिन पर आप Allstar चलाना चाहते हैं। यदि आप कोई रिपॉजिटरी निर्दिष्ट नहीं करते हैं, तो स्थापित होने के बावजूद Allstar नहीं चलेगा। ऑप्ट-इन रणनीति चुनें यदि आप अपनी कुल रिपॉजिटरी में से केवल कुछ पर नीतियाँ लागू करना चाहते हैं, या अधिक पर सक्षम करने से पहले एकल रिपॉजिटरी पर Allstar आज़माना चाहते हैं। v4.3 रिलीज़ के बाद से, समान नाम वाली कई रिपॉजिटरी आसानी से जोड़ने के लिए ग्लोब्स समर्थित हैं।

  • ऑप्ट-आउट रणनीति (अनुशंसित) सभी रिपॉजिटरी पर Allstar सक्षम करती है और आपको Allstar प्रवर्तनों से बाहर निकलने के लिए रिपॉजिटरी को मैन्युअल रूप से चुनने की अनुमति देती है। आप सभी सार्वजनिक रिपॉजिटरी या सभी निजी रिपॉजिटरी को ऑप्ट-आउट करना भी चुन सकते हैं। यह विकल्प चुनें यदि आप किसी संगठन की सभी रिपॉजिटरी पर Allstar चलाना चाहते हैं, या केवल कुछ रिपॉजिटरी या विशिष्ट प्रकार (जैसे, सार्वजनिक बनाम निजी) की रिपॉजिटरी को ऑप्ट-आउट करना चाहते हैं। v4.3 रिलीज़ के बाद से, समान नाम वाली कई रिपॉजिटरी आसानी से जोड़ने के लिए ग्लोब्स समर्थित हैं।

ऑप्ट-आउट (अनुशंसित)
optOutStrategy = true
ऑप्ट-इन
optOutStrategy = false
डिफ़ॉल्ट व्यवहार सभी रिपॉजिटरी सक्षम हैंकोई रिपॉजिटरी सक्षम नहीं है
रिपॉजिटरी को मैन्युअल रूप से जोड़नारिपॉजिटरी को मैन्युअल रूप से जोड़ने से उन रिपॉजिटरी पर Allstar अक्षम हो जाता हैरिपॉजिटरी को मैन्युअल रूप से जोड़ने से उन रिपॉजिटरी पर Allstar सक्षम हो जाता है
अतिरिक्त कॉन्फ़िगरेशनoptOutRepos: सूचीबद्ध रिपॉजिटरी पर Allstar अक्षम हो जाएगा

optOutPrivateRepos: यदि true है, तो सभी निजी रिपॉजिटरी पर Allstar अक्षम हो जाएगा

optOutPublicRepos: यदि true है, तो सभी सार्वजनिक रिपॉजिटरी पर Allstar अक्षम हो जाएगा

(optInRepos: यह सेटिंग अनदेखी की जाएगी)
optInRepos: सूचीबद्ध रिपॉजिटरी पर Allstar सक्षम हो जाएगा

(optOutRepos: यह सेटिंग अनदेखी की जाएगी)
रिपॉजिटरी ओवरराइड यदि true है: रिपॉजिटरी अपनी स्वयं की रिपॉजिटरी फ़ाइल में सेटिंग्स का उपयोग करके अपने संगठन के Allstar प्रवर्तनों से ऑप्ट-आउट कर सकती हैं। उस रिपॉजिटरी पर लागू होने वाली संगठन-स्तरीय ऑप्ट-इन सेटिंग्स को अनदेखा किया जाता है।

यदि false है: रिपॉजिटरी संगठन स्तर पर कॉन्फ़िगर किए गए Allstar प्रवर्तनों से ऑप्ट-आउट नहीं कर सकती हैं।
यदि true है: रिपॉजिटरी अपने संगठन के Allstar प्रवर्तनों में ऑप्ट-इन कर सकती हैं, भले ही वे संगठन स्तर पर रिपॉजिटरी के लिए कॉन्फ़िगर न हों। उस रिपॉजिटरी पर लागू होने वाली संगठन-स्तरीय ऑप्ट-आउट सेटिंग्स को अनदेखा किया जाता है।

यदि false है: रिपॉजिटरी Allstar प्रवर्तनों में ऑप्ट-इन नहीं कर सकती हैं यदि वे संगठन स्तर पर कॉन्फ़िगर नहीं हैं।

स्थापना विकल्प

Allstar आपके संगठन पर GitHub ऐप के रूप में कार्य करता है: आप ऐप बनाते हैं, और आप उस प्रक्रिया को चलाते हैं जो इसके रूप में प्रमाणित होती है। इसलिए सेटअप दो चरण हैं जो हर तैनाती के लिए सामान्य हैं — ऐप बनाएँ और नियंत्रण रिपॉजिटरी बनाएँ — और फिर इसे चलाने के तरीके का विकल्प:

GitHub Actionसेवा डेमन
यह कैसे चलता हैआपकी .allstar रिपॉजिटरी में निर्धारित कार्यस्थायी प्रक्रिया जिसे आप होस्ट करते हैं
आप प्रदान करते हैंGitHub के अलावा कुछ नहींएक सर्वर या कंटेनर ऑर्केस्ट्रेटर
कैडेंसजो भी आप cron सेट करते हैंनिरंतर, 5-10 मिनट में परिणामों के साथ
सेटअप प्रयासमध्यमउच्च
सबसे अच्छा कबआप सबसे कम-इन्फ्रास्ट्रक्चर विकल्प चाहते हैंआप सबसे अधिक नियंत्रण चाहते हैं, या पहले से सेवाएँ चलाते हैं

Action दोनों में से कम ओवरहेड वाला है और अधिकांश संगठनों को यहीं से शुरू करना चाहिए; आप बाद में बिना किसी नीति कॉन्फ़िगरेशन को बदले डेमन पर जा सकते हैं।

अपना GitHub ऐप बनाएँ

एक ऐप आपके संगठन में अनुमतियों के एक सेट के साथ एक उपयोगकर्ता-जैसी पहचान है। अनुपालन का पता लगाने के लिए Allstar को अधिकांश सेटिंग्स और फ़ाइल सामग्री तक पढ़ने की पहुँच की आवश्यकता होती है, और समस्याएँ दर्ज करने और block क्रिया का समर्थन करने के लिए समस्याओं और जाँचों तक लिखने की पहुँच की आवश्यकता होती है।

ऑपरेटर निर्देश - GitHub ऐप बनाएँ का पालन करें, और ऐप ID और निजी कुंजी रिकॉर्ड करें। दोनों रन मोड को उनकी आवश्यकता होती है।

अपना .allstar नियंत्रण रिपॉजिटरी बनाएँ

Allstar अपना कॉन्फ़िगरेशन आपके संगठन में .allstar नामक रिपॉजिटरी से पढ़ता है।

एक बनाने का सबसे तेज़ तरीका नमूने से है:

  1. नमूना रिपॉजिटरी खोलें और "Use this template" बटन पर क्लिक करें
  2. रिपॉजिटरी नाम के फ़ील्ड में, .allstar टाइप करें
  3. "Create repository from template" पर क्लिक करें

यह ऑप्ट-आउट रणनीति का उपयोग करके सभी रिपॉजिटरी पर सभी वर्तमान Allstar नीतियों को issue क्रिया के साथ सक्षम करता है। आप बाद में इसमें से कोई भी बदल सकते हैं।

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

Allstar को GitHub Action के रूप में चलाना

यह विकल्प GitHub Actions का उपयोग करके Allstar को एक निर्धारित कार्य के रूप में चलाता है, इसलिए GitHub के अलावा संचालित करने के लिए कोई इन्फ्रास्ट्रक्चर नहीं है।

अपनी .allstar रिपॉजिटरी में एक आवर्ती Action सेट करने, उसे सख्त बनाने और उसके परिणामों की निगरानी करने के लिए GitHub Actions स्थापना निर्देशों का पालन करें।

Allstar को सेवा डेमन के रूप में चलाना

यह विकल्प Allstar को एक स्थायी प्रक्रिया के रूप में चलाता है, जो शेड्यूल के बजाय निरंतर उल्लंघनों का पता लगाता है और उन्हें हल करता है।

प्रक्रिया चलाने, रहस्यों के प्रबंधन, आकार निर्धारण और उपलब्ध पर्यावरण चर के लिए ऑपरेटर निर्देश देखें।

होस्टेड ऐप से माइग्रेट करना

यदि आपके संगठन ने OpenSSF-होस्टेड ऐप का उपयोग किया है, तो आपका कॉन्फ़िगरेशन ज्यों का त्यों स्थानांतरित हो जाता है.allstar नियंत्रण रिपॉजिटरी, allstar.yaml, और हर नीति फ़ाइल बिना बदलाव के काम करती रहती है; आप केवल उस प्रक्रिया को बदल रहे हैं जो उन्हें पढ़ती है।

माइग्रेट करने के लिए:

  1. अपना स्वयं का GitHub ऐप बनाएँ और इसे अपने संगठन पर उसी रिपॉजिटरी पहुँच के साथ स्थापित करें जो होस्टेड ऐप के पास थी।
  2. अपनी मौजूदा .allstar रिपॉजिटरी को बिल्कुल वैसे ही रखें।
  3. Allstar को Action के रूप में या डेमन के रूप में चलाएँ।
  4. अपने संगठन से allstar-app अनइंस्टॉल करें, यदि यह अभी भी Settings -> GitHub Apps के अंतर्गत दिखाई देता है।

होस्टेड ऐप द्वारा पहले दर्ज की गई समस्याएँ आपकी रिपॉजिटरी में बनी रहती हैं। आपका अपना उदाहरण अपनी समस्याओं को उसी allstar लेबल (या आपके कॉन्फ़िगर किए गए issueLabel) द्वारा पहचानता है, इसलिए यह उल्लंघनों के हल होने पर डुप्लिकेट दर्ज करने के बजाय उन्हें अपनाएगा और बंद करेगा।

नीतियाँ और क्रियाएँ

क्रियाएँ

प्रत्येक नीति को एक क्रिया के साथ कॉन्फ़िगर किया जा सकता है जो Allstar तब करेगा जब वह किसी रिपॉजिटरी को अनुपालन से बाहर पाता है।

  • log: यह डिफ़ॉल्ट क्रिया है, और वास्तव में सभी क्रियाओं के लिए होती है। सभी नीति चलाने के परिणाम और विवरण लॉग किए जाते हैं। लॉग वर्तमान में केवल ऐप ऑपरेटर को दिखाई देते हैं, इन्हें उजागर करने की योजनाएँ चर्चा में हैं।
  • issue: यह क्रिया एक GitHub समस्या बनाती है। प्रति नीति केवल एक समस्या बनाई जाती है, और पाठ नीति उल्लंघन के विवरण का वर्णन करता है। यदि समस्या पहले से खुली है, तो हर 24 घंटे में बिना अपडेट के एक टिप्पणी के साथ उसे पिंग किया जाता है (वर्तमान में उपयोगकर्ता कॉन्फ़िगर करने योग्य नहीं)। यदि नीति परिणाम बदलता है, तो समस्या पर एक नई टिप्पणी छोड़ी जाएगी और समस्या के मुख्य भाग में लिंक की जाएगी। एक बार उल्लंघन का समाधान हो जाने पर, समस्या Allstar द्वारा 5-10 मिनट के भीतर स्वचालित रूप से बंद कर दी जाएगी।
  • fix: यह क्रिया नीति-विशिष्ट है। नीति नीति उल्लंघन को ठीक करने के लिए GitHub सेटिंग्स में परिवर्तन करेगी। सभी नीतियाँ इसका समर्थन करने में सक्षम नहीं होंगी (नीचे देखें)।

प्रस्तावित, लेकिन अभी तक लागू नहीं की गई क्रियाएँ। परिभाषाएँ भविष्य में जोड़ी जाएँगी।

  • block: Allstar एक GitHub स्थिति जाँच सेट कर सकता है और यदि जाँच विफल होती है तो रिपॉजिटरी में किसी भी PR को मर्ज होने से रोक सकता है।
  • email: Allstar रिपॉजिटरी प्रशासक(ओं) को एक ईमेल भेजेगा।
  • rpc: Allstar किसी संगठन-विशिष्ट सिस्टम को एक rpc भेजेगा।

क्रिया कॉन्फ़िगरेशन

समस्या क्रिया को कॉन्फ़िगर करने के लिए दो सेटिंग्स उपलब्ध हैं:

  • issueLabel संगठन और रिपॉजिटरी स्तर पर उपलब्ध है। इसे सेट करने से Allstar द्वारा अपनी समस्याओं की पहचान करने के लिए उपयोग किया जाने वाला डिफ़ॉल्ट allstar लेबल ओवरराइड हो जाएगा।

  • issueRepo संगठन स्तर पर उपलब्ध है। इसे सेट करने से संगठन में बनाई गई सभी समस्याएँ निर्दिष्ट रिपॉजिटरी में बनाई जाएँगी।

नीतियाँ

Allstar ऐप सक्षम कॉन्फ़िगरेशन के समान, सभी नीतियाँ संगठन की .allstar रिपॉजिटरी या रिपॉजिटरी की .allstar निर्देशिका में एक yaml फ़ाइल के साथ सक्षम और कॉन्फ़िगर की जाती हैं। ऐप की तरह, नीतियाँ डिफ़ॉल्ट रूप से ऑप्ट-इन होती हैं, साथ ही डिफ़ॉल्ट log क्रिया दृश्यमान परिणाम उत्पन्न नहीं करेगी। सभी नीतियों को सक्षम करने का एक सरल तरीका प्रत्येक नीति के लिए निम्न सामग्री के साथ एक yaml फ़ाइल बनाना है:```yaml optConfig: optOutStrategy: true action: issue

प्रत्येक नीति के लिए `fix` क्रिया कैसे काम करती है, इसका विवरण नीचे दिया गया है। यदि नीचे छोड़ा गया है, तो `fix` क्रिया लागू नहीं होती है।

### Branch Protection

इस नीति की कॉन्फ़िग फ़ाइल का नाम `branch_protection.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/branch#OrgConfig)।

Branch protection नीति जाँचती है कि GitHub की [branch protection
सेटिंग्स](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)
निर्दिष्ट कॉन्फ़िगरेशन के अनुसार सही ढंग से सेट हैं या नहीं। Issue टेक्स्ट
बताएगा कि कौन सी सेटिंग गलत है। सेटिंग्स को सही करने के लिए [GitHub का
दस्तावेज़ीकरण](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)
देखें।

`fix` क्रिया branch protection सेटिंग्स को निर्दिष्ट नीति कॉन्फ़िगरेशन के अनुपालन में बदल देगी।

### Binary Artifacts

इस नीति की कॉन्फ़िग फ़ाइल का नाम `binary_artifacts.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/binary#OrgConfig)।

यह नीति [scorecard से चेक](https://github.com/ossf/scorecard/#scorecard-checks) को शामिल करती है। अनुपालन प्राप्त करने के लिए
रिपॉज़िटरी से binary artifact हटाएँ। चूँकि scorecard
परिणाम विस्तृत हो सकते हैं, आपको सभी विस्तृत जानकारी देखने के लिए [scorecard
स्वयं](https://github.com/ossf/scorecard) चलाने की आवश्यकता हो सकती है।

### CODEOWNERS

इस नीति की कॉन्फ़िग फ़ाइल का नाम `codeowners.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/codeowners#OrgConfig)।

यह नीति आपकी रिपॉज़िटरीज़ पर [`CODEOWNERS` फ़ाइल](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) की उपस्थिति की जाँच करती है।

### Outside Collaborators

इस नीति की कॉन्फ़िग फ़ाइल का नाम `outside.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/outside#OrgConfig)।

यह नीति जाँचती है कि क्या किसी [Outside
Collaborator](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/adding-outside-collaborators-to-repositories-in-your-organization)
के पास रिपॉज़िटरी तक administrator(डिफ़ॉल्ट) या push(वैकल्पिक) पहुँच है।
केवल संगठन के सदस्यों के पास यह पहुँच होनी चाहिए, अन्यथा
अविश्वसनीय सदस्य admin स्तर की सेटिंग्स बदल सकते हैं और दुर्भावनापूर्ण कोड कमिट कर सकते हैं।

### SECURITY.md

इस नीति की कॉन्फ़िग फ़ाइल का नाम `security.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/security#OrgConfig)।

यह नीति जाँचती है कि रिपॉज़िटरी में `SECURITY.md` में सुरक्षा नीति फ़ाइल है और वह खाली नहीं है। बनाई गई issue में [GitHub
टैब](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) का लिंक होगा
जो आपकी रिपॉज़िटरी में सुरक्षा नीति कमिट करने में आपकी मदद करता है।

### Dangerous Workflow

इस नीति की कॉन्फ़िग फ़ाइल का नाम `dangerous_workflow.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/workflow#OrgConfig)।

यह नीति **सभी** शाखाओं पर चलेगी, तर्क [यहाँ](https://github.com/ossf/allstar/issues/569) देखें।

यह नीति GitHub Actions workflow कॉन्फ़िगरेशन फ़ाइलों
(`.github/workflows`) की जाँच करती है, किसी भी पैटर्न के लिए जो ज्ञात खतरनाक
व्यवहार से मेल खाता है। इस चेक के बारे में अधिक जानकारी के लिए [OpenSSF Scorecard
दस्तावेज़ीकरण](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow)
देखें।

### Generic Scorecard Check

इस नीति की कॉन्फ़िग फ़ाइल का नाम `scorecard.yaml` है, और [कॉन्फ़िग
परिभाषाएँ यहाँ
हैं](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/scorecard#OrgConfig)।

यह नीति `checks` कॉन्फ़िगरेशन में सूचीबद्ध किसी भी scorecard चेक को चलाती है। सभी
चलाए गए चेकों का स्कोर `threshold` सेटिंग के बराबर या उससे अधिक होना चाहिए। प्रत्येक चेक के बारे में अधिक जानकारी के लिए कृपया
[OpenSSF Scorecard
दस्तावेज़ीकरण](https://github.com/ossf/scorecard/blob/main/docs/checks.md)
देखें।

#### SARIF Upload

Scorecard नीति वैकल्पिक रूप से परिणामों को
[SARIF](https://sarifweb.azurewebsites.net/) के रूप में प्रत्येक रिपॉज़िटरी के
**Security > Code Scanning** टैब पर अपलोड कर सकती है। यह संगठन प्रशासकों को
अन्य सुरक्षा टूल्स (CodeQL, Dependabot, आदि) के साथ Scorecard निष्कर्षों में दृश्यता देता है, बिना प्रति-रिपॉज़िटरी workflow सेटअप की आवश्यकता के।

SARIF अपलोड सक्षम करने के लिए, अपने `scorecard.yaml` में `upload` फ़ील्ड जोड़ें:```yaml
optConfig:
  optOutStrategy: true
action: issue
checks:
  - Binary-Artifacts
  - Signed-Releases
threshold: 8
upload:
  sarif: true

आवश्यकताएँ:

  • Allstar GitHub ऐप के पास Code scanning alerts रिपॉजिटरी अनुमति Read & write पर सेट होनी चाहिए (API स्कोप: security_events)। यह उन अनुमतियों में से नहीं है जिनकी Allstar को अन्यथा आवश्यकता होती है, इसलिए SARIF अपलोड सक्षम करने से पहले इसे अपने ऐप में जोड़ें।
  • SARIF अपलोड गैर-अवरोधक है: यदि अपलोड विफल हो जाता है (जैसे, अनुमतियों की कमी के कारण), तो नीति जाँच सामान्य रूप से जारी रहती है।
  • परिवर्तन का पता लगाना रिपॉजिटरी के HEAD कमिट SHA की तुलना करता है और स्कैन तथा अपलोड को छोड़ देता है जब रिपो को पिछले अपलोड के बाद से पुश नहीं किया गया हो।

SARIF अपलोड Allstar चलाने के दोनों तरीकों के साथ काम करता है: सेवा डेमन के रूप में या GitHub Action के रूप में।

GitHub Actions

इस नीति की कॉन्फ़िग फ़ाइल का नाम actions.yaml है, और कॉन्फ़िग परिभाषाएँ यहाँ हैं

यह नीति प्रत्येक रिपो में GitHub Actions वर्कफ़्लो कॉन्फ़िगरेशन फ़ाइलों (.github/workflows) (और कुछ मामलों में वर्कफ़्लो रन) की जाँच करती है ताकि यह सुनिश्चित किया जा सके कि वे नीति के लिए संगठन-स्तरीय कॉन्फ़िग में परिभाषित नियमों (जैसे, आवश्यक, अस्वीकार) के अनुरूप हैं।

Repository Administrators

इस नीति की कॉन्फ़िग फ़ाइल का नाम admin.yaml है, और कॉन्फ़िग परिभाषाएँ यहाँ हैं

यह नीति जाँचती है कि डिफ़ॉल्ट रूप से सभी रिपॉजिटरीज़ में एक उपयोगकर्ता या समूह को Administrator के रूप में नियुक्त किया गया हो। यह आपको वैकल्पिक रूप से कॉन्फ़िगर करने की अनुमति देता है कि क्या उपयोगकर्ताओं को प्रशासक बनने की अनुमति है (टीमों के विपरीत)।

Future Policies

  • सुनिश्चित करें कि dependabot सक्षम है।
  • जाँच करें कि निर्भरताएँ पिन/फ़्रोज़न हैं।

उदाहरण कॉन्फ़िग रिपॉजिटरी

इस रिपो को Allstar कॉन्फ़िग के उपयोग के उदाहरण के रूप में देखें। संगठन प्रशासक के रूप में, अपने संगठन में Allstar का उपयोग कैसे किया जा रहा है, इसके बारे में कुछ जानकारी के साथ एक README.md पर विचार करें।

Advanced

कॉन्फ़िगरेशन परिभाषाएँ

द्वितीयक Org-स्तर कॉन्फ़िगरेशन स्थान

डिफ़ॉल्ट रूप से, org-स्तरीय कॉन्फ़िगरेशन फ़ाइलें, जैसे कि ऊपर दी गई allstar.yaml फ़ाइल, एक .allstar रिपॉजिटरी में होने की उम्मीद की जाती हैं। यदि यह रिपॉजिटरी मौजूद नहीं है, तो .github रिपॉजिटरी का allstar निर्देशिका एक द्वितीयक स्थान के रूप में उपयोग की जाती है। स्पष्ट करने के लिए, allstar.yaml के लिए:

प्राथमिकतारिपॉजिटरीपथ
प्राथमिक.allstarallstar.yaml
द्वितीयक.githuballstar/allstar.yaml

यह व्यक्तिगत नीतियों के लिए org-स्तरीय कॉन्फ़िगरेशन फ़ाइलों के लिए भी सत्य है, जैसा कि नीचे वर्णित है।

Org रिपो में रिपो नीति कॉन्फ़िगरेशन

Allstar संगठन के .allstar रिपॉजिटरी में, रिपॉजिटरी के समान नाम वाली निर्देशिका के अंतर्गत, रिपो-स्तरीय नीति कॉन्फ़िगरेशन की भी तलाश करेगा। यह कॉन्फ़िगरेशन उपयोग किया जाता है चाहे "repo override" अक्षम हो या नहीं।

उदाहरण के लिए, Allstar किसी दिए गए रिपो myapp के लिए नीति कॉन्फ़िगरेशन को निम्नलिखित क्रम में देखेगा:

रिपॉजिटरीपथशर्त
myapp.allstar/branch_protection.yamlजब "repo override" की अनुमति हो।
.allstarmyapp/branch_protection.yamlहर समय।
.allstarbranch_protection.yamlहर समय।
.githuballstar/myapp/branch_protection.yamlयदि .allstar रिपो मौजूद नहीं है।
.githuballstar/branch_protection.yamlयदि .allstar रिपो मौजूद नहीं है।

Org-स्तरीय Base और Merge कॉन्फ़िगरेशन स्थान

Org-स्तरीय Allstar और नीति कॉन्फ़िगरेशन फ़ाइलों के लिए, आप फ़ील्ड baseConfig निर्दिष्ट कर सकते हैं ताकि किसी अन्य रिपॉजिटरी को निर्दिष्ट किया जा सके जिसमें आधार Allstar कॉन्फ़िगरेशन हो। इसे एक उदाहरण के साथ सबसे अच्छी तरह समझाया जा सकता है।

मान लीजिए कि आपके पास कई GitHub संगठन हैं, लेकिन एक ही Allstar कॉन्फ़िगरेशन बनाए रखना चाहते हैं। आपका मुख्य संगठन "acme" है, और रिपॉजिटरी acme/.allstar में allstar.yaml है:```yaml optConfig: optOutStrategy: true issueLabel: allstar-acme issueFooter: Issue created by Acme security team.

आपके पास "acme-sat" नामक एक सैटेलाइट GitHub संगठन भी है। आप मुख्य कॉन्फ़िग का पुनः उपयोग करना चाहते हैं, लेकिन कुछ रिपॉज़िटरीज़ पर Allstar को अक्षम करके उसके ऊपर कुछ बदलाव लागू करना चाहते हैं। रिपॉज़िटरी `acme-sat/.allstar` में `allstar.yaml` शामिल है:```yaml
baseConfig: acme/.allstar
optConfig:
  optOutRepos:
  - acmesat-one
  - acmesat-two

यह acme/.allstar से सभी कॉन्फ़िग को आधार कॉन्फ़िग के रूप में उपयोग करेगा, लेकिन फिर आधार कॉन्फ़िगरेशन के ऊपर वर्तमान फ़ाइल में किए गए किसी भी बदलाव को लागू करेगा। यह जिस विधि से लागू किया जाता है उसे JSON Merge Patch के रूप में वर्णित किया गया है। baseConfig एक GitHub <org>/<repository> होना चाहिए।

योगदान

देखें CONTRIBUTING.md

श्रेणियाँ