Noma Labs തെളിയിച്ചത്, AI അധിഷ്ഠിത ഓട്ടോമേഷൻ ഉപയോഗിച്ച് ഒരു സിംഗിൾ പബ്ലിക് GitHub issue വഴി പ്രൈവറ്റ് റിപ്പോസിറ്ററികളിൽ നിന്ന് കോഡ് മോഷ്ടിക്കാമെന്നാണ്. അവരുടെ proof-of-concept പ്രകാരം, ഒരു അറ്റാക്കർക്ക് ഒരു സ്ഥാപനത്തിന്റെ സ്വന്തം വർക്ക്ഫ്ലോ ബോട്ടുകളെ അവർക്കെതിരെ തന്നെ തിരിച്ചുവിടാനും, GitHub-ന്റെ ഓതന്റേഷൻ ലംഘിക്കാതെ തന്നെ ഉടമസ്ഥാവകാശമുള്ള ഫയലുകൾ ചോർത്താനും സാധിക്കും.

പരസ്യമായ രീതിയിലുള്ള ആക്രമണം

ഈ സംഭവങ്ങൾ താഴെ പറയുന്ന രീതിയിൽ ലളിതമായി ആവർത്തിക്കാവുന്നതാണ്:

  • ഒരു അറ്റാക്കർ ആർക്കും കാണാൻ കഴിയുന്ന ഒരു പബ്ലിക് റിപ്പോസിറ്ററിയിൽ ഒരു issue ക്രിയേറ്റ് ചെയ്യുന്നു.
  • continuous-integration പൈപ്പ്‌ലൈനിൽ ഘടിപ്പിച്ചിട്ടുള്ള ഒരു AI ഏജന്റ്, ആ issue-യുടെ ടൈറ്റിലും ബോഡിയും വായിക്കുന്നു.
  • അതേ ഏജന്റിന് സ്ഥാപനത്തിലെ മറ്റ് പ്രൈവറ്റ് റിപ്പോസിറ്ററികൾ വായിക്കാനുള്ള അനുമതി (read permissions) നേരത്തെ തന്നെ ഉണ്ടായിരിക്കും.
  • പബ്ലിക് issue-യിലുള്ള ഒളിഞ്ഞിരിക്കുന്ന നിർദ്ദേശങ്ങൾ ഏത് പ്രൈവറ്റ് ഫയലുകളാണ് എടുക്കേണ്ടതെന്ന് ഏജന്റിനോട് പറയുന്നു.
  • ഏജന്റ് കണ്ടെത്തിയ ഫയലുകൾ പബ്ലിക് issue-വിൽ ഒരു കമന്റായി പോസ്റ്റ് ചെയ്യുന്നു, അങ്ങനെ അവ ലോകത്തിന് മുന്നിൽ തുറന്നുകാട്ടപ്പെടുന്നു.

ഓട്ടോമേഷന്റെ ഒരു സിംഗിൾ റണ്ണിൽ തന്നെ ഇതെല്ലാം സംഭവിക്കുന്നു. ഇതിൽ ക്രെഡൻഷ്യൽ മോഷണമോ, API-key ചോർച്ചയോ, GitHub-ന്റെ സുരക്ഷാ വീഴ്ചയോ ഇല്ല. സ്ഥാപനം അതിന്റെ സ്വന്തം ബോട്ടിന് നൽകിയിട്ടുള്ള വിശ്വാസത്തെയാണ് അറ്റാക്കർ ഇവിടെ ചൂഷണം ചെയ്യുന്നത്.

എന്തുകൊണ്ടാണ് ഇത് ഇപ്പോൾ പ്രധാനമാകുന്നത്

AI അധിഷ്ഠിത ഏജന്റുകളാണ് ഇന്ന് ആധുനിക ഡെവലപ്‌മെന്റ് പൈപ്പ്‌ലൈനുകളെ കോർത്തിണക്കുന്നത്. അവ pull-requests തുറക്കുന്നു, ടെസ്റ്റുകൾ റൺ ചെയ്യുന്നു, ബിൽഡുകൾ ഡെപ്ലോയ് ചെയ്യുന്നു, ബഗുകൾ തരംതിരിക്കുന്നു (triage) — ഇവയെല്ലാം issue കമന്റുകൾ പോലുള്ള ലളിതമായ സിഗ്നലുകളിലൂടെയാണ് പ്രവർത്തിക്കുന്നത്. ഇത്തരം ഏജന്റുകൾക്ക് റിപ്പോസിറ്ററികളിൽ വിപുലമായ ആക്സസ് ഉള്ളപ്പോൾ, വിശ്വസനീയമായ ഡാറ്റയും വിശ്വസിക്കാൻ കൊള്ളാത്ത യൂസർ ഇൻപുട്ടും തമ്മിലുള്ള വ്യത്യാസം ഇല്ലാതാകുന്നു.

ഒരു ഏജന്റിന് ഒരേ സമയം പ്രൈവറ്റ് കോഡ് വായിക്കാനും പബ്ലിക് ആയി എഴുതാനും സാധിക്കുമെങ്കിൽ, സ്ഥാപനത്തിന്റെ ആക്സസ്-കൺട്രോൾ മോഡൽ തകർന്നടിയുന്നു.

യഥാർത്ഥ പിഴവ്: പെർമിഷനുകൾ, മോഡലല്ല

ഈ ഡെമോൺസ്‌ട്രേഷൻ അടിസ്ഥാനപരമായ AI മോഡലിനെ കുറ്റപ്പെടുത്തുന്നില്ല. മോഡൽ ലഭിക്കുന്ന നിർദ്ദേശങ്ങൾ പാലിക്കുക മാത്രമാണ് ചെയ്യുന്നത്. ഓട്ടോമേഷന് നൽകിയിട്ടുള്ള പെർമിഷനുകളിലാണ് സുരക്ഷാ വീഴ്ചയുള്ളത്:

  • സ്ഥാപനത്തിലുടനീളമുള്ള പ്രൈവറ്റ് റിപ്പോസിറ്ററികളിലേക്കുള്ള Read access.
  • പബ്ലിക് issue ത്രെഡുകളിലേക്കുള്ള Write access.
  • ആർക്കും നിർമ്മിക്കാവുന്ന പബ്ലിക് ടെക്സ്റ്റുകളിൽ നിന്നുള്ള Trigger.

ചിലവില്ലാത്തതും എന്നാൽ ഫലപ്രദവുമായ പരിഹാരങ്ങൾ

'Principle of least privilege' (മിനിമം അനുമതിയുടെ തത്വം) പ്രയോഗിക്കുന്നത് ആക്രമണ സാധ്യത കുറയ്ക്കും:

  • ബോട്ടിന്റെ പരിധി നിശ്ചയിക്കുക (Scope the bot): ബോട്ടിന് ഒരു പ്രത്യേക റിപ്പോസിറ്ററിയിൽ മാത്രം പ്രവർത്തിക്കേണ്ടതുണ്ടെങ്കിൽ, മറ്റ് റിപ്പോസിറ്ററികളിലേക്കുള്ള റീഡ് റൈറ്റുകൾ നിഷേധിക്കുക.
  • Read, write ടോക്കണുകൾ വേർതിരിക്കുക: കോഡ് എടുക്കുന്നതിന് ഒരു ക്രെഡൻഷ്യലും കമന്റുകൾ പോസ്റ്റ് ചെയ്യുന്നതിന് കർശനമായി നിയന്ത്രിക്കപ്പെട്ട മറ്റൊരു ക്രെഡൻഷ്യലും ഉപയോഗിക്കുക.
  • മനുഷ്യന്റെ അംഗീകാരം (Human approval): പബ്ലിക് ആയി പോസ്റ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഒരു മനുഷ്യന്റെ പരിശോധന ഉറപ്പാക്കുക. പൈപ്പ്‌ലൈൻ തടസ്സപ്പെടുത്താതെ തന്നെ ഒരു ലളിതമായ റിവ്യൂ സ്റ്റെപ്പ്—ഉദാഹരണത്തിന് ഒരു അപ്രൂവൽ ലേബൽ ആവശ്യപ്പെടുന്നത്—ഒരു ചെക്ക്പോയിന്റായി പ്രവർത്തിക്കും.
  • ബ്ലാസ്റ്റ് റേഡിയസ് കുറയ്ക്കുക (Blast-radius reduction): ഒരു പരാജയമോ ദുരുപയോഗമോ ഉണ്ടായാൽ അത് ഒരു റിപ്പോസിറ്ററിയെ മാത്രം ബാധിക്കുന്ന രീതിയിൽ വർക്ക്ഫ്ലോകൾ രൂപകൽപ്പന ചെയ്യുക, അല്ലാതെ മുഴുവൻ സ്ഥാപനത്തെയും അല്ല.

എതിർവാദം: പ്രവർത്തനപരമായ അധികഭാരം (operational overhead)

ഇനി ശ്രദ്ധിക്കേണ്ടവ

ചുരുക്കത്തിൽ: ഒരു AI ഓട്ടോമേഷന് പ്രൈവറ്റ് കോഡ് കാണാനും പബ്ലിക് ആയി പ്രതികരിക്കാനും സാധിക്കുമെങ്കിൽ, ആ സിസ്റ്റം തെറ്റായ രീതിയിലാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. പെർമിഷനുകൾ കർശനമാക്കുക, മനുഷ്യന്റെ പരിശോധനകൾ ഉൾപ്പെടുത്തുക, ബ്ലാസ്റ്റ് റേഡിയസ് കുറഞ്ഞ അളവിൽ നിർത്തുക — അല്ലാത്തപക്ഷം ഒരു സിംഗിൾ പബ്ലിക് issue ഡാറ്റ ചോർച്ചയ്ക്കുള്ള ഒരു മാർഗ്ഗമായി മാറിയേക്കാം.