لایحه مواد نرم افزار (SBOM) چیست؟

لایحه مواد نرم افزار (SBOM) یک لیست دقیق و جامع از تمام اجزای موجود در یک برنامه نرم افزاری، از جمله استفاده از نرم افزار منبع باز، وابستگی های قطعات، مجوزها و آسیب پذیری های شناخته شده است. SBOM ها فهرستی از هر جزء جداگانه ای را که شامل برنامه است ارائه می دهند، بسیار شبیه به لیستی از مواد تشکیل دهنده در یک دستور غذا. SBOM ها در سال 2018 به عنوان یک تلاش مشترک توسط جامعه امنیت اطلاعات مورد توجه قرار گرفتند و تا حد زیادی توسط اداره ملی ارتباطات و اطلاعات (NTIA) و دولت ایالات متحده در سال های اخیر هدایت شده اند.

SBOM ها اسناد بسیار مهمی هستند که اطلاعات مهمی را برای سازمان هایی که به دنبال به حداقل رساندن و کاهش ریسک های زنجیره تامین عملیاتی، قانونی و نرم افزاری خود هستند، ارائه می دهند، اما بسیاری از سازمان ها هنوز در پیاده سازی SBOM ها در فرآیندهای موجود خود با چالش هایی روبرو هستند یا از مزایای آنها بی اطلاع هستند. این مقاله به بررسی این موضوع می پردازد که چگونه SBOM ها می توانند به سازمان ها کمک کنند تا در مورد نرم افزاری که استفاده می کنند اطلاعات بهتری کسب کنند و چرا SBOM ها باید به عنوان بهترین روش اتخاذ شوند.

دریابید که چگونه UpGuard به کسب و کارها کمک می کند تا دید بهتری از آسیب پذیری های نرم افزاری خود >

چرا SBOM ها مهم هستند؟

از آنجایی که کسب و کار متوسط از بیش از 130 برنامه SaaS در عملیات روزانه استفاده می کند و شرکت های بزرگتر ممکن است روزانه از بیش از 200 برنامه استفاده کنند، SBOM ها برای کاهش خطرات امنیتی ضروری تر می شوند. هرچه یک سازمان روزانه از برنامه های کاربردی بیشتری استفاده کند، سازمان با ریسک بیشتری مواجه می شود. اگر یک برنامه یا جزء به دلیل آسیب پذیری نقض شود، به طور بالقوه می تواند کل زنجیره تامین نرم افزار را به خطر بیندازد.

SBOM ها به سازمان ها کمک می کنند تا خطرات عملیاتی و امنیتی مرتبط با نرم افزارهای خاص را شناسایی کنند و همچنین دید بیشتری در ترکیبات نرم افزاری به دست آورند. سازمان ها می توانند آسیب پذیری ها را بهتر مدیریت کنند، از مجوزها پیروی کنند و سایر وظایف مهم مدیریت نرم افزار را با دانستن دقیق آنچه در داخل یک محصول نرم افزاری وجود دارد، انجام دهند. SBOM ها در حال تبدیل شدن به ابزاری مهم در دنیای امنیت سایبری، چرخه عمر توسعه نرم افزار (SDLC) و فرآیندهای DevSecOps هستند.

در ماه مه 2021، دولت فدرال ایالات متحده فرمان اجرایی 14028 را صادر کرد که همه سازمان های دولتی ایالات متحده را ملزم می کند فقط با فروشندگان نرم افزاری که SBOM ها را ارائه می دهند، معامله کنند. این قانون جدید بخشی از تلاش بزرگتر امنیت سایبری برای ایمن سازی زیرساخت های دیجیتال کشور و هدایت فروشندگان نرم افزار بیشتر برای اطمینان از ساخت ایمن محصولات بود. EO 14028 همچنین فروشندگان را تشویق می کند تا استانداردهای امنیت سایبری فدرال را رعایت کنند، زیرا قراردادهای دولتی به طور بالقوه فرصت های سودآور هستند.

برنامه ها و سرویس های نرم افزاری مدرن با مؤلفه ها و وابستگی های مختلف از منابع مختلف ساخته می شوند. این اجزا و وابستگی ها ممکن است شامل نرم افزار منبع باز، کد اختصاصی، API های سفارشی، چارچوب های زبان برنامه نویسی و کتابخانه های نرم افزاری باشد. کل منابعی که برنامه های نرم افزاری را تشکیل می دهند بخشی از زنجیره تأمین نرم افزار در نظر گرفته می شوند.

یک صورتحساب نرم افزار با ابرداده نرم افزار متفاوت است زیرا ابرداده نرم افزار ممکن است اطلاعات بیشتری در مورد استفاده گسترده تر و هدف برنامه ارائه دهد، در حالی که SBOM ها بر اجزای فردی درون برنامه و وابستگی های آنها تمرکز می کنند.

سازمان ها همچنین برای رسیدگی به موارد زیر به SBOM های خود متکی هستند:

انطباق قانونی
عملکرد امنیت سایبری
مدیریت ریسک
پاسخ به حادثه
کارایی عملیاتی
مدیریت آسیب پذیری

SBOM ها شامل چه مواردی می شوند؟

اداره ملی ارتباطات و اطلاعات (NTIA) دستورالعمل هایی را صادر کرد که حداقل عناصر برای SBOM را شرح می دهد، از جمله حوزه های اساسی زیر:

نام و نسخه های مؤلفه: هر جزء نرم افزار باید شناسایی و فهرست شود، از جمله نام، شماره نسخه، اطلاعات مجوز، نام تامین کننده، نویسنده و مهر زمانی برای زمان تولید داده های SBOM. این اطلاعات به سازمان ها اجازه می دهد تا اطمینان حاصل کنند که از جدیدترین و امن ترین نسخه های هر جزء استفاده می کنند. اگر یک جزء یا جزء فرعی به روز شود، SBOM باید به روز شود و دوباره صادر شود.
وابستگی های نرم افزاری: SBOM باید شامل درخت وابستگی بین اجزای نرم افزار، از جمله وابستگی های گذرا، برای حفظ عملکرد نرم افزار و پشتیبانی از شیوه های مدیریت وابستگی کارآمد باشد. اگر یک وابستگی تغییر کند یا یک جزء قدیمی شود، SBOM باید به روز شود تا چنین تغییراتی را منعکس کند.
اتوماسیون: NTIA حداقل سطوح اتوماسیون را برای تولید SBOM و انتقال داده ها توصیه می کند تا سایر سیستم ها بتوانند داده های SBOM تولید شده را درک کرده و از آنها استفاده کنند. از آنجایی که برنامه های نرم افزاری می توانند بسیار پیچیده باشند، NTIA اکیدا توصیه می کند که با استفاده از فرآیندهای دستی SBOM تولید نکنید.
فرآیندها: SBOM ها به فرآیندهای جمع آوری داده مداوم نیاز دارند که نحوه تولید SBOM ها، نحوه دسترسی به آنها و اینکه چه کسی مجوز دسترسی به آنها را دارد، تعریف می کند.
مجوزهای نرم افزار منبع باز: اگر نرم افزار از مجوزهای نرم افزار منبع باز استفاده می کند، مهم است که نوع مجوز هر جزء و همچنین شرایط و ضوابط را مستند کنید تا از مشکلات قانونی جلوگیری شود. سازمان ها می توانند با پیگیری تمام مجوزها، اطمینان حاصل کنند که به شرایط و ضوابط تعیین شده توسط سازندگان مؤلفه پایبند هستند. علاوه بر این، داده های صدور مجوز سازمان ها را قادر می سازد تا آسیب پذیری ها یا سوء استفاده های کد منبع باز را ردیابی کرده و قبل از اینکه منجر به نقض سایبری شوند، آنها را اصلاح کنند.
آسیب پذیری های شناخته شده: فهرست کردن آسیب پذیری های امنیتی شناخته شده برای هر جزء به سازمان ها کمک می کند تا خطرات احتمالی را کاهش دهند و امنیت کلی نرم افزار خود را بهبود بخشند. این اطلاعات به تیم های فناوری اطلاعات اجازه می دهد تا به روزرسانی ها و وصله ها را برای حفظ یک محیط نرم افزاری امن اولویت بندی کنند.

فرمت های استاندارد SBOM

چند فرمت استاندارد برای ایجاد و اشتراک گذاری SBOM وجود دارد. فرمت های استاندارد سازگاری داده های SBOM را در سراسر زنجیره تامین نرم افزار فراهم می کند و شفافیت کامل و همکاری بین ذینفعان مختلف را ارتقا می دهد. رایج ترین فرمت های SBOM امروزه عبارتند از:

CycloneDX، توسعه یافته توسط پروژه امنیت برنامه های کاربردی وب باز (OWASP)
برچسب های شناسایی نرم افزار (SWID) ، توسعه یافته توسط NIST

تبادل داده بسته نرم افزاری (SPDX)، توسعه یافته توسط ISO/IEC تحت ISO/IEC 5962

مزایای پیاده سازی SBOM ها

پیاده سازی SBOM ها می تواند فرآیند دشواری باشد، اما می تواند مزایای زیادی را به همراه داشته باشد که می تواند به سازمان ها کمک کند تا امنیت خود را بهتر حفظ کنند و خطرات را در دراز مدت به حداقل برسانند، از جمله:

وضعیت های امنیتی پیشرفته: SBOM ها عمق و دید بیشتری را در اجزای نرم افزاری ارائه می دهند که به سازمان ها کمک می کند تا آسیب پذیری های شناخته شده را شناسایی، ردیابی و اصلاح کنند.
انطباق با مجوز: SBOM ها به سازمان ها کمک می کنند تا با پیگیری تمام اجزای اختصاصی و منبع باز در حال استفاده، الزامات صدور مجوز را برآورده کنند. این اطلاعات مجوز همچنین به سازمان ها کمک می کند تا الزامات قانونی و استانداردهای نظارتی را برآورده کنند.
شفافیت زنجیره تامین: ایجاد شفافیت نرم افزار به ویژه برای سازمان ها با شروع مقیاس بندی مهم است. درک منبع هر محصول نرم افزاری به سازمان ها اجازه می دهد تا قابلیت اطمینان و امنیت هر جزء را به درستی ارزیابی کنند.
ممیزی های نرم افزاری کارآمد: ممیزی های نرم افزاری باید به طور منظم برای ارزیابی انطباق، اثربخشی، بحرانی بودن و ضرورت محصول انجام شود. SBOM ها با ارائه فهرستی جامع از هر جزء مورد استفاده، صرفه جویی در زمان و منابع مورد نیاز برای تکمیل حسابرسی، به تسهیل این فرآیند کمک می کنند.
مدیریت موثر ریسک و آسیب پذیری: ردیابی هر جزء مورد استفاده در برنامه های نرم افزاری به کسب و کارها اجازه می دهد تا خطرات بالقوه را شناسایی کرده و قبل از بهره برداری از آنها کاهش یا اصلاح کنند.

چالش های پیاده سازی SBOM ها

در حالی که SBOM ها می توانند به سازماندهی اکوسیستم فناوری اطلاعات یک کسب و کار کمک کنند، بسیاری از فرآیندها هنوز در حال استاندارد سازی و تعریف هستند. از آنجایی که هنوز تنوع در ایجاد و استفاده از SBOM وجود دارد، سازمان ها ممکن است برخی از چالش ها و ناکارآمدی های اولیه را تجربه کنند، مانند:

فرآیندهای پیچیده پیاده سازی و نگهداری: شرکت های بزرگتر که از طیف گسترده ای از محصولات نرم افزاری و پایگاه های کد استفاده می کنند، ممکن است در به دست آوردن SBOM برای هر برنامه با چالش های قابل توجهی مواجه شوند. به نوبه خود، تامین کنندگان نرم افزار نیز هنگام تولید SBOM ها وظیفه کار اضافی را بر عهده دارند، به خصوص زمانی که نرم افزار به روز می شود. محصولات نرم افزاری که اغلب به روز می شوند به این معنی است که SBOM ها نیز باید مرتبا به روز شوند.
عدم استانداردسازی: از آنجایی که SBOM ها هنوز یک روش نسبتا جدید هستند، هنوز مشکلات استانداردسازی وجود دارد که می تواند منجر به ناهماهنگی بین فرمت ها و مشکلات سازگاری بین انواع ابزارها و پلتفرم های مورد استفاده در طول تولید داده شود.
منابع بسیار فشرده: مقدار زیادی کار مورد نیاز برای تولید و نگهداری SBOM ها به این معنی است که تامین کنندگان باید زمان و منابع قابل توجهی را به این کار اختصاص دهند. علاوه بر این، پرسنل ویژه در هر تیم امنیتی باید آموزش ببینند، که می تواند برای سازمان های کوچکتر با اولویت های بالاتر چالش برانگیز باشد. سازمان هایی که از این نرم افزار استفاده می کنند همچنین به تیم ها یا افراد اختصاصی برای ردیابی SBOM ها نیاز دارند تا آنها را در فرآیندهای تدارکات و حسابرسی بگنجانند.
امنیت داده های SBOM: هر سند SBOM حاوی اطلاعات مهمی در مورد اجزای نرم افزار است که ممکن است منجر به فرصت های نقض جدید هم برای تامین کننده و هم برای سازمانی شود که از برنامه استفاده می کند. داده های SBOM باید محرمانه و ایمن نگه داشته شوند و فرآیندهای امنیتی داخلی جدید امنیت داده های آن را تعریف کنند.
فقدان قابلیت های ادغام: از آنجایی که SBOM ها هنوز یک روش رایج نیستند، ادغام فرآیندهای آن با توسعه و استقرار نرم افزار موجود ممکن است امکان پذیر نباشد یا بسیار چالش برانگیز باشد. با این حال، قابلیت های یکپارچه سازی نرم افزار بیشتری را می توان به دست آورد زیرا سازمان های بیشتری SBOM ها را در فرآیندهای خود اتخاذ می کنند.
مشارکت فروشنده: با توجه به اینکه سازمان ها به طور بالقوه با صدها یا هزاران فروشنده که برنامه های نرم افزاری را عرضه می کنند، کار می کنند، وادار کردن ارائه دهندگان شخص ثالث به اتخاذ فرآیندهای جدید و تولید SBOM های به روز شده و دقیق می تواند دشوار باشد، به خصوص اگر مزایا را نبینند یا احساس کنند که کار اضافی غیر ضروری است. علاوه بر این، ارائه دهندگان نرم افزار ممکن است نخواهند جزئیات اجزای سازنده را ارائه دهند، اگر احساس کنند که اطلاعات محرمانه و اختصاصی را فاش می کنند.