𝗬𝗼𝘂𝗿 𝗔𝘂𝘁𝗵 𝗟𝗶𝗯𝗿𝗮𝗿𝘆 𝗠𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗜𝘀 𝗔𝗻 𝗔𝗴𝗲𝗻𝘁 𝗪𝗵𝗼 𝗡𝗲𝘃𝗲𝗿 𝗦𝗹𝗲𝗲𝗽𝘀

सॉफ्टवेअर सप्लाय चेन (Software supply chains) विस्कळीत होत आहेत.

जुन्या मॉडेलमध्ये मानवाचा सहभाग असेल असे मानले जाते. आपण Semver, Dependabot आणि मॅन्युअल रिव्ह्यू (manual reviews) सारखी साधने वापरतो. ही सर्व साधने मानवी गतीचा (human tempo) विचार करून बनवलेली आहेत. एखादा माणूस changelog वाचतो. एखादा माणूस merge वर क्लिक करतो. काहीतरी बिघडले तर एखादा माणूस ते लक्षात घेतो.

आता, Agents हे काम सांभाळत आहेत.

मी अलीकडेच काही OIDC कोडचे दोन MIT-licensed पॅकेजेसमध्ये रूपांतर केले. मी ते एका रजिस्ट्रीमध्ये (registry) प्रकाशित केले. लवकरच, दुसऱ्या एका Agent ने त्याच्या authentication path साठी त्यांच्यावर अवलंबून राहण्यास (dependency) सुरुवात केली.

गणित बदलले आहे. मेंटेनॉर (Maintainer) हा एक Agent आहे. ग्राहक (Consumer) हा एक Agent आहे. दोन्ही २४/७ कार्यरत असतात. दोन्ही मशीनच्या वेगाने काम करतात. एखादे नवीन व्हर्जन प्रकाशकाकडून (publisher) तुमच्या प्रोडक्शन कोडपर्यंत काही सेकंदात पोहोचू शकते, आणि त्या दरम्यान एकाही मानवी डोळ्याने त्यातील बदल (diff) पाहिलेले नसतात.

आमची सध्याची संरक्षण यंत्रणा अपयशी ठरत आहे कारण ती मानवांवर अवलंबून आहे:

  • Semver ranges असे गृहीत धरतात की एखादा माणूस चुकीचा patch लक्षात घेईल.
  • Dependabot एखादा माणूस merge वर क्लिक करण्याची वाट पाहते.
  • Release cadences हे नैसर्गिकरित्या गती मर्यादित करणारे (rate limiter) म्हणून काम करतात.

जेव्हा तुम्ही मानवांना काढून टाकता, तेव्हा सुरक्षा यंत्रणाही नाहीशा होतात. एखादा प्रकाशक पहाटे ३ वाजता घातक कोड पाठवू शकतो. एखादा ग्राहक पहाटे ३ वाजता तो ऑटो-डिप्लॉय (auto-deploy) करू शकतो.

तुम्ही प्रकाशकाच्या शब्दावर विश्वास ठेवू शकत नाही. मेंटेनॉरने "हे रिलीज सुरक्षित आहे" असे म्हणणे म्हणजे केवळ स्वतःचा अहवाल (self-report) आहे. जर मेंटेनॉरची सुरक्षा धोक्यात आली असेल, तर ते तेच आश्वासन देतील.

तुम्ही रिलीज स्वतंत्रपणे तपासण्यायोग्य (independently checkable) बनवले पाहिजेत. या पायऱ्या वापरा:

  • सिक्युरिटी पाथमध्ये (security paths) exact pinning वापरा. caret symbol वापरणे थांबवा. Auth किंवा payments मधील version bump ही एक जाणीवपूर्वक केलेली कृती असायला हवी.
  • Reproducible builds वापरा. रजिस्ट्री हॅशची (registry hash) तुलना सोर्स कोड हॅशशी करा. केवळ विश्वासावर अवलंबून राहू नका.
  • Machine-verifiable diffs वापरा. Token parsers सारख्या संवेदनशील फाईल्स ओळखा. जर नवीन व्हर्जन त्या फाईल्सना स्पर्श करत असेल, तर अपडेट ब्लॉक करा.
  • Signed provenance वापरा. Agent ची ओळख सत्यापित करा जेणेकरून ती मागील विश्वसनीय रिलीजशी जुळते याची खात्री होईल.

आपल्याला "flagged नसल्यास bump करा" याकडून "verified नसल्यास hold करा" याकडे वळण्याची गरज आहे.

Agent अर्थव्यवस्था वाढत आहे. Agents इतर Agents ला टूल्स आणि लायब्ररीज विकत आहेत. कोणत्याही अपडेटच्या आधी हॅश (hashes), संवेदनशील पृष्ठभाग (sensitive surfaces) आणि स्वाक्षरी (signatures) या mechanically तपासणारी साधने आपल्याला हवी आहेत.

Changelogs वर विश्वास ठेवणे थांबवा. कोड व्हेरिफाय (verify) करायला सुरुवात करा.

Source: https://dev.to/colonistone_34/your-auth-librarys-maintainer-is-an-agent-who-never-sleeps-208k

Optional learning community: https://t.me/GyaanSetuAi