بر خلاف باور عموم، کانتینرهای داکر به خودی خود امن نیستند. بنابراین استفاده از ابزارها و اسکنرها برای خلاصی از نقاط آسیب‌پذیر در امنیت کانتینر ضروری است.
بسیاری از مردم فکر می‌کنند کانتینرها و ایمیج‌های داکر به صورت پیش‌فرض امن هستند، که - متاسفانه - درست نیست. موارد مختلفی در امنیت ایمیج‌های داکر تاثیرگذار است. اجزای مختلفی مثل پکیج‌های نصب شده در ایمیج، کتابخانه‌های مورد استفاده توسط اپلیکیشن یا حتی فایل اصلی ایمیج، ممکنه باعث ایجاد آسیب‌پذیری در اپلیکیشن شما بشن. هرچند بسیاری از این آسیب‌پذیری ها قابل پیش‌گیری هستند.
ابزارهای Anchore و Clair
ساده‌ترین راه برای پیدا کردن نقاط آسیب‌پذیر در ایمیج‌های داکر اجرای بازرسی (inspection) روی اون‌ها با استفاده از ابزارهای زیر است:
Anchore Engine
Anchore Engine یک سرویس مرکزی برای بازرسی، تحلیل و تصدیق ایمیج کانتینر است. این سرویس با استفاده از داده‌های توسعه دهنده‌های سیستم عامل مانند Red Hat، Debian یا Alpine در خصوص نقاط آسیب‌پذیر، ایمیج‌ها رو اسکن می‌کنه.
برای داده‌هایی که از سیستم عامل به دست نمیان، از NVD (National Vulnerability Database) یا مرکز اطلاعات آسیب‌پذیری ملی استفاده می‌کنه، که شامل آسیبپذیریهایی از RPM، Deb، APK و همین طور پایتون (PIP) و Ruby Gems و غیره است.
Clair
Clair یک تحلیلگر ثابته که توسط CoreOS برای کانتینرهای داکر و APPC توسعه داده شده. این ابزار برای تشخیص آسیب‌پذیری‌ها از فراداده‌ها منابع مورد استفاده Anchore استفاده می‌کنه - Red Hat Security Data, NVD, Ubuntu CVE Tracker, Alpine SecDB, Debian Security Bug Tracker و غیره.
آماده‌سازی
حالا که ابزارهای مورد استفاده رو شناختیم، وقتشه که اون‌ها رو آماده به کار کنیم. هر دو ابزار Anchore و Clair روش‌های مختلفی برای یکپارچه‌سازی دارن و می تونن در Kubernetes یا OpenShift مستقر بشن، اما برای دستیابی به هدف این مقاله ما این ابزارها را با استفاده از docker-compose بر روی یک ماشین مجازی محلی آماده به کار می‌کنیم:
برای تنظیم Anchore کد زیر رو اجرا کنین:
mkdir ~/aevolume
cd ~/aevolume
docker pull docker.io/anchore/anchore-engine:latest
docker create --name ae docker.io/anchore/anchore-engine:latest
docker cp ae:/docker-compose.yaml ~/aevolume/docker-compose.yaml
docker rm ae
docker-compose pull
docker-compose up -d
export ANCHORE_CLI_USER=admin
export ANCHORE_CLI_PASS=foobar
docker run --net=host -e ANCHORE_CLI_URL=http://localhost:8228/v1/ -it anchore/engine-cliبرای تنظیم Clair هم کد زیر را اجرا کنین:
# Download Clair Scanner from https://github.com/arminc/clair-scanner/releases
chmod +x clair-scanner
docker run -p 5432:5432 -d --name db arminc/clair-db:$(date +%F)
docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.6
و به این ترتیب ما آماده تحلیل هستیم!
نکته: کمی بعد در مقاله بیشتر در مورد Clair صحبت می‌کنیم.
بررسی ایمیج برای نقاط آسیب پذیری
بیایید با Anchore و یک ایمیج ساده Debian شروع کنیم. کاری که باید برای تحلیل ایمیج خودمون انجام بدیم اینه که ایمیج رو با دستور add اضافه کرده و صبر کنیم تا تحلیل کامل بشه:
# inside anchore-cli Docker container
~ $ anchore-cli image add docker.io/library/debian:latest
Image Digest: sha256:121dd2a723be1c8aa8b116684d66157c93c801f2f5107b60287937e88c13ab89
Parent Digest: sha256:a63d0b2ecbd723da612abf0a8bdb594ee78f18f691d7dc652ac305a490c9b71a
Analysis Status: analyzed
Image Type: docker
Analyzed At: 2020-03-07T10:46:20Z
Image ID: 971452c943760ab769134f22db8d3381b09ea000a6c459fbfa3603bb99115f62
Dockerfile Mode: Guessed
Distro: debian
Distro Version: 10
Size: 126607360
Architecture: amd64
Layer Count: 1
Full Tag: docker.io/library/debian:latest
Tag Detected At: 2020-03-07T10:45:48Z
~ $ anchore-cli image wait docker.io/library/debian:latest
Status: analyzing
Waiting 5.0 seconds for next retry.
...
~ $ anchore-cli image list
Full Tag Image Digest Analysis Status
docker.io/library/debian:latest sha256:121dd2a723be1c8aa8b116684d66157c93c801f2f5107b60287937e88c13ab89 analyzed
حالا که ایمیج تحلیل شده وقتشه ببینیم چه آسیبپذیریهایی پیدا شده:
~ $ anchore-cli image vuln docker.io/library/debian:latest all
Vulnerability ID Package Severity Fix CVE Refs Vulnerability URL
CVE-2005-2541 tar-1.30+dfsg-6 Negligible None CVE-2005-2541 https://security-tracker.debian.org/tracker/CVE-2005-2541
CVE-2007-5686 login-1:4.5-1.1 Negligible None CVE-2007-5686 https://security-tracker.debian.org/tracker/CVE-2007-5686
...
~ $ anchore-cli evaluate check docker.io/library/debian:latest
Image Digest: sha256:121dd2a723be1c8aa8b116684d66157c93c801f2f5107b60287937e88c13ab89
Full Tag: docker.io/library/debian:latest
Status: pass
Last Eval: 2020-03-14T13:25:24Z
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
در ابتدا ما دستور image vuln رو با ویژگی all اجرا می‌کنیم تا هم آسیب‌پذیری‌های سیستم عامل و هم آسیب‌پذیری‌های پکیج موجود در ایمیج نمایش داده بشه. همه اون ها برچسب Negligible یا Unknown دارن، که این خوبه.
بعد ما دستور evaluate check رو اجرا می‌کنیم تا ببینیم ایمیج آزمون بررسی خط مشی پیش فرض رو قبول میشه یا نه، و همون طور که در بالا می‌تونین ببینین (Status: pass) قبول شده.
این نوع از ایمیج‌های پایه به صورت عمومی در این زمینه عملکرد خیلی خوبی دارن، چرا که به طور گسترده ای مورد استفاده هستن و از این رو تحت بررسی های دقیقی قرار دارن.
اما ایمیج Debian Buster یک اپلیکیشن خیلی خیلی ساده Hello World در پایتون که با پایتون 3 ساخته شده چطور؟ بیاین اول یه نگاهی به فایل داکر بندازیم:
# debian.Dockerfile
FROM python:3-slim AS build-env
ADD . /app
WORKDIR /app
FROM python:3-buster
COPY --from=build-env /app /app
WORKDIR /app
CMD ["python", "hello.py", "/etc"]چیزی که بگه این اپلیکیشن آسیب‌پذیر یا ناامنه نشون نمیده، درسته؟ خب بیاین این اپلیکیشن رو بسازیم و تحلیلش کنیم:
~ $ docker build -f debian.Dockerfile -t martinheinz/debian-python-anchore .
~ $ docker run martinheinz/debian-python-anchore:latest
~ $ docker push martinheinz/debian-python-anchore:latest
# From anchore Docker CLI
~ $ anchore-cli image add martinheinz/debian-python-anchore:latest
~ $ anchore-cli image wait martinheinz/debian-python-anchore:latest
~ $ anchore-cli image list
Full Tag Image Digest Analysis Status
docker.io/library/debian:latest sha256:121dd2a723be1c8aa8b116684d66157c93c801f2f5107b60287937e88c13ab89 analyzed
docker.io/martinheinz/debian-python-anchore:latest sha256:59dff8bdf4af5cd8e9ba0754d25a43a96dfb47b46b771549a0d79d35bc3cc1aa analyzed
من اول با استفاده از debian.Dockerfile و برنامه ساده hello.py ایمیج رو ساختم. بعد از اون به هاب داکر ارسالش کردم، که از اونجا به Anchore اضافه و بالاخره تحلیل شد. حالا می‌تونیم نتیجه رو بررسی کنیم:
~ $ anchore-cli image vuln docker.io/martinheinz/debian-python-anchore:latest os
Vulnerability ID Package Severity Fix CVE Refs Vulnerability URL
CVE-2007-3476 libwmf-dev-0.2.8.4-14 Low None CVE-2007-3476 https://security-tracker.debian.org/tracker/CVE-2007-3476
CVE-2007-3476 libwmf0.2-7-0.2.8.4-14 Low None CVE-2007-3476 https://security-tracker.debian.org/tracker/CVE-2007-3476
CVE-2007-3477 libwmf-dev-0.2.8.4-14 Low None CVE-2007-3477 https://security-tracker.debian.org/tracker/CVE-2007-3477
CVE-2007-3477 libwmf0.2-7-0.2.8.4-14 Low None CVE-2007-3477 https://security-tracker.debian.org/tracker/CVE-2007-3477
CVE-2016-8660 linux-libc-dev-4.19.98-1 Low None CVE-2016-8660 https://security-tracker.debian.org/tracker/CVE-2016-8660
CVE-2007-3996 libwmf-dev-0.2.8.4-14 Medium None CVE-2007-3996 https://security-tracker.debian.org/tracker/CVE-2007-3996
CVE-2007-3996 libwmf0.2-7-0.2.8.4-14 Medium None CVE-2007-3996 https://security-tracker.debian.org/tracker/CVE-2007-3996
CVE-2009-3546 libwmf-dev-0.2.8.4-14 Medium None CVE-2009-3546 https://security-tracker.debian.org/tracker/CVE-2009-3546
CVE-2009-3546 libwmf0.2-7-0.2.8.4-14 Medium None CVE-2009-3546 https://security-tracker.debian.org/tracker/CVE-2009-3546
...
~ $ anchore-cli image vuln docker.io/martinheinz/debian-python-anchore:latest os | wc -l
1056
~ $ anchore-cli evaluate check docker.io/martinheinz/debian-python-anchore:latest
Image Digest: sha256:59dff8bdf4af5cd8e9ba0754d25a43a96dfb47b46b771549a0d79d35bc3cc1aa
Full Tag: docker.io/martinheinz/debian-python-anchore:latest
Status: fail
Last Eval: 2020-03-07T12:15:00Z
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
خب، دیگه بدون مشکل به نظر نمیاد. تنها کاری که ما کردیم جایگزینی ایمیج Debian پایتون رسمی بود و حالا بیشتر از هزار آسیب‌پذیری دارم، که بعضی از اون‌ها برچسب شدت Low و Medium دارن، حالا مقایسه کنید با چند آسیب پذیری با برچسب Negligible که موقع استفاده از ایمیج Debian ساده دیدیم. علاوه بر اون، بعد از اجرای ارزیابی ایمیج، می‌تونیم ببینیم که در ارزیابی رد شده (Status: fail).
بنابراین با این که موقع ساخت یک اپلیکیشن ساده بدون هیچ آسیب‌پذیری مشخص از ایمیج رسمی و به ظاهر امن استفاده کردیم، تعداد زیادی مشکل امنیتی دیدیم. خب، چطور می تونیم این وضعیت رو بهبود ببخشیم؟
پیدا کردن ایمیج برتر
وقتی صحبت از امنیت میشه، بهترین انتخاب برای ایمیج پایه scratch است که در واقع یک کانتینر خالی است. با این حال ساختن ایمیج خودمون از پایه زیاد کاربردی نیست و از اونجایی که بیشتر ما متخصص امنیت نیستیم، ممکنه مشکلات امنیتی بیشتری هم به وجود بیاره.
بهترین انتخاب بعد از scratch - به نظر من - Distroless است، که یه سری ایمیج ساخته شده توسط گوگله و با هدف امن بودن ساخته شدن. این ایمیج‌ها شامل حداقل‌های مورد نیاز برای اپلیکیشن شما هستن، که یعنی هیچ پوسته، ابزار مدیریت پکیج یا هر ابزار دیگه‌ای وجود نداره که باعث افزایش حجم ایمیج و ایجاد نویز سیگنال برای اسکنرهای امنیتی (مثل CVE) بشه.
من قبلا در این پست بلاگ در مورد Distroless با جزئیات صحبت کردم، پس اگه می‌خواین بیشتر درباره‌ش بدونین، این پست رو ببینین.
خب، پس ما الان Distroless رو به عنوان ایمیج امن انتخاب کردیم، اما بیاین قبل از شروع تحلیل نگاهی به فایل داکر جدید بندازیم:
# distroless.Dockerfile
FROM python:3-slim AS build-env
ADD . /app
WORKDIR /app
FROM gcr.io/distroless/python3
COPY --from=build-env /app /app
WORKDIR /app
CMD ["hello.py", "/etc"]
در مقایسه با ورژن Debian تغییر زیادی نکرده. در واقع ما فقط Runner ایمیج رو به gcr.io/distroless/python3 تغییر دادیم. حالا می‌تونیم ادامه بدیم و بسازیمش، انتقالش بدیم و در Anchore Engine اضافه ش کنیم:
docker build -f distroless.Dockerfile -t martinheinz/distroless-python-anchore .
docker run martinheinz/distroless-python-anchore:latest
docker push martinheinz/distroless-python-anchore:latest
# From anchore Docker CLI
anchore-cli image add martinheinz/distroless-python-anchore:latest
سرانجام، وقتشه ببینیم Distroless از نسخه Debian بهتر عمل کرده یا نه:
~ $ anchore-cli image vuln docker.io/martinheinz/distroless-python-anchore:latest os
Vulnerability ID Package Severity Fix CVE Refs Vulnerability URL
CVE-2019-16935 libpython3.5-minimal-3.5.3-1+deb9u1 Low None CVE-2019-16935 https://security-tracker.debian.org/tracker/CVE-2019-16935
CVE-2019-16935 python3.5-minimal-3.5.3-1+deb9u1 Low None CVE-2019-16935 https://security-tracker.debian.org/tracker/CVE-2019-16935
...
~ $ anchore-cli image vuln docker.io/martinheinz/distroless-python-anchore:latest os | wc -l
53
~ $ anchore-cli evaluate check docker.io/martinheinz/distroless-python-anchore:latest
Image Digest: sha256:29b5288e934dc724377f2ff187e8a0664246c95b0e70bd9a13f6874628dc8662
Full Tag: docker.io/martinheinz/distroless-python-anchore:latest
Status: pass
Last Eval: 2020-03-07T12:15:20Z
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
و البته که بهتر عمل کرده! در مقایسه با مثال اول ما فقط 53 آسیب‌پذیری داریم و تنها دو عدد از اون‌ها برچسب شدت Low دارن. همین در مورد ارزیابی خط مشی، این ایمیج قبول شده در حالی که نسخه Debian رد شده بود.
پس می‌دونیم با اطمینان نتیجه بگیری که برای تامین امنیت اپلیکیشن های ساخته شده در کانتینر Distroless انتخاب بهتری است. البته چند مورد دیگه هست که می‌تونیم بررسی و اون‌ها رو بهبود ببخشیم. برای مثال می‌تونیم خط مشی‌های ارزیابی متفاوتی استفاده کنیم:
~ $ anchore-cli policy hub list
Name Description
anchore_security_only Single policy, single whitelist bundle for performing
security checks, including example blacklist known malicious
packages by name.
anchore_default_bundle Default policy bundle that comes installed with vanilla
anchore-engine deployments. Mixture of light vulnerability
checks, dockerfiles checks, and warning triggers for common
best practices.
anchore_cis_1.13.0_base Docker CIS 1.13.0 image content checks, from section 4 and
5. NOTE: some parameters (generally are named 'example...')
must be modified as they require site-specific settings
دستور بالا تمام خط مشی‌هایی که می‌تونیم با اون‌ها ایمیج رو بررسی کنیم برای ما لیست می‌کنه. به طور پیش‌فرض این دستور از anchore_default_bundle استفاده می‌کنه که به خوبی جواب میده، اما در صورتی که بخوایم بررسی‌های انجام شده با استفاده از لیست‌های سفید و قوانین متفاوت رو ببینیم، می‌تونیم برای مثال دستور anchore_cis_1.13.0_base رو امتحان کنیم:
~ $ anchore-cli policy hub get anchore_cis_1.13.0_base
Policy Bundle ID: anchore_cis_1.13.0_base
Name: anchore_cis_1.13.0_base
Description: Docker CIS 1.13.0 image content checks, from section 4 and 5. NOTE: some parameters (generally are named 'example...') must be modified as they require site-specific settings
Policy Name: CIS File Checks
Policy Description: Docker CIS section 4.8 and 4.10 checks.
Policy Name: CIS Dockerfile Checks
Policy Description: Docker CIS section 4.1, 4.2, 4.6, 4.7, 4.9 and 5.8 checks.
Policy Name: CIS Software Checks
Policy Description: Docker CIS section 4.3 and 4.4 checks.
Whitelist Name: RHEL SUID Files
Whitelist Description: Example whitelist with triggerIds of files that are expected to have SUID/SGID, for rhel-based images
Whitelist Name: DEB SUID Files
Whitelist Description: Example whitelist with triggerIds of files that are expected to have SUID/SGID, for debian-based images
Mapping Name: default
Mapping Rule: */*:*
Mapping Policies: CIS Software Checks,CIS Dockerfile Checks,CIS File Checks
Mapping Whitelists: DEB SUID Files,RHEL SUID Files
~ $ anchore-cli policy hub install anchore_cis_1.13.0_base
Policy ID: anchore_cis_1.13.0_base
Active: False
Source: local
Created: 2020-03-07T12:20:46Z
Updated: 2020-03-07T12:20:46Z
~ $ anchore-cli policy list
Policy ID Active Created Updated
2c53a13c-1765-11e8-82ef-23527761d060 True 2020-02-17T11:10:20Z 2020-02-17T11:10:20Z
anchore_cis_1.13.0_base False 2020-03-07T12:20:46Z 2020-03-07T12:20:46Z
~ $ anchore-cli policy activate anchore_cis_1.13.0_base
Success: anchore_cis_1.13.0_base activated
در کد بالا می‌تونین ببینین که ما اول با استفاده از دستور policy hub get نگاهی به توضیحات این خط مشی خاص انداختیم. بعد از اون نصبش کردیم و دستور policy list رو اجرا کردیم که نشون میده ما حالا دو خط مشی در دسترس داریم، که خط مشی جدید غیر فعال است.
پس ما با دستور آخر فعالش کردیم (policy activate). قبل از این که بررسی رو با استفاده از خط مشی جدید شروع کنیم، بیاین در مورد این که شامل چه مواردی است صحبت کنیم. با توجه به این که این بررسی برای داکر CIS 1.13.0 است، بر روی راهنمایی‌های ارائه شده در این سند تمرکز می‌کنه. در زیر چند مثال از مشکلاتی که این خط مشی به دنبال اون‌ها می‌گرده رو نوشتیم:
- دستورهای ADD استفاده شده به جای COPY
- پورت‌های بازی که در لیست سفید نیستن
- دستورهای HEALTCHECK جا افتاده
- استفاده از ایمیج پایه‌های غیر مطمئن
- استفاده از root به عنوان کاربر اصلی
برای دیدن فهرست کامل قوانین این خط مشی می‌تونین دستور anchore-cli --json policy hub get anchore_cis_1.13.0_base رو اجرا کنین. حالا که می‌دونیم دنبال چی می‌گرده وقتشه اجراش کنیم:
~ $ anchore-cli evaluate check docker.io/martinheinz/distroless-python-anchore:latest --detail
...
dockerfile instruction Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check stop
dockerfile instruction Dockerfile directive 'FROM' check 'not_in' matched against 'example_trusted_base1,example_trusted_base2' for line 'scratch' stop
dockerfile effective_user User root found as effective user, which is explicity not allowed list stop
...
در خروجی تعدادی هشدار مربوط به پکیج‌های نصب شده وجود داره، اما اون‌هایی که مخصوص این خط مشی هستن، در بالا ذکر شدن. این ها مشکلات یا آسیبپذیریهایی هستن که باعث میشن ایمیج در ارزیابی خط مشی رد بشه و باید تحلیل بشن.
یکی از این‌ها (دومی) به خاطر استفاده از Distroless ایجاد شده، چون این ایمیج در لیست سفید قرار نداره، برای همین اون رو میشه ندید گرفت.
اما دو اخطار دیگه، مشکلات جدی هستن که باید درست بشن، که هر دو راه حل های ساده و سرراستی دارن.
این به ما نشون میده که استفاده از یک خطی مشی خاص بر اساس نیازهامون و یا حتی استفاده از چند خط مشی به صورت هم‌زمان فکر خوبی است.
انواع و سطوح آسیب پذیری‌ها
آسیب‌پذیری‌های مثال بالا به راحتی حل می‌شدن، اما همیشه این‌طور نیست. شما ممکنه به آسیبپذیریهایی بر بخورید که امتیاز شدت بالایی دارن یا تنها در مورد برنامه شما مشکل‌زا هستن.
وقتی موضوع مشکلات به وجود اومده در ایمیج یا پکیج‌های داخل اونه، شما نباید اون مشکلات رو برطرف کنین، چون این مسئولیت توسعه دهنده‌ها و/یا ناشران ابزار اشاره شده است. با این حال شما باید از به وجود آمدن‌آسیب پذیری‌های در آینده جلوگیری و میزان خطر آسیب‌پذیری‌های فعلی رو با حذف شاخص‌های حمله کاهش بدین.
برای مثال می‌تونین با استفاده از Distroless که هیچ پوسته‌ای نداره این کار رو انجام بدین. علاوه بر اون انجام بررسی‌های دوره ای برای آگاهی از آسیب‌پذیری‌های معرفی شده در سریع‌ترین زمان ممکن و با استفاده از چندین ابزار اسکن فکر خیلی خوبیه.
آسیب پذیری امنیتی ایمیج‌های داکر را قبل از دیر شدن، پیدا کنید!
Anchore در برابر Clair
صحبت از اجرای چندین ابزار اسکن شد… چطور باید Clair استفاده کنیم؟ در مقایسه با Anchore چطور عمل می‌کنه؟ در زیر می‌تونین نحوه استفاده از Clair در مثال ایمیج های Debian و Distroless رو ببینین:
# Run setup steps from beginning of article...
~ $ clair-scanner --ip 192.168.1.56 martinheinz/debian-python-anchore:latest
2020/03/07 17:54:11 [INFO] ▶ Start clair-scanner
2020/03/07 17:54:18 [INFO] ▶ Server listening on port 9279
2020/03/07 17:54:18 [INFO] ▶ Analyzing 55db4dd701c0a4eea04ba231e74bd04d6c1cdbd86cf8084e988648aa7cf5af9b
2020/03/07 17:54:18 [INFO] ▶ Analyzing 1938b02d46a5b801035965c5680d11c513a679e0ad4a560276df9a8ececa0bed
2020/03/07 17:54:18 [INFO] ▶ Analyzing 90bd3e8e4e9f1dd7624ecdd1ee35c36072e582a2cd5c606f290d2b3cb4a1559c
2020/03/07 17:54:18 [INFO] ▶ Analyzing ced4f27972d40674b72da7b1a51b63a8396bbca3a4fca86dffa8031228ab88cb
2020/03/07 17:54:18 [INFO] ▶ Analyzing 7abae7ca0ef88724a59f51748b1658136bdbb1eae246550478f5939484358d94
2020/03/07 17:54:18 [INFO] ▶ Analyzing 62547b912c7f2d5d69eaca3cd5ad1cb053c39886cb7276b0cb753b3824c32358
2020/03/07 17:54:18 [INFO] ▶ Analyzing cb7076fa495a6c437ac374b1b67a62075b94db45400c10e8849b5db75ffbce21
2020/03/07 17:54:18 [INFO] ▶ Analyzing a3ffe04a8073815ecfa94620efbbccf412b85ca80b6550c029617eed51c5edb6
2020/03/07 17:54:18 [INFO] ▶ Analyzing 715fd7b0b1161fa57f74a843f4525f1ab7035c9a8051a6559c91ff360e44f20f
2020/03/07 17:54:18 [INFO] ▶ Analyzing 20519035fc6a7d347a1540a633c461ac321dc8db7cb8c163283c1d802097697b
2020/03/07 17:54:18 [WARN] ▶ Image [martinheinz/debian-python-anchore:latest] contains 356 total vulnerabilities
2020/03/07 17:54:18 [ERRO] ▶ Image [martinheinz/debian-python-anchore:latest] contains 356 unapproved vulnerabilities
... List of vulnerabilities follows
~ $ clair-scanner --ip 192.168.1.56 martinheinz/distroless-python-anchore:latest
2020/03/07 17:56:08 [INFO] ▶ Start clair-scanner
2020/03/07 17:56:09 [INFO] ▶ Server listening on port 9279
2020/03/07 17:56:09 [INFO] ▶ Analyzing 51756e4adf1ad2b5a00c36dcc9e799a69d72462d60e6f88c87f96eed832b8a2a
2020/03/07 17:56:09 [INFO] ▶ Analyzing 49905beb7372788afbefede92af761383ad2bac7f8d21b2f2d6fb165afff48e8
2020/03/07 17:56:09 [INFO] ▶ Analyzing 3d9fd80998dc9ea371366e1ef54046fbe86e6e360d17ece650ea8a3ea5023c63
2020/03/07 17:56:09 [INFO] ▶ Analyzing 83b671756e1e2cc132505e55c87c5c5b1da185665f9bb875d771568959dc05a2
2020/03/07 17:56:09 [INFO] ▶ Analyzing b80190979f279448d479a3ed0450f6d2912662e12edd1fe477a2b74d0568e1f0
به خروجی دستورات بالا که نگاه کنیم، به نظر خیلی شبیه Anchore است. تعداد زیادی مشکل برای نسخه Debian و هیچ مشکلی برای Distroless شناسایی نشده. در خروجی اسکن اول، یک فهرست بزرگ از آسیب‌پذیری‌ها وجود داره که من حذفشون کردم، اما مشکلات با برچسب شدت Low و Medium رو بررسی کردم و همه اون‌ها در نتیجه اسکن هر دو ابزار Anchore و Clair وجود دارن، البته ممکنه همیشه این‌طور نباشه. به همین دلیل من استفاده از ابزارهای اسکن مختلف رو پیشنهاد می‌کنم، به خصوص اون‌هایی که از منابع متفاوتی برای داده‌های آسیب‌پذیری‌ها استفاده می‌کنن.
بعضی از ابزارهای دیگه‌ای که ممکنه شما بخواین یه نگاهی بهشون بندازین Docker Bench for Security یا ابزار اسکن آسیب‌پذیری موجود در IBM Container Registry هستند.
نتیجه‌گیری
در مسائل مربوط به امنیت، بهتره همیشه بیش فعال باشین و سعی کنین از آسیبپ‌پذیری‌ها قبل از این که تبدیل به یک مشکل جدی بشن جلوگیری کنین و ابزارهای معرفی شده در این مقاله می‌تونین در این راه به شما خیلی کمک کنن. فکر می کنم استفاده از این ابزارها به اندازه کافی آسون هست، تا هر کسی اون ها رو در گردش کار روزانه‌ش یا حتی بهتر، جزیی از فرایندهای اتوماسیون کسب و کارش قرار بده.
امنیت اپلیکیشن هایی که می‌سازیم - تا یه حد مشخصی - وظیفه هر توسعه دهنده‌ای است، نه فقط متخصصان امنیت یا متخصصان نفوذ، پس همه ما باید با اجرای اسکن آسیب‌پذیری به صورت دوره‌ای، نقشمون رو در امن‌تر کردن اپلیکیشن‌ها ایفا کنیم.
