जाँचें कि release में क्या जाता है

पूछें कि dependency जरूरी है या नहीं

Agent ऐसा package सुझा सकता है जो समस्या हल करता लगे। यह सुझाव प्रस्ताव है, package के मौजूद या उपयुक्त होने का प्रमाण नहीं। Installation से पहले सटीक registry, publisher, package name और version जाँचें।

काल्पनिक CSV export के लिए runtime में जरूरी व्यवहार पहले से हो सकता है। नया package फिर भी उपयुक्त हो सकता है, लेकिन उससे रखरखाव और execution के रास्ते बढ़ते हैं। Implementation के प्रयास की तुलना dependency की लगातार बनी रहने वाली जिम्मेदारियों से करें।

License और समर्थित runtime का review करें। Maintenance activity और संबंधित advisories जाँचें। परिचित नाम दूसरी registry में अलग package का हो सकता है। सफल install केवल installation पूरा होना दिखाता है।

Installation और build का व्यवहार जाँचें

Dependencies installation या build के दौरान code execute कर सकती हैं। इन environments में credentials और network access सीमित करें। Untrusted pull request process करने वाली job को production secrets न दें।

Ecosystem support करे तो committed lockfile इस्तेमाल करें। Build को उस file का पालन करना जरूरी बनाएँ। Source change के साथ lockfile changes का review करें, जिनमें अप्रत्याशित transitive packages भी शामिल हों। Version pin करने से reproducibility बेहतर होती है, लेकिन vulnerable version सुरक्षित नहीं होता।

NIST का SSDF पूरे lifecycle में software की सुरक्षा और development practices cover करता है। Build environment design करते समय यह व्यापक दृष्टि अपनाएँ। Framework पढ़ें।

Inventory और provenance का अंतर समझें

Software bill of materials, या SBOM, software के components दर्ज करता है। किसी component पर चिंता होने पर इससे प्रभावित releases पहचानने में मदद मिलती है। यह अपने आप components के सुरक्षित होने का प्रमाण नहीं है।

Provenance बताता है कि artifact कैसे बना। SLSA build और उसके inputs की जानकारी के लिए provenance format तय करता है। Verification को इस जानकारी का संबंध trusted producer और आपके इस्तेमाल किए जाने वाले artifact से जोड़ना चाहिए। “Provenance” नाम की file पर्याप्त नहीं है। SLSA provenance।

Export service के लिए ऐसी शृंखला दर्ज करें जिसे आप जाँच सकें:

1. Reviewed commit स्वीकार किए गए source की पहचान करता है।
2. Build अपने inputs और execution environment की पहचान करता है।
3. Artifact का स्थिर digest होता है।
4. Checks बताती हैं कि उन्होंने कौन-सा artifact या source जाँचा।
5. Deployment record बताता है कि target environment में कौन-सा artifact रखा गया।

तय verification प्रक्रिया के बिना approval के बाद अलग तरीके से rebuild न करें। latest जैसा बदलने वाला tag बाद में दूसरी image को दिखा सकता है।

तय करें कि finding का क्या अर्थ है

Vulnerability finding को context चाहिए: प्रभावित version, execution के दौरान पहुँचा जा सकने वाला व्यवहार, exposure, उपलब्ध fix और परिणाम। हर अस्थायी exception के पीछे का प्रमाण दर्ज करें। जिम्मेदार व्यक्ति, समाप्ति और review की शर्त तय करें।

एक finding लागू न होने पर पूरा scanner suppress न करें। Scan पूरा न हुआ हो तो clean result का दावा न करें। Timeout, unsupported package या अनुपलब्ध advisory feed का अर्थ है प्रमाण अधूरा है।

Release के बाद updates की योजना भी बनाएँ। नई advisories कल स्वीकार किए artifact को प्रभावित कर सकती हैं। Service के जिम्मेदार व्यक्ति को inventory, प्रतिक्रिया की प्रक्रिया और सुधरा release बनाने की क्षमता चाहिए।

बार-बार होने वाले scans को सत्यापित production fixes से जोड़ने के लिए लगातार vulnerability management पढ़ें।