Repository ownership बदल रहा है? Handoff से पहले access audit करें

Repository ownership changes security events होते हैं, भले ही transfer सामान्य housekeeping जैसा लगे। Repository दोपहर भर में नई team के पास जा सकती है, लेकिन उसके आसपास की permissions उन maintainers से जुड़ी रह सकती हैं जो जा चुके हैं, retired automation से, पुराने cloud accounts से और ऐसे credentials से जिन्हें महीनों से किसी ने नहीं खोला।

मैंने teams को repository owner बदलने और collaborator page से दो लोगों को हटाने के बाद handoff पूरा घोषित करते देखा है। फिर कोई भूला हुआ deployment job personal token से publish करता रहता है, कोई orphaned SSH key private source पढ़ती रहती है या कोई पुराना Git hosting app pull requests बदलने की authority रखता है। Repository page साफ दिखता था, लेकिन असली control plane साफ नहीं था।

व्यावहारिक नियम सरल है: ownership तभी transfer करें जब आप हर उस identity और service का नाम बता सकें जो कोई महत्वपूर्ण प्रभाव डाल सकती है। «महत्वपूर्ण» में nonpublic code पढ़ना, commits push करना, pull requests खोलना या approve करना, build definitions बदलना, secrets तक पहुँचना, packages publish करना, software deploy करना और access खुद बदलना शामिल है।

Repository transfer से accountability transfer नहीं होती

Repository owner एक administrative label है। Accountability का मतलब है कि कोई वर्तमान व्यक्ति बता सके कि repository किन चीज़ों से जुड़ी है, हर connection क्यों मौजूद है, उसका रखरखाव कौन करता है और incident के दौरान उसे कैसे revoke किया जाएगा।

ये अलग बातें हैं। Git hosting permissions एक service के भीतर access बताती हैं। Modern projects CI runners, package registries, cloud roles, code scanning apps, release bots, documentation publishers, chat notifications, DNS providers और artifact stores पर भी निर्भर करते हैं। हर system की अपनी identities और project की अपनी memory होती है।

यह अंतर तब सबसे ज़्यादा मायने रखता है जब project reorganization, acquisition, internal platform migration या staff turnover के कारण move होता है। Receiving team आमतौर पर build को green रखने पर ध्यान देती है। Departing team अपने नाम हटाने पर। इनमें से कोई काम यह साबित नहीं करता कि control सुरक्षित रूप से transfer हुआ।

Access बदलने से पहले ownership boundary लिखें। इसमें ये बातें होनी चाहिए:

• receiving technical owner, जो operational responsibility स्वीकार करता है
• business owner, जो तय करता है कि code और releases तक किसे access मिल सकता है
• incident contact, जो urgent revocation को authorize कर सकता है
• repository membership और service identities का source of record
• वह तारीख जब पुरानी team की authority समाप्त होगी

Final owner के रूप में group mailbox या अस्पष्ट team name का इस्तेमाल न करें। Group mail प्राप्त कर सकता है, लेकिन रात के दो बजे निर्णय नहीं ले सकता। नामित लोगों की पहचान करें और team बदलने पर उस record की समीक्षा करें।

एक और असुविधाजनक बात है: जिस project का वर्तमान owner नहीं है, उसे केवल इसलिए broad production access नहीं मिलना चाहिए कि वह अभी भी build हो रहा है। अगर deployment credentials की जिम्मेदारी लेने वाला कोई नहीं है, तो releases रोकें या permissions घटाएं। Availability अज्ञात authority बनाए रखने का कारण नहीं है।

Repository page से नहीं, effects से inventory बनाएं

उपयोगी access inventory उन actions से शुरू होती है जो हो सकते हैं, फिर पीछे जाकर उन identities को खोजती है जो उन्हें कर सकती हैं। Collaborator list से शुरुआत तेज़ लगती है, लेकिन बहुत कुछ छूट जाता है।

पूछें कि Git hosting website पर developer बैठे बिना इस project के साथ क्या हो सकता है। कोई bot commit भेज सकता है। CI workflow cloud token प्राप्त कर सकता है। Tag आने के बाद package publish हो सकता है। Webhook receiver production deployment शुरू कर सकता है। Code review app comments लिख या checks बदल सकता है। हर effect ऐसी permission की ओर इशारा करता है जिसका owner होना चाहिए।

पाँच columns वाली working table बनाएं: capability, identity, credential location, current owner और revoke procedure। Revoke procedure का अपना column होना ज़रूरी है, क्योंकि «token delete कर दें» अक्सर वास्तविक प्रक्रिया नहीं होती। आपको app uninstall करनी पड़ सकती है, cloud trust rule हटाना पड़ सकता है, deploy key delete करनी पड़ सकती है, registry token invalidate करना पड़ सकता है या दोनों ends पर webhook secret बदलना पड़ सकता है।

पहले चरण में इन categories को शामिल करें:

• Human identities, जिनमें direct collaborators, organization teams, outside collaborators और organization administrators शामिल हैं।
• Nonhuman identities, जिनमें machine users, service accounts, CI runner identities और application installations शामिल हैं।
• Credentials, जिनमें SSH deploy keys, personal access tokens, app private keys, webhook secrets, registry tokens और cloud credentials शामिल हैं।
• Execution paths, जिनमें workflow files, reusable workflow references, runner groups, deployment environments, release scripts और scheduled jobs शामिल हैं।
• Data exits, जिनमें webhooks, package publishing, documentation publication, backups, mirrors, issue integrations और notification services शामिल हैं।

Inventory में credential का purpose आसान भाषा में लिखें। «CI token» पर्याप्त नहीं है। «Signed release tag push होने पर source पढ़ना और internal command line package publish करना» अगले maintainer को बताता है कि क्या test करना है और failure का क्या risk है।

आपको ऐसी entries मिलेंगी जिन्हें कोई पहचानता नहीं। केवल नाम ठीक लगने के कारण उन्हें चालू न रखें। Evidence मांगें: यह कहाँ configured है, हाल में किस job ने इसका इस्तेमाल किया, यह क्या कर सकता है और transfer के बाद इसका owner कौन होगा। जवाब अस्पष्ट रहे तो removal schedule करें। अज्ञात credentials अक्सर incident के बाद ही पहचाने जाते हैं।

Personal credentials handoff को कमजोर बनाते हैं

जो production या release path किसी एक maintainer के personal token पर निर्भर है, उसे पहले ही बदला जाना चाहिए। Project move केवल इस कमजोरी को सामने लाता है।

Personal credentials दो तरह की समस्याएं पैदा करते हैं। पहली स्पष्ट है: former maintainer project छोड़ने के बाद भी access रख सकता है। दूसरी अधिक आम है: account disable हो जाता है या token expire हो जाता है और receiving team की सबसे ज़रूरत के समय release path टूट जाता है। Teams अक्सर former maintainer से एक और token बनाने को कहती हैं। इससे तत्काल समस्या ठीक होती है, लेकिन dependency और मजबूत हो जाती है।

Personal credentials को service identity से तभी बदलें जब service को सचमुच durable identity की ज़रूरत हो। उसे documented job पूरा करने के लिए सबसे छोटी permission set दें। Release publisher को एक package publish करने की permission चाहिए हो सकती है। उसे broad organization administration या हर repository का access नहीं चाहिए।

Machine user को अच्छी तरह managed service identity न समझें। Machine user automation के लिए इस्तेमाल किया जाने वाला account है। उसका unknown password, personal recovery email, broad membership और कोई owner न होना संभव है। उसे भी सामान्य identity की तरह lifecycle दें: सोच-समझकर provision करें, owner document करें, memberships review करें और काम खत्म होने पर हटाएं।

यहीं «बस एक shared automation account इस्तेमाल करें» वाली लोकप्रिय सलाह विफल होती है। यह जल्दी automation शुरू कर देती है और हर integration समझने की मेहनत बचाती है। लेकिन इससे unrelated permissions एक ही identity में इकट्ठी हो जाती हैं। एक project के team बदलने पर उसका access revoke करना बाकी projects को जोखिम में डाल सकता है।

Operational purpose के आधार पर identities अलग रखें। Build reader, release publisher और production deployer को अक्सर अलग privileges और अलग owners चाहिए होते हैं। इससे revocation कम जोखिम भरा और incident investigation अधिक स्पष्ट होता है।

Git host के बाहर मौजूद user-owned tokens भी जाँचें। Deployment script CI secret से token पढ़ सकती है, लेकिन वह token किसी departed व्यक्ति के cloud account का हो सकता है। Secret कहाँ रखा है, इससे उसकी authority का पता नहीं चलता। Issuer तक जाएं और वहाँ permissions देखें।

Deploy keys और application installations की अलग समीक्षा करें

Deploy keys, Git hosting apps और OAuth integrations repository access देते हैं, लेकिन इनके failure अलग होते हैं। इन्हें एक ही list मानने से revocation लापरवाही से होती है।

Deploy key आमतौर पर repository से जुड़ी SSH public key होती है। Configuration के आधार पर वह read या write access दे सकती है। इसका लाभ narrow attachment है। इसकी कमजोरी identity का अस्पष्ट होना है: key यह कम बताती है कि private half किस system के पास है। अगर comment में «build server» लिखा हो और वह server दो बार हाथ बदल चुका हो, तो repository record आपकी मदद नहीं करेगा।

हर deploy key के लिए चार बातें verify करें: private key कहाँ रहती है, कौन-सा process उसका इस्तेमाल करता है, क्या उसे write permission चाहिए और जिस host या secret store में वह रखी है उसका owner कौन है। केवल source fetch करने वाली keys से write access हटाएं। ऐसी key हटाएं जिसे active system और नामित owner से जोड़ा नहीं जा सकता।

Application installation में उलटी समस्या होती है। उसकी identity, permissions और event history आमतौर पर बेहतर होती है, लेकिन वह कई repositories में installed हो सकती है। उसे एक project से हटाने पर संबंधित service कहीं और सक्रिय रह सकती है। App की requested permissions, installation scope, private key rotation process, callback URLs और उस organization account की जाँच करें जो installation बदल सकता है।

GitHub के documentation में deploy keys और GitHub Apps को अलग रखा गया है, और इसका कारण सही है। Deploy keys repositories से जुड़ती हैं, जबकि app को installation के ज़रिए permissions मिलती हैं और वह अपने credentials इस्तेमाल करती है। Deploy key delete करने से app access प्रभावित होगा, या app uninstall करने से SSH key invalidate होगी, ऐसा न मानें। ये अलग authority paths हैं।

OAuth integrations पर भी यही सावधानी रखें। वे dedicated application identity के बजाय किसी user की ओर से action कर सकती हैं। Transfer के दौरान पता करें कि integration की authorization former maintainer पर निर्भर तो नहीं। अगर निर्भर है, तो उसे supported service identity में ले जाएं या हटा दें। किसी व्यक्ति के company छोड़ने तक इंतज़ार करना revocation plan नहीं है।

Workflow files अपने नाम से अधिक authority दे सकती हैं

Test चलाने वाली दिखने वाली workflow भी credentials प्राप्त कर सकती है, reusable workflows चला सकती है, repository में write कर सकती है या deployment systems trigger कर सकती है। Access को harmless मानने से पहले file पढ़ें।

सभी executable repository configuration देखें, केवल release workflow नहीं। इसमें CI definitions, उनके द्वारा बुलाए गए scripts, dependency update configuration, deployment manifests, infrastructure code, package publication settings और comments या pull requests से trigger होने वाली scripts शामिल हैं।

उन जगहों पर ध्यान दें जहाँ job trust boundary पार करती है। सामान्य उदाहरण हैं, identity token को cloud role के लिए exchange करने वाली workflow, repository write permission के साथ pull request का code चलाने वाली job या किसी अन्य repository से लिया गया reusable workflow। Workflow का नाम «lint» हो सकता है, लेकिन उसकी permissions असली स्थिति बताती हैं।

GitHub के Actions documentation में चेतावनी दी गई है कि pull_request_target base repository के context में चलता है और उसे सामान्य pull request workflow से अधिक privileges मिल सकती हैं। यह event अपने आप गलत नहीं है। समस्या तब होती है जब इसके साथ untrusted pull request code या outsider द्वारा प्रभावित की जा सकने वाली scripts चलें। Handoff के दौरान ऐसी workflows खोजें और receiving team से उन्हें स्पष्ट रूप से स्वीकार करवाएं।

एक साधारण repository search कई स्पष्ट references पकड़ लेती है। जितनी पूरी repository history देखनी हो उसे fetch करने के बाद इसे locally चलाएं:

git grep -nE '(AWS_|AZURE_|GCP_|TOKEN|SECRET|DEPLOY|PUBLISH|ssh |curl |webhook)' -- \
  '.github' '.gitlab-ci.yml' 'scripts' 'infra' 'package.json' 2>/dev/null

Output कुछ ऐसा दिख सकता है:

.github/workflows/release.yml:42:  id-token: write
scripts/publish.sh:18: curl -H "Authorization: Bearer $REGISTRY_TOKEN"
infra/deploy.sh:9: ssh -i "$DEPLOY_KEY" "$DEPLOY_HOST"

यह command यह साबित नहीं करती कि कोई secret मौजूद है या job खतरनाक है। यह review queue देती है। हर hit को credential issuer, permission scope और failure path तक trace करें। ऐसी workflow references भी खोजें जो repository के बाहर point करती हैं, क्योंकि reusable workflow के ज़रिए code ऐसी authority पा सकता है जिसे यह repository नियंत्रित नहीं करती।

Inherited workflow को चलाने के लिए broad defaults न दें। Job की declared permissions ठीक करें और केवल आवश्यक action test करें। Transfer उन permissions को हटाने का अच्छा समय है जो केवल इसलिए बची रहीं क्योंकि कोई पुराने pipeline को छेड़ना नहीं चाहता था।

Evidence बचाते हुए और outages से बचकर revoke करें

Revocation का क्रम महत्वपूर्ण है। अगर पहले सब कुछ delete कर देंगे, तो active dependency पहचानने के लिए ज़रूरी evidence खो सकते हैं। अगर perfect documentation का इंतज़ार करेंगे, तो पुराना access हमेशा बना रह सकता है।

Review के दौरान discretionary changes रोकें। Receiving owner को baseline पूरा होने से पहले यह पता होना चाहिए कि कोई नया app installation, deploy key या organization administrator तो नहीं जुड़ा। इसका मतलब सामान्य development रोकना नहीं है, लेकिन changes दिखाई देने चाहिए।

Memberships, external collaborator lists, deploy keys, app installations, webhooks, CI secrets metadata, cloud trust relationships और recent audit events का export या recorded snapshot लें। Secret values record में न रखें। Identifiers, scopes, owners, उपलब्ध हो तो creation context और inspection time रखें।

फिर यह क्रम अपनाएं:

1. Former maintainers का direct access हटाएं और जहाँ transfer के लिए आवश्यक हो वहाँ former organization administrators की privileges घटाएं।
2. Unknown integrations disable या uninstall करें और बिना active owner वाली deploy keys revoke करें।
3. Known personal credentials को service identities से बदलें, फिर exact build, publish या deploy path test करें।
4. Replacement काम करने के बाद webhook secrets, application private keys और registry credentials जैसे shared secrets rotate करें।
5. Project की release cadence के अनुरूप अवधि तक audit events और failed jobs review करें, फिर temporary exceptions हटाएं।

इस क्रम से unknown authority को known dependencies से अलग किया जाता है। Unknown deploy key कोई supported function नहीं देती, इसलिए उसे जल्दी हटाएं। Known release credential के लिए पहले replacement चाहिए, नहीं तो security correction एक avoidable outage बन जाएगी।

Failed replacement के लिए deliberate break-glass path रखें। इसमें यह स्पष्ट हो कि service कौन restore कर सकता है, exception कितने समय तक रहेगी और team उसे कैसे record करेगी। Release late होने पर departed maintainer का broad token वापस न लाएं। Current ownership के तहत temporary, narrowly scoped credential बनाएं, exception record करें और repair के बाद उसे हटा दें।

Agent access को भी उसी ownership boundary का पालन करना चाहिए

Autonomous coding agents code edit कर सकते हैं, APIs call कर सकते हैं, SSH इस्तेमाल कर सकते हैं, artifacts publish कर सकते हैं और attached tools के ज़रिए infrastructure प्रभावित कर सकते हैं। Agent access को नज़रअंदाज़ करने वाला repository transfer review में बड़ा gap छोड़ देता है।

केवल यह न पूछें कि कौन लोग agent चला सकते हैं। पूछें कि repository की ओर से कौन-से agent processes action कर सकते हैं, वे कौन-से tools call कर सकते हैं, उन tools के credentials किसके हैं और क्या reviewer बाद में किसी specific action को फिर से समझ सकता है। Developer shell, CI job या remote runner से चलने वाले agent की authority अलग हो सकती है, भले ही model एक ही हो।

Long-lived credentials को agent के prompt और working files से बाहर रखें। Environment variables या tool output से secret देने पर वह logs, subprocesses, accidental commits और agent के अपने context तक पहुँच सकता है। किसी एक log viewer में value mask कर देना process boundary को सुरक्षित नहीं बनाता।

Sallyport इस्तेमाल करने वाली teams के लिए Mac app HTTP और SSH credentials को अपने encrypted vault में रख सकता है। MCP-capable agent local shim के ज़रिए action request करता है, credential खुद प्राप्त नहीं करता। इसके session और activity journals agent runs और individual calls के अलग records देते हैं, जो handoff review के समय केवल transcript से अधिक उपयोगी हैं।

Transition के दौरान पुराने workstations या processes से जुड़े agent sessions revoke करें और नए owner से fresh runs approve करवाएं। फिर हर credential का उपयोग देखें: read-only source fetch और production deployment के लिए एक जैसी approval expectation नहीं होनी चाहिए। उद्देश्य हर command को कठिन बनाना नहीं है। उद्देश्य powerful calls को उस व्यक्ति के सामने स्पष्ट करना है जो उनके परिणामों की जिम्मेदारी लेता है।

Written agent inventory में repository scope, execution location, tool channels, credential owner, action owner और emergency revoke action शामिल करें। अगर ये fields भर नहीं सकते, तो agent के पास ऐसा access है जिसे project जिम्मेदारी से transfer नहीं कर सकता।

Audit records को बताना चाहिए कि control किसने बदला

Ownership change के बाद «token used» लिखने वाला log पर्याप्त नहीं है। आपको पता होना चाहिए कि token किसका था, किस process ने इस्तेमाल किया, उसने क्या किया, किस repository को target किया और नई ownership के तहत वह action allowed था या नहीं।

Repository audit events, CI execution records, cloud audit records, package registry events और agent action records को transfer file या incident system में साथ रखें। इनका format एक जैसा नहीं होगा, और यह ठीक है। ज़रूरी बात common time reference और पर्याप्त identifiers हैं, ताकि systems के बीच event को follow किया जा सके।

Transfer पूरा घोषित करने से पहले records test करें। हर supported route से harmless change करें: normal developer push, pull request automation event, scheduled job अगर मौजूद हो, उपलब्ध हो तो nonproduction destination पर package publish और approval चाहने वाला agent action। Confirm करें कि receiving team former maintainers को बुलाए बिना evidence खोज सकती है।

Tamper evidence उपयोगी है, लेकिन retention और access control की जगह नहीं लेता। Append-only log बताता है कि किसी ने record बदला या नहीं। अगर event source ने call record ही नहीं की, log retention समाप्त हो गई या incident के समय कोई current person log पढ़ नहीं सकता, तो उससे मदद नहीं मिलेगी।

Move के बाद review date तय करें। पहली review weekly या monthly चलने वाली automation पकड़ती है। दूसरी review उन लोगों को पकड़ती है जो कुछ बंद होने पर exception मांगते हैं। ये exceptions diagnostic material हैं। हर exception ऐसी dependency दिखाती है जो initial inventory से छूट गई थी।

Receiving team को हर access path हटाने में सक्षम होना चाहिए

Handoff तब पूरा होता है जब receiving team हर meaningful access path revoke कर सके, बिना पुरानी team से secret समझने, machine ढूँढने या change approve करवाने की ज़रूरत के। यह standard repository transfer dialog से अधिक सख्त है और उस समस्या को रोकता है जो बार-बार होती है: कागज़ पर code ownership move हो जाती है, लेकिन control दूसरी जगह बिखरा रहता है।

सबसे कम आकर्षक artifact, access inventory, से शुरुआत करें। हर connected service के पास owner और revoke procedure लिखें। फिर वे entries हटाएं जिनके पास दोनों में से कुछ भी नहीं है। काम tedious लगता है, जब तक पहली urgent credential rotation न आ जाए। उस समय inventory contained repair और एक सप्ताह की guessing के बीच का अंतर बन जाती है।