Noma Labs ஒரு பொதுவான GitHub issue மூலம் AI-அடிப்படையிலான ஆட்டோமேஷனைப் பயன்படுத்தி, தனிப்பட்ட (private) ரெப்போசிட்டரிகளில் இருந்து குறியீடுகளை (code) திருட முடியும் என்பதைக் காட்டியுள்ளது. அவர்களின் proof-of-concept, ஒரு நிறுவனத்தின் சொந்த workflow bots-களை அவர்களுக்கு எதிராகத் திருப்பி, GitHub-ன் அங்கீகாரத்தை (authentication) உடைக்காமலேயே அந்த நிறுவனத்தின் ரகசியக் கோப்புகளைக் கசியவிட அனுமதிக்கிறது.

வெளிப்படையான தாக்குதல்

இந்த நிகழ்வுகளின் சங்கிலித் தொடர் எளிதாக மீண்டும் நிகழக்கூடியது:

  • ஒரு தாக்குதல்தாரர் (attacker), அனைவரும் பார்க்கக்கூடிய ஒரு பொதுவான (public) ரெப்போசிட்டரியில் ஒரு issue-வை உருவாக்குகிறார்.
  • continuous-integration pipeline-உடன் இணைக்கப்பட்ட ஒரு AI agent, அந்த issue-வின் தலைப்பு மற்றும் உள்ளடக்கத்தைப் படிக்கிறது.
  • அதே agent ஏற்கனவே அந்த நிறுவனத்தின் பிற தனிப்பட்ட (private) ரெப்போசிட்டரிகளுக்கான read permissions-களைக் கொண்டுள்ளது.
  • பொதுவான issue-வில் மறைந்துள்ள அறிவுறுத்தல்கள், எந்தத் தனிப்பட்ட கோப்புகளைப் பெற வேண்டும் என்று agent-க்குத் தெரிவிக்கின்றன.
  • அந்த agent பெறப்பட்ட கோப்புகளை பொதுவான issue-வில் ஒரு comment-ஆகப் பதிவிடுவதன் மூலம், அவற்றை உலகிற்கு வெளிப்படுத்துகிறது.

இவை அனைத்தும் ஆட்டோமேஷனின் ஒரே ஒரு செயல்பாட்டில் (run) நடந்துவிடுகின்றன. இதில் credential திருட்டு இல்லை, API-key கசிவு இல்லை, GitHub-ல் எந்தப் பாதிப்பும் (vulnerability) இல்லை. தாக்குதல்தாரர் அந்த நிறுவனம் தனது சொந்த bot-ன் மீது வைத்திருக்கும் நம்பிக்கையை மட்டுமே பயன்படுத்துகிறார்.

இது இப்போது ஏன் முக்கியமானது

AI-ஆல் இயங்கும் agents இப்போது நவீன டெவலப்மென்ட் pipelines-களை ஒருங்கிணைக்கின்றன. அவை pull-requests-களைத் திறக்கின்றன, சோதனைகளை (tests) நடத்துகின்றன, builds-களை deploy செய்கின்றன மற்றும் bugs-களை வகைப்படுத்துகின்றன (triage)—இவை அனைத்தும் issue comments போன்ற எளிய சிக்னல்களால் தூண்டப்படுகின்றன. அந்த agents-களுக்கு விரிவான ரெப்போசிட்டரி அணுகல் (repository access) இருக்கும்போது, நம்பகமான தரவுக்கும் (trusted data) நம்பகத்தன்மையற்ற பயனர் உள்ளீட்டிற்கும் (untrusted user input) இடையிலான எல்லை மங்கலாகிறது.

ஒரு agent ஒரே செயல்பாட்டில் (execution) தனிப்பட்ட குறியீட்டைப் படிக்கவும், பொதுப்படையாக எழுதவும் முடிந்தால், நிறுவனத்தின் access-control மாடல் முறிந்துவிடும்.

உண்மையான குறைபாடு: permissions, மாடல் அல்ல

இந்தச் செயல்முறை அடிப்படையிலுள்ள AI மாடலைச் சுட்டிக்காட்டவில்லை. மாடல் தான் பெறும் அறிவுறுத்தல்களை மட்டுமே பின்பற்றுகிறது. இந்தத் தாக்குதலுக்கான வாய்ப்பு (vulnerability), ஆட்டோமேஷனுக்கு வழங்கப்பட்ட permission செட்டில் உள்ளது:

  • நிறுவனத்தின் அனைத்துத் தனிப்பட்ட (private) ரெப்போசிட்டரிகளுக்கும் Read access.
  • பொதுவான issue threads-களுக்கு Write access.
  • எவராலும் உருவாக்கக்கூடிய பொதுவான உரையின் (public text) மூலம் Trigger செய்யப்படுவது.

செலவில்லாத, ஆனால் பயனுள்ள தீர்வுகள்

'Principle of least privilege'-ஐப் பயன்படுத்துவது தாக்குதல் பாதையைக் குறைக்கும்:

  • Bot-ன் எல்லையைத் (Scope) தீர்மானிக்கவும்: அதற்குத் தேவையான ரெப்போசிட்டரியுடன் மட்டும் அதைத் தொடர்புபடுத்தவும். ஒரு குறிப்பிட்ட ரெப்போசிட்டரியில் மட்டும் செயல்பட வேண்டியிருந்தால், மற்ற எந்த read உரிமங்களையும் அதற்கு வழங்க வேண்டாம்.
  • Read மற்றும் write tokens-களைத் தனித்தனியாகப் பிரிக்கவும்: குறியீட்டைப் பெற ஒரு credential-ஐயும், comment-களைப் பதிவிடக் கடுமையாகக் கட்டுப்படுத்தப்பட்ட மற்றொரு credential-ஐயும் பயன்படுத்தவும்.
  • மனித அங்கீகாரம் (Human approval): பொதுப்படையாகப் பதிவிடுவதற்கு முன் மனித அங்கீகாரம் தேவை. ஒரு சிறிய மறுஆய்வுப் படிநிலை—உதாரணமாக, ஒரு கட்டாய அங்கீகார லேபிள் (approval label)—pipeline-ஐத் தடுக்காமல் ஒரு சரிபார்ப்புப் புள்ளியை (checkpoint) சேர்க்கும்.
  • Blast-radius-ஐக் குறைக்கவும்: ஒரு தோல்வி அல்லது தவறான பயன்பாடு முழு நிறுவனத்தையும் பாதிக்காமல், அதிகபட்சம் ஒரு ரெப்போசிட்டரியை மட்டுமே பாதிக்கும் வகையில் workflows-களை வடிவமைக்கவும்.

எதிர் கருத்து: செயல்பாட்டுச் சுமை (operational overhead)

அடுத்து கவனிக்க வேண்டியவை

சுருக்கம் (Takeaway): ஒரு AI ஆட்டோமேஷனால் தனிப்பட்ட குறியீட்டைப் பார்க்கவும், பொதுப்படையாகப் பேசவும் (write) முடிந்தால், அந்த அமைப்பு தவறாக வடிவமைக்கப்பட்டுள்ளது. permissions-களைக் கடுமையாக்குங்கள், மனிதச் சரிபார்ப்புகளைச் சேர்க்கவும் மற்றும் blast radius-ஐச் சிறியதாக வைத்திருக்கவும்—இல்லையெனில் ஒரு பொதுவான issue தரவு கசிவுக்கான (data-leak vector) வழியாக மாறிவிடும்.