لوگوی سفید Xygeni
رایگان شروع کنید
نسخه ی نمایشی را رزرو کنید

چه چیزی می‌تواند اشتباه پیش برود؟ CI/CD pipelines?

فهرست مندرجات

پست‌های خواندنی

آخرین پست‌های مورد علاقه

ادغام مداوم و تحویل مداوم (CI/CD) pipelineاتوماسیون، پایه و اساس هر سازمان نرم‌افزاری است که نرم‌افزار را به روشی «مدرن» می‌سازد. اتوماسیون قدرت زیادی را فراهم می‌کند، اما اکثر توسعه‌دهندگان مسئولیتی را که به همراه دارد، نادیده می‌گیرند.

توسعه دهندهبله، می‌بریم CI/CD تیم امنیت لاتاری به طور جدی و با کنترل قوی بر روی نگهدارندگان کد، بررسی کنید commitقبل از ادغام؛ مشاغل و pipelineتوسط کارکنان ارشد نگهداری می‌شوند، آنها مراقبند که اسرار فاش نشود. pipelineو این ابزار توسط پرسنلی که با این موضوع آشنا هستند نصب شده است. چه مشکلی ممکن است پیش بیاید؟

توسعه‌دهنده عزیز، CI/CD سیستم‌ها پیچیده هستند. سطح حمله وسیع آن، عاملان بدخواه را جذب می‌کند. بهتر است محتاط باشید و هرگز بیش از حد مطمئن نباشید.

پیکربندی پیش‌فرض گاهی اوقات حفظ می‌شود و به بهترین دوست هکرها تبدیل می‌شود. نقص‌های بحرانی می‌توانند در ... وجود داشته باشند. CI/CD pipeline منابع، در پیکربندی سیستم، یا پیرامون فرآیند و زمینه‌ی آن pipeline و چگونه فعال می‌شود.

در این پست، خودمان را جای بازیگران بد داستان قرار می‌دهیم. تصور کنید که ما در حال خواندن افکار ... بودیم. M3M3N70 (یادآوری مرگ؟) و خشم باتلاق جایی در وب تاریک، احتمالاً به زبانی غیر غربی، اما هرگز از دست ندهید که شر در سراسر جهان پخش شده است.

 

در زمان‌های قدیم خیلی آسان بود…

M3M3N70برگردیم به دوران خوب گذشته، کار ما خیلی آسان بود... آسیب‌پذیری‌های روز صفر در دسترس بودند، برنامه‌ها کاملاً باز بودند و به راحتی می‌شد از آنها سوءاستفاده کرد، و ما می‌توانستیم در یک چشم به هم زدن به هر جایی که می‌خواهیم برویم.

خشم باتلاق: لعنت! بعضی‌ها هنوز عقلشون کمه، اما اوضاع عوض شده. گنده‌ها حسابی سر اون مزخرفات AppSec کلاه گذاشتن.

M3M3N70بله. اما احمق‌های جدید، توسعه‌دهندگان هستند. برای ما، استفاده از ابزارهایی که این افراد استفاده می‌کنند، آسان‌تر بوده است. به طور خاص، CI یک معدن طلاست! توکن‌های دسترسی ابری، SCM اطلاعات احراز هویت، رمزهای عبور پایگاه داده در محیط عملیاتی، کلیدهای خصوصی SSH، اطلاعات احراز هویت سایر کاربران CI... پریدن از چیزهای خسته‌کننده توسعه به اصل ماجرا نسبتاً بی‌اهمیت بود.

اتوماسیون برای ساخت، آزمایش و استقرار نرم‌افزار با ... CI/CD این ابزار اغلب نیاز دارد که رمزها را به صورت مرحله‌ای به دستورات ارسال کند. و اغلب این رمزها فاش می‌شوند و عواقب بدی به همراه دارند.

Pipelineبه رازهایی نیاز داریم که گاهی فاش می‌شوند

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

شاید دوران خوب گذشته این بود که در تاریخ گیت یک ... پیدا کنیم. .env فایل (توسعه‌دهنده فراموش کرده است که آن را به آن اضافه کند) .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

که در یک گردش کار GitHub استفاده شده بود .github/deploy.yaml که شامل چیزی شبیه به این بود:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: وای! اون کلیدهای aws کار می‌کردن! ما اول یه تغییر inocuos رو تو برنامه آزمایش کردیم، بعد چون انگار اون یاروها بی‌خبر بودن، sting رو اضافه کردیم. بینگو! چه کمپینی...

این عامل مخرب به سادگی از کلیدهای AWS برای آپلود یک برنامه اصلاح‌شده حاوی بدافزار استفاده کرده و سپس دستور استقرار را با چنین اعتبارنامه‌هایی اجرا کرده است. اسرار فاش‌شده، به همراه اطلاعات موجود در pipeline«چه کمپینی!» احتمالاً به این معنی است که «ممنتو» حسابی آن قربانی بیچاره را به دردسر انداخته است.

چیزی که Memento اینجا به ما می‌گوید این است که وقتی یک نشت اطلاعات محرمانه رخ می‌دهد، مانند کلیدهای دسترسی AWS در مثال، شما باید آن راز را لغو کنید (کلیدهای بالا را بچرخانید) بلافاصلههمیشه یک ... وجود دارد پنجره نوردهی بین نشتی commit و ابطال مخفیانه؛ بازنویسی تاریخچه گیت سخت است (حتی سرسخت‌ترین حکومت‌های اقتدارگرا نیز چنین بازنویسی تاریخی را امتحان کردند، اما بی‌فایده بود) و احتمالاً بی‌اثر بود (ممکن است دوستان ما قبل از مخزن، با افشای اطلاعات محرمانه، آن را شبیه‌سازی کرده باشند) commit). فوراً کلیدها را بچرخانید و هنگام خواندن گزارش‌های فعالیت برای حساب کاربری مورد نظر در طول پنجره‌ی مواجهه، دعا کنید!

احتمالاً سازمان‌ها باید ممنوعیت استفاده از اسرار بلندمدت در CI/CD pipelinesو آنها را با اعتبارنامه‌های موقت جایگزین کنید. در مثال قبلی با کلیدهای AWS در اقدامات GitHub، استفاده از a امن‌تر است. ارائه دهنده OpenID Connect (OIDC) برای دریافت اعتبارنامه‌های کوتاه‌مدت مورد نیاز برای اقدامات.

خشم باتلاق: خیلی خوش شانس بودی! لو دادن اسکریپت‌ها با کلیدهای هاردکد شده در قدیم، حتی در سطل‌های S3 که در دسترس عموم بودند، یک روش رایج بود. تنها کاری که باید انجام می‌دادید این بود که اشیاء موجود در سطل را پیمایش کنید و کمی greping انجام دهید تا چیزهای جالبی پیدا کنید.

گاهی اوقات ناحیه‌ای که برای استقرار استفاده می‌شد (در این مثال یک سطل AWS S3) به دلیل یک نقص پیکربندی (که کشف نشده بود) برای خواندن توسط افراد خارجی باز بود. چه خشم باتلاق مورد استفاده چیزی شبیه به این بود:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

این باکت احتمالاً در یک الگوی آماده‌سازی ایجاد شده است که می‌تواند به طور خودکار برای نقص‌های امنیتی اسکن شود.

پیکربندی پیش‌فرض ابزار برای ما مثل یک اسباب‌بازی بود

برای مثال‌های مشخص، بیایید در مورد آن صحبت کنیم جنکینز، یکی از محبوب‌ترین ابزارهای CI است.

خشم باتلاقآیا آن کادر انتخاب «فعال کردن امنیت» در جنکینز را به خاطر دارید، و اینکه چند سازمان به خاطر راحتی آن را فعال نکردند؟ و آن «هر کسی می‌تواند هر کاری انجام دهدو آن افزونه‌های مزاحم جنکینز، مانند افزونه‌ی گیت‌هاب OAuthشخصی که آن را پیکربندی کرده، هم «اعطای مجوزهای خواندن به همه کاربران احراز هویت‌شده» و هم «استفاده از مجوزهای مخزن گیت‌هاب» را انتخاب کرده است که به ما امکان دسترسی به همه پروژه‌هایش را می‌دهد.

(جنکینز، بابت مثال زدنت معذرت می‌خوام 😉

به اصول امنیتی مسلط (یا حتی معتاد) باشید. یکی از آنها این است ایمن به صورت پیش‌فرض اصل: کنترل‌ها باید به صورت پیش‌فرض روی امن‌ترین تنظیمات ممکن باشند. امنیت باید در آنها تعبیه شود CI/CD ابزار و pipelineاز پایه طراحی شده، نه اینکه بعداً به آن فکر شود. اما کاربرپسندی و راحتی اغلب با امنیت در تضاد است.

برای مورد جنکینز، احراز هویت داخلی بیش از حد شکننده است: هرگز از مکانیزم‌های احراز هویت داخلی Jenkins استفاده نکنید.بهتر است از یک مکانیزم شخص ثالث (SAML، LDAP، Google ...) با افزونه‌ی Role-based Authorization Strategy ("RBAC") استفاده کنید. و در مورد ... بسیار محتاط باشید. admin حساب.

مراقب نحوه کار و pipeline فایل‌ها در جنکینز مدیریت می‌شوند. همین امر در مورد افزونه پیکربندی به عنوان کد و فایل‌های پیکربندی آن، که برای پیکربندی Jenkins اعمال می‌شوند.

انتقال از هاست شخصی CI/CD تبدیل سیستم‌ها به سیستم‌های SaaS مبتنی بر ابر، برخی از خطرات بالقوه‌ای را که امکان جابجایی جانبی در شبکه سازمان را فراهم می‌کنند، حذف می‌کند، اما خطرات دیگری مانند نیاز به باز کردن اتصالات خارجی بین سیستم‌های داخلی موجود و سیستم‌های خارجی‌شده را اضافه می‌کند. CI/CD ابزار است.

سازمان‌ها باید تمرین کنندcisدقت لازم در سخت کردن CI/CD سیستم، با محدودترین تنظیمات شروع می‌شود و به تدریج با حداقل مجوزهای مورد نیاز برای pipeline مراحل

پیکربندی امنیت در CI/CD ابزارها می‌توانند بسیار پیچیده باشند. بسیاری از آنها افزونه‌ها یا اکستنشن‌هایی دارند که بیشتر آسیب‌پذیری‌ها را دارند و نیاز به به‌روزرسانی دارند.

اسکنرهای پیکربندی نادرست امنیتی برای چنین ابزارهای پیچیده‌ای یا بنچمارک‌ها می‌توانند مفید باشند.

تزریق کد pipeline دستورات برای سرگرمی و سود

M3M3N70آیا تا به حال از بررسی کدهای غیرقابل اعتماد، که شامل اقدامات و اسکریپت‌های آسیب‌پذیر در برابر تزریق دستور هستند، استفاده کرده‌اید؟

این بخش نشان می‌دهد که pipeline خود می‌تواند اشتباهات کدنویسی داشته باشد که به بازیگران بد اجازه می‌دهد کد دلخواه خود را در آن تزریق کنند. pipeline بدون تغییر دادن pipeline خود منبعبرای مثال، استفاده از PR

اولین نمونه از یک گردش کار نامناسب گیت‌هاب:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

ترکیب pull_request_target فعال کردن گردش کار با یک پرداخت صریح از یک PR غیرقابل اعتماد، یک اقدام خطرناک است که ممکن است منجر به به خطر افتادن مخزن شود. در مثال، ترکیب نامطلوب موارد زیر:

  • pull_request_target رویدادی که به طور پیش‌فرض مجوز نوشتن در مخزن هدف و اسرار مخزن هدف، حتی از انشعاب‌های خارجی، را دارد و در چارچوب مخزن هدف PR اجرا می‌شود،
  • کد PR را از منبع، مخزن نامعتبر، بررسی کنید.
  • هر اسکریپتی را که ممکن است روی محتوای کنترل‌شده توسط PR عمل کند، مانند مورد زیر، فعال می‌کند. npm installو
  • عدم استفاده از شرط برای شروع pull_request_target این رویداد فقط در صورتی اجرا می‌شود که نوعی برچسب «این PR بررسی شده است» به PR اختصاص داده شده باشد (کاربران خارجی نمی‌توانند برچسب‌هایی به PR اختصاص دهند).

مثال دوم ورودی غیرقابل اعتماد (از یک مسئله، نظر یا ...) را دریافت می‌کند. pull request) به عنوان منبع آرگومان‌های ارسالی به a pipeline دستور از طریق عبارات. این است pipeline نسخه‌ای از آسیب‌پذیری تزریق دستور سیستم‌عامل.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

عملیات اجرا، یک اسکریپت پوسته موقت بر اساس الگو تولید می‌کند، با $ جایگزین شده است، و آن را در برابر تزریق دستور shell آسیب‌پذیر می‌کند. یک مهاجم با یک حساب کاربری جعلی GitHub می‌تواند با یک عنوان مشکل ایجاد کند. a"; bad_code_goes_here;#و بوم! 

خشم باتلاق: اوه، اون یاروها داشتن با باز کردن یه مسئله، در رو برای تزریق دستور باز می‌کردن...

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

نکته اخلاقی داستان: هرگز بدون بررسی اولیه PR، از منابع غیرقابل اعتماد PR نگیرید و PR نسازید. «غیرقابل اعتماد» در اینجا، مگر اینکه تحت احراز هویت سختگیرانه‌ی منشأ باشد، می‌تواند به معنای هر حساب توسعه‌دهنده‌ی بالقوه ربوده شده باشد.

 

استقرار ناخواسته بدافزار در اینجا!

استقرار مستمر اوج اتوماسیون است، اما این اوج می‌تواند به دلیل فقدان کنترل‌های تأیید مناسب روی ... مختل شود. pipeline جریان.

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

برای کاهش این خطرات، اغلب توصیه می‌شود که سازمان‌ها در فرآیند استقرار خود یک «استراحت اساسی» اعمال کنند که مستلزم... تایید انسانی قبل از اینکه نسخه‌ها در محیط‌های نهایی مستقر شوند.

دارند درها را می‌بندند

خشم باتلاق: آن رمزهای عبور پیش‌فرض شاد در CI/CD ابزارها در حال پاک شدن هستند. دسترسی به /var/lib/jenkins/secrets/initialAdminPassword الان دیگه خبری ازش نیست. خیلی از ابزارها الان احراز هویت دو مرحله‌ای رو ارائه میدن، که کووید باعث محبوبیتش شده، و حتی تنبل‌ترین کدنویس‌ها هم ازش استفاده می‌کنن!

M3M3N70ما در حال مبارزه با 2FA هستیم، اما این کار به این آسانی نیست. فیشینگ هدفمند (spear phishing) روی این افراد دشوار است، زیرا «اسکتر سوین» با توئیلیو این کار را کردبا کلیدهای WebAuthn این کار بسیار دشوارتر است. حداقل می‌توانیم سعی کنیم سرقت کوکی‌ها برای دور زدن MFAاما باید وارد محدوده‌ی توسعه‌دهندگان شوید.

احراز هویت چند عاملی گامی خوب در مسیر درست برای محدود کردن خطر افشای اسرار احراز هویت است. اکثر ابزارهای مدرن DevOps از MFA پشتیبانی می‌کنند. و کلیدهای احراز هویت تحت WebAuthn / U2F (به بخش «شناسایی چند عاملی» مراجعه کنید) پروژه FIDO2) شاید بهترین گزینه برای MFA در DevOps باشند، البته اگر به درستی مدیریت شوند.

خشم باتلاقبچه‌های DevOps دارند از خواب بیدار می‌شوند. آنها آن چیز لعنتیِ «حداقل امتیاز» را در خونشان دارند. و دیگر مثل میمون‌های کدنویس نیستند. حالا ما موقع خطاکاری توسط بازرسان لو می‌رویم.

در واقع، pipelineاکنون کمی قوی‌تر از چند سال پیش هستند، با حذف اقدامات و اسکریپت‌های ضعیف، و با مراحل تست امنیتی اضافی که حتی دراپرهای ما را که به صورت مخفیانه پنهان شده بودند، شناسایی کردند. commitها و بسته‌هایی که ما ربودیم.

سوال برای خواننده: آیا فرآیند ساخت نرم‌افزار از منابع و استقرار در محیط عملیاتی، یک کسب و کار پرخطر است؟ آیا می‌توانید DevOps خود را در مرحله ... ببینید؟ اوقات خوشی را سپری کنید برای آدم بدها؟

توصیه های نهایی

از کجا شروع کنیم CI/CD pipelineس

اولین توصیه در اینجا ساده است: با دقت این فایل نقد می نویسید: pipelines (آنها هستند بحرانی منابع) برای مسائل امنیتی. بررسی‌ها پرهزینه اما ضروری هستند و باید به درستی انجام شوند. بررسی‌کنندگان باید از آنچه باید بررسی کنند آگاه باشند. هر مرحله باید از نظر نقص بررسی شود.

شاید ترکیبی از متخصصان بررسی که به اسکنرهای خودکار کدهای مخرب مجهز هستند، بتواند مفید باشد.

توصیه دوم این است که توسعه‌دهندگانی را که می‌نویسند آموزش دهید pipelineو آنها را در وضعیت امنیتی حفظ کنیدمواردی که باید در نظر گرفته شوند:

  • چگونه احراز هویت را با سرویس‌های داخلی و ابری به درستی مدیریت کنیم و از دردسرهای مدیریت اعتبارنامه‌های بلندمدت جلوگیری کنیم.
  • چگونه محدود کنیم pipelineبه مجموعه دقیق منابعی که نیاز به دسترسی به آنها دارد. اصل حداقل امتیاز دوباره می‌درخشد.
  • نحوه نوشتن مراحل ساخت pipelineقابل تکرار مانند پین کردن نسخه و جلوگیری از آسیب‌پذیری‌های تزریق دستور.
  • نحوه تأیید استقرارها از دیدگاه امنیتی (آنها موارد دیگری هستند!): کدام امنیت standardها باید تطبیق داده شوند و نحوه اضافه کردن چک/گیت های مربوطه در pipelines.

توصیه سوم این است که پیکربندی کنید CI/CD سیستم با مراقبت لازماحراز هویت قوی، بدون رمزهای عبور پیش‌فرض یا تنظیمات ناامن، حداقل امتیازات... مراقب آسیب‌پذیری‌های موجود در افزونه‌ها و اکستنشن‌های نصب‌شده باشید. این موضوع می‌تواند موضوع اصلی پست‌های بعدی باشد، لطفاً با ما همراه باشید.

توصیه چهارم این است که اهرم CI/CD pipelineبرای اتوماسیون امنیتیتحلیل کد منبع (SAST) ، تجزیه و تحلیل ترکیب منبع (SCA)، اسکن نشت اسرار، ابزارهای ضد بدافزار، اسکنرهای امنیتی کانتینر یا آشکارسازهای خودکار زمان اجرا (DAST و بدافزار) می‌توانند به طور معمول روی pipelineو سازمان شما ممکن است اجرا کند standardدرباره پوشش اسکن امنیتی در CI/CD.

به یاد داشته باشید، این ابزارها هنوز بررسی‌های تخصصی را از معادله حذف نمی‌کنند، در غیر این صورت ممکن است احساس امنیت کاذب داشته باشید.

اگر در OWASP مهارت دارید، یک پروژه خوب اخیر این است OWASP 10 برتر CI/CD خطر امنیتی.

یادداشت سلب مسئولیت

(1) مثال‌های این پست از GitHub به عنوان SCM، AWS به عنوان ارائه دهنده ابر، و GitHub Actions یا Jenkins به عنوان CI/CD ابزار. آنها ضعیف‌تر/ایمن‌تر از جایگزین‌هایشان نیستند. قصد بدی ندارم! این ابزارها قدرتمند هستند و باید به طور مناسب استفاده شوند.

(2) M3M3N70 و خشم باتلاق شخصیت‌های خیالی هستند. هرگونه شباهتی با افراد یا گروه‌ها، چه زنده و چه مرده، صرفاً تصادفی است... یا هست؟

برای خواندن ادامه مطلب

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

توسعه و تحویل نرم‌افزار خود را ایمن کنید

با مجموعه محصولات Xygeni

رایگان شروع کنید
در تور محصول شرکت کنید
لوگوی سفید Xygeni

© 2026 شیگنی. تمامی حقوق محفوظ است.

لینکدین ایکس توئیتر یوتیوب

محصولات - Sanxin

منابع

شرکت

قانونی