آنچه تأیید کردهاید، همان چیزی نیست که اجرا میشود
اخیراً ابزار جدیدی مورد توجه قرار گرفته است. این ابزار در مقابل دستوراتی مانند curl قرار میگیرد و اسکریپت را پیش از اجرا به شما نشان میدهد. بخشهای خطرناک را برجسته میکند. این ابزار مفید است، اما مشکل اصلی را نادیده میگیرد.
مشکل این نیست که آیا بایتها مخرب به نظر میرسند یا خیر. مشکل اینجاست که یک URL میتواند امروز یک اسکریپت را ارائه دهد و فردا اسکریپت دیگری را. بررسی شما فقط مربوط به یک لحظه خاص در زمان است.
کارشناسان سیستم، این پدیده را TOCTOU مینامند. این عبارت مخفف time-of-check to time-of-use (زمانِ بررسی تا زمانِ استفاده) است. شما فایلی را بررسی میکنید، سپس کسی پیش از آنکه فایل را باز کنید، آن را تعویض میکند. بررسی شما درست بود، اما درباره چیزی بود که دیگر وجود ندارد.
عاملهای هوش مصنوعی (AI agents) این ریسک را بسیار بالاتر میبرند. عاملها بهطور مداوم بررسیها را انجام میدهند.
- یک عامل، یک URL را ping میکند و پاسخ موفقیتآمیز را نشانهای از امنیت میپندارد.
- یک عامل، یک پروفایل را میخواند و یک ادعا را به عنوان یک واقعیت در نظر میگیرد.
- یک عامل، یک امضا را میبیند و فرض میکند بایتهای دقیقی که قرار است اجرا کند، همانهایی هستند که امضا شدهاند.
هر بررسی، اعتماد را به یک لحظه یا یک کانال گره میزند. سپس عامل بر اساس چیزی در مراحل بعدی (downstream) عمل میکند که آن بررسی هرگز پوشش نداده است.
برای مثال، یک عامل ممکن است یک manifest ابزار را اعتبارسنجی کرده و نتیجه را کش (cache) کند. اگر قبل از اینکه عامل ابزار را فراخوانی کند، endpoint تغییر کند، عامل نسخه اشتباه را اجرا میکند. اعتبارسنجی با موفقیت انجام شده، اما برای مانیفستی انجام شده که عامل دیگر از آن استفاده نمیکند.
تلاش برای رفع این مشکل از طریق اسکن دقیقتر، کارساز نیست. قوانین بیشتر فقط بازه زمانی را محدودتر میکنند، اما آن را نمیبندند. یک تولیدکننده همچنان میتواند در میلیثانیههای بین اسکن و اجرای شما، آرتیفکت (artifact) متفاوتی را ارائه دهد.
برای رفع این مشکل، تأیید کردنِ «لحظه» را متوقف کنید. تأیید کردنِ «آرتیفکت» را شروع کنید.
تصمیمات خود را به جای یک fetch، به یک شیء تغییرناپذیر (immutable object) متصل کنید.
- یک URL را تأیید نکنید.
- یک هش (hash) محتوایی مشخص را تأیید کنید.
- بهتر است که هشی را تأیید کنید که توسط یک کلید مورد اعتماد امضا شده است.
این کار پرسش را از «آیا این متن ترسناک است؟» به «آیا این دقیقاً همان آرتیفکتی است که کلید برای آن ضمانت داده است؟» تغییر میدهد. اگر هش مطابقت نداشته باشد، آن را رد میکنید. هیچ بحثی در کار نیست.
این رویکرد همچنین قابلیت انتقال (portability) تأیید را فراهم میکند. یک شخص ثالث میتواند همان هش و امضا را بردارد تا خودش نتیجه را تأیید کند. این ویژگیِ خودِ شیء است، نه ویژگیِ زمانِ انجام کار شما.
از این دو سؤال برای آزمایش هر نوع تأییدی استفاده کنید:
- Is the check bound to the exact artifact used, or to a moment and a promise?
- Can a stranger re-run the check and reach the same verdict?
If the answer to the first is a moment, the check has an expiry date. If the answer to the second is no, you do not have verification. You have testimony.
Most current agent verification is just testimony. "The handshake succeeded" or "the scan was clean" are true statements about a moment, but they do not attach to the bytes that actually run.
Agents act thousands of times without human oversight. If you do not pin trust to artifacts, the whole chain inherits the weakest, oldest check.
You do not need new technology to fix this. Content addressing and digital signatures are decades old. You simply need to point them at the right thing: the exact bytes that execute, not the request that fetched them.
Before you trust a check, find out what it attaches to. If it attaches to a moment, it has already expired.
Source: https://dev.to/anp2network/the-thing-you-verified-is-not-the-thing-that-runs-hnl
Optional learning community: https://t.me/GyaanSetuAi