Docker Scout: कंटेनर इमेज में कमजोरियों को कैसे स्कैन करें

कहानी कुछ यूँ है: आपने अपनी Docker इमेज बनाई, टैग किया, और डिप्लॉय कर दिया। सब कुछ बढ़िया लगता है, तभी आपकी सुरक्षा टीम किसी ऐसे पैकेज में कमजोरियाँ पकड़ लेती है जिसके बारे में आपको पता भी नहीं था। और इससे भी बुरा, कंप्लायंस टीम Software Bill of Materials (SBOM) माँगती है और आप समझ नहीं पाते कि आपकी इमेज के साथ कौन-कौन सी डिपेंडेंसीज़ शिप हो रही हैं। कंटेनर इमेज अक्सर ब्लैक बॉक्स जैसी लगती हैं—और जब प्रोडक्शन में चल रही चीज़ों की जिम्मेदारी आपकी हो, तो यह परेशानी बन जाती है।

Docker Scout आपकी कंटेनर इमेज पर रोशनी डालता है—उन्हें कमजोरियों के लिए स्कैन करके और अपने आप SBOMs बनाकर। यह Docker में ही शामिल है, इसलिए कोई अलग टूल इंस्टॉल या सीखने की ज़रूरत नहीं।

इस गाइड में, मैं आपको दिखाऊँगा कि Docker Scout से इमेज कैसे स्कैन करें और उसकी तैयार की गई भेद्यता रिपोर्टों को कैसे समझें, ताकि आप जान सकें कि इसे कब और कैसे उपयोग करना उचित है।

यदि आप Docker में नए हैं, तो हमारे लेख Top 18 Docker Commands पर नज़र डालें। ये आपको कंटेनर बनाने, चलाने, और प्रबंधित करने की सही दिशा में ले जाएँगे।

Docker Scout क्या है?

Docker Scout, Docker का नेटिव इमेज विश्लेषण टूल है जो आपकी कंटेनर इमेज को कमजोरियों के लिए स्कैन करता है और Software Bill of Materials (SBOMs) बनाता है।

यह आपकी इमेज के अंदर हर चीज़ का विश्लेषण करता है—बेस OS पैकेज, भाषा-विशिष्ट डिपेंडेंसीज़ से लेकर एप्लिकेशन लाइब्रेरी तक। फिर इन्हें ज्ञात कमजोरियों के डेटाबेस से मिलान करता है। आपको एक रिपोर्ट मिलती है जिसमें बताया जाता है कि किन पैकेजों में सुरक्षा समस्याएँ हैं, उनकी गंभीरता क्या है, और कौन-से संस्करण उन्हें ठीक करते हैं।

इस तरह, तीसरे पक्ष के स्कैनर इस्तेमाल करने या डिप्लॉयमेंट के बाद सुरक्षा टीम के अलर्ट का इंतज़ार करने के बजाय, आप इमेज को वहीं स्कैन कर सकते हैं जहाँ आप उन्हें बनाते हैं। Scout, Docker Desktop, CLI और Docker Hub—सबमें काम करता है।

यह Docker इकोसिस्टम में ऐसे फिट बैठता है: Docker आपके कंटेनर बनाता और चलाता है, Docker Hub उन्हें स्टोर करता है, और Docker Scout बताता है कि उनके अंदर क्या है। याद रखें, यह अब प्लेटफ़ॉर्म का हिस्सा है, कोई अलग ऐड-ऑन नहीं।

Docker Scout पुराने docker scan कमांड की जगह लेता है, जो Snyk के स्कैनिंग इंजन पर निर्भर था। Scout Docker के अपने भेद्यता डेटाबेस का उपयोग करता है और आपको स्कैनिंग पर अधिक नियंत्रण देता है। यदि आप अभी भी docker scan इस्तेमाल कर रहे हैं, तो वह अब अप्रचलित है—Scout ही आधिकारिक विकल्प है और नए Docker Desktop संस्करणों में पहले से उपलब्ध है।

Docker Scout को इंस्टॉल और सक्षम करना

Docker Scout, Docker Desktop 4.17 और उससे नए संस्करणों में बिल्ट-इन आता है, इसलिए यदि आप हाल का संस्करण चला रहे हैं, तो यह पहले से मौजूद है।

यह Docker CLI के ज़रिये काम करता है और Docker Desktop के GUI में भी दिखता है। यदि आप Docker Desktop का उपयोग कर रहे हैं, तो Scout डिफ़ॉल्ट रूप से सक्षम रहता है—आप तुरंत इमेज स्कैन करना शुरू कर सकते हैं।

यह जाँचने के लिए कि आपके सिस्टम पर Scout उपलब्ध है या नहीं, यह कमांड चलाएँ:

docker scout version

आउटपुट में Scout CLI संस्करण और प्लगइन की स्थिति दिखाई देगी।

Docker scout version

यदि कमांड चल जाती है, तो आप इमेज स्कैन करने के लिए तैयार हैं।

यदि आपको "command not found" त्रुटि मिलती है, तो आपका Docker संस्करण बहुत पुराना है। Docker Scout का उपयोग करने के लिए Docker Desktop अपडेट करें।

Docker Scout से इमेज स्कैन करना

स्कैन चलाना एक ही कमांड में हो जाता है—यही आसान हिस्सा है। कभी-कभी चुनौती यह समझना होती है कि Scout ने क्या पाया।

किसी इमेज का विश्लेषण

आप यह कमांड चलाकर किसी लोकल इमेज को उसके नाम या ID से Docker Scout को दे कर स्कैन कर सकते हैं:

docker scout cves python:3.14

Scout इमेज लेयरों का विश्लेषण करता है, पैकेज जानकारी निकालता है, और ज्ञात कमजोरियों की जाँच करता है। अधिकतर इमेज के लिए स्कैन 30 सेकंड के भीतर पूरा हो जाता है।

Scan results for Python 3.14 image

आप उन इमेज को भी स्कैन कर सकते हैं जो अभी आपकी मशीन पर नहीं हैं:

docker scout cves postgres:18.1

Scout, रजिस्ट्री से पूरा इमेज डाउनलोड किए बिना केवल मेटाडेटा खींच लेता है। इससे आप लोकल में पुल करने से पहले ही इमेज जाँच सकते हैं।

Scan results for Postgres 18.1 image

विश्लेषण के दौरान, Scout हर लेयर को अनपैक करता है, इंस्टॉल किए गए पैकेजों और डिपेंडेंसीज़ की पहचान करता है, और फिर सब कुछ अपने भेद्यता डेटाबेस से मिलाता है। यह बेस OS (जैसे Ubuntu-आधारित इमेज में apt पैकेज) और भाषा-विशिष्ट डिपेंडेंसीज़ (जैसे Python पैकेज या Node मॉड्यूल)—दोनों को ट्रैक करता है।

आउटपुट को समझना

Scout कमजोरियों को उनकी गंभीरता के आधार पर समूहित करता है: Critical, High, Medium, और Low।

Critical और High कमजोरियों पर पहले ध्यान देना चाहिए। ये वे सक्रिय रूप से शोषित होने वाली समस्याएँ या गंभीर बग होते हैं जो आपके सिस्टम को खतरे में डाल सकते हैं। Medium स्तर की समस्याएँ महत्वपूर्ण होती हैं, पर अक्सर तुरंत सुधार जरूरी नहीं होता। Low स्तर की कमजोरियों पर नज़र रखना ठीक है, पर वे आमतौर पर डिप्लॉयमेंट को नहीं रोकतीं।

हर भेद्यता यह भी दिखाती है कि समस्या किस पैकेज में है। रिपोर्ट स्क्रॉल करने पर आपको कुछ ऐसा आउटपुट दिखेगा:

Vulnerability report

यह आपको बिल्कुल बताता है कि क्या कमजोर है (openssl), आप कौन-सा संस्करण चला रहे हैं, और कौन-सा संस्करण इसे ठीक करता है। Scout CVE विवरण के लिए लिंक भी देता है, ताकि आप खुद भी भेद्यता के बारे में पढ़ सकें।

पैकेज एट्रीब्यूशन बताता है कि कमजोरियाँ कहाँ से आई हैं—बेस इमेज पैकेज, एप्लिकेशन डिपेंडेंसीज़, या सिस्टम लाइब्रेरी। इससे आप तय कर सकते हैं कि बेस इमेज अपडेट करनी है, अपने कोड में किसी डिपेंडेंसी को अपग्रेड करना है, या अपस्ट्रीम फिक्स का इंतज़ार करना है।

SBOM बनाने और देखने के लिए Docker Scout का उपयोग

Software Bill of Materials (SBOM) आपकी कंटेनर इमेज के अंदर मौजूद हर घटक—हर पैकेज, लाइब्रेरी, और डिपेंडेंसी—की पूरी सूची है।

यह ठीक-ठीक बताता है कि आपकी इमेज में क्या-क्या गया, यहाँ तक कि विशिष्ट संस्करण संख्या तक। सुरक्षा टीमें प्रोडक्शन में क्या चल रहा है, यह ट्रैक करने के लिए SBOM का उपयोग करती हैं, और कई कंप्लायंस फ़्रेमवर्क इसकी माँग करते हैं।

Docker Scout, पिछली अनुभाग में दिखाए गए कमांड से इमेज स्कैन करने पर अपने आप SBOM तैयार करता है। दोहराने के लिए:

docker scout sbom postgres:18.1

यह आपके टर्मिनल पर पूरी पैकेज सूची आउटपुट करता है। Scout इमेज लेयरों का विश्लेषण करके पैकेज मेटाडेटा निकालता है, फिर उसे ऐसे SBOM के रूप में फ़ॉर्मैट करता है जिसे आप सेव या साझा कर सकते हैं।

आप SBOM को स्क्रीन पर प्रिंट करने के बजाय फ़ाइल में एक्सपोर्ट भी कर सकते हैं:

docker scout sbom postgres:18.1 --format spdx > postgres-sbom.json

SBOM SPDX report

Scout दो मानक SBOM फ़ॉर्मैट सपोर्ट करता है: SPDX (Software Package Data Exchange) और CycloneDX। दोनों व्यापक रूप से उपयोग किए जाते हैं। SPDX कंप्लायंस और लीगल रिव्यू के लिए उपयुक्त है, जबकि CycloneDX सुरक्षा उपयोग मामलों और भेद्यता ट्रैकिंग पर केंद्रित है।

आप --format फ़्लैग के साथ फ़ॉर्मैट बदल सकते हैं:

docker scout sbom postgres:18.1 --format cyclonedx > postgres-sbom.json

SBOX CycloneDX report

SBOM फ़ाइल मिल जाने पर आप उसे सुरक्षा टीमों से साझा कर सकते हैं, अन्य स्कैनिंग टूल्स में फ़ीड कर सकते हैं, या कंप्लायंस ऑडिट के लिए आर्काइव कर सकते हैं।

Docker Scout के साथ CVEs ढूँढ़ना और समझना

Docker Scout आपकी इमेज में मौजूद पैकेजों का ज्ञात सुरक्षा समस्याओं के डेटाबेस से मिलान करके कमजोरियाँ ढूँढ़ता है।

जब आप docker scout cves चलाते हैं, तो Scout आपकी इमेज से हर पैकेज—OS पैकेज, भाषा लाइब्रेरी, एप्लिकेशन डिपेंडेंसी—निकालकर Common Vulnerabilities and Exposures (CVE) रिकॉर्ड से जाँचता है। CVE एक सार्वजनिक रूप से प्रकटीकृत सुरक्षा खामी होती है, जिसका एक यूनीक ID होता है, जैसे CVE-2024-1234।

Scout कई स्रोतों से CVE डेटा खींचता है:

• The National Vulnerability Database (NVD)
• Linux डिस्ट्रीब्यूशनों की सुरक्षा एडवाइजरी
• Python, Node.js, Go, और अन्य इकोसिस्टम के भाषा-विशिष्ट सुरक्षा डेटाबेस

यानि Scout आपके बेस इमेज के OS पैकेजों और आपके एप्लिकेशन की डिपेंडेंसी—दोनों में कमजोरियाँ पकड़ सकता है।

ध्यान रहे, विश्लेषण इस पर निर्भर करता है कि आपकी इमेज कहाँ मौजूद है—तरीका थोड़ा बदलता है।

• लोकल इमेज (जो आपने अपनी मशीन पर बिल्ड या पुल की हैं) के लिए, Scout सीधे आपके Docker डेमॉन से इमेज लेयर पढ़ता है। यह हर लेयर को अनपैक करके पैकेज पहचानता है और लोकल में ही भेद्यता जाँच चलाता है। यह तेज़ है और इमेज पर नेटवर्क एक्सेस की ज़रूरत नहीं पड़ती।
• रिमोट इमेज (Docker Hub या अन्य रजिस्ट्री में) के लिए, Scout पूरा इमेज डाउनलोड किए बिना इमेज मैनिफेस्ट और लेयर मेटाडेटा फ़ेच करता है। इससे आप पुल करने से पहले ही इमेज स्कैन कर सकते हैं। भेद्यता डेटा Scout के डेटाबेस से ही आता है, पर इमेज विश्लेषण रजिस्ट्री मेटाडेटा पर होता है।

दोनों तरीकों से आपको समान भेद्यता जानकारी मिलती है—अंतर केवल यह है कि Scout इमेज डेटा कहाँ से पढ़ता है।

रीमेडिएशन गाइडेंस और बेस इमेज सिफारिशें

जब Scout किसी ऐसी कमजोरी का पता लगाता है जिसका पैच उपलब्ध है, तो यह ठीक करने वाला सटीक संस्करण दिखाता है। हर CVE के पास आपको "Fixed in: 1.2.3" जैसा आउटपुट दिखेगा। इससे आपको पता चलता है कि पैकेज अपडेट करना है, नए बेस के साथ इमेज को फिर से बनाना है, या अपस्ट्रीम फिक्स का इंतज़ार करना है।

Scout, बेस इमेज अपग्रेड की भी सिफारिश करता है—जब नए बेस पर स्विच करने से कमजोरियाँ समाप्त हो जाएँ। यदि आप python:3.13 इस्तेमाल कर रहे हैं और Scout बेस OS पैकेजों में समस्याएँ पाता है, तो वह python:3.14 या और विशिष्ट पैच संस्करण पर जाने का सुझाव दे सकता है।

ये सिफारिशें तब दिखती हैं जब Scout पाता है कि कोई अलग बेस इमेज टैग, आपके वर्तमान टैग की तुलना में कम कमजोरियाँ रखता है। सुझाव क्रियात्मक होते हैं—आप नया टैग अपने Dockerfile में कॉपी करके रीबिल्ड कर सकते हैं।

तो, यह क्यों महत्वपूर्ण है?

आपकी बेस इमेज में OS पैकेज, सिस्टम लाइब्रेरी और भाषा रनटाइम होते हैं जिन पर बाकी सब निर्भर करता है। यदि बेस इमेज में कमजोरियाँ हैं, तो उससे बनी हर कंटेनर इमेज वही कमजोरियाँ विरासत में लेती है। जब आप न्यूनतम और सक्रिय रूप से मेंटेन की गई बेस इमेज चुनते हैं, तो हमले की गुंजाइश कम हो जाती है।

Docker Hub की आधिकारिक इमेज को नियमित सुरक्षा अपडेट मिलते हैं, लेकिन उन फिक्स को पाने के लिए आपको अपनी इमेज दोबारा बनानी पड़ती है। उदाहरण के लिए, आज python:3.13 पुल करने पर आपको छह महीने पहले की तुलना में अलग पैकेज मिलेंगे।

CI/CD में Docker Scout का उपयोग

टीमें Docker Scout को CI पाइपलाइनों में जोड़ती हैं ताकि इमेज प्रोडक्शन तक पहुँचने से पहले कमजोरियाँ पकड़ ली जाएँ।

विचार सरल है: बिल्ड प्रक्रिया के हिस्से के रूप में हर इमेज स्कैन करें, और यदि Critical या High कमजोरियाँ दिखें तो बिल्ड फेल कर दें। इस तरह समस्याएँ डिप्लॉयमेंट के बाद नहीं, बल्कि डेवलपमेंट के दौरान ही पकड़ में आती हैं। अधिकांश टीमें किसी नए Dockerfile पुश या बेस इमेज अपडेट पर Scout को स्वतः चलाती हैं।

पाइपलाइन प्रायः दो चीज़ें जाँचती हैं:

• Vulnerability regressions - ये आपकी नई इमेज की तुलना पिछले संस्करण से करती हैं। यदि नए बिल्ड में Critical या High कमजोरियाँ पहले से ज़्यादा हैं, तो पाइपलाइन फेल हो जाती है। इससे आप अनजाने में मौजूदा से बदतर सुरक्षा के साथ शिपिंग करने से बचते हैं।
• Policy drift - ये जाँचती हैं कि आपकी इमेज सुरक्षा मानकों पर खरी उतरती है या नहीं। आपके पास ऐसी नीति हो सकती है: "Critical CVE स्वीकार्य नहीं" या "बेस इमेज 30 दिनों से पुरानी नहीं होनी चाहिए।" Scout इन नियमों को आपके CI वर्कफ़्लो में स्वचालित रूप से लागू कर सकता है।

GitHub Actions, GitLab CI, या Jenkins के साथ इंटीग्रेशन अवधारणात्मक रूप से इसी तरह काम करता है। आप इमेज बिल्ड करते हैं, उस पर docker scout cves चलाते हैं, परिणाम पार्स करते हैं, और अपने मानदंडों के आधार पर पाइपलाइन पास या फेल करने का निर्णय लेते हैं। कुछ टीमें कंटेनर रजिस्ट्री वर्कफ़्लोज़ में Scout जोड़ती हैं ताकि इमेज पुश होते ही स्कैन हो जाएँ।

Docker Scout बनाम अन्य इमेज स्कैनर

Docker Scout अकेला टूल नहीं है। यह Trivy और Snyk जैसे टूल्स से मुकाबला करता है, लेकिन हर एक की अपनी लक्षित कार्यप्रणाली है।

• Trivy एक ओपन-सोर्स स्कैनर है जो कहीं भी चल सकता है—लोकल मशीनों, CI पाइपलाइनों से लेकर Kubernetes क्लस्टरों तक। यह कंटेनर इमेज, फ़ाइल सिस्टम, और Git रिपॉज़िटरी स्कैन करता है। Trivy आपको स्कैन करने के स्थान और तरीके में अधिक लचीलापन देता है, और इसे इस्तेमाल करने के लिए Docker अकाउंट की ज़रूरत नहीं। इसे Docker इकोसिस्टम से स्वतंत्र, स्टैंडअलोन स्कैनर समझें।
• Snyk डेवलपर वर्कफ़्लो पर केंद्रित है और IDEs, GitHub, तथा अन्य डेवलपमेंट टूल्स के साथ गहरा इंटीग्रेशन देता है। कंटेनरों के अलावा, यह एप्लिकेशन डिपेंडेंसी, इंफ्रास्ट्रक्चर ऐज़ कोड, और सोर्स कोड को भी स्कैन करता है। Snyk विस्तृत रीमेडिएशन गाइडेंस देता है और कमजोरियाँ ठीक करने के लिए पुल रिक्वेस्ट भी खोल सकता है। यदि आपको सिर्फ कंटेनरों से परे—पूरे स्टैक—की सुरक्षा चाहिए, तो Snyk उचित विकल्प है।
• Docker Scout तब सबसे अच्छा काम करता है जब आप पहले से Docker Desktop और Docker Hub का उपयोग कर रहे हों। इंटीग्रेशन नेटिव है—कोई अतिरिक्त सेटअप नहीं, न API कुंजियाँ प्रबंधित करनी हैं, न अलग टूल सीखने हैं। Scout, Docker Hub पर पुश की गई इमेज को स्कैन करता है, और CLI आपके Docker इंस्टॉलेशन का हिस्सा है।

यदि आपकी टीम Docker टूल्स से कंटेनर बनाती और चलाती है और आप बिना जटिलता बढ़ाए सुरक्षा दृश्यता चाहते हैं, तो Docker Scout चुनें। यदि आपको कहीं भी चलने वाला लचीला, ओपन-सोर्स विकल्प चाहिए, तो Trivy लें। यदि आपको कंटेनर, कोड, और इंफ्रास्ट्रक्चर—पूरे स्टैक—की व्यापक सुरक्षा और स्वचालित फिक्स चाहिए, तो Snyk लें।

सामान्य सीमाएँ और ध्यान रखने योग्य बातें

Docker Scout कंटेनर इमेज स्कैन करता है, लेकिन डिप्लॉयमेंट के बाद क्या होता है, उस पर नज़र नहीं रखता।

यह स्थिर इमेज—यानी, आपके कंटेनर में बिल्ट पैकेज और फ़ाइलें—का विश्लेषण करता है। यह रनटाइम समस्याएँ, जैसे प्रिविलेज एस्केलेशन हमले, नेटवर्क घुसपैठ, या डिप्लॉयमेंट के बाद शुरू होने वाली दुर्भावनापूर्ण प्रक्रियाएँ नहीं पकड़ सकता। यदि आपको रनटाइम सुरक्षा मॉनिटरिंग चाहिए, तो Falco या Sysdig जैसे टूल्स का उपयोग करें जो प्रोडक्शन में कंटेनर व्यवहार पर नज़र रखते हैं।

Scout, पूर्ण SAST (Static Application Security Testing) या DAST (Dynamic Application Security Testing) का विकल्प भी नहीं है। SAST टूल्स किसी भी चीज़ को बिल्ड करने से पहले आपके सोर्स कोड की सुरक्षा खामियों के लिए जाँच करते हैं। DAST टूल्स चल रही एप्लिकेशन पर हमलों का अनुकरण करके परीक्षण करते हैं। Scout केवल आपकी बनी हुई इमेज के अंदर मौजूद पैकेजों को देखता है—यह आपके एप्लिकेशन लॉजिक की कमजोरियाँ या कोड में कॉन्फ़िगरेशन भूलें नहीं पकड़ेगा।

Scout की खासियत यह है कि यह आपकी इमेज के अंदर क्या है, इसकी दृश्यता देता है और समाधान की दिशा दिखाता है। यह बताता है कि कौन-से पैकेज कमजोर हैं, कौन-से संस्करण उन्हें ठीक करते हैं, और कौन-सी बेस इमेज हमले की संभावनाएँ घटाती हैं। इससे Scout, बिल्ड-टाइम सुरक्षा जाँच और कंप्लायंस ट्रैकिंग के लिए उपयोगी बनता है, लेकिन संपूर्ण सुरक्षा कवरेज के लिए आपको अन्य टूल्स की भी ज़रूरत होगी।

Docker Scout उपयोग के लिए श्रेष्ठ अभ्यास

यहाँ एक चेकलिस्ट है जिससे आप Docker Scout का अधिकतम लाभ उठा सकते हैं।

• डेवलपमेंट चक्र के शुरुआती चरण में स्कैन करें। केवल CI या डिप्लॉयमेंट से पहले ही नहीं, लोकल डेवलपमेंट के दौरान भी इमेज पर Scout चलाएँ। कमजोरियाँ जल्दी मिलेंगी तो संदर्भ ताज़ा रहेगा और बदलाव सस्ते पड़ेंगे। प्रोडक्शन तक इंतज़ार करने का मतलब है दबाव में पैचिंग करना।

• समय के साथ इमेज की तुलना करके सुरक्षा प्रवृत्तियाँ ट्रैक करें। Scout दिखा सकता है कि आपकी सुरक्षा सुधर रही है या बिगड़ रही है। हर बिल्ड पर स्कैन चलाएँ और परिणामों की तुलना करें। यदि नए बिल्ड में पिछली बार की तुलना में अधिक Critical कमजोरियाँ हैं, तो कुछ बदला है—शायद कोई डिपेंडेंसी अपडेट या बेस इमेज शिफ्ट। इसकी जाँच करें।

• Scout की फ़ाइंडिंग्स को प्राथमिकता संकेत समझें, पूर्ण अवरोध नहीं। हर कमजोरी पर तुरंत कार्रवाई जरूरी नहीं। कोई लो-सीवेरिटी CVE जो केवल डेवलपमेंट डिपेंडेंसी में है और प्रोडक्शन में उपयोग नहीं होती, इंतज़ार कर सकती है। जबकि किसी पब्लिक-फेसिंग सर्विस में क्रिटिकल CVE पर तुरंत ध्यान चाहिए। अपनी डिप्लॉयमेंट के संदर्भ में Scout की गंभीरता रेटिंग और पैकेज संदर्भ का उपयोग करें।

• Scout को बेस इमेज हाईजीन के साथ जोड़ें। न्यूनतम, सक्रिय रूप से मेंटेन की गई बेस इमेज चुनें और उन्हें नियमित रूप से अपडेट करें। python:3.14-slim की जगह python:3.14 इस्तेमाल करने से अनावश्यक पैकेज हट जाते हैं। अपनी इमेज को मासिक रीबिल्ड करने से बेस लेयर के सुरक्षा पैच मिलते रहते हैं। Scout आपको बताता है कि क्या कमजोर है, पर अच्छी बेस चुनने से कई कमजोरियाँ पहले ही नहीं आतीं।

निष्कर्ष

Docker Scout आपको अपनी कंटेनर इमेज के अंदर क्या है, इसे व्यावहारिक ढंग से समझने का तरीका देता है।

यह Docker-आधारित डेवलपमेंट में सहजता से फिट बैठता है—अलग टूल इंस्टॉल नहीं करने, न ही अतिरिक्त अकाउंट सेट करने की ज़रूरत। आप एक कमांड चलाते हैं, भेद्यता रिपोर्ट पाते हैं, और देखते हैं किन पैकेजों को अपडेट चाहिए।

Scout, व्यापक सुरक्षा दृष्टिकोण का हिस्सा बनकर सबसे अच्छा काम करता है, अकेला समाधान नहीं। इसे रनटाइम मॉनिटरिंग, सोर्स कोड विश्लेषण, और नियमित बेस इमेज अपडेट के साथ जोड़ें। इसे बिल्ड के दौरान कमजोरियाँ पकड़ने के लिए उपयोग करें, फिर डिप्लॉयमेंट के बाद होने वाली गतिविधियों को कवर करने के लिए अन्य टूल्स जोड़ें।

यदि आप जानना चाहते हैं कि मशीन लर्निंग के लिए CI/CD पाइपलाइनों में Docker कैसे फिट बैठता है, तो हमारा CI/CD for Machine Learning कोर्स जॉइन करें। एक दोपहर में आपके सारे प्रश्नों के उत्तर मिल जाएँगे।