मुख्य सारांश
Python package ecosystem को निशाना बनाने वाले supply chain हमलों से निपटने के लिए ऐसी multi-layered defense strategy की ज़रूरत है जो किसी एक नियंत्रण पर निर्भर न हो। इस लेख में Ruff के S (Bandit) rules का उपयोग कर static vulnerability blocking, uv के ज़रिए cryptographic hash-आधारित dependency pinning, और CI environment में pip-audit तथा SBOM(CycloneDX) generation की सिफारिश की गई है। package distribution के समय long-lived API tokens की जगह OIDC-आधारित Trusted Publishing अपनाने, और नए package की intentional delayed ingestion के माध्यम से malicious package पर community validation के लिए समय उपलब्ध कराने वाला एक व्यावहारिक pipeline भी प्रस्तुत किया गया है.
गहन विश्लेषण
- Supply chain attack vectors और transitive dependency: इस समय PyPI पर 7.4 लाख से अधिक packages मौजूद हैं, और ctx domain hijacking, Ultralytics(YOLO) CI script injection, GhostAction token theft जैसी बड़े पैमाने की security incidents लगातार सामने आ रही हैं। भले ही आप केवल एक package (जैसे Flask) install करें, उसके साथ कई transitive dependencies (जैसे MarkupSafe आदि) भी install हो जाती हैं। इसलिए developer द्वारा explicit रूप से declare न किए गए packages भी एक बड़े attack surface के रूप में काम करते हैं।
- अपने code में vulnerabilities को पहले से रोकना: external packages से पहले internal code की कमियों को रोकना ज़रूरी है। hardcoded secrets, weak hash algorithms (MD5, SHA1), timeout के बिना network requests (DoS का कारण), unsafe serialization (
pickle) जैसी समस्याएँ code review के दौरान आसानी से छूट सकती हैं। इसे रोकने के लिए CI/CD pipeline और IDE में Ruff के Bandit security rules को integrate करके automatic detection और blocking करना आवश्यक है। - Dependency pinning और delayed ingestion: dependency install करते समय केवल version specify करना काफ़ी नहीं है; package के cryptographic hash को भी pin करना चाहिए ताकि runtime environment में tampering रोकी जा सके। साथ ही, नए release हुए malicious packages के block होने से पहले के जोखिम को कम करने के लिए
uvके--exclude-newerflag का उपयोग, या internal mirror repository में '7-दिन ingestion queue' बनाकर केवल community की प्रारंभिक validation से गुज़रे packages को ही internal network में आने देना, एक प्रभावी रणनीति है। - सुरक्षित package distribution: open source maintainers और package publishers को compromise के जोखिम वाले static API tokens हटाकर Sigstore का उपयोग करने वाले OIDC(OpenID Connect)-आधारित Trusted Publishing पर जाना चाहिए। इससे source repository के साथ linkage को cryptographically prove करने वाली attestation अपने आप generate होती है।
मुख्य code और data
1. Transitive dependencies की जाँच
# एक single package(Flask) install करने पर साथ आने वाली hidden dependency tree की जाँच
uv pip install flask
uv pip tree
# Output:
flask v3.1.0
├── blinker v1.9.0
├── click v8.1.8
├── itsdangerous v2.2.0
├── jinja2 v3.1.5
│ └── markupsafe v3.0.2
└── werkzeug v3.1.3
└── markupsafe v3.0.2
2. Ruff का उपयोग कर security ruleset(Bandit) लागू करना
# `pyproject.toml` configuration example
[tool.ruff]
line-length = 120
# E(Error), F(Pyflakes) के साथ S(Bandit security rules) enabled
lint.select = ["E", "F", "S"]
# Ruff 'S' ruleset द्वारा automatically detect होने वाले representative vulnerability patterns
# FLAGGED: S301 - `pickle.loads()` में arbitrary code execution का जोखिम है (`json.loads()` recommended)
import pickle
data = pickle.loads(untrusted_input)
# FLAGGED: S608 - string formatting के ज़रिए SQL injection vulnerability
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'")
# FLAGGED: S113 - timeout के बिना external request (infinite wait और DoS attack का exposure)
import requests
response = requests.get("[https://api.example.com/data](https://api.example.com/data)")
3. Delayed ingestion के माध्यम से नए packages पर नियंत्रण
# किसी specific date से पहले (जैसे 7 दिन पहले) release हुए packages को ही dependency के रूप में compile करके शुरुआती malware/errors से बचाव
uv pip compile --exclude-newer 2026-03-02 requirements.in -o requirements.txt
4. संगठन के भीतर ingestion control pipeline
| प्रसंस्करण चरण | सिस्टम घटक | सुरक्षा उद्देश्य और विवरण |
|---|---|---|
| Inflow | PyPI ➜ Ingestion Queue | PyPI में registered नए packages को internal system में तुरंत deploy न करके queue में लाना |
| Wait | Wait (ex. 7 days) | package के malicious होने या vulnerabilities की community और security researchers द्वारा analysis के लिए पर्याप्त समय देना |
| Verification | Security Scan ➜ Approved | waiting period के बाद, केवल known vulnerabilities(CVE) और malware scan पास करने पर approval |
| Deployment | Internal Mirror ➜ Developers | केवल verified packages को internal mirror repository में cache करके development team को सुरक्षित उपयोग की अनुमति |
अभी कोई टिप्पणी नहीं है.