Software के उपयोगी जीवन भर रखरखाव करें

रखरखाव के लिए service का जिम्मेदार व्यक्ति तय करें

उपयोगी software पहले release के बाद भी बदलता रहता है। Dependencies को fixes मिलते हैं। Runtimes का support खत्म होता है। Certificates expire होते हैं। Business rules बदलते हैं। Setup के समय दिया access इच्छित समय से अधिक बना रह सकता है।

Services, जिम्मेदार लोग, deployed versions, dependencies और support की अवधि व तारीखों की inventory रखें। Scheduled work और नई finding से शुरू हुआ काम शामिल करें। दोनों के लिए capacity रखें। बिना जिम्मेदार व्यक्ति का maintenance backlog service की रक्षा नहीं करता।

रखरखाव को तत्काल incident response से अलग रखें। Exposed credential या चल रहे compromise के प्रमाण पर सामान्य development cycle खत्म होने से पहले containment जरूरी हो सकता है। ऐसे cases को security response प्रक्रिया में भेजें।

वास्तविक exposure की प्राथमिकता तय करें

Severity संभावित परिणाम बताती है। प्राथमिकता exploitation, reachability, डेटा, मौजूदा controls और देरी की लागत पर भी निर्भर है। कम traffic वाली internal service में भी महत्वपूर्ण credentials हो सकते हैं।

CISA का Known Exploited Vulnerabilities catalog उन vulnerabilities को दर्ज करता है जिनके exploitation के प्रमाण हैं। इसे प्राथमिकता तय करने का एक input मानें। Catalog में न होने से vulnerability सुरक्षित सिद्ध नहीं होती। CISA catalog।

इन काल्पनिक findings को देखें। समय-सीमाएँ उदाहरण वाले संगठन की हैं; ये हर स्थिति की deadlines नहीं हैं।

हर finding को अपने आप major upgrade न बनाएँ। समर्थित सुधार चुनें, compatibility देखें और जरूरी व्यवहार जाँचें। Temporary mitigations के साथ जिम्मेदार व्यक्ति और समाप्ति की शर्त दर्ज करें।

सुधार को production तक trace करें

Trace की जा सकने वाली प्रक्रिया रखें: finding, decision, change, review, deployment और verification। Production के वास्तविक artifact का identifier दर्ज करें। बदलाव के बाद संबंधित artifact या environment फिर scan करें।

काल्पनिक vulnerable PDF package के लिए team 10:00 पर upgrade merge करती है। 11:00 पर production अभी कल की image चला रहा है। Repository का सुधार पूरा है। Production remediation अधूरा है।

Deployment के बाद package version और PDF generation दोनों जाँचें। Vulnerability scan यह सिद्ध नहीं कर सकता कि export अब भी काम करता है। Functional test यह सिद्ध नहीं कर सकता कि vulnerable component हट गया है।

NIST के SSDF में vulnerabilities की लगातार पहचान और प्रतिक्रिया शामिल हैं। पूरे lifecycle में ये practices लागू करें, उस software पर भी जिसमें कम नए features माँगे जाते हैं। NIST SSDF।

स्पष्ट सीमाओं के साथ automation इस्तेमाल करें

Taiga Maintaining जुड़ी repositories scan करता है और findings को remediation initiatives में बदल सकता है। नवीनतम सफल sweep, प्रभावित version और बना बदलाव जाँचें। Repository scan से production में vulnerable code तक पहुँच का प्रमाण नहीं मिलता। Maintaining।

Automation दोहराया काम घटा सकता है, लेकिन service को deployment की जिम्मेदारी और verification फिर भी चाहिए। Release decisions, emergency access और exception expiry स्पष्ट रखें।

रखरखाव में service retirement भी शामिल है। नियंत्रित प्रक्रिया से अनुपयोगी routes, credentials, integrations और infrastructure हटाएँ। Deletion से पहले retention requirements और dependent services जाँचें। चलती service बंद करें और बचे retention या audit दायित्व सौंपें।

अगला पाठ लगातार vulnerability scanning और remediation को विस्तार से समझाता है।