برنامه نویسی

امنیت قبل از استقرار تولید شروع می شود

به عنوان یک توسعه‌دهنده، ویژگی‌های جدید ایجاد می‌کنید، اشکالات را برطرف می‌کنید و کد ارسال می‌کنید. این همان چیزی است که شرح شغل اصلی شامل می شود. امروزه توسعه‌دهندگان نرم‌افزار مسئولیت‌های دیگری مانند تخصص در استقرار یا تأمین امنیت نرم‌افزار را بر عهده دارند. شما می توانید یک مورد قانع کننده ایجاد کنید که امنیت یک دغدغه فقط تولید است. تا زمانی که روی ویژگی های خود کار می کنید،
امنیت ضروری نیست (هنوز). اما اگر مسائل امنیتی در تولید به وجود بیاید چه؟ این نوع بلیط ها به مهندسی باز می گردند و هر کاری را که انجام می دهید قطع می کنند. در حالی که این موقعیت‌ها می‌توانند در هر زمان اتفاق بیفتند، شما می‌توانید در وهله اول نقش فعالی در پیشگیری از آنها ایفا کنید – نتیجه: بلیط‌ها و وقفه‌های با اولویت بالا کمتر.

در این پست وبلاگ، بیایید ابزارهایی را بررسی کنیم که می‌توانید از آنها برای فعال بودن در مورد دسته‌ای از حوادث امنیتی استفاده کنید.

در اینجا در مورد چه مسائل امنیتی صحبت می کنیم؟

در چند سال گذشته، شرکت‌هایی مانند GitHub سرمایه‌گذاری زیادی در ایجاد امنیت نرم‌افزار انجام داده‌اند. Dependabot به طور خودکار لیست های وابستگی شما را اسکن می کند (به عنوان مثال، package.json) و اگر از نسخه کتابخانه آسیب پذیر استفاده می کنید، درخواست های کشش را ارسال می کند. از آنجایی که این یک گردش کاری کم تلاش است، توسعه دهندگان می توانند به سرعت بسته های آسیب پذیر را به عنوان بخشی از گردش کار معمولی خود وصله کنند.

در این پست وبلاگ، می خواهیم جنبه دیگری از امنیت نرم افزار را روشن کنیم: زمان اجرای تولید. اگر در حال ساختن Docker Images به عنوان بخشی از گردش کار CI/CD خود هستید، این پست وبلاگ برای شما مناسب است. مهم نیست که از چه استراتژی ساخت خاصی برای تصاویر خود استفاده می کنید، احتمالاً بسته های اضافی را نصب می کنید تا مطمئن شوید کد شما بدون مشکل اجرا می شود.

تصاویر Docker ناامن؟

آیا تا به حال به امنیت تصاویر Docker که در مراحل تولید اجرا می کنید فکر کرده اید؟ اگر از تصویر LTS فعلی اوبونتو استفاده کنیم، آن را دارد 106 بسته های نصب شده:

docker run --rm ubuntu:jammy dpkg -l | wc -l
  106
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

از اوبونتو استفاده نمی کنید؟ Alpine فقط 15 بسته از پیش نصب شده دارد:

docker run --rm alpine:latest apk list -i | wc -l
      15
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اگر یک تصویر Docker دارای 15 یا بیش از 100 بسته نصب شده باشد، هر یک از این بسته ها به طور بالقوه می تواند در برابر حمله آسیب پذیر باشد. اگر فکر می کنید، “بسیار خوب، وقتی گزارشی را در اخبار ببینم، وصله می کنم” (مانند Heartbleed یا Log4Shell)، بیشتر فرصت های پچ را “از دست داده اید”. اکثر آسیب‌پذیری‌های امنیتی (شدید) در صفحه اول لیست اخبار هکر قرار نمی‌گیرند.

نیازی به مرور دستی پایگاه داده CVE نیست. در عوض، می‌توانیم به سمت گردش کاری که شبیه Dependabot GitHub است کار کنیم. می‌توانیم تصاویر Docker را در حین ساخت اسکن کنیم تا متوجه شویم بسته‌های آسیب‌پذیری وجود دارد یا خیر و آن‌ها را وصله کنیم. در حالی که ما هرگز به امنیت 100% نخواهیم رسید،
ما با یک فرآیند سربار کم به یک قدم نزدیکتر می شویم.

نحوه اسکن تصاویر داکر

معرفی KubeClarity KubeClarity یک پروژه منبع باز است که به شما کمک می کند نرم افزار ایمن تر ارسال کنید. در حالی که KubeClarity موارد استفاده مختلف را پوشش می دهد، بیایید فعلاً روی اسکن تصویر تمرکز کنیم.

نصب و راه اندازی

برای یافتن دستورالعمل‌های نصب برای پلتفرم خاص خود، KubeClarity README را بررسی کنید. در این
آموزش، ما عمدتا از CLI استفاده می کنیم، اما با خیال راحت داشبورد را برای تجسم نصب کنید.

تصویر خود را اسکن کنید

برای نشان دادن اسکن تصویر، از این مخزن استفاده می کنیم.
حاوی نمونه کار Rust با نسخه آسیب پذیر OpenSSL. دستور زیر را اجرا کنید:

kubeclarity-cli scan ghcr.io/schultyy/rust-workload:0.0.3 --input-type image -o table
NAME           INSTALLED               FIXED-IN          VULNERABILITY     SEVERITY    SCANNERS
perl-base      5.28.1-6+deb10u1                          CVE-2023-31484    HIGH        grype
libgcc1        1:8.3.0-6                                 CVE-2018-12886    HIGH        grype
libsystemd0    241-7~deb10u9                             CVE-2019-3844     HIGH        grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u4  CVE-2023-0215     HIGH        grype
ncurses-base   6.1+20181013-2+deb10u3                    CVE-2023-29491    HIGH        grype
libudev1       241-7~deb10u9                             CVE-2019-3844     HIGH        grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u5  CVE-2023-0464     HIGH        grype
libstdc++6     8.3.0-6                                   CVE-2019-15847    HIGH        grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u5  CVE-2023-2650     HIGH        grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u4  CVE-2023-0286     HIGH        grype
libc-bin       2.28-10+deb10u2                           CVE-2020-1751     HIGH        grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u4  CVE-2022-4450     HIGH        grype
libss2         1.44.5-1+deb10u3                          CVE-2022-1304     HIGH        grype
libsystemd0    241-7~deb10u9                             CVE-2021-3997     MEDIUM      grype
libsystemd0    241-7~deb10u9                             CVE-2022-3821     MEDIUM      grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u5  CVE-2023-0466     MEDIUM      grype
libudev1       241-7~deb10u9                             CVE-2022-3821     MEDIUM      grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u4  CVE-2022-2097     MEDIUM      grype
libudev1       241-7~deb10u9                             CVE-2021-3997     MEDIUM      grype
libsystemd0    241-7~deb10u9                             CVE-2022-4415     MEDIUM      grype
libudev1       241-7~deb10u9                             CVE-2022-4415     MEDIUM      grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u4  CVE-2022-4304     MEDIUM      grype
openssl        1.1.1n-0+deb10u3        1.1.1n-0+deb10u5  CVE-2023-0465     MEDIUM      grype
libpcre3       2:8.39-12                                 CVE-2020-14155    MEDIUM      grype
libgcrypt20    1.8.4-5+deb10u1                           CVE-2019-13627    MEDIUM      grype
login          1:4.5-1.1                                 CVE-2023-29383    LOW         grype
bsdutils       1:2.33.1-0.1                              CVE-2021-37600    LOW         grype
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

(خروجی برای اختصار کوتاه شد)

را kubeclarity scan فرمان لیستی از بسته هایی را که CVE برای آنها ثبت شده است، خروجی می دهد. openssl چندین بار با نسخه ای که مشکل را برطرف می کند (نگاه کنید به FIXED-IN ستون).

رفع بسته های آسیب پذیر

باز کن Dockerfile و به خط 19 بروید. خط 19 در حال حاضر یک خاص نصب می کند openssl نسخه:

RUN apt-get update && apt-get install -y openssl=1.1.1n-0+deb10u3 && rm -rf /var/lib/apt/lists/*
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این خط را به روز کنید تا آخرین نسخه را مطابق با نصب کنید kubeclarity-cli نتیجه اسکن:

RUN apt-get update && apt-get install -y openssl=1.1.1n-0+deb10u5 && rm -rf /var/lib/apt/lists/*
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

نشان داد که مشکلات متعاقبا برطرف خواهد شد
1.1.1n-0+deb10u4 و 1.1.1n-0+deb10u5. بنابراین، ما با آخرین نسخه موجود پیش خواهیم رفت.

بیایید یک تصویر جدید بسازیم:

docker build -t ghcr.io/schultyy/rust-workload:0.0.4 .
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

برای تأیید اینکه مشکل برطرف شده است، KubeClarity را دوباره اجرا می کنیم، این بار با LOCAL_IMAGE_SCAN=true مجموعه متغیر ما می‌خواهیم قبل از فشار دادن تصویر محلی خود را اسکن کنیم و تأیید کنیم که OpenSSL هیچ آسیب‌پذیری برجسته‌ای ندارد:

LOCAL_IMAGE_SCAN=true kubeclarity-cli scan ghcr.io/schultyy/rust-workload:0.0.4 --input-type image -o table | grep openssl
 openssl        1.1.1n-0+deb10u5                  CVE-2010-0928     NEGLIGIBLE  grype
 openssl        1.1.1n-0+deb10u5                  CVE-2007-6755     NEGLIGIBLE  grype..
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اسکن هنوز دو فهرست را نشان می دهد openssl ورودی ها، هر چند فقط با شدت NEGLIGIBLE. بنابراین مشکل برطرف شده است.

بعدش چی؟

KubeClarity را بررسی کنید
مخزن GitHub برای آشنایی با موارد استفاده اضافی، و مطمئن شوید که مخزن را ستاره دار کنید!

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا