निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण
SCA उपकरणों से तृतीय-पक्ष लाइब्रेरी का ऑडिट करें, निर्भरता पिनिंग लागू करें और स्वचालित कमज़ोरी चेतावनियों को CI/CD पाइपलाइन में एकीकृत करें।
निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण, CoddyKit पर Cloud & IT Cert Prep का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Cloud & IT Cert Prep सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
Open Source Dependency का जोखिम
आधुनिक applications बड़े पैमाने पर third-party open source libraries और frameworks से बनी होती हैं। किसी सामान्य Node.js application में 1,000 से अधिक transitive dependencies हो सकती हैं; कोई Java project सैकड़ों Maven artifacts ला सकता है। प्रत्येक dependency संभावित attack surface है। Log4j library में मौजूद Log4Shell vulnerability (CVE-2021-44228) ने दिखाया कि disclosure के कुछ ही दिनों के भीतर कोई एक dependency दुनिया भर में लाखों applications को तुरंत exploit किए जाने योग्य बना सकती है।
Software Composition Analysis क्या है
Software Composition Analysis (SCA) tools किसी application में मौजूद सभी open source components की inventory अपने-आप बनाते हैं—इसमें transitive dependencies (आपकी dependencies की dependencies) भी शामिल होती हैं—और ज्ञात CVEs के लिए उन्हें vulnerability databases से लगातार जाँचते हैं। SCA एक Software Bill of Materials (SBOM) बनाता है, जिसमें प्रत्येक component और version की सूची होती है। इससे नई vulnerabilities disclose होने पर प्रभावित systems की तुरंत पहचान की जा सकती है।
# SCA tool usage examples:
# npm audit (Node.js):
# npm audit
# -> Reports vulnerabilities in package.json dependencies
# -> Shows severity, CVE ID, affected package, fix version
# OWASP Dependency-Check (Java/Python/etc.):
# dependency-check --project 'MyApp' --scan ./lib/
# -> Generates HTML/XML report with CVE findings
# Snyk scan:
# snyk test
# -> Reports vulns + 'snyk fix' applies patches automaticallyTransitive Dependencies: छिपा हुआ जोखिम
Transitive dependencies वे libraries हैं जिन पर आपकी direct dependencies निर्भर करती हैं और जिन्हें आपने स्पष्ट रूप से नहीं चुना। हो सकता है कि आप सीधे Package A पर निर्भर हों, जो Package B (version 1.2) पर निर्भर हो, और Package B Package C (version 3.0—एक vulnerable version) पर निर्भर हो। आपको Package C के बारे में जानकारी न हो, लेकिन आपका application उसे चलाता है। SCA tools पूरी dependency tree को traverse करके इन छिपी vulnerabilities को उजागर करते हैं, जिनकी developers को सीधे visibility नहीं होती।
# Dependency tree example:
# Your package.json:
# 'express': '^4.18.0' (direct dependency)
# 'lodash': '^4.17.21' (direct dependency)
# Transitive dependencies (you didn't choose these):
# express -> 'qs' 6.11.0 (URL parsing)
# express -> 'body-parser' 1.20 -> 'qs' 6.11.0
# lodash (self-contained in this case)
# If 'qs' 6.10.x had a prototype pollution CVE,
# you are vulnerable via express even though
# you never directly imported 'qs'.Software Bill of Materials (SBOM)
Software Bill of Materials (SBOM) किसी software product में मौजूद सभी components की औपचारिक, machine-readable inventory है—कुछ-कुछ food ingredient list जैसी। SBOM formats में SPDX (Linux Foundation) और CycloneDX (OWASP) शामिल हैं। US Executive Order 14028 (2021) ने federal government को बेचे जाने वाले software के लिए SBOM अनिवार्य किए। SBOM होने पर security teams तुरंत पूछ सकती हैं: 'हमारे किन products में Log4j मौजूद है?' और दिनों तक manually खोजने के बजाय कुछ मिनटों में उत्तर पा सकती हैं।
# Generate SBOM with syft:
# syft packages . -o spdx-json > sbom.spdx.json
# SBOM content example (SPDX JSON):
# {
# 'packages': [
# { 'name': 'express', 'version': '4.18.2', 'license': 'MIT' },
# { 'name': 'lodash', 'version': '4.17.21','license': 'MIT' },
# { 'name': 'log4j-core','version': '2.14.0','license': 'Apache-2.0'}
# ]
# }
# When Log4Shell announced, query SBOM:
# grep -i 'log4j-core' sbom.spdx.json -> FOUND in 3 projectsDependency Pinning और Lock Files
Dependency pinning flexible ranges (^1.2.3 या *) के बजाय dependencies के exact versions निर्धारित करता है। Lock files (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) install के समय प्रत्येक dependency के exact resolved version को दर्ज करती हैं। इन्हें source control में commit किया जाना चाहिए, ताकि प्रत्येक team member और CI/CD pipeline समान dependency versions का उपयोग करे और installs के बीच package versions को दूषित करके किए जाने वाले supply chain attacks रोके जा सकें।
# Version range vs pinned versions:
# FLEXIBLE (can pull different versions each install):
# 'express': '^4.0.0' -> installs latest 4.x.x
# 'lodash': '*' -> installs any version!
# PINNED (always same version):
# 'express': '4.18.2' -> always exactly 4.18.2
# Lock file (package-lock.json):
# Records EXACT resolved version of every transitive dep.
# Commit this file! It ensures reproducible builds.
# Never .gitignore lock files (security anti-pattern).Supply Chain Attacks: typosquatting और Dependency Confusion
Supply chain attacks dependency ecosystem को target करते हैं। Typosquatting में लोकप्रिय packages से मिलते-जुलते नाम वाले malicious packages प्रकाशित किए जाते हैं (जैसे lodash के बजाय lodahs), इस उम्मीद में कि developers नाम गलत type कर देंगे। Dependency confusion attacks उस क्रम का लाभ उठाते हैं जिसमें package managers registries में खोज करते हैं—attacker किसी internal private package के समान नाम वाला malicious package, लेकिन अधिक version number के साथ प्रकाशित करता है। इससे package manager उसके बजाय malicious public version install कर देता है।
# Dependency Confusion Attack (Alex Birsan 2021):
# Company uses internal package 'company-utils' v1.0.0
# Hosted on: internal.registry.company.com
# Attacker publishes 'company-utils' v9.9.9 to npmjs.com
# (public registry with higher version number)
# npm install resolves: 'find highest version across ALL registries'
# -> Installs v9.9.9 from public npm (attacker's malicious package!)
# -> Instead of v1.0.0 from internal registry
# Defense: use namespace scoping (@company/utils)
# or configure npm to ONLY use internal registry for private packagesबाज़ार में उपलब्ध SCA Tools
Industry में कई SCA tools व्यापक रूप से उपयोग किए जाते हैं। Snyk automatic fix PRs के साथ developers के लिए सरल dependency scanning उपलब्ध कराता है। OWASP Dependency-Check Java, .NET, Python और Ruby के लिए एक free और व्यापक रूप से अपनाया गया tool है। GitHub Dependabot GitHub repositories में vulnerable dependencies को update करने के लिए pull requests अपने-आप खोलता है। JFrog Xray और Sonatype Nexus IQ SCA को artifact repositories में integrate करते हैं, ताकि vulnerable builds production तक न पहुँचें।
CI/CD Pipelines में SCA को Integrate करना
SCA सबसे प्रभावी तब होता है जब उसे CI/CD pipeline में quality gate के रूप में integrate किया जाता है। प्रत्येक pull request और build पर pipeline SCA tool चलाती है और यदि dependencies में critical या high severity CVEs मिलें, तो build विफल कर देती है। यह 'shift left' approach vulnerable dependencies को production तक पहुँचने से पहले पकड़ लेती है—न कि महीनों बाद manual security review के दौरान या breach के बाद। Teams को vulnerability severity की स्पष्ट सीमाएँ निर्धारित करनी चाहिए: कौन-सी deployment रोकेंगी और कौन-सी केवल warnings उत्पन्न करेंगी।
# GitHub Actions SCA pipeline step:
# - name: Run Snyk SCA scan
# uses: snyk/actions/node@master
# env:
# SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
# with:
# args: --severity-threshold=high
# --fail-on=upgradable
# # Build fails if any HIGH or CRITICAL vuln found
# # that has an available fix (--fail-on=upgradable)
# # No fix available? Generates warning, doesn't block
# # (acknowledging risk explicitly is better than blocking forever)Open Source Package Health का मूल्यांकन
किसी dependency को जोड़ने से पहले कई संकेतों का उपयोग करके उसकी security posture का मूल्यांकन करें। Maintenance activity: क्या project सक्रिय रूप से maintain किया जा रहा है? आखिरी commit और release कब हुआ था? Known vulnerability history: इसमें कितने CVEs रहे हैं और उन्हें कितनी जल्दी patch किया गया? Download volume: व्यापक रूप से उपयोग किए जाने वाले packages पर अधिक security scrutiny होती है। Dependency count: कम dependencies वाले packages कम transitive risk पैदा करते हैं। OpenSSF Scorecard open source project की security practices का automated scoring उपलब्ध कराता है।
Vulnerability Remediation Strategies
जब SCA किसी vulnerable dependency की पहचान करता है, तो remediation की कई strategies उपलब्ध होती हैं। Upgrade करके patched version पर जाएँ—उपलब्ध होने पर यह पसंदीदा विकल्प है। Upgrade तैयार होने तक ज्ञात exploit paths को WAF rules के माध्यम से Virtual patching करके कम किया जा सकता है। यदि dependency की अब आवश्यकता नहीं है, तो उसे Remove करें। यदि vulnerability विशेष उपयोग context में exploitable नहीं है (जैसे client-side library में server-side vulnerability), तो documented justification के साथ Accept the risk करें। Documented acceptance के बिना critical vulnerabilities को कभी अनसुलझा न छोड़ें।
Dependencies में License Compliance
SCA tools दोहरे उद्देश्य की पूर्ति करते हैं: वे security vulnerabilities की पहचान और open source dependencies में license compliance issues को flag करते हैं। आम problematic licenses में GPL v2/v3 (copyleft—यदि आप product distribute करते हैं, तो उसे भी open source करना आवश्यक होता है), AGPL (GPL को network services तक विस्तारित करता है) और SSPL शामिल हैं। Commercial license के बिना proprietary commercial software में GPL-licensed library का उपयोग गंभीर legal liability पैदा कर सकता है। FOSSA, Black Duck, and WhiteSource जैसे SCA tools vulnerability detection के साथ license scanning को automate करते हैं और open source obligations के अनुपालन को सुनिश्चित करते हैं।
# License compliance risk levels:
# PERMISSIVE (low risk for commercial use):
# MIT, Apache 2.0, BSD 2/3-Clause
# -> Can use in proprietary code, just keep attribution
# WEAK COPYLEFT (medium risk - check usage):
# LGPL -> can link dynamically without open-sourcing your code
# MPL 2.0 -> modifications to MPL files must be open-sourced
# STRONG COPYLEFT (high risk for proprietary products):
# GPL v2, GPL v3 -> if you distribute code using GPL library,
# your entire product must also be GPL
# AGPL -> extends GPL to SaaS/network services
# SCA policy: block AGPL/GPL in commercial product
# -> Review any exception requests manuallyत्वरित जाँच
इस lesson में दिए गए CompTIA Security+ (SY0-701) concepts की अपनी समझ जाँचें।
Lesson Recap
इस lesson में आपने सीखा: SCA tools ज्ञात CVEs के लिए transitive dependencies सहित पूरी dependency tree को scan करते हैं; SBOMs machine-readable inventory उपलब्ध कराते हैं, जिससे नई vulnerabilities disclose होने पर तुरंत response दिया जा सकता है; और SCA को CI/CD quality gate के रूप में integrate करना vulnerable dependencies को production तक पहुँचने से पहले पकड़ लेता है। आगे हम DevSecOps और यह अध्ययन करेंगे कि security controls को पूरी CI/CD pipeline में बाईं ओर कैसे स्थानांतरित किया जाए।
एआई शिक्षक के साथ Cloud & IT Cert Prep सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 150
- पाठ
- 600
अक्सर पूछे जाने वाले प्रश्न
क्या “निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण” पाठ निःशुल्क है?
हाँ—“निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Cloud & IT Cert Prep पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण” में मैं क्या सीखूँगा?
SCA उपकरणों से तृतीय-पक्ष लाइब्रेरी का ऑडिट करें, निर्भरता पिनिंग लागू करें और स्वचालित कमज़ोरी चेतावनियों को CI/CD पाइपलाइन में एकीकृत करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Cloud & IT Cert Prep का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Cloud & IT Cert Prep शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Cloud & IT Cert Prep शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Cloud & IT Cert Prep पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Cloud & IT Cert Prep पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- इनपुट सत्यापन और आउटपुट एन्कोडिंग
- सुरक्षित गुप्त-सूचना प्रबंधन और पर्यावरण चर
- निर्भरता सुरक्षा और सॉफ़्टवेयर संरचना विश्लेषण
- DevSecOps: पाइपलाइनों में सुरक्षा को प्रारंभिक चरण में लाना