‏Dependabot فایل bun.lock رو نمی‌بینه

نیکلا شارپانتیه تو پنجمین قسمت از سری مقاله‌هاش دربارهٔ مدیریت CVEها، سراغ یه مشکل پنهون رفته: گراف وابستگی گیت‌هاب هنوز bun.lock رو نمی‌خونه. هشدارهای Dependabot روی همین گراف ساخته می‌شن. برای npm و Yarn و pnpm، گیت‌هاب lockfile رو می‌خونه و نسخهٔ دقیق همه‌چی رو می‌دونه. ولی تو پروژهٔ Bun فقط سراغ package.json می‌ره که فقط وابستگی‌های مستقیم توشه. نکتهٔ گول‌زننده اینه که Dependabot version updates از اوایل ۲۰۲۵ از Bun پشتیبانی می‌کنه، ولی هشدارها از یه مسیر دیگه میان.

نویسنده یه پروژهٔ نمونه ساخته با سه وابستگی آسیب‌پذیر. bun audit هر سه‌تا رو پیدا می‌کنه، ولی Dependabot فقط برای zod هشدار می‌ده. uuid@8.3.2 یه وابستگی غیرمستقیمه (یعنی وابستگیِ یه وابستگی) که فقط تو bun.lock وجود داره. happy-dom هم با catalog: تعریف شده (یعنی نسخه‌ش یه جای مرکزی تو workspace نوشته شده) و گیت‌هاب نسخه‌ش رو همون رشتهٔ catalog: می‌بینه که با هیچ advisoryای جور نمی‌شه. تو پروژه‌های واقعی بیشتر پکیج‌ها غیرمستقیمن، پس این شکاف خیلی بزرگ‌تره.

قسمت عجیب‌تر ماجرا مهاجرته. وقتی از npm یا Yarn می‌رین سراغ Bun، فایل package-lock.json یا yarn.lock حذف می‌شه و گیت‌هاب هشدارهای باز مربوط به اون فایل رو fixed می‌زنه. در حالی که پکیج‌های آسیب‌پذیر هنوز سر جاشونن، فقط این بار تو bun.lock. به گفتهٔ نویسنده، تو یه مهاجرت واقعی دیدن که چندتا هشدار همون روز بسته شدن ولی bun audit هنوز همه‌شون رو گزارش می‌کرد.

برای فهمیدن اینکه درگیرین یا نه، می‌شه تو Insights → Dependency graph نگاه کرد که bun.lock جزو manifestها هست یا نه. یا هشدارهای باز رو با خروجی bun audit مقایسه کرد. راه‌حل نویسنده استفاده از dependency submission API گیت‌هابه، یعنی یه API که هر ابزاری می‌تونه درخت کامل وابستگی‌ها رو بهش بفرسته. اون یه Action به اسم bun-lock-submission ساخته که همهٔ bun.lockهای ریپو رو می‌خونه و می‌فرسته:

jobs:
  submit:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v7
      - uses: charpeni/bun-lock-submission@v1

این Action وابستگی‌ها رو مستقیم/غیرمستقیم و runtime/development برچسب می‌زنه، workspaceها و catalogها رو می‌فهمه و تکراری‌ها رو تا جای ممکن حذف می‌کنه. اگه تو package.json از رنج نسخه مثل ^8.3.0 استفاده می‌کنین، تنظیم layout: workspaces جلوی هشدار دوتایی رو می‌گیره. نویسنده اونو روی پروژه‌های نصب‌شده با Bun 1.1 تا 1.4 (lockfile نسخهٔ ۰ تا ۳) تست کرده و هشدارها معمولاً تو چند ثانیه تا چند دقیقه ظاهر می‌شن.

چندتا نکته هم هست: هشدارها فقط برای برنچ پیش‌فرض صادر می‌شن، Dependabot برای Bun پول‌ریکوئست امنیتی باز نمی‌کنه (برای اصلاح باید سراغ bun audit fix رفت)، و اجرای اول احتمالاً کلی هشدار یه‌جا می‌ریزه. پکیج‌های خصوصی رو هم باید با ورودی exclude بیرون گذاشت، چون گیت‌هاب advisoryها رو با اسم پکیج تطبیق می‌ده. نویسنده امیدواره این مقاله زود قدیمی بشه؛ هر وقت گیت‌هاب خودش bun.lock رو خوند، می‌شه workflow رو حذف کرد و با bunx bun-lock-submission clear داده‌های فرستاده‌شده رو پاک کرد.

نکات کلیدی:

• گراف وابستگی گیت‌هاب bun.lock رو نمی‌خونه و تو پروژه‌های Bun فقط package.json رو می‌بینه.
• وابستگی‌های غیرمستقیم و پکیج‌های تعریف‌شده با catalog: هیچ هشدار Dependabot نمی‌گیرن.
• مهاجرت از npm یا Yarn به Bun می‌تونه هشدارهای باز رو به‌اشتباه fixed نشون بده.
• Action bun-lock-submission از طریق dependency submission API کل bun.lock رو به گیت‌هاب می‌فرسته و دسترسی contents: write می‌خواد.
• هشدارها فقط روی برنچ پیش‌فرض فعال می‌شن و Dependabot برای Bun پول‌ریکوئست اصلاحی نمی‌سازه.