SaaS vulnerability disclosure policy और security.txt guide
Researchers के लिए साफ SaaS vulnerability policy, safe reporting channel, triage workflow और RFC 9116 security.txt file बनाएँ।
इस मार्गदर्शिका में
Vulnerability disclosure policy क्या है और security.txt क्या करता है?
Vulnerability disclosure policy (VDP) security researcher को बताती है कि कौन-से systems scope में हैं, product vulnerability कहाँ report करनी है, कौन-सी testing allowed है और company fix को कैसे coordinate करेगी। यह documented intake और response process है; इसमें paid bug bounty होना जरूरी नहीं। RFC 9116 का machine-readable security.txt contact और policy details प्रकाशित करने का तरीका देता है। यह program का link है, उसका विकल्प नहीं और अपने-आप testing की अनुमति नहीं देता।
Product vulnerability report और incident-response request अलग रखें
Researcher product flaw report कर सकता है, जबकि customer को active compromise या account incident में तत्काल मदद चाहिए हो सकती है। दोनों के लिए अलग route दें और on-call staff को अंतर समझना सिखाएँ। RFC 9116 vulnerability response और incident response को संबंधित, लेकिन अलग प्रक्रियाएँ मानता है।
वे assets, methods और सीमाएँ बताएँ जिन्हें आपकी team संभाल सकती है
अपने product domains, applications, APIs या अन्य owned अथवा authorized assets सूचीबद्ध करें। Third-party services को scope से बाहर बताएँ, real users या availability को नुकसान पहुँचाने वाली actions मना करें और clarification माँगने का तरीका दें। Publication से पहले legal, engineering और operations के साथ scope review करें।
Good-faith policy को अपने jurisdiction के अनुसार review कराएँ
बताएँ कि policy की सीमा में किए गए research को company कैसे handle करेगी और ऐसी terms न दें जिन्हें staff निभा न सके। कानून या claims से पूरी immunity का वादा न करें; legal counsel के बिना किसी government template का safe-harbor statement copy न करें। CISA template federal agencies के लिए है; private SaaS company को अपनी systems और legal context के मुताबिक इसे बदलना चाहिए।
| Scope में asset | Allowed test और सीमा | Report channel और backup | Triage owner और coverage | Customer या public update trigger |
|---|---|---|---|---|
| Public product और API | ||||
| Mobile app या client software | ||||
| Third-party hosted service |
SaaS vulnerability disclosure policy में क्या शामिल करें?
काम का scope और reporting instructions प्रकाशित करें
Researcher से कौन-से asset identifier, security contact और finding दोबारा बनाने के लिए कौन-सी जानकारी चाहिए, यह बताएं। Customer data सुरक्षित रखने को कहें, minimal proof of concept स्वीकारें और destructive tests, social engineering, denial of service या किसी और का data देखने से मना करें।
Owner वाला intake और acknowledgement process बनाएँ
Submission को monitored queue में भेजें और staff की छुट्टी या बदलाव के लिए backup रखें। संभव हो तो receipt acknowledge करें, report मिलने का समय दर्ज करें, केवल जरूरी जानकारी माँगें और investigation से पहले तय severity score अनिवार्य न करें। Response target तभी प्रकाशित करें जब team उसे staff कर सके और measure करे।
Coordinated fix और researcher recognition समझाएँ
Impact और affected versions जाँचें, सुरक्षित ढंग से reproduce करें, fix owner तय करें और customer या public communication coordinate करें। Users के update करने से पहले ऐसे विवरण रोकें जो attack आसान कर सकते हैं। Researcher status या credit कैसे माँग सकता है, बताएं। VDP में bounty जरूरी नहीं; reward दें तो उसकी अलग शर्तें लिखें।
Security.txt को प्रकाशित और maintain कैसे करें?
File को RFC 9116 के well-known path पर serve करें
UTF-8 plain-text file को HTTPS पर `/.well-known/security.txt` में रखें और हर field एक line में लिखें। RFC 9116 में Contact और Expires जरूरी हैं; expiry current रखें ताकि researcher stale जानकारी पहचान सके। Deployment के बाद और हर production domain पर जाँचें जो scope में है।
Policy link और language तथा encryption fields सही दें
Policy field पूरे VDP तक link कर सकता है; Preferred-Languages से बताएं कि आपकी team कौन-सी भाषाएँ संभाल सकती है। Encryption field उपयोग करें तो वह उस जगह का URI होता है जहाँ key मिलेगी; RFC 9116 के अनुसार field में key स्वयं न रखें। Contact endpoint को monitored और account takeover से सुरक्षित रखें।
Expiry, domain coverage और stale ownership test करें
Expiry से पहले reminder लगाएँ, redirects और TLS जाँचें, और पुष्टि करें कि listed mailbox या form अभी trained owner तक पहुँचता है। Acquisition, domain change, नए product surface या support process के बाद policy review करें। Security.txt जानकारी ढूँढ़ना आसान करता है; यह complete response program चलने का प्रमाण नहीं है।
Vulnerability disclosure और security.txt के सवाल
क्या security.txt प्रकाशित करने से researcher को test की अनुमति मिलती है?
नहीं। RFC 9116 के अनुसार file disclosure जानकारी के लिए है और अपने-आप testing की अनुमति नहीं देती। Policy में असली scope और terms लिखें और researcher से उनका पालन कराएँ।
क्या vulnerability disclosure policy bug bounty के समान है?
नहीं। VDP report और response का तय रास्ता देता है। Bug bounty अलग program है जिसमें तय eligibility और payment rules के तहत reward दिया जाता है; company इनमें से एक या दोनों चला सकती है।
क्या VDP incident response की जगह लेता है?
नहीं। Product flaw की vulnerability report और active intrusion की report के लिए जुड़े हुए, लेकिन अलग workflows चाहिए। Urgent incident का साफ route दें और दोनों channels जिम्मेदार staff तक पहुँचाएँ।
security.txt में कौन-से fields जरूरी हैं?
RFC 9116 के अनुसार Contact और Expires जरूरी हैं। Policy और Preferred-Languages जैसे optional fields अतिरिक्त जानकारी दे सकते हैं। RFC format का पालन करें और contact, links तथा expiry current रखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .