بر خلاف باور عموم، کانتینرهای داکر به خودی خود امن نیستند. بنابراین استفاده از ابزارها و اسکنرها برای خلاصی از نقاط آسیب‌پذیر در امنیت کانتینر ضروری است.

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

ابزارهای 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 هستند.

نتیجه‌گیری

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