یافتن تمام محصول‌های متأثر از یک مؤلفه
وقتی اطلاعیه تازه‌ای درباره یک کتابخانه منتشر می‌شود، پرسش مسئول پاسخ‌گویی معمولاً این است که کدام نسخه از کدام محصول به بررسی نیاز دارد. اگر گزارش هر خط ساخت در پوشه جداگانه باقی مانده باشد، جمع‌آوری پاسخ حتی برای یک شرکت متوسط زمان می‌برد. OWASP Dependency-Track صورت مواد نرم‌افزار محصول‌ها را دریافت می‌کند و استفاده از مؤلفه‌ها را در مجموعه پروژه‌ها دنبال می‌کند. تیم می‌تواند از یک وابستگی به پروژه‌های مصرف‌کننده برسد، مالک اصلاح را پیدا کند و اثر تغییر را در انتشار بعدی بررسی کند. ارزش این روش به کیفیت فهرستی وابسته است که به سامانه فرستاده می‌شود.
برای مثال، سه برنامه مختلف می‌توانند یک کتابخانه پردازش تصویر را از مسیرهای متفاوت دریافت کنند. یکی آن را مستقیم نصب کرده، دیگری از طریق چارچوب وب گرفته و سومی نسخه‌ای همراه محصول فروشنده دارد. اگر هر سه صورت مواد دقیق داشته باشند، بررسی از یک پرسش مشترک آغاز می‌شود و به سه پرونده با مالکان متفاوت می‌رسد. اگر یکی از محصول‌ها فهرست قدیمی داشته باشد، پاسخ مربوط به همان محصول ناقص خواهد بود. در جلسه رخداد، نبود نتیجه و نبود داده باید جدا ثبت شوند تا محصول فاقد فهرست به اشتباه محصول سالم تلقی نشود.
نسخه مستندات و قرارداد تبادل
راهنمای اتصال خط ساختی که این نوشته به آن ارجاع می‌دهد به شاخه چهارم Dependency-Track تعلق دارد. صفحه رسمی، مسیر متفاوتی برای مستندات شاخه پنجم معرفی می‌کند. پیش از کپی کردن نمونه درخواست، نسخه سرور و مستندات منطبق را مشخص کنید. اصل گردش کار پایدار است. سامانه ساخت، فهرست CycloneDX را برای یک پروژه معین ارسال می‌کند و تیم امنیت نتیجه تحلیل را در همان زمینه می‌بیند. جزئیات مسیر رابط، مجوز لازم، رفتار ایجاد پروژه و پشتیبانی قالب باید از راهنمای نسخه نصب‌شده خوانده شود.
در شروع همکاری با تیم توسعه، قرارداد کوتاهی تعریف کنید. هر فهرست باید به یک محصول و نسخه قابل شناسایی تعلق داشته باشد و در مرحله‌ای تولید شود که ترکیب نهایی محصول معلوم است. مالک خط ساخت مسئول تولید و ارسال فایل است و مالک محصول باید بتواند توضیح دهد چه انتشارهایی در محیط واقعی باقی مانده‌اند. اگر نسخه آزمایشی، نسخه عرضه‌شده و شاخه توسعه همگی با نام یکسان وارد شوند، تحلیل گذشته و حال مخلوط می‌شود. انتخاب کلید پروژه و قرارداد نام‌گذاری پیش از ورود صدها فایل، هزینه اصلاح بعدی را کم می‌کند.
طراحی ساختار پروژه و نسخه
فرض کنید سرویس پرداخت هر هفته منتشر می‌شود و دو نسخه پشتیبانی‌شده دارد. ثبت همه انتشارها در یک پروژه با نام «آخرین» برای دیدن وضعیت جاری ساده است، اما امکان پیگیری دقیق نسخه قبلی را از بین می‌برد. ثبت پروژه جدا برای هر ساخت لحظه‌ای نیز می‌تواند مجموعه را چنان بزرگ کند که تشخیص نسخه‌های واقعاً مستقر دشوار شود. معیار را براساس چرخه پشتیبانی تعیین کنید. محصول‌هایی که هم‌زمان در اختیار چند مشتری هستند معمولاً به هویت نسخه پایدار نیاز دارند. ساخت‌های موقت باید چرخه نگه‌داری روشن داشته باشند.
در راهنمای شاخه چهارم، ارسال با شناسه یکتای پروژه توضیح داده شده و امکان استفاده از نام و نسخه نیز آمده است. ایجاد خودکار زمانی مناسب است که نام‌گذاری تحت کنترل باشد. اشتباه کوچک در حروف یا نام شاخه می‌تواند پروژه تازه ایجاد کند و تاریخچه یک محصول را میان چند رکورد تقسیم کند. در آغاز، پروژه‌ها را صریح بسازید و شناسه‌ها را در تنظیمات خط ساخت نگه دارید. پس از آزمون قرارداد نام‌گذاری، در صورت نیاز ایجاد خودکار را فقط به فرایندهایی بدهید که واقعاً اجازه افزودن پروژه دارند.
تولید صورت مواد در نقطه درست
فایل وابستگی مخزن، محیط ساخت و محصول نهایی می‌توانند سه مجموعه متفاوت از مؤلفه‌ها داشته باشند. ابزار تولید CycloneDX باید با اکوسیستم محصول سازگار باشد و در نقطه مناسب اجرا شود. برای یک سرویس کانتینری، بسته‌های سیستم‌عامل موجود در تصویر نهایی ممکن است در فهرست کتابخانه‌های زبان دیده نشوند. برای یک بسته جاوا، وابستگی‌های آزمون ممکن است در محصول نهایی حضور نداشته باشند. نخست مشخص کنید گزارش قرار است کدام دارایی را توصیف کند و سپس چند مؤلفه شناخته‌شده را در خروجی بررسی کنید.
هویت مؤلفه باید آن‌قدر دقیق باشد که تحلیل بتواند آن را به اطلاعات بیرونی وصل کند. نام کوتاه، نسخه مبهم و نبود اکوسیستم می‌توانند تطبیق را دشوار کنند. اگر یک مؤلفه داخلی با کتابخانه عمومی هم‌نام است، اطلاعات ناشر و شناسه بسته را در زنجیره تولید بررسی کنید. اصلاح دستی فایل پس از هر ساخت راهی پرهزینه و خطاپذیر است. بهتر است علت کمبود داده در ابزار تولید یا فراداده پروژه اصلاح شود تا همه انتشارهای آینده از همان بهبود بهره ببرند. فایل نمونه معتبر را برای آزمون تغییرات خط ساخت حفظ کنید.
ارسال فایل و حفاظت از کلید
در مستندات شاخه چهارم، ارسال فایل با کلید رابط و شناسه پروژه نشان داده شده است. یک روش فایل را در قالب درخواست چندبخشی می‌فرستد و روش دیگری محتوای کدگذاری‌شده را در بدنه ساخت‌یافته قرار می‌دهد. هنگام انتخاب روش، اندازه گزارش و امکانات ابزار خط ساخت را در نظر بگیرید. برای فایل بزرگ، عبور مستقیم فایل از مسیر امن معمولاً خواناتر از ساخت دستی یک رشته بسیار طولانی است. پاسخ سرور و شناسه پیگیری را ذخیره کنید تا در صورت شکست پردازش بتوان مسیر درخواست را پیدا کرد.
کلید رابط باید متعلق به فرایند ارسال باشد و فقط مجوز لازم را داشته باشد. از قرار دادن مقدار آن در فایل مخزن، گزارش خطا یا فرمان چاپ‌شده خودداری کنید. کانال انتقال را با هویت سرور معتبر تنظیم کنید، به ویژه اگر فهرست نام مؤلفه‌های داخلی یا سرویس‌های خصوصی را افشا می‌کند. موفقیت ارسال داده را از پایان تحلیل تفکیک کنید. پاسخ موفق رابط می‌تواند فقط به معنی پذیرش درخواست باشد. برای کنترل انتشار، شرایطی تعریف کنید که نشان دهد پروژه درست به‌روز شده و نتیجه مربوط به همان فهرست آماده بررسی است.
تحلیل مداوم محصولی که تغییر نکرده است
ممکن است محصول سه ماه بدون تغییر باقی بماند و امروز به دلیل انتشار داده جدید نیازمند اقدام شود. Dependency-Track برای همین وضعیت مؤلفه‌های مجموعه را دوباره تحلیل می‌کند. راهنمای شاخه چهارم از تحلیل هنگام ورود یا تغییر مؤلفه و بررسی دوره‌ای خودکار صحبت می‌کند. بنابراین خط ساخت تنها نقطه دریافت هشدار نیست. مسئول محصول قدیمی نیز باید اعلان مرتبط را دریافت کند و مسیر اصلاح یا بازنشستگی محصول روشن باشد. محصولی که دیگر پشتیبانی نمی‌شود ولی هنوز مستقر است باید در فهرست دارایی‌های در معرض باقی بماند.
وقتی نتیجه تازه ظاهر شد، ابتدا نسخه و هویت مؤلفه را تأیید کنید. سپس اطلاعیه اولیه را بخوانید و شرایط اثرگذاری را با معماری محصول بسنجید. وجود یک بسته در فهرست به تنهایی اولویت عملیاتی یکسان برای همه مصرف‌کنندگان ایجاد نمی‌کند. یک سرویس عمومی ورودی نامطمئن را پردازش می‌کند، در حالی که محصول دیگر همان کتابخانه را فقط برای تولید مستندات به کار می‌گیرد. شواهد این تفاوت باید در تحلیل ثبت شوند تا مسئول بعدی بداند چرا اقدام‌ها متفاوت بوده‌اند و چه تغییری ممکن است تصمیم را عوض کند.
ممیزی، سیاست و اطلاع‌رسانی
گردش ممیزی کمک می‌کند نتیجه فنی از تصمیم تیم جدا بماند. ثبت کنید چه کسی یافته را بررسی کرده، به کدام نسخه اشاره داشته و چه شواهدی برای نتیجه وجود دارد. اگر محصول در شرایط بررسی‌شده تحت تأثیر نیست، محدوده استدلال را روشن کنید. انتقال همان تصمیم به نسخه‌ای که پیکربندی متفاوت دارد می‌تواند اشتباه باشد. اگر تیم به دلیل نبود وصله موقتاً ریسک را می‌پذیرد، موعد بازبینی و کنترل موقت را ثبت کند. این وضعیت با خطای شناسایی مؤلفه فرق دارد و پیگیری متفاوتی می‌خواهد.
سامانه از سیاست‌های مربوط به ریسک امنیتی و مجوز مؤلفه‌ها پشتیبانی می‌کند. برای شروع، سیاستی کوچک با اقدام مشخص انتخاب کنید. به عنوان مثال، ورود مجوزی که نیاز به بررسی حقوقی دارد باید به مسئول همان فرایند برسد. اطلاعات مجوز در صورت مواد، ورودی بررسی است و تصمیم حقوقی به قرارداد و نحوه توزیع محصول وابسته می‌ماند. برای هشدار امنیتی نیز مسیر اعلان را براساس مالک محصول تنظیم کنید. فرستادن همه پیام‌ها به یک کانال شلوغ باعث می‌شود دریافت پیام با پذیرش مسئولیت اشتباه گرفته شود.
تشخیص داده ناقص و پروژه اشتباه
اگر داشبورد ناگهان مؤلفه‌های کمتری نشان داد، ابتدا فهرست ورودی پیش و پس از تغییر را مقایسه کنید. ابزار تولید، مرحله ساخت و شناسه پروژه را بررسی کنید. ممکن است فایل یک ماژول آزمایشی روی پروژه محصول کامل بارگذاری شده باشد. تعداد کمتر مؤلفه تنها زمانی نشانه بهبود است که کاهش در بسته واقعی نیز تأیید شده باشد. فایل اصلی، شناسه ساخت و پاسخ ارسال را کنار هم نگه دارید. این اطلاعات مسیر عیب‌یابی را کوتاه می‌کنند و نیاز به حدس درباره رفتار سرور را کاهش می‌دهند.
اگر پروژه‌ای از تحلیل جا مانده است، سه زمان را جدا کنید. آخرین ساخت محصول، آخرین دریافت فهرست و آخرین تحلیل موفق ممکن است با هم فرق داشته باشند. شاید محصول واقعاً تغییری نکرده، شاید ارسال از خط ساخت متوقف شده یا شاید منبع داده بیرونی به‌روز نمی‌شود. مسئول هر مشکل متفاوت است. شاخص پایش باید بتواند این تفاوت را نشان دهد. برای محصول حساس، یک وابستگی کنترل‌شده و مورد انتظار را دوره‌ای جست‌وجو کنید تا از سلامت مسیر تولید، ارسال، پردازش و نمایش اطمینان بیشتری داشته باشید.
تمرین واکنش با محصولات واقعی
یک تمرین داخلی طراحی کنید که با اعلام فرضی یک مشکل در مؤلفه‌ای شناخته‌شده آغاز شود. تحلیلگر باید پروژه‌های دارای آن مؤلفه را پیدا کند، نسخه‌های مستقر را از محصول‌های کنار گذاشته‌شده جدا کند و مسئول هر اصلاح را مشخص کند. تیم توسعه بسته تازه‌ای بسازد و صورت مواد آن را بفرستد. سپس تیم عملیات تأیید کند که نسخه مستقر همان نسخه اصلاح‌شده است. زمان انجام هر مرحله نشان می‌دهد کندی از کیفیت فهرست، نام‌گذاری پروژه، پاسخ مالک یا فرایند تحویل ناشی می‌شود.
در پایان تمرین، دو عدد را کنار هم ببینید. چند محصول تحت پشتیبانی فهرست قابل اعتماد دارند و برای چند یافته مهم تصمیمی با مالک و شواهد ثبت شده است؟ درصد پوشش بدون کیفیت هویت مؤلفه می‌تواند تصویر خوش‌بینانه بسازد و تعداد یافته بدون شناخت مالک نیز پاسخ را سریع‌تر نمی‌کند. وقتی تیم بتواند از اطلاعیه یک کتابخانه به نسخه محصول، شواهد تحلیل و تحویل اصلاح برسد، مجموعه Dependency-Track برای تصمیم عملیاتی آماده است. این مسیر با چند پروژه نماینده آغاز می‌شود و پس از آزمون قرارداد داده می‌تواند در سراسر سازمان گسترش یابد.
