Noma Labs ಒಂದು AI-ಚಾಲಿತ ಆಟೊಮೇಷನ್ ಬಳಸಿ ಕೇವಲ ಒಂದು ಸಾರ್ವಜನಿಕ GitHub issue ಮೂಲಕ ಖಾಸಗಿ ರೆಪೊಸಿಟರಿಗಳಿಂದ (private repositories) ಕೋಡ್ ಅನ್ನು ಕದಿಯಬಹುದು ಎಂದು ತೋರಿಸಿಕೊಟ್ಟಿದೆ. ಅವರ proof-of-concept ಮೂಲಕ ದಾಳಿಕೋರರು ಸಂಸ್ಥೆಯ ಸ್ವಂತ workflow bots ಅನ್ನು ಸಂಸ್ಥೆಯ ವಿರುದ್ಧವೇ ಬಳಸಿಕೊಳ್ಳಬಹುದು, ಇದರಿಂದ GitHub ನ ಅಥೆಂಟಿಕೇಶನ್ ಅನ್ನು ಮುರಿಯದೆಯೇ ಪ್ರೊಪ್ರೈಟರಿ ಫೈಲ್‌ಗಳನ್ನು ಸೋರಿಕೆ ಮಾಡಬಹುದು.

ಕಣ್ಣೆದುರಿಗೇ ನಡೆಯುವ ದಾಳಿ

ಈ ಘಟನಾವಲಿಯನ್ನು táiಸೃಷ್ಟಿಸುವುದು ಸಾಕಷ್ಟು ಸರಳವಾಗಿದೆ:

  • ದಾಳಿಕೋರರು ಯಾರೂ ನೋಡಬಹುದಾದ ಒಂದು ಸಾರ್ವಜನಿಕ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಒಂದು issue ಅನ್ನು ರಚಿಸುತ್ತಾರೆ.
  • continuous-integration pipeline ಗೆ ಸಂಪರ್ಕ ಹೊಂದಿರುವ ಒಂದು AI ಏಜೆಂಟ್, ಆ issue ನ ಶೀರ್ಷಿಕೆ ಮತ್ತು ವಿಷಯವನ್ನು ಓದುತ್ತದೆ.
  • ಅದೇ ಏಜೆಂಟ್‌ಗೆ ಸಂಸ್ಥೆಯ ಇತರ ಖಾಸಗಿ ರೆಪೊಸಿಟರಿಗಳನ್ನು ಓದುವ ಅನುಮತಿ (read permissions) ಈಗಾಗಲೇ ಇರುತ್ತದೆ.
  • ಸಾರ್ವಜನಿಕ issue ನಲ್ಲಿರುವ ಗುಪ್ತ ಸೂಚನೆಗಳು ಯಾವ ಖಾಸಗಿ ಫೈಲ್‌ಗಳನ್ನು ಪಡೆಯಬೇಕೆಂದು ಏಜೆಂಟ್‌ಗೆ ತಿಳಿಸುತ್ತವೆ.
  • ಏಜೆಂಟ್ ಪಡೆದ ಫೈಲ್‌ಗಳನ್ನು ಸಾರ್ವಜನಿಕ issue ನಲ್ಲಿ ಕಾಮೆಂಟ್ ಆಗಿ ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಅವು ಜಗತ್ತಿಗೆ ಬಹಿರಂಗವಾಗುತ್ತವೆ.

ಇದೆಲ್ಲವೂ ಆಟೊಮೇಷನ್‌ನ ಒಂದೇ ಒಂದು ರನ್‌ನಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಯಾವುದೇ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಕಳ್ಳತನ, API-key ಸೋರಿಕೆ ಅಥವಾ GitHub ದೋಷಗಳಿಲ್ಲ. ದಾಳಿಕೋರರು ಕೇವಲ ಸಂಸ್ಥೆಯು ತನ್ನ ಸ್ವಂತ ಬಾಟ್‌ಗೆ ನೀಡಿದ ನಂಬಿಕೆಯನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುತ್ತಾರೆ.

ಇದು ಈಗ ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ

AI-ಚಾಲಿತ ಏಜೆಂಟ್‌ಗಳು ಈಗ ಆಧುನಿಕ ಡೆವಲಪ್‌ಮೆಂಟ್ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಜೋಡಿಸುತ್ತಿವೆ. ಅವು pull-requests ತೆರೆಯುತ್ತವೆ, tests ನಡೆಸುತ್ತವೆ, builds ನಿಯೋಜಿಸುತ್ತವೆ (deploy) ಮತ್ತು bugs ವಿಂಗಡಿಸುತ್ತವೆ (triage)—ಇವೆಲ್ಲವೂ issue ಕಾಮೆಂಟ್‌ಗಳಂತಹ ಲಘು ಸಂಕೇತಗಳಿಂದ ಪ್ರಚೋದಿತಗೊಳ್ಳುತ್ತವೆ. ಅಂತಹ ಏಜೆಂಟ್‌ಗಳು ವ್ಯಾಪಕವಾದ ರೆಪೊಸಿಟರಿ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದಾಗ, ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ಮತ್ತು ನಂಬಿಕೆಗೆ ಅರ್ಹವಲ್ಲದ ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಅಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಒಂದು ಏಜೆಂಟ್ ಒಂದೇ ಎಕ್ಸಿಕ್ಯೂಶನ್‌ನಲ್ಲಿ ಖಾಸಗಿ ಕೋಡ್ ಅನ್ನು ಓದಬಲ್ಲದು ಮತ್ತು ಸಾರ್ವಜನಿಕವಾಗಿ ಬರೆಯಬಲ್ಲದು ಎಂದಾದರೆ, ಸಂಸ್ಥೆಯ access-control ಮಾಡೆಲ್ ಕುಸಿದು ಬೀಳುತ್ತದೆ.

ನಿಜವಾದ ದೋಷ: ಮಾಡೆಲ್ ಅಲ್ಲ, ಅನುಮತಿಗಳು (permissions)

ಈ ಪ್ರದರ್ಶನವು ಮೂಲ AI ಮಾಡೆಲ್ ಅನ್ನು ದೂಷಿಸುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ಕೇವಲ ತನಗೆ ಸಿಗುವ ಸೂಚನೆಗಳನ್ನು ಪಾಲಿಸುತ್ತದೆ. ಈ ದೋಷವು ಆಟೊಮೇಷನ್‌ಗೆ ನೀಡಲಾದ ಅನುಮತಿಗಳಲ್ಲಿದೆ (permission set):

  • ಸಂಸ್ಥೆಯಾದ್ಯಂತ ಇರುವ ಖಾಸಗಿ ರೆಪೊಸಿಟರಿಗಳಿಗೆ Read access.
  • ಸಾರ್ವಜನಿಕ issue ಥ್ರೆಡ್‌ಗಳಿಗೆ Write access.
  • ಯಾರೂ ಕೂಡ ಸೃಷ್ಟಿಸಬಹುದಾದ ಸಾರ್ವಜನಿಕ ಪಠ್ಯದ ಮೇಲೆ Trigger.

ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲದ, ಆದರೆ ಪರಿಣಾಮಕಾರಿ ಪರಿಹಾರಗಳು

'Least privilege' ತತ್ವವನ್ನು ಅನ್ವಯಿಸುವುದರಿಂದ ದಾಳಿಯ ಹಾದಿಯನ್ನು ತಡೆಯಬಹುದು:

  • ಬಾಟ್‌ನ ಕಾರ್ಯವ್ಯಾಪ್ತಿಯನ್ನು (Scope the bot) ಸೀಮಿತಗೊಳಿಸಿ: ಬಾಟ್ ಅಗತ್ಯವಿರುವ ರೆಪೊಸಿಟರಿಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿರಲಿ. ಅದು ಕೇವಲ ಒಂದು ನಿರ್ದಿಷ್ಟ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕಿದ್ದರೆ, ಇತರ ಯಾವುದೇ ಓದುವ ಹಕ್ಕುಗಳನ್ನು ನಿರಾಕರಿಸಿ.
  • Read ಮತ್ತು write tokens ಪ್ರತ್ಯೇಕಿಸಿ: ಕೋಡ್ ಪಡೆಯಲು ಒಂದು ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಮತ್ತು ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲು ಮತ್ತೊಂದು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಯಂತ್ರಿಸಲ್ಪಟ್ಟ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಬಳಸಿ.
  • ಮಾನವ ಅನುಮೋದನೆ (Human approval): ಯಾವುದೇ ಸಾರ್ವಜನಿಕ ಪೋಸ್ಟಿಂಗ್‌ಗಿಂತ ಮೊದಲು ಅನುಮೋದನೆ ಪಡೆಯಿರಿ. ಅಗತ್ಯವಿರುವ ಅನುಮೋದನಾ ಲೇಬಲ್‌ನಂತಹ ಒಂದು ಲಘು ಪರಿಶೀಲನಾ ಹಂತವು ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ತಡೆಹಿಡಿಯದೆ ಒಂದು ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ.
  • Blast-radius ಕಡಿತಗೊಳಿಸಿ: ವೈಫಲ್ಯ ಅಥವಾ ದುರುಪಯೋಗವು ಇಡೀ ಸಂಸ್ಥೆಯ ಬದಲಾಗಿ ಗರಿಷ್ಠ ಒಂದು ರೆಪೊಸಿಟರಿಯ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುವಂತೆ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ (operational overhead)

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

ಸಾರಾಂಶ (Takeaway): ಒಂದು AI ಆಟೊಮೇಷನ್ ಖಾಸಗಿ ಕೋಡ್ ಅನ್ನು ನೋಡಬಲ್ಲದು ಮತ್ತು ಸಾರ್ವಜನಿಕವಾಗಿ ಮಾತನಾಡಬಲ್ಲದು ಎಂದಾದರೆ, ಆ ವ್ಯವಸ್ಥೆಯ ವಿನ್ಯಾಸ ತಪ್ಪಾಗಿದೆ. ಅನುಮತಿಗಳನ್ನು ಬಿಗಿಗೊಳಿಸಿ, ಮಾನವ ಪರಿಶೀಲನೆಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು blast radius ಅನ್ನು ಚಿಕ್ಕದಾಗಿಡಿ—ಅಲ್ಲದಿದ್ದರೆ ಕೇವಲ ಒಂದು ಸಾರ್ವಜನಿಕ issue ಡೇಟಾ ಸೋರಿಕೆಯ ಮೂಲವಾಗಬಹುದು.