گذشته از باگها و قابلیتهای جدید، ماندگاری یک پروژه نه تنها به مفید بودن آن، بلکه به اعتمادی که از کاربرانش کسب میکند بستگی دارد. اقدامات امنیتی قوی برای زنده نگه داشتن این اعتماد مهم هستند. در اینجا برخی از اقدامات مهمی که میتوانید برای بهبود چشمگیر امنیت پروژه خود انجام دهید آورده شده است.
اطمینان حاصل کنید که همه مشارکتکنندگان دارای دسترسی، احراز هویت چندعاملی (MFA) را فعال کردهاند
یک بازیگر مخرب که موفق به جعل هویت یک مشارکت کننده دارای دسترسی در پروژه شما شود، خسارات فاجعهباری به بار خواهد آورد.
پس از به دست آوردن دسترسی privileged، این بازیگر میتواند کد شما را تغییر دهد تا اقدامات ناخواسته انجام دهد (مانند استخراج ارز دیجیتال)، یا میتواند بدافزار را به زیرساخت کاربران شما توزیع کند، یا میتواند به مخازن کد خصوصی دسترسی یابد تا مالکیت فکری و دادههای حساس، از جمله اعتبارنامههای سرویسهای دیگر را سرقت کند.
MFA یک لایه امنیتی اضافی در برابر تصاحب حساب ارائه میدهد. پس از فعالسازی، باید با نام کاربری و رمز عبور خود وارد شوید و شکل دیگری از احراز هویت را ارائه دهید که فقط شما آن را میدانید یا به آن دسترسی دارید.
کد خود را به عنوان بخشی از گردش کار توسعه خود ایمن کنید
رفع آسیبپذیریهای امنیتی در کد شما، در صورت تشخیص زودهنگام در فرآیند، بسیار کمهزینهتر از زمانی است که در محیط production استفاده میشوند.
از یک ابزار Static Application Security Testing (SAST) برای تشخیص آسیبپذیریهای امنیتی در کد خود استفاده کنید. این ابزارها در سطح کد عمل میکنند و به محیط اجرایی نیاز ندارند، و بنابراین میتوانند در مراحل اولیه فرآیند اجرا شوند و به طور یکپارچه در گردش کار توسعه معمول شما، در طول مرحله build یا مرور کد، ادغام شوند.
این مانند داشتن یک متخصص ماهر است که مخزن کد شما را بررسی میکند و به شما کمک میکند آسیبپذیریهای امنیتی رایجی که ممکن است در حین کدنویسی در معرض دید باشند را پیدا کنید.
چگونه ابزار SAST خود را انتخاب کنیم؟
- مجوز را بررسی کنید: برخی ابزارها برای پروژههای متنباز رایگان هستند. برای مثال GitHub CodeQL یا SemGrep.
- پوشش زبان(های) برنامهنویسی خود را بررسی کنید.
- ابزاری را انتخاب کنید که به راحتی با ابزارها و فرآیندهای موجود شما ادغام میشود. برای مثال، بهتر است که هشدارها به عنوان بخشی از فرآیند و ابزار مرور کد موجود شما در دسترس باشند، نه اینکه برای مشاهده آنها به ابزار دیگری مراجعه کنید.
- مراقب هشدارهای کاذب (False Positives) باشید! شما نمیخواهید ابزار بدون دلیل شما را کند کند!
- ویژگیها را بررسی کنید: برخی ابزارها بسیار قدرتمند هستند و میتوانند ردیابی نشت داده (Taint Tracking) انجام دهند (مثال: GitHub CodeQL)، برخی پیشنهادات رفع مشکل تولید شده توسط هوش مصنوعی ارائه میدهند، و برخی نوشتن کوئریهای سفارشی را آسانتر میکنند (مثال: SemGrep).
اسرار خود را به اشتراک نگذارید
دادههای حساس، مانند کلیدهای API، توکنها و رمزهای عبور، گاهی اوقات ممکن است به طور تصادفی در مخزن شما commit شوند.
این سناریو را تصور کنید: شما maintainer یک پروژه متنباز محبوب با مشارکت توسعهدهندگان از سراسر جهان هستید. یک روز، یک مشارکتکننده ناخواسته برخی از کلیدهای API یک سرویس شخص ثالث را در مخزن commit میکند. روزها بعد، شخصی این کلیدها را پیدا میکند و از آنها برای دسترسی غیرمجاز به سرویس استفاده میکند. سرویس به خطر میافتد، کاربران پروژه شما downtime را تجربه میکنند و اعتبار پروژه شما آسیب میبیند. به عنوان maintainer، اکنون با وظایف دلهرهآور لغو اسرار به خطر افتاده، بررسی اقدامات مخربانهای که مهاجم میتوانسته با این راز انجام دهد، اطلاعرسانی به کاربران affected و اجرای وصلهها روبرو هستید.
برای جلوگیری از چنین حوادثی، راهحلهای “اسکن اسرار” (secret scanning) وجود دارند که به شما در تشخیص این اسرار در کدتان کمک میکنند. برخی ابزارها مانند GitHub Secret Scanning و Trufflehog از Truffle Security اساساً از push شدن آنها به شاخههای remote جلوگیری میکنند، و برخی ابزارها به طور خودکار برخی اسرار را برای شما لغو میکنند.
وابستگیهای خود را بررسی و بهروز کنید
وابستگیهای موجود در پروژه شما میتوانند دارای آسیبپذیریهایی باشند که امنیت پروژه شما را به خطر میاندازند. بهروز نگه داشتن دستی وابستگیها میتواند کاری وقتگیر باشد.
این را تصور کنید: پروژهای که بر اساس بنیان محکم یک کتابخانه پرکاربرد ساخته شده است. این کتابخانه بعداً یک مشکل امنیتی بزرگ پیدا میکند، اما افرادی که برنامه را با استفاده از آن ساختهاند از آن اطلاعی ندارند. دادههای حساس کاربر در معرض دید قرار میگیرند وقتی یک مهاجم از این ضعف سوء استفاده کرده و آنها را میدزدد. این یک مورد نظری نیست. این دقیقاً چیزی است که برای Equifax در سال ۲۰۱۷ اتفاق افتاد: آنها پس از اعلام تشخیص یک آسیبپذیری شدید، وابستگی Apache Struts خود را بهروز نکردند. از آن سوء استفاده شد و نقض دادههای معروف Equifax 144 میلیون کاربر را تحت تاثیر قرار داد.
برای جلوگیری از چنین سناریوهایی، ابزارهای Software Composition Analysis (SCA) مانند Dependabot و Renovate به طور خودکار وابستگیهای شما را برای یافتن آسیبپذیریهای شناخته شده منتشر شده در پایگاههای داده عمومی مانند NVD یا GitHub Advisory Database بررسی میکنند و سپس pull requestهایی برای بهروزرسانی آنها به نسخههای ایمن ایجاد میکنند. بهروز ماندن با آخرین نسخههای ایمن وابستگیها، پروژه شما را در برابر خطرات بالقوه محافظت میکند.
از تغییرات ناخواسته با شاخههای محافظت شده (protected branches) جلوگیری کنید
دسترسی بدون محدودیت به شاخههای اصلی شما میتواند منجر به تغییرات تصادفی یا مخرب شود که ممکن است آسیبپذیریها را معرفی کرده یا ثبات پروژه شما را مختل کنند.
یک مشارکتکننده جدید دسترسی write به شاخه اصلی دریافت میکند و به طور تصادفی تغییراتی را که تست نشدهاند push میکند. یک نقص امنیتی فاجعهبار سپس آشکار میشود، به لطف آخرین تغییرات. برای جلوگیری از چنین مشکلاتی، قوانین محافظت از شاخه (branch protection rules) تضمین میکنند که تغییرات نمیتوانند به شاخههای مهم push یا merge شوند مگر اینکه ابتدا مرور شده و بررسیهای وضعیت مشخص شده را پشت سر بگذارند. با این اقدام اضافی در امانتر و در موقعیت بهتری هستید و هر بار کیفیت عالی را تضمین میکنید.
یک مکانیزم دریافت برای گزارشدهی آسیبپذیری راهاندازی کنید
این یک روش خوب است که گزارش باگ را برای کاربران خود آسان کنید، اما سوال بزرگ این است: وقتی این باگ تاثیر امنیتی دارد، چگونه میتوانند آن را به طور ایمن به شما گزارش دهند بدون اینکه شما را در معرض هدف هکرهای مخرب قرار دهند؟
این را تصور کنید: یک محقق امنیتی یک آسیبپذیری در پروژه شما کشف میکند اما راه روشن یا ایمنی برای گزارش آن پیدا نمیکند. بدون یک فرآیند مشخص شده، ممکن است یک issue عمومی ایجاد کند یا در مورد آن به طور آشکار در رسانههای اجتماعی بحث کند. حتی اگر خوشنیت باشند و یک وصله ارائه دهند، اگر آن را با یک pull request عمومی انجام دهند، دیگران قبل از merge شدن آن را خواهند دید! این افشای عمومی، آسیبپذیری را قبل از اینکه شما فرصت رسیدگی به آن را داشته باشید در معرض دید بازیگران مخرب قرار میدهد و به طور بالقوه منجر به یک اکسپلویت zero-day شده و پروژه شما و کاربرانش را مورد حمله قرار میدهد.
خطمشی امنیتی (Security Policy)
برای اجتناب از این، یک خطمشی امنیتی منتشر کنید. یک خطمشی امنیتی، که در یک فایل SECURITY.md تعریف میشود، مراحل گزارش نگرانیهای امنیتی را به تفصیل شرح میدهد، یک فرآیند شفاف برای افشای هماهنگ شده ایجاد میکند و مسئولیتهای تیم پروژه را برای رسیدگی به issues گزارش شده تعیین میکند. این خطمشی امنیتی میتواند به سادگی این باشد: “لطفاً جزئیات را در یک issue یا PR عمومی منتشر نکنید، یک ایمیل خصوصی به ما به آدرس security@example.com ارسال کنید”، اما میتواند حاوی جزئیات دیگری نیز باشد، مانند زمانی که باید انتظار دریافت پاسخ از شما را داشته باشند. هر چیزی که میتواند به اثربخشی و کارایی فرآیند افشا کمک کند.
گزارشدهی خصوصی آسیبپذیری (Private Vulnerability Reporting)
در برخی پلتفرمها، میتوانید فرآیند مدیریت آسیبپذیری خود را از دریافت تا انتشار، با استفاده از issues خصوصی، سادهتر و تقویت کنید. در GitLab، این کار را میتوان با issues خصوصی انجام داد. در GitHub، این کار گزارشدهی خصوصی آسیبپذیری (PVR) نامیده میشود. PVR به maintainers امکان میدهد گزارشهای آسیبپذیری را دریافت کرده و رسیدگی کنند، همه در داخل پلتفرم GitHub. GitHub به طور خودکار یک fork خصوصی برای نوشتن وصلهها و یک security advisory پیشنویس ایجاد میکند. همه اینها محرمانه باقی میمانند تا زمانی که شما تصمیم به افشای issues و انتشار وصلهها بگیرید. برای تکمیل فرآیند، security advisoryها منتشر میشوند و از طریق ابزار SCA به همه کاربران شما اطلاع رسانی کرده و آنها را محافظت میکنند.
نتیجهگیری: چند قدم برای شما، یک بهبود بزرگ برای کاربران شما
این چند قدم ممکن است برای شما آسان یا ابتدایی به نظر برسند، اما راه زیادی را برای ایمنتر کردن پروژه شما برای کاربرانش طی میکنند، زیرا در برابر رایجترین مسائل محافظت ارائه میدهند.
مشارکتکنندگان
با تشکر از همه maintainerهایی که تجربیات و نکات خود را برای این راهنما با ما به اشتراک گذاشتند!
این راهنما توسط @nanzggits & @xcorail نوشته شده است با مشارکت:
@JLLeitschuh @intrigus-lgtm + بسیاری دیگر!