सुरक्षा

Apothem की सुरक्षा मुद्रा पाँच स्तंभों पर बनी है: आपूर्ति-श्रृंखला हार्डनिंग, भेद्यता प्रतिक्रिया, ब्रांच सुरक्षा, रिलीज़ हस्ताक्षर, और निरंतर सुरक्षा विश्लेषण। यह अनुभाग प्रत्येक सतह का दस्तावेज़ीकरण करता है।

ख़तरा मॉडलCopy Anchor Link

Apothem एक कॉन्फ़िगरेशन मूर्तीकारक है। यह एक साझा प्रोफ़ाइल पढ़ता है और उन डायरेक्टरियों में हार्नेस-नेटिव कॉन्फ़िगरेशन फ़ाइलें लिखता है जिन्हें प्रत्येक हार्नेस पढ़ता है। यही एक कार्य यह सीमित करता है कि वह किस पर भरोसा करता है और किस पर नहीं।

• Apothem किस पर भरोसा करता है। वह साझा प्रोफ़ाइल जिसे आप लिखते हैं, और इंस्टॉलर द्वारा रखा गया बंडल्ड स्रोत ट्री। प्रोफ़ाइल आपका घोषित अभिप्राय है; स्कीमा सत्यापन के बाद इंजन इसे आधिकारिक इनपुट के रूप में मानता है।
• Apothem किस पर भरोसा नहीं करता। प्रोफ़ाइल की सामग्री केवल सत्यापन के बाद फ़ाइल सिस्टम तक पहुँचती है: स्कीमा विफलताएँ, अज्ञात हार्नेस ID, असुरक्षित प्रोजेक्ट पथ, लुप्त मैनिफ़ेस्ट स्रोत, टारगेट ट्रैवर्सल, और सिमलिंक क्रॉसिंग — ये सभी किसी भी लेखन से पहले रुक जाते हैं और files_written: [] के साथ संरचित निदान लौटाते हैं।
• मटेरियलाइज़ किया गया आउटपुट कभी क्या नहीं ले जाता। कोई सीक्रेट नहीं। प्रोफ़ाइल निदान सीक्रेट-जैसी कुंजियों और टोकन-आकार के मानों को सादे आउटपुट, JSON, लॉग, दस्तावेज़ स्निपेट, या परीक्षणों तक पहुँचने से पहले छिपा देते हैं, और सार्वजनिक उदाहरण नकली प्लेसहोल्डर पहचानों और डोमेन का उपयोग करते हैं। मटेरियलाइज़ किया गया कॉन्फ़िगरेशन कमिट और साझा किए जाने के लिए है; उसमें कोई क्रेडेंशियल नहीं होते।
• सार्वभौमिक-अस्वीकार तल। Apothem जो Claude Code settings.json मटेरियलाइज़ करता है, उसमें किसी भी प्रति-हार्नेस अनुमति-सूची की परवाह किए बिना एक गैर-परक्राम्य अस्वीकार तल होता है; अन्य हार्नेस पर वही तल मटेरियलाइज़ किए गए नियमों में नीति-पाठ के रूप में रहता है, सेटिंग्स-स्तर की अस्वीकार सूची के रूप में नहीं। इस तल में शामिल हैं: सीक्रेट पथ (.env*, ~/.ssh/**, क्रेडेंशियल स्टोर), विनाशकारी शेल संचालन (rm -rf, sudo, संरक्षित ब्रांचों पर फ़ोर्स-पुश), और अविश्वसनीय इनपुट का निष्पादन। कोई भी अनुमति-सूची इस तल को चुपचाप विस्तृत नहीं करती।
• प्रभाव त्रिज्या। लेखन हार्नेस डायरेक्टरियों और Apothem-स्वामित्व वाले समर्थन उप-वृक्षों तक सीमित हैं। मौजूदा प्रबंधित टारगेट प्रतिस्थापन से पहले बैकअप किए जाते हैं, और साझा डिस्कवरी डायरेक्टरियाँ चाइल्ड-दर-चाइल्ड मर्ज की जाती हैं, ताकि असंबंधित ऑपरेटर-लिखित फ़ाइलें अपनी जगह बनी रहें।

रनटाइम सुरक्षा मुद्राCopy Anchor Link

हार्नेस जीवनचक्र और प्रोफ़ाइल-लेखन कमांड लिखने से पहले सत्यापन करते हैं। प्रोफ़ाइल स्कीमा विफलताएँ, अज्ञात हार्नेस ID, असुरक्षित प्रोजेक्ट पथ, लुप्त मैनिफ़ेस्ट स्रोत, टारगेट ट्रैवर्सल, और सिमलिंक क्रॉसिंग फ़ाइल सिस्टम लेखन से पहले रुक जाते हैं और files_written: [] के साथ संरचित निदान लौटाते हैं।

इंस्टॉल और अपडेट संचालन मौजूदा प्रबंधित टारगेट को प्रतिस्थापन से पहले बैकअप करके संरक्षित करते हैं। साझा डिस्कवरी डायरेक्टरियाँ चाइल्ड-दर-चाइल्ड मर्ज की जाती हैं ताकि असंबंधित ऑपरेटर-लिखित फ़ाइलें अपनी जगह बनी रहें। --dry-run वही सत्यापन करता है और कोई डायरेक्टरी या फ़ाइल बनाए बिना नियोजित परिणामों की रिपोर्ट करता है।

प्रोफ़ाइल निदान सीक्रेट-जैसी कुंजियों और टोकन-आकार के मानों को सादे आउटपुट, JSON आउटपुट, लॉग, दस्तावेज़ स्निपेट या परीक्षणों तक पहुँचने से पहले छिपा देते हैं। सार्वजनिक उदाहरण नकली प्लेसहोल्डर पहचानों और डोमेन का उपयोग करते हैं।

त्वरित लिंकCopy Anchor Link

• OpenSSF Scorecard स्थिति — प्रति-जाँच साक्ष्य और ज्ञात प्लेटफ़ॉर्म सीमाएँ
• Webhooks ऑडिट — webhook-सीक्रेट स्वच्छता का साक्ष्य
• ब्रांच सुरक्षा — पुल-रिक्वेस्ट आवश्यकता, आवश्यक स्टेटस चेक, और फ़ोर्स-पुश तथा विलोपन अवरोध
• बाइनरी आर्टिफ़ैक्ट स्वीप — इस बात का साक्ष्य कि स्रोत ट्री में कोई बाइनरी फ़ाइल नहीं है
• सुरक्षा नीति — भेद्यता रिपोर्टिंग और समर्थित संस्करण
• OpenSSF Scorecard बैज — लाइव स्कोर

किसी भेद्यता की रिपोर्ट करनाCopy Anchor Link

रिपॉज़िटरी के Security टैब पर निजी भेद्यता रिपोर्टिंग का उपयोग करें। पूर्ण नीति, समर्थित-संस्करण मैट्रिक्स, और प्रतिक्रिया समयरेखाएँ SECURITY.md पर हैं।

आपूर्ति-श्रृंखला रिलीज़ साक्ष्यCopy Anchor Link

प्रत्येक रिलीज़ आर्टिफ़ैक्ट इनके साथ शिप होता है:

• SLSA-3 बिल्ड प्रोवेनेंस, slsa-framework/slsa-github-generator के माध्यम से
• Sigstore हस्ताक्षर, sigstore/cosign-installer के माध्यम से
• CycloneDX SBOM, शिप किए गए wheel और sdist का, जिसे scripts/release/generate_sbom.py लिखता है: apothem पैकेज, apothem/_vendor के अंतर्गत वेंडर किया गया हर पैकेज उसके लाइसेंस के साथ, घोषित रनटाइम आवश्यकताएँ, और प्रत्येक वितरण का SHA-256। SBOM हस्ताक्षरित है और वितरणों की तरह बिल्ड प्रोवेनेंस के दायरे में आता है
• npm प्रोवेनेंस कथन, @ahmed-g-gad/apothem पर Trusted Publishing OIDC के माध्यम से
• GPG-हस्ताक्षरित git टैग (EDDSA कुंजी 70396FED9C634163)

किसी रिलीज़ को सत्यापित करेंCopy Anchor Link

किसी रिलीज़ के हर असेट को एक खाली डायरेक्टरी में डाउनलोड करें, फिर हस्ताक्षरों और बिल्ड प्रोवेनेंस की जाँच करें। vX.Y.Z और X.Y.Z को उस रिलीज़ से बदलें जिसे आपने डाउनलोड किया है।

gh release download vX.Y.Z --repo ahmed-g-gad/apothem
cosign verify-blob \
  --bundle apothem-X.Y.Z-py3-none-any.whl.cosign.bundle \
  --certificate-identity https://github.com/Ahmed-G-Gad/apothem/.github/workflows/release.yml@refs/tags/vX.Y.Z \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  apothem-X.Y.Z-py3-none-any.whl
slsa-verifier verify-artifact \
  --provenance-path provenance.intoto.jsonl \
  --source-uri github.com/Ahmed-G-Gad/apothem \
  --source-tag vX.Y.Z \
  apothem-X.Y.Z-py3-none-any.whl apothem-X.Y.Z.tar.gz

cosign Verified OK प्रिंट करता है और slsa-verifier PASSED: SLSA verification passed प्रिंट करता है। किसी भी अन्य असेट के लिए cosign कमांड को उसके <asset>.cosign.bundle के साथ दोहराएँ (पहले की रिलीज़ प्लेटफ़ॉर्म-आर्काइव और SHA256SUMS बंडलों को <asset>.sig नाम देती हैं)। darwin और linux आर्काइव दो नामों के अंतर्गत समान बाइट्स हैं, इसलिए SHA256SUMS एक ही डाइजेस्ट दो बार सूचीबद्ध करता है। किसी क्लोन से, bash scripts/release/verify-provenance.sh <download-dir> तीनों जाँचें, SHA256SUMS मैनिफ़ेस्ट सहित, एक ही पास में चलाता है।

दो बातें तय करती हैं कि सत्यापन का कोई अर्थ है या नहीं:

• स्वामी के अक्षरों का केस। पहचान जाँचें केस-संवेदी होती हैं, और प्रमाणपत्र स्वामी को उसी रूप में रखते हैं जैसा GitHub उसे रिपोर्ट करता है: Ahmed-G-Gad। छोटे अक्षरों वाला स्वामी दोनों टूल में विफल होता है।

• सटीक पहचान। ऊपर दिए गए पूर्ण सब्जेक्ट के साथ --certificate-identity को प्राथमिकता दें। किसी भी रिलीज़ टैग को स्वीकार करने के लिए, पैटर्न को दोनों सिरों पर एंकर करें:

  Copy Text

  --certificate-identity-regexp '^https://github\.com/Ahmed-G-Gad/apothem/\.github/workflows/release\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$'

  github.com/Ahmed-G-Gad/apothem जैसा बिना एंकर वाला पैटर्न किसी ऐसे जाली सब्जेक्ट से भी मेल खाता है जिसमें केवल वह टेक्स्ट शामिल हो, उदाहरण के लिए किसी अन्य रिपॉज़िटरी में इस रिपॉज़िटरी के नाम पर रखी गई ब्रांच पर चलने वाला वर्कफ़्लो।

रिलीज़-चक्र रनबुक इन्हीं कमांडों को अनुरक्षक की रिलीज़-पश्चात जाँच के रूप में दर्ज करता है।

किसी रिलीज़ को फिर से बिल्ड करें और तुलना करेंCopy Anchor Link

wheel और sdist पुनरुत्पादनीय हैं: रिलीज़ टूलचेन के साथ टैग को फिर से बिल्ड करने पर प्रकाशित SHA-256 डाइजेस्ट मिलते हैं। Linux पर Python 3.12 का उपयोग करें, जैसा कि रिलीज़ करती है:

git clone https://github.com/ahmed-g-gad/apothem && cd apothem
git checkout vX.Y.Z
python3.12 -m venv .build && . .build/bin/activate
pip install --require-hashes -r scripts/release/requirements-build-linux.txt
export SOURCE_DATE_EPOCH="$(git log -1 --pretty=%ct)"
python -m build --no-isolation
python scripts/release/normalize_sdist.py dist/*.tar.gz
sha256sum dist/*

डाइजेस्ट की तुलना प्रकाशित wheel और sdist से करें। बिल्ड उस हैश-लॉक setuptools का उपयोग करता है जिसे pyproject.toml पिन करता है, और normalize_sdist.py sdist से बिल्ड समय, फ़ाइल स्वामी और चेकआउट टाइमस्टैम्प हटा देता है।