भेद्यता विश्लेषण DevSecOps खतरा खुफिया आपूर्ति श्रृंखला सुरक्षा

aquasecurity/vex-repo-spec

vex-repo-spec

VEX रिपॉजिटरी विनिर्देशन

रिपॉजिटरी देखें

722 साल पहले

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →

साझा करें

5.5 दक्षता रणनीतियाँ

इस दस्तावेज़ में कीवर्ड "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" की व्याख्या RFC 2119 में वर्णित अनुसार की जानी है।

1. संस्करण

VEX (Vulnerability Exploitability eXchange) रिपॉजिटरी विनिर्देश को vX.Y संस्करण का उपयोग करना आवश्यक (MUST) है।
v1.0 और उसके बाद के लिए:
- X (मुख्य संस्करण) को ब्रेकिंग परिवर्तनों के लिए अद्यतन करना आवश्यक (MUST) है।
- Y (लघु संस्करण) को पिछड़े-संगत परिवर्तनों के लिए अद्यतन करना आवश्यक (MUST) है।
v0.Y संस्करणों के लिए, लघु संस्करण अद्यतनों के साथ ब्रेकिंग परिवर्तन हो सकते हैं (MAY)।

संस्करणों की तुलना करते समय:

संस्करणों की तुलना संख्यात्मक रूप से की जानी आवश्यक (MUST) है, शब्दकोशीय रूप से नहीं।
मुख्य संस्करणों की तुलना पहले की जानी आवश्यक (MUST) है:
- यदि मुख्य संस्करण भिन्न हैं, तो उच्च मुख्य संस्करण वाला संस्करण नया माना जाता है।
- यदि मुख्य संस्करण समान हैं, तो लघु संस्करणों की तुलना करने के लिए आगे बढ़ें।
लघु संस्करणों की तुलना केवल तभी आवश्यक (MUST) है जब मुख्य संस्करण समान हों:
- उच्च लघु संस्करण वाला संस्करण नया माना जाता है।

उदाहरण तुलनाएँ:

1.0 < 2.0
1.1 < 1.2
1.10 > 1.2

2. रिपॉजिटरी मैनिफेस्ट

2.1 अवलोकन

मैनिफेस्ट फ़ाइल VEX डेटा रिपॉजिटरी के बारे में मेटाडेटा प्रदान करती है। इस फ़ाइल में VEX डेटा प्राप्त करने और अद्यतन करने के लिए आवश्यक जानकारी होनी चाहिए (MUST)।

2.2 फ़ाइल स्थान

HTTPS के लिए: मैनिफेस्ट फ़ाइल https://<domain>/.well-known/vex-repository.json पर स्थित होना आवश्यक (MUST) है।
GitHub रिपॉजिटरी के लिए: vex-repository.json को मुख्य शाखा की रूट निर्देशिका में रखा जाना आवश्यक (MUST) है।

2.3 स्कीमा

मैनिफेस्ट फ़ाइल के लिए JSON स्कीमा यहाँ परिभाषित है।

2.4 उदाहरण

{
  "name": "Example Org VEX Repository",
  "description": "VEX repository for Example Organization",
  "versions": [
    {
      "spec_version": "0.1",
      "locations": [
        {
          "url": "https://example.com/vex-hub/v0/vex-data-v0.tar.gz"
        }
      ],
      "update_interval": "24h",
      "repository_specific": {
        "location": {
          "repository_type": "db",
          "db_type": "bbolt",
          "url": "oci://ghcr.io/example.com/vex-db:0"
        }
      }
    },
    {
      "spec_version": "1.0",
      "locations": [
        {
          "url": "https://example.com/vex-hub/v1/vex-data-v1.tar.gz//subdirectory"
        },
        {
          "url": "https://example.com/vex-api/v1"
        }
      ],
      "update_interval": "1h"
    }
  ]
}

2.5 फ़ील्ड विवरण और उपयोग नोट्स

मुख्य फ़ील्ड

फ़ील्ड	आवश्यक	विवरण और उपयोग नोट्स
name	✓	रिपॉजिटरी का नाम।
description	✓	रिपॉजिटरी का संक्षिप्त विवरण।
versions	✓	उपलब्ध संस्करणों के विवरण वाली एक सरणी। सरणी का प्रत्येक ऑब्जेक्ट एक संस्करण का प्रतिनिधित्व करता है जो VEX रिपॉजिटरी विनिर्देश के एक संस्करण को लागू करता है। संस्करणों को आरोही क्रम में, सबसे पुराने से नवीनतम तक क्रमबद्ध होना आवश्यक (MUST) है। उप-फ़ील्ड के लिए अलग तालिका देखें।

संस्करण उप-फ़ील्ड

फ़ील्ड	आवश्यक	विवरण और उपयोग नोट्स
spec_version	✓	लागू किए गए VEX रिपॉजिटरी विनिर्देश का संस्करण (जैसे, "0.1")। प्रारूप "X.Y" होना आवश्यक (MUST) है, जैसा कि अनुभाग 1 में परिभाषित है।
locations	✓	VEX डेटा लोकेशन का वर्णन करने वाले ऑब्जेक्ट्स की एक सरणी। इसमें कम से कम एक लोकेशन ऑब्जेक्ट होना आवश्यक (MUST) है। उप-फ़ील्ड के लिए अलग तालिका देखें।
update_interval	✓	इस संस्करण के VEX डेटा के लिए अनुशंसित अद्यतन जाँच अंतराल। Go अवधि प्रारूप का उपयोग करता है (जैसे, "1h", "30m", "24h")।
repository_specific	-	अतिरिक्त रिपॉजिटरी-विशिष्ट जानकारी।

लोकेशन उप-फ़ील्ड

फ़ील्ड	आवश्यक	विवरण और उपयोग नोट्स
url	✓	VEX डेटा लोकेशन के लिए URL, जो "https://" से शुरू होता है। सामग्री अनुभाग 3 और 4 में दी गई रिपॉजिटरी संरचना विनिर्देशों का पालन करती है। URL में '//' के बाद उपनिर्देशिका पथ जोड़कर एक उपनिर्देशिका निर्दिष्ट की जा सकती है।

3. रिपॉजिटरी संरचना

3.1 फ़ाइल संरचना

रिपॉजिटरी में निम्नलिखित संरचना होना आवश्यक (MUST) है:

vex-repository.<archive_extension>
[optional_subdirectory/]
├── index.json
└── pkg/
    ├── <type>/
    │   ├── <namespace>/
    │   │   ├── <name>/
    │   │   │   └── vex.json
    │   │   └── ...
    │   └── ...
    └── ...

जहाँ <archive_extension> समर्थित संग्रह प्रारूपों में से एक है।

[optional_subdirectory/] तब शामिल किया जाता है जब locations फ़ील्ड में URL // के बाद उपनिर्देशिका पथ के साथ समाप्त होता है। यह रिपॉजिटरी संरचना में लचीलापन प्रदान करता है, विशेष रूप से GitHub रिपॉजिटरी जैसी मौजूदा रिपॉजिटरी लेआउट का उपयोग करते समय।

उदाहरण के लिए, यदि URL https://github.com/org/repo/archive/refs/heads/main.tar.gz//repo-main है, तो फ़ाइल संरचना इस प्रकार होगी:

main.tar.gz
└──repo-main/
   ├── index.json
   └── pkg/
       └── ...

इस स्थिति में, repo-main/ tar.gz फ़ाइल के भीतर VEX रिपॉजिटरी के लिए रूट निर्देशिका है।

3.2 index.json

index.json फ़ाइल संग्रह फ़ाइल की सामग्री के लिए एक मैनिफेस्ट के रूप में कार्य करती है। इसे संग्रह की रूट निर्देशिका में या URL में परिभाषित होने पर निर्दिष्ट उपनिर्देशिका में रखा जाना आवश्यक (MUST) है। फ़ाइल में निम्नलिखित संरचना होना आवश्यक (MUST) है:

{
  "updated_at": "2023-07-04T12:00:00Z",
  "packages": [
    {
      "id": "pkg:deb/debian/curl",
      "location": "pkg/deb/debian/curl/vex.json"
    },
    {
      "id": "pkg:npm/lodash",
      "location": "pkg/npm/lodash/vex.json",
      "format": "csaf"
    }
  ]
}

फ़ील्ड विवरण:

फ़ील्ड	आवश्यक	विवरण
updated_at	✓	वह टाइमस्टैम्प जो दर्शाता है कि यह index.json अंतिम बार कब अद्यतन किया गया था।
packages	✓	ऑब्जेक्ट्स की सरणी, जिसका प्रत्येक ऑब्जेक्ट रिपॉजिटरी में एक पैकेज का प्रतिनिधित्व करता है।
packages[].id	✓	पैकेज का पहचानकर्ता। वर्तमान में, केवल Package URL (PURL) स्वीकार किया जाता है। संस्करण, क्वालिफायर और सबपाथ को हटाना आवश्यक (MUST) है क्योंकि वे VEX दस्तावेज़ में शामिल होते हैं। OCI प्रकार के पैकेजों के लिए, `repository_url` क्वालिफायर को id में शामिल किया जाना आवश्यक (MUST) है।
packages[].location	✓	संग्रह के भीतर इस पैकेज के VEX फ़ाइल का सापेक्ष पथ। क्लाइंट को विशिष्ट पैकेज VEX फ़ाइलों का पता लगाने के लिए इस फ़ील्ड का उपयोग करना आवश्यक (MUST) है।
packages[].format	-	VEX डेटा का प्रारूप। या तो "openvex" या "csaf"। यदि छोड़ा गया है, तो "openvex" मान लिया जाता है।

इंडेक्स फ़ाइल के लिए स्कीमा यहाँ परिभाषित है।

3.3 VEX दस्तावेज़

प्रत्येक पैकेज की VEX जानकारी index.json फ़ाइल में परिभाषित पथ संरचना का पालन करते हुए एक अलग JSON फ़ाइल में संग्रहीत होना आवश्यक (MUST) है। इन फ़ाइलों की सामग्री format फ़ील्ड में निर्दिष्ट VEX प्रारूप विनिर्देश (OpenVEX या CSAF VEX) का पालन करना आवश्यक (MUST) है। एक एकल VEX दस्तावेज़ में एक ही पैकेज के विभिन्न संस्करणों, क्वालिफायरों और सबपाथों के लिए जानकारी शामिल हो सकती है (MAY)।

OpenVEX दस्तावेज़ उदाहरणों के लिए, कृपया OpenVEX विनिर्देश देखें।

3.4 उपयोग नोट्स

निर्देशिका संरचना

पैकेजों के लिए उनके PURL के आधार पर निर्देशिका संरचनाएँ बनाने की अनुशंसा (RECOMMENDED) की जाती है, जिसमें संस्करण, क्वालिफायर और सबपाथ शामिल नहीं होते। उदाहरण के लिए, PURL "pkg:deb/debian/curl" वाला पैकेज "pkg/deb/debian/curl/vex.json" में संग्रहीत किया जा सकता है।
OCI पैकेजों के लिए, निर्देशिका संरचना बनाने हेतु PURL के repository_url क्वालिफायर का उपयोग किया जा सकता है (MAY)। उदाहरण के लिए, PURL "pkg:oci/debian@sha256:3e45770a143ee5afd1ebde5a6aea6e32a71d2bt5602f5dac8025db0d9cc19f10?repository_url=docker.io/library/debian" वाला पैकेज "pkg/oci/docker.io/library/debian/vex.json" में संग्रहीत किया जा सकता है।
VEX फ़ाइलों का वास्तविक स्थान अनुशंसित संरचना की परवाह किए बिना index.json फ़ाइल के location फ़ील्ड में स्वतंत्र रूप से परिभाषित किया जा सकता है (MAY)।
संग्रह के भीतर सभी फ़ाइल पथों को ऑपरेटिंग सिस्टम की परवाह किए बिना विभाजक के रूप में फॉरवर्ड स्लैश (/) का उपयोग करना आवश्यक (MUST) है।
निर्देशिका संरचना में पैकेज नामों को URL-एनकोडेड होना आवश्यक (MUST) है यदि उनमें विशेष वर्ण हों।

VEX दस्तावेज़ सामग्री

एक एकल VEX दस्तावेज़ में एक ही पैकेज के विभिन्न संस्करणों, क्वालिफायरों और सबपाथों के लिए जानकारी शामिल हो सकती है (MAY)।
किसी विशिष्ट संस्करण, क्वालिफायर या सबपाथ के लिए क्वेरी करते समय, क्लाइंट को प्रासंगिक जानकारी खोजने के लिए पूरे VEX दस्तावेज़ को पार्स करना आवश्यक (MUST) है।

3.5 रिपॉजिटरी को अद्यतन करना

VEX रिपॉजिटरी को अद्यतन करते समय:

प्रभावित पैकेजों के लिए नई या अद्यतन vex.json फ़ाइलें बनाएँ।
किसी भी परिवर्तन को दर्शाने के लिए index.json फ़ाइल को अद्यतन करें, जिसमें updated_at टाइमस्टैम्प को अद्यतन करना शामिल है।
अद्यतन सामग्री के साथ एक नया संग्रह बनाएँ।
नए संग्रह को मैनिफेस्ट फ़ाइल (vex-repository.json) में निर्दिष्ट स्थान पर अपलोड करें।
यदि आवश्यक हो तो मैनिफेस्ट फ़ाइल (vex-repository.json) में प्रासंगिक locations URL को अद्यतन करें।

4. रिपॉजिटरी वितरण

4.1 अवलोकन

VEX रिपॉजिटरी को VEX डेटा और संबंधित मेटाडेटा वाली एक संग्रह फ़ाइल के रूप में वितरित किया जाना आवश्यक (MUST) है। इस संग्रह का संदर्भ vex-repository.json फ़ाइल में locations फ़ील्ड द्वारा दिया जाना आवश्यक (MUST) है, और यह VEX जानकारी वितरित करने का प्राथमिक माध्यम है।

4.2 संग्रह प्रारूप

संग्रह फ़ाइल निम्नलिखित प्रारूपों में से एक में होना आवश्यक (MUST) है:

tar.gz और tgz
tar.bz2 और tbz2
tar.xz और txz
zip
gz
bz2
xz

5. क्लाइंट कार्यान्वयन दिशानिर्देश

5.1 संस्करण चयन

versions सरणी से संस्करण चुनते समय:

क्लाइंट को spec_version फ़ील्ड के आधार पर एक ऐसा संस्करण चुनना आवश्यक (MUST) है जिसे वे समर्थन करते हैं।
क्लाइंट को अनुभाग 1 में परिभाषित नियमों के अनुसार संस्करणों की तुलना करना आवश्यक (MUST) है।
versions सरणी को सबसे पुराने से नवीनतम तक क्रमबद्ध होने की गारंटी है। क्लाइंट इस क्रम का उपयोग किसी उपयुक्त संस्करण का कुशलतापूर्वक चयन करने के लिए कर सकते हैं।
v1.0 और उसके बाद के संस्करणों के लिए:
- क्लाइंट उसी मुख्य संस्करण के भीतर अपने समर्थित नवीनतम संस्करण का चयन कर सकते हैं (MAY), क्योंकि मुख्य संस्करणों के भीतर पिछड़ी संगतता बनाए रखी जाती है।
v0.Y संस्करणों के लिए (जहाँ Y कोई भी लघु संस्करण है):
- क्लाइंट को सटीक संस्करण मिलान का चयन करना चाहिए (SHOULD)।
- ऐसा इसलिए है क्योंकि v0.Y संस्करणों में लघु संस्करणों के बीच ब्रेकिंग परिवर्तन शामिल हो सकते हैं (MAY)।
यदि कोई समर्थित संस्करण उपलब्ध नहीं है, तो क्लाइंट को रिपॉजिटरी का उपयोग नहीं करना चाहिए (MUST NOT) और उपयोगकर्ता को सूचित करना चाहिए (SHOULD)।

5.2 लोकेशन चयन

locations सरणी में कई लोकेशनों से निपटते समय:

प्राथमिकता क्रम: क्लाइंट को सरणी में उनके क्रम के आधार पर लोकेशनों को प्राथमिकता देना आवश्यक (MUST) है। पहले सूचीबद्ध लोकेशन का प्रयास बाद की लोकेशनों पर जाने से पहले किया जाना चाहिए।
स्कीमा समर्थन:
- वर्तमान में, विनिर्देश में केवल "https" स्कीम समर्थित है।
- इस विनिर्देश के भविष्य के संस्करण अतिरिक्त स्कीम पेश कर सकते हैं।
- क्लाइंट को प्रत्येक लोकेशन की URL स्कीम की जाँच करनी चाहिए (SHOULD) और केवल समर्थित स्कीम वाली लोकेशनों का उपयोग करना चाहिए।
फ़ॉलबैक तंत्र: यदि किसी क्लाइंट को किसी एक लोकेशन के साथ त्रुटि होती है, तो उसे सरणी में अगली उपलब्ध लोकेशन का उपयोग करने का प्रयास करना चाहिए (SHOULD)।

5.3 एकाधिक रिपॉजिटरी समर्थन

क्लाइंटों को एकाधिक VEX रिपॉजिटरी का समर्थन करने के लिए डिज़ाइन किया जाना चाहिए (SHOULD)।

रिपॉजिटरी प्राथमिकता

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

5.4 अद्यतनों की जाँच

क्लाइंटों को अद्यतनों की जाँच के लिए निम्नलिखित प्रक्रिया का उपयोग करना चाहिए (SHOULD):

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

5.5 दक्षता रणनीतियाँ

कुशल संचालन के लिए, क्लाइंट निम्नलिखित रणनीतियों को लागू कर सकते हैं (MAY):

अद्यतनों की जाँच के लिए अनुरोध करते समय HTTP ETags या Last-Modified हेडर का उपयोग करें। यह सामग्री न बदलने पर अनावश्यक डाउनलोड को कम करने में मदद कर सकता है।
अत्यधिक नेटवर्क अनुरोधों से बचने के लिए अद्यतन जाँचों के बीच एक न्यूनतम अंतराल लागू करें (जैसे, 1 घंटा), विशेष रूप से उन स्थितियों में जहाँ update_interval बहुत छोटा है।
अद्यतन जाँचों के मैन्युअल ओवरराइड की अनुमति दें, जिससे उपयोगकर्ता गणना किए गए अगले अद्यतन समय की परवाह किए बिना तुरंत जाँच को बाध्य कर सकें।

टूल डाउनलोड करें

vex-repo-spec

सबसे लोकप्रिय

VEX रिपॉजिटरी विनिर्देश v0.1

1. संस्करण

2. रिपॉजिटरी मैनिफेस्ट

2.1 अवलोकन

2.2 फ़ाइल स्थान

2.3 स्कीमा

2.4 उदाहरण

2.5 फ़ील्ड विवरण और उपयोग नोट्स

मुख्य फ़ील्ड

संस्करण उप-फ़ील्ड

लोकेशन उप-फ़ील्ड

3. रिपॉजिटरी संरचना

3.1 फ़ाइल संरचना

3.2 index.json

3.3 VEX दस्तावेज़

3.4 उपयोग नोट्स

निर्देशिका संरचना

VEX दस्तावेज़ सामग्री

3.5 रिपॉजिटरी को अद्यतन करना

4. रिपॉजिटरी वितरण

4.1 अवलोकन

4.2 संग्रह प्रारूप

5. क्लाइंट कार्यान्वयन दिशानिर्देश

5.1 संस्करण चयन

5.2 लोकेशन चयन

5.3 एकाधिक रिपॉजिटरी समर्थन

रिपॉजिटरी प्राथमिकता

5.4 अद्यतनों की जाँच

5.5 दक्षता रणनीतियाँ