شواهد نرم‌افزاری · بررسی یک نسخه مشخص
منشأ یک نسخه از بسته npm را چطور بررسی کنیم؟
در گزارش تحویل نوشته‌اند «کد منبع بسته در این مخزن است». لینک را باز می‌کنید و پروژه‌ای مرتب می‌بینید. هنوز یک پرسش بی‌پاسخ مانده: بسته‌ای که تحویل گرفته‌اید به کدام نسخه از همین کد وصل است؟ دیدن مخزن امروز، پاسخ نسخه تحویلی دیروز نیست.
برای شروع، نام و نسخه دقیق بسته را مشخص کنید؛ سپس سابقه منشأ یا provenance همان نسخه را بخوانید و نشانی کد و ساخت را با ادعای تحویل مقایسه کنید. این مرحله با خواندن صفحات عمومی انجام می‌شود و نیازی به نصب بسته ندارد. خروجی مطلوب، یک ارتباط قابل پیگیری یا یک اختلاف روشن است.
قبل از نشان سبز، شماره نسخه را پیدا کنید
نام کامل بسته، پیشوند احتمالی @scope، شماره نسخه و رجیستری مبدأ را کنار هم بنویسید. رجیستری همان محل انتشار و دریافت بسته است. عبارت «آخرین نسخه» برای بایگانی شواهد کافی نیست؛ ممکن است نفر بعدی با همین عبارت به نسخه دیگری برسد.
اگر موضوع، وابستگی یک پروژه است، از مسئول پروژه فقط بخش مرتبط فایل وابستگی را بخواهید. طبق راهنمای lockfile در npm، این فایل درخت وابستگی حل‌شده را ثبت می‌کند و می‌تواند به تعیین نسخه کمک کند. البته فایل دریافتی به‌تنهایی ثابت نمی‌کند چه چیزی اکنون روی سرور اجرا می‌شود. منبع و تاریخ همان فایل را هم نگه دارید.
حالا سؤال را محدود کنید: «آیا سابقه بسته با این نام و این نسخه، به همان بازبینی کدی اشاره دارد که در گزارش تحویل آمده؟» با این صورت‌بندی می‌دانید دنبال چه تطبیقی هستید.
از نسخه بسته به رکورد ساخت بروید
راهنمای رسمی npm مسیر نشان کنار Version و سپس View more details را توضیح می‌دهد. ارجاع‌های Source Commit، Build File، Build Summary، محیط ساخت و Public Ledger را ثبت کنید. هشدار پیدا نشدن مخزن یا commit را هم در یادداشت بیاورید.
در قدم بعد، دوباره شماره نسخه نمایش‌داده‌شده را با پرونده خود تطبیق دهید. شناسه کامل بازبینی منبع را با شناسه‌ای که تحویل‌دهنده معرفی کرده مقایسه کنید. منظور از commit، یک بازبینی مشخص از کد است. به نام شاخه یا صفحه اصلی پروژه اکتفا نکنید؛ باید معلوم باشد رکورد به کدام تغییر و کدام ساخت اشاره می‌کند.
اگر دو شناسه فرق دارند، هر دو را حفظ کنید. جایگزین‌کردن خودکار شناسه قدیمی با جدید، همان اختلافی را پاک می‌کند که قرار بود بررسی شود.
در تعریف SLSA، سابقه ساخت برای دنبال‌کردن خروجی تا منبع تولید آن به کار می‌رود. این با پرسش «چه کسی قابلیت را نوشته؟» فرق دارد. برای پرسش دوم، راهنمای بررسی مشارکت در گیت‌هاب مسیر مناسب‌تری دارد.
تمرین: مدرک درست برای نسخه اشتباه
مثال کاملاً فرضی. یک تیم بسته آموزشی «پردازشگر بندر» با نسخه ۲.۴.۱ را تحویل گرفته است. گزارش می‌گوید اصلاحیه موجود در بازبینی B داخل بسته است. سابقه‌ای که برای نسخه ۲.۴.۱ نشان داده‌اند به A می‌رسد. سپس تصویر دیگری می‌فرستند که B را نشان می‌دهد، اما شماره نسخه در آن ۲.۴.۲ است. این مثال گزارش آزمایش یک بسته واقعی نیست.
یادداشت درست این است: «مدرک نسخه ۲.۴.۱ به A اشاره دارد؛ ارجاع به B مربوط به ۲.۴.۲ است. وجود اصلاحیه B در نسخه تحویلی هنوز احراز نشده.» درخواست بعدی باید مدرک همان نسخه تحویلی یا اصلاح توضیح تحویل باشد.
فرض کنید بعداً یک برنامه‌نویس نشان دهد اصلاح مشابهی با روش دیگری در A پیاده شده است. این شاهد می‌تواند نتیجه مربوط به قابلیت را تغییر دهد؛ اما شناسه‌ای را که در سابقه ساخت ثبت شده عوض نمی‌کند. ثبت جداگانه این دو یافته، جلوی یک نتیجه‌گیری شتاب‌زده را می‌گیرد.
هر خلأ، اقدام بعدی خودش را دارد
اگر ارجاع‌ها سازگارند، همان اتصال نسخه به منبع را گزارش کنید. اگر سابقه‌ای پیدا نکردید، محل جست‌وجو و نسخه بررسی‌شده را بنویسید و مدرک دیگری برای زنجیره انتشار بخواهید. اگر لینک باز نمی‌شود، پیام و زمان مشاهده را ثبت کنید؛ محتویات قبلی آن را حدس نزنید. اگر شناسه‌ها متناقض‌اند، ابتدا روشن کنید ادعا درباره کدام بسته است.
npm در توضیح محدودیت‌های provenance می‌گوید این سابقه تضمین نبود کد مخرب نیست. همچنین خواندن صفحه وب را اعتبارسنجی رمزنگاری محلی یا بازسازی بسته معرفی نکنید. اگر این کارها انجام نشده، همان را صریح بنویسید.
یک برگه کوتاه برای تحویل بررسی
- ادعای دقیق و نشانی محل بیان آن
- نام کامل، رجیستری و نسخه بسته؛ مدرکی که نسخه را مشخص می‌کند
- صفحه سابقه و زمان مشاهده؛ شناسه منبع و ارجاع ساخت
- شناسه مورد انتظار در گزارش تحویل
- نتیجه تطبیق، اختلاف یا شاهد موجودنبودن اطلاعات
- مدرک لازم برای ادامه و بررسی‌هایی که انجام نشده‌اند
این برگه را پیش از جمع‌کردن تصویرهای بیشتر کامل کنید. اگر بررسی بخشی از پرونده یک تأمین‌کننده است، آن را در گزارش قابل پیگیری اوسینت قرار دهید. خواننده باید بتواند از نتیجه به نسخه مشخص و مدرک مربوط به آن برگردد.
انتشار: ۲۳ اکتبر ۲۰۲۶ · تحریریه اوسینت جت
ادامه مسیر اوسینت
سرنخ‌های خام را به یک تحقیق ساختارمند در اوسینت جت تبدیل کنید
برای نتیجه بهتر، فقط به یک سرنخ اکتفا نکنید. شماره تلفن، ایمیل، یوزرنیم، دامنه، نام شرکت، تصویر، شهر، لینک شبکه اجتماعی و توضیح زمینه پرونده را کنار هم قرار دهید تا موتور اطلاعاتی اوسینت جت تحلیل دقیق‌تری بسازد.