Semgrep नियम

यह केंद्रीय Semgrep नियम भंडार है जो GitLab semgrep analyzer के लिए Semgrep नियमों को होस्ट करता है।

भंडार निम्नानुसार संरचित है:

.
├── mappings
│   ├── find_sec_bugs.yml
│   ├── eslint.yml
│   └── ...
├── rules
│   ├── lpgl
│   │   ├── java
│   │   │   ├── webview
│   │   │   │   ├── rule-ignore_ssl_certificate_error.yml
│   │   │   │   ├── rule-ignore_ssl_certificate_error.java
│   │   │   │   └── ...
│   │   │   └── ...
│   │   ├── python
│   │   │   └── ...
│   │   └── ...
│   ├── lpgl-cc
│   │   ├── java
│   │   │   └── ...
│   │   └── ...
│   └── ...
├── c
│   ├── buffer
│   │   ├── rule-strcpy.yml
│   │   ├── test-strcpy.c
│   │   ├── rule-memcpy.yml
│   │   └── test-memcpy.c
│   └── ...
└── javascript
│   └── ...
└── ...

उपरोक्त संरचना इस पैटर्न का अनुसरण करती है:

rules/<license>/<language>/<ruleclass>/rule-<rulename>\.(yml|<ext>)

जहाँ:

1. <license> उन सभी नियमों का लाइसेंस है जो इसके अंतर्गत हैं
2. <language> लक्ष्य प्रोग्रामिंग भाषा
3. <ruleclass> अंतर्निहित नियमों के वर्ग के लिए एक वर्णनात्मक नाम
4. <rulename> वास्तविक नियम के लिए एक वर्णनात्मक नाम
5. <ext> <language> के लिए सामान्य फ़ाइल एक्सटेंशन

पुराने नियम <language>/<ruleclass>/rule-... पैटर्न का पालन करते हैं, और जब भी संभव हो उपरोक्त नए पैटर्न को प्राथमिकता दी जानी चाहिए।

mappings निर्देशिका में नियम-पैक कॉन्फ़िगरेशन शामिल है।

Makefile

Makefile नियमों पर काम करते समय सहायक कुछ लक्ष्यों को परिभाषित करता है:

$ make help
TARGETS:
  test                  test all rules with Semgrep
  watch                 watch for file changes and auto-run affected tests
  help                  prints this message

फ़ॉर्मेटिंग दिशानिर्देश

इस भंडार में शामिल नियमों को निम्नलिखित प्रारूप का पालन करना होगा:

• स्ट्रिंग्स के लिए " का उपयोग करें, अन्यथा YAML शाब्दिक ब्लॉक |
• सरणी तत्वों का संक्षिप्तीकरण नहीं
• अधिकतम पंक्ति-लंबाई/टेक्स्ट-चौड़ाई: 100 वर्ण
• इंडेंटेशन: 2 स्पेस
• प्रत्येक नियम का एक संगत परीक्षण-मामला होना चाहिए
• यदि प्रदान किया गया है, तो नियम फ़ाइल के शीर्ष पर टिप्पणी-अनुभाग
• प्रत्येक YAML फ़ाइल --- से शुरू होती है

मैपिंग

इस भंडार में mappings निर्देशिका में YAML कॉन्फ़िगरेशन फ़ाइलें हैं जो मूल विश्लेषक आईडी (जैसे Bandit, Brakeman, आदि) को संबंधित Semgrep नियमों से मैप करती हैं।

मैपिंग फ़ाइलों का उद्देश्य सबसे पहले और सबसे महत्वपूर्ण, विश्लेषक-विशिष्ट जानकारी को वास्तविक नियमों से अलग करना है, और दूसरा, विभिन्न उद्देश्यों के लिए नियम-पैक या नियम-सेट (भाषा या विश्लेषक सीमाओं के पार) उत्पन्न करने का एक गैर-हस्तक्षेपी तरीका प्रदान करना है।

मैपिंग फ़ाइलें mappings/ निर्देशिका के अंतर्गत स्थित होती हैं जहाँ फ़ाइल नाम उस नियमपैक और/या विश्लेषक को संदर्भित करता है जो संबंधित फ़ाइल में उपयोग किए गए नियमों के सेट द्वारा दर्शाया जाता है। यदि आप चाहते हैं कि नियम GitLab मानक नियमसेट में शामिल हों और नियम उन नियम-पैक (या विश्लेषकों) में से किसी एक में फिट नहीं होता है जो पहले से mappings/ निर्देशिका में उपलब्ध हैं, तो आप अपनी मैपिंग को mappings/gitlab_<license>_<language>.yml फ़ाइल में जोड़ सकते हैं जहाँ <license> उस स्रोत द्वारा निर्धारित एक उपयुक्त लाइसेंस है जिससे नियम लिया गया है और <language> उस भाषा का प्लेसहोल्डर है जिसे नियम संदर्भित करता है।

यदि आप एक नए नियम को एकीकृत करना चाहते हैं जो शुरू से विकसित किया गया था, तो आप mappings/gitlab_ee_<language>.yml फ़ाइल में एक संबंधित मैपिंग जोड़ सकते हैं। यह निर्धारित करते समय कि आप जिस विशेष नियम को मैप कर रहे हैं, उस पर कौन सा लाइसेंस लागू होना चाहिए, इस आंतरिक मार्गदर्शन का संदर्भ लें।

मैपिंग का उपयोग स्वचालित रूप से नियम-पैक को इकट्ठा करने के लिए भी किया जाता है। नीचे दिया गया स्निपेट bandit विश्लेषक के लिए मैपिंग फ़ाइलों के साथ एक उदाहरण दर्शाता है। native_id अनुभाग में मूल विश्लेषक आईडी के बारे में कुछ जानकारी शामिल है, यानी मेटा-जानकारी जो मूल विश्लेषक (इस मामले में bandit) अपने द्वारा उत्पन्न निष्कर्ष से जोड़ता है। वास्तविक नियम मैपिंग mappings अनुभाग में परिभाषित की गई हैं। प्रत्येक मैपिंग एक मूल विश्लेषक नियम आईडी (नीचे दिए गए उदाहरण में B301) को इस भंडार में semgrep फ़ाइलों के एक सेट से मैप करती है जो उस विशेष मूल नियम के समान हैं, या आदर्श रूप से वास्तविक रूप से समतुल्य हैं।

bandit:
  native_id:
    type: "bandit_test_id"
    name: "Bandit Test ID: $ID"
    value: "$ID"
  mappings:
  - id: "B301"
    rules:
    - path: "python/deserialization/rule-pickle"
      primary_id: "bandit.B301-1"
      id: "bandit.B301-1"
    - path: "python/deserialization/rule-cpickle"
      primary_id: "bandit.B301-2"
      id: "bandit.B301-2"
    - path: "python/deserialization/rule-dill"
      primary_id: "bandit.B301-3"
      id: "bandit.B301-3"
    - path: "python/deserialization/rule-shelve"
      primary_id: "bandit.B301-4"
      id: "bandit.B301-4"
  # ...

मैपिंग फ़ाइल की संरचना नीचे और अधिक विस्तार से समझाई गई है।

1. id का उपयोग semgrep नियम-पैक में स्थिर और अद्वितीय semgrep नियम पहचानकर्ता उत्पन्न करने के लिए किया जाता है जो एक मैपिंग फ़ाइल से मेल खाता है।
2. primary_id स्थिर भेद्यता प्राथमिक पहचानकर्ता उत्पन्न करने में मदद करता है जो GitLab Semgrep analyzer द्वारा उत्पन्न भेद्यताओं से जुड़े होते हैं (gl-sast-report.json में) डिडुप्लिकेशन उद्देश्यों के लिए।
3. native_id वह प्रविष्टि है जो भेद्यता पहचानकर्ता की संरचना से बिल्कुल मिलती-जुलती है जैसा कि मूल विश्लेषक द्वारा उत्पन्न किया जाएगा। इसे GitLab Semgrep analyzer द्वारा उत्पादित gl-sast-report.json में जोड़ा जाएगा और भेद्यता रिपोर्ट में उपलब्ध कराया जाएगा।
4. mappings में मूल विश्लेषक आईडी शामिल है (उपरोक्त मामले में B301 जो python विश्लेषक bandit के नियमों में से एक को संदर्भित करता है)। rules सरणी भंडार में उन फ़ाइलों को इंगित करती है जिन्हें यह नियम संदर्भित करता है। दूसरे शब्दों में, B301 का तर्क उपरोक्त स्निपेट में सूचीबद्ध चार फ़ाइलों में लागू किया गया है।

हम नियम विभाजन का समर्थन करने के लिए दो विभिन्न प्रकार के पहचानकर्ताओं id और primary_id का उपयोग करते हैं: एकाधिक semgrep नियमों (id) को एक एकल मूल विश्लेषक के नियम (primary_id) से मैप किया जा सकता है।

डेटा स्रोत

इस भंडार में नियम और परीक्षण-मामले आंशिक रूप से नीचे सूचीबद्ध स्रोतों से लिए गए हैं:

1. https://github.com/returntocorp/semgrep-rules
2. https://github.com/PyCQA/bandit
3. https://github.com/nodesecurity/eslint-plugin-security
4. https://github.com/jsx-eslint/eslint-plugin-react
5. https://github.com/david-a-wheeler/flawfinder/blob/master/flawfinder.py

विवरण सभी नियम और परीक्षण-फ़ाइलों के शीर्षलेखों में सूचीबद्ध हैं जिनमें लाइसेंसिंग जानकारी और उचित श्रेय शामिल हैं।

योगदान

यदि आप एक ऐसे पैटर्न के बारे में जानते हैं जो इस रेपो में मौजूद नहीं है या परिशोधन जो इस भंडार के नियमों पर लागू किए जा सकते हैं, तो आप एक मुद्दा खोलकर योगदान कर सकते हैं, या इस भंडार में नियम फ़ाइलों/परीक्षण मामलों में सुधार भी प्रस्तुत कर सकते हैं।

वर्जनिंग

हम इस भंडार पर निम्नलिखित सिमैंटिक वर्जनिंग योजना लागू करते हैं:

1. पैच वर्जन वृद्धि: अद्यतन/पैच किए गए/जोड़े गए नियमों के लिए।
2. माइनर वर्जन वृद्धि: पश्चगामी-संगत YAML स्कीमा परिवर्तन (जैसे, वैकल्पिक फ़ील्ड जोड़ना/हटाना)।
3. मेजर वर्जन वृद्धि: गैर-पश्चगामी-संगत YAML स्कीमा परिवर्तन (जैसे, आवश्यक फ़ील्ड जोड़ना/हटाना)

SAST नियम रिलीज़ प्रक्रिया

नए SAST नियम रिलीज़ को प्रभावी होने के लिए semgrep analyzer में शामिल किया जाना चाहिए। एक नया semgrep रिलीज़ का अनुरोध करने के लिए, SAST रिलीज़ मुद्दा टेम्पलेट में दिए गए निर्देशों का उपयोग करके एक रिलीज़ मुद्दा बनाएं।

श्रेय

हम निम्नलिखित लेखकों को उनके मूल्यवान योगदान के लिए बहुत-बहुत धन्यवाद देना चाहते हैं।