स्वतंत्र डेवलपर्स और फ्रीलांसर

सुरक्षा दायित्व जो पहले से ही आप पर लागू होते हैं

यदि आप एक फ्रीलांसर या एक स्वतंत्र डेवलपर हैं जो ग्राहक डेटा को संभाल रहे हैं, तो आप छोटे होने के कारण सुरक्षा विनियमन से बाहर नहीं निकल सकते। GDPR के तहत प्रोसेसर दायित्व, EU AI Act के तहत deployer दायित्व, और आपके ग्राहकों की अनुबंधित सुरक्षा आवश्यकताएं सभी सीधे आपको जोड़ती हैं — आज, आपके वर्तमान आकार पर। यहाँ क्या पहले से लागू है, नाम विनियमन द्वारा विनियमन, और वर्तमान में आपके अपने खाते पर exposed है।

आप पर क्या पहले से लागू होता है

GDPR: आप व्यक्तिगत रूप से एक डेटा प्रोसेसर हैं

जब एक ग्राहक आपको व्यक्तिगत डेटा सौंपता है — एक उपयोगकर्ता डेटाबेस, एक उत्पादन प्रणाली, एक निर्यात — आप GDPR के तहत एक डेटा प्रोसेसर के रूप में कार्य कर रहे हैं (और कभी-कभी एक नियंत्रक)। वह स्थिति कंपनी की आवश्यकता नहीं करती: यह „एक प्राकृतिक या कानूनी व्यक्ति" को जोड़ता है। यह आपको एक अनुबंध के तहत प्रक्रिया करने के लिए बाध्य करता है, आप जो डेटा रखते हैं उसके लिए उचित सुरक्षा उपाय लागू करने के लिए, और यदि यह breach होता है तो बिना अनुचित देरी के अपने ग्राहक को सूचित करने के लिए — और यह आपको मुआवजे के दावों और प्रशासनिक जुर्माने के संपर्क में लाता है।

आधार: GDPR आर्टिकल 4 (परिभाषाएं), आर्टिकल 28 (अनुबंध के तहत प्रोसेसिंग), आर्टिकल 32 (प्रोसेसिंग की सुरक्षा), आर्टिकल 33 (breach सूचना), आर्टिकल 82–83 (दायित्व और प्रशासनिक जुर्माना 20 मिलियन यूरो तक या वार्षिक विश्वव्यापी टर्नओवर का 4%, जो अधिक हो।

EU AI Act: ग्राहकों के लिए AI को तैनात करना दायित्व रखता है

यदि आपके ग्राहक काम में AI प्रणालियों को उत्पादन में डालना शामिल है — एक ग्राहक के उत्पाद में एक सहायक, एक वर्कफ़्लो को स्वचालित करने वाला एक AI एजेंट — EU AI Act deployers पर दायित्व लगाता है: जो अपने स्वयं के अधिकार के तहत एक व्यावसायिक संदर्भ में AI प्रणालियों का उपयोग करते हैं। कौन से दायित्व लागू होते हैं यह सिस्टम की जोखिम श्रेणी पर निर्भर करता है, लेकिन „मैंने केवल इसे एकीकृत किया" बिल्कुल वह भूमिका है जो deployer श्रेणी कवर करती है।

आधार: EU AI Act आर्टिकल 26 (उच्च-जोखिम AI प्रणालियों के deployers के दायित्व), आर्टिकल 4 (AI साक्षरता), आर्टिकल 99 (दंड)।

आपके enterprise ग्राहकों को आपसे सुरक्षा साक्ष्य एकत्र करना चाहिए

SOC 2, ISO 27001, या GDPR आर्टिकल 28 के तहत संचालन करने वाली कंपनियां विक्रेता-प्रबंधन प्रोग्राम चलाती हैं जिन्हें उनके ऑडिटर वास्तव में जांचते हैं — और वे प्रोग्राम 500-व्यक्तिगत विक्रेता और एक-व्यक्तिगत विक्रेता के बीच अंतर नहीं करते। यही कारण है कि सुरक्षा प्रश्नावली अनुबंध से पहले आती है। फ्रीलांसर जो साक्ष्य के साथ उत्तर दे सकते हैं जो improvise करते हैं उनकी तुलना में तेजी से बंद करते हैं।

आधार: अनुबंधात्मक — डेटा प्रोसेसिंग समझौते और विक्रेता सुरक्षा आवश्यकताएं जो आपके ग्राहकों को किसी को भी हाथ सौंपने के लिए लगाई जाती हैं, व्यक्तियों सहित।

एक breached ग्राहक परियोजना एक वास्तविक व्यावसायिक जोखिम है

एक ग्राहक परियोजना में एक सुरक्षा घटना आपके अनुबंध के indemnification clause के तहत प्रत्यक्ष दायित्व का मतलब हो सकता है, GDPR आर्टिकल 82 के तहत प्रोसेसर दायित्व का मतलब हो सकता है जहां व्यक्तिगत डेटा शामिल है, और ग्राहक और संदर्भ खोने का मतलब हो सकता है जो इसके साथ आया। एक व्यक्तिगत व्यवसायों के लिए, प्रतिष्ठात्मक परिसंपत्ति व्यवसाय है। यह जोखिम है, निश्चितता नहीं — लेकिन यह सामान्य परिणाम श्रृंखला है जब एक भूल गया credential एक घटना में बदल जाता है।

आधार: GDPR आर्टिकल 82 (मुआवजे का अधिकार); आपने स्वयं की सेवा अनुबंध।

वर्तमान में आपके खाते पर क्या exposed है

ऊपर हर दायित्व एक ही पहली सवाल का तात्पर्य: आपके ग्राहक काम रहता है उस जगह क्या पहुंच है? अधिकांश स्वतंत्र डेवलपर्स के लिए वह जगह एक व्यक्तिगत GitHub खाता है — और यह वर्षों के लिए access जमा कर रहा है। निम्नलिखित सभी GitHub के अपने API से मशीन-पठनीय हैं:

स्थापित GitHub Apps

Deployment bots, CI tools, AI assistants — प्रत्येक आपने एक बार अनुमति दी। कुछ के पास आप जो मालिक हैं उसके ऊपर write या admin है; कुछ परियोजनाओं के हैं जो लंबे समय पहले समाप्त हो गईं।

Deploy keys

सर्वर पर अनुपस्थित SSH क्रेडेंशियल। एक read-write key एक repository पर जो केवल read की आवश्यकता थी एक code-injection path है यदि वह सर्वर कभी compromise हो जाए।

सहयोगी

सहयोग के दौरान जोड़े गए लोग जो तब से समाप्त हो गए, अभी भी write पहुंच रखते हैं — public repositories पर भी।

सार्वजनिक repositories

आपके repositories में से कौन सार्वजनिक हैं, और कौन उन्हें push कर सकता है, एक इन्वेंटरी सवाल है अधिकांश डेवलपर्स स्मृति से उत्तर नहीं दे सकते।

AI विक्रेता keys जो परियोजनाएं survive करती हैं

OpenAI, Anthropic, Mistral, या Cursor खाता आपके side परियोजनाओं के पीछे API keys और seats जमा करता है परियोजना समाप्त होने के बहुत बाद। 8200.dev का AI Governance view stale और org-wide keys को flag करता है, keys जो role परिवर्तन को outlived करते हैं, और seats जो कोई उपयोग नहीं करता — विक्रेता के अपने admin APIs से, केवल-पढ़ने के लिए।

यह देखें, फिर निर्णय लें

अपने व्यक्तिगत GitHub खाते को read-only से कनेक्ट करें और inventory प्राप्त करें: हर स्थापित ऐप और इसकी अनुमतियां, हर deploy key और यह read-only है या नहीं, हर सहयोगी, हर सार्वजनिक repository — गंभीरता द्वारा ranked निष्कर्षों के साथ। फ्री tier आपके शीर्ष 3 निष्कर्षों को पूरी तरह से दिखाता है। कोई कानून आपको स्कैन चलाने के लिए आवश्यक नहीं करता; ऊपर दायित्व किसी भी तरह लागू होते हैं। एक स्कैन जो बदलता है वह है कि क्या आप उन सवालों का उत्तर दे सकते हैं जो वे imply करते हैं।

अपने खाते को मुफ्त स्कैन करें पूरा लेख पढ़ें →

केवल-पढ़ने के लिए scopes। कभी आपका source code नहीं। कोई credit card नहीं।

यह पृष्ठ विनियमों के बारे में सामान्य जानकारी है जो आमतौर पर स्वतंत्र डेवलपर्स और फ्रीलांसरों पर लागू होते हैं; यह कानूनी सलाह नहीं है। प्रत्येक विनियमन आपकी विशिष्ट स्थिति पर कैसे लागू होता है यह तथ्यों पर निर्भर करता है जो आपके लिए विशिष्ट हैं — इसके लिए, एक वकील से परामर्श लें।