कोई सिक्योरिटी रिपोर्ट तभी काम की है जब वह merge हुए फ़िक्स में बदले। CodeAuditAgent की रिपोर्ट इसी सोच से बनी हैं: हर फ़ाइंडिंग इतनी विशिष्ट है कि उसे जल्दी जाँचा जा सके, और साथ में एक पैच आता है जिसे आप ढाल सकते हैं। यह गाइड रिपोर्ट के हर हिस्से को समझाती है, बताती है कि समर्पित सिक्योरिटी इंजीनियर न होने पर उसे कैसे triage करें, और अपने फ़िक्स की पुष्टि कैसे करें।
किसका ऑडिट होता है
ऑडिट या तो किसी पब्लिक GitHub रिपॉज़िटरी पर चलता है या आपके पेस्ट किए कोड स्निपेट पर। रिपॉज़िटरीज़ के लिए CodeAuditAgent डिफ़ॉल्ट branch पढ़ता है। प्राइवेट रिपॉज़िटरीज़ का URL से ऑडिट नहीं हो सकता, और अभी pull-request टिप्पणियाँ नहीं हैं; नतीजे डैशबोर्ड और एक्सपोर्ट में रहते हैं।
किसी रिपॉज़िटरी का कितना हिस्सा पढ़ा जाएगा यह आपके प्लान पर निर्भर है। फ़्री प्लान में 1 रिपॉज़िटरी, महीने में 3 ऑडिट और हर ऑडिट में 20 फ़ाइलें तक शामिल हैं। Starter, $49 प्रति माह पर, 5 रिपॉज़िटरीज़, 50 ऑडिट और हर ऑडिट में 40 फ़ाइलें देता है। Pro, $199 प्रति माह पर, असीमित रिपॉज़िटरीज़, 500 ऑडिट और हर ऑडिट में 80 फ़ाइलें देता है। 60 KB से बड़ी अलग-अलग फ़ाइलें छोड़ दी जाती हैं। मासिक ऑडिट गिनती हर कैलेंडर महीने की शुरुआत (UTC) पर रीसेट होती है। पूरी रिपॉज़िटरी का ऑडिट करने से पहले जिस एक फ़ाइल की चिंता हो उसे पेस्ट किए स्निपेट के रूप में जाँचना भी एक तेज़ तरीक़ा है।
जब इन सीमाओं की वजह से फ़ाइलें छूट जाती हैं, तो रिपॉर्ट को partial snapshot के रूप में चिह्नित किया जाता है। उस लेबल को गंभीरता से लें। साफ़-सुथरी partial रिपोर्ट का मतलब है कि जो फ़ाइलें पढ़ी गईं वे साफ़ दिखती हैं, यह नहीं कि रिपॉज़िटरी साफ़ है। अगर जिस कोड की आपको सबसे ज़्यादा परवाह है वही छूट गया, तो उसका ऑडिट पेस्ट किए स्निपेट के रूप में करें या ऐसे प्लान पर करें जो ज़्यादा फ़ाइलें कवर करता हो।
Risk score
हर रिपोर्ट के सबसे ऊपर 0 से 100 तक का एक risk score होता है; Markdown एक्सपोर्ट उसके बगल में कुल severity भी बताता है। ज़्यादा का मतलब ज़्यादा जोखिम। यह उस ऑडिट की फ़ाइंडिंग्स का सारांश है, जो दो चीज़ों के लिए उपयोगी है: यह तय करना कि किसी रिपॉज़िटरी को कितनी जल्दी देखना है, और यह ट्रैक करना कि वह समय के साथ बेहतर हो रही है या नहीं।
असंबंधित रिपॉज़िटरीज़ के बीच छोटे अंतरों का बहुत मतलब न निकालें। Score हमेशा इस पर निर्भर है कि किसका ऑडिट हुआ, और partial snapshot कम कोड देखता है। एक ही रिपॉज़िटरी की फ़िक्स से पहले और बाद की तुलना करना ही वह जगह है जहाँ यह संख्या सबसे सार्थक है।
Severity और confidence
हर फ़ाइंडिंग की एक severity और एक confidence होती है। ये अलग सवालों के जवाब देती हैं: severity यह कि अगर फ़ाइंडिंग सच है तो कितनी बुरी होगी, और confidence यह कि रिव्यूअर कितना निश्चित है कि वह सच है।
- Critical: सीधे exploit करने योग्य और गंभीर असर वाला, जैसे किसी पब्लिक endpoint पर injection, authentication bypass या उजागर प्रोडक्शन credentials।
- High: असली vulnerability जिसे कोई पूर्वशर्त चाहिए, या जिसका असर बड़ा पर सीमित है।
- Medium: ऐसी कमज़ोरी जो दूसरे बग्स के साथ मिलकर मायने रखती है, या जिसका असर मध्यम है।
- Low: hardening की बातें और defense-in-depth की कमियाँ।
- Info: जानने लायक़ अवलोकन जो अपने आप में vulnerabilities नहीं हैं।
Confidence high, medium या low होती है। High-confidence फ़ाइंडिंग के पास पढ़े गए कोड में साफ़ सबूत होता है। Low-confidence फ़ाइंडिंग आमतौर पर किसी ऐसी चीज़ पर निर्भर होती है जो ऑडिट को दिखी नहीं, जैसे किसी दूसरी फ़ाइल का middleware, कोई डेटाबेस policy, या डिप्लॉय के समय सेट होने वाली कोई कॉन्फ़िगरेशन value। Low confidence का मतलब उसे नज़रअंदाज़ करना नहीं; इसका मतलब है कि फ़िक्स से पहले किसी इंसान को छूटा हुआ संदर्भ जाँचना चाहिए।
एक फ़ाइंडिंग की बनावट
हर फ़ाइंडिंग एक ही ढाँचे पर चलती है, ताकि आप उसे एक ही क्रम में जाँच सकें।
- Title और CWE: कमज़ोरी की श्रेणी, जैसे यूज़र-नियंत्रित key से authorization bypass के लिए CWE-639। CWE बताता है कि किस तरह का फ़िक्स अपेक्षित है।
- Location: फ़ाइल और लाइन, ताकि आप कोड सीधे खोल सकें।
- Evidence: फ़ाइल से कोट किया गया संबंधित कोड। जाँचें कि कोट आपके मौजूदा कोड से मेल खाता है; अगर लाइन पहले ही बदल चुकी है, तो फ़ाइंडिंग पुरानी हो सकती है।
- Exploit परिदृश्य: हमलावर उस कमज़ोरी का असल में कैसे इस्तेमाल करेगा, क़दम-दर-क़दम। आपके संदर्भ में वह सच है या नहीं, यह परखने का सबसे तेज़ रास्ता यही है।
- Remediation पैच: आस-पास के कोड की शैली में एक सुझाया गया बदलाव।
पैच को एक मज़बूत शुरुआती बिंदु मानें, merge के लिए तैयार कमिट नहीं। वह उस कोड से लिखा गया है जो ऑडिट ने पढ़ा, इसलिए हो सकता है उसे आपके helper फ़ंक्शन, आपके ORM की परंपराओं या कोडबेस में कहीं और मौजूद किसी caller के बारे में पता न हो। एक सामान्य पैच छोटा और लक्षित होता है:
--- a/app/api/invoices/[id]/route.ts
+++ b/app/api/invoices/[id]/route.ts
@@
- const invoice = await db.invoice.findUnique({ where: { id } });
+ const invoice = await db.invoice.findFirst({
+ where: { id, userId: session.user.id },
+ });
if (!invoice) return Response.json({ error: 'not_found' }, { status: 404 });सकारात्मक अवलोकन और अगले क़दम
रिपोर्ट यह भी गिनाती हैं कि क्या अच्छा किया गया है: parameterized queries का लगातार इस्तेमाल, environment से लोड होते secrets, सख़्त cookie कॉन्फ़िगरेशन। इन्हें पढ़ना फ़ायदेमंद है। ये बताती हैं कि कौन-से पैटर्न बनाए रखने और नए कोड में उतारने हैं, और ये तब भी काम आती हैं जब आपको किसी और को कोडबेस की हालत समझानी हो।
सुझाए गए अगले क़दम वाला हिस्सा फ़ाइंडिंग्स को एक क्रमबद्ध योजना में बदल देता है। वह अक्सर संबंधित फ़ाइंडिंग्स को समूहबद्ध करता है, जैसे ownership चेक की कई कमियाँ जिन्हें पाँच अलग पैच के बजाय एक साझा helper से ठीक करना बेहतर है।
छोटी टीमों के लिए triage वर्कफ़्लो
सिक्योरिटी इंजीनियर के बिना जोखिम रिपोर्ट को नज़रअंदाज़ करना नहीं है; जोखिम यह है कि किसी critical फ़ाइंडिंग के इंतज़ार करते हुए आप low फ़ाइंडिंग्स पर एक दिन ख़र्च कर दें। एक सरल क्रम अच्छा काम करता है:
- पहले हर critical और high फ़ाइंडिंग पढ़ें। हर एक के लिए exploit परिदृश्य पढ़ें और तय करें: सच, सच नहीं, या संदर्भ चाहिए।
- असली critical फ़ाइंडिंग्स उसी दिन ठीक करें। अगर फ़िक्स में समय लगे, तो कोई अस्थायी उपाय जोड़ें, जैसे endpoint बंद करना या कोई चेक कसना।
- जिन फ़ाइंडिंग्स को संदर्भ चाहिए, उनका छूटा हुआ हिस्सा जाँचें: क्या कोई middleware, row-level policy या कॉन्फ़िग पहले से इसे रोकता है? जवाब लिखकर रखें।
- High फ़ाइंडिंग्स मौजूदा sprint में, medium बैकलॉग में डालें, और low तथा info आइटम एक hardening पास में इकट्ठे करें।
- जब कोई फ़ाइंडिंग सच न हो, तो कारण दर्ज करें। वह नोट अगले व्यक्ति को उसी जाँच से बचा लेता है।
हर फ़ाइंडिंग किसी एक मालिक को सौंपें। पूरी टीम के साझे फ़ाइंडिंग्स अक्सर किसी के नहीं होते।
Findings explorer और एक्सपोर्ट
जब आपके पास कई ऑडिट हो जाएँ, तो अलग-अलग रिपोर्ट की तुलना में findings explorer से काम करना आसान है। वह ऑडिट के आर-पार फ़ाइंडिंग्स सूचीबद्ध करता है और उन्हें severity, CWE और रिपॉज़िटरी से filter करता है। CWE से filter करना ख़ास तौर पर उपयोगी है: अगर वही कमज़ोरी तीन रिपॉज़िटरीज़ में दिखती है, तो यह आमतौर पर किसी साझा पैटर्न या छूटे हुए helper की ओर इशारा करता है, और पैटर्न ठीक करना हर उदाहरण ठीक करने से सस्ता है।
फ़ाइंडिंग्स को explorer से CSV के रूप में एक्सपोर्ट किया जा सकता है, जो किसी issue tracker या स्प्रेडशीट में लाने के लिए सुविधाजनक है। अलग-अलग रिपोर्ट Markdown के रूप में एक्सपोर्ट हो सकती हैं, जो किसी pull request के विवरण, किसी internal wiki या फ़िक्स कर रहे किसी contractor को भेजे संदेश में अच्छी पढ़ी जाती हैं।
फ़िक्स की पुष्टि के लिए फिर से ऑडिट करें
कोई फ़िक्स तब तक पूरा नहीं जब तक आपने उसे जाँच न लिया हो। Merge के बाद उसी रिपॉज़िटरी पर नया ऑडिट चलाएँ। हर रिपोर्ट की तुलना पिछले ऑडिट से की जा सकती है, ताकि आप देख सकें कि कौन-सी फ़ाइंडिंग्स गईं, कौन-सी बची हैं और क्या कुछ नया आया। असली समस्याएँ ठीक होने पर risk score गिरना चाहिए; अगर नहीं गिरता, तो तुलना देखकर वजह पता करें।
तुलना को निष्पक्ष रखें। अगर पहला ऑडिट partial snapshot था और दूसरे ने अलग फ़ाइलें पढ़ीं, तो अंतर फ़िक्स के साथ-साथ coverage को भी दिखाता है। ऑडिट आपके मासिक कोटे से कटते हैं, इसलिए हर कमिट के बाद दोबारा चलाने के बजाय आमतौर पर कई फ़िक्स इकट्ठे करके फिर ऑडिट करना बेहतर होता है।
रिपोर्ट क्या कवर नहीं करती
सीमाएँ जानने से कमियाँ भरने में मदद मिलती है। ऑडिट आपका सोर्स कोड पढ़ते हैं; वे dependencies को ज्ञात vulnerable वर्ज़न के लिए स्कैन नहीं करते, इसलिए अपने पैकेज मैनेजर या GitHub में मौजूद dependency scanner भी चलाते रहें। ऑडिट डिप्लॉय-समय की कॉन्फ़िगरेशन, रिपॉज़िटरी के बाहर की इंफ्रास्ट्रक्चर या छोड़ी गई फ़ाइलें नहीं देखते। और किसी भी रिव्यूअर की तरह, इंसान हो या AI, ऑडिट ग़लत भी हो सकता है: सबूत और confidence स्तर इसीलिए हैं कि आप उसे भरोसे पर लेने के बजाय जल्दी जाँच सकें।
इस तरह इस्तेमाल करने पर रिपोर्ट सबूत के साथ जुड़े बदलावों की एक छोटी, प्राथमिकता वाली सूची बन जाती है। Critical ठीक करें, अनिश्चित वाले जाँचें, फिर से ऑडिट करें, और score को हिलते हुए देखें।