לוגו 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 האלה עבדו! בדקנו קודם שינוי לא מסוכן באפליקציה, ואז הוספנו את הסטינג כי נראה היה שהחבר'ה האלה לא מודעים. בינגו! איזה קמפיין...

הגורם הרע פשוט השתמש במפתחות AWS כדי להעלות אפליקציה שעברה שינוי עם תוכנה זדונית ולאחר מכן הפעיל את פקודת deploy עם אישורים אלה. הסודות שדלפו, יחד עם המידע הכלול ב- pipeline"איזה קמפיין!" כנראה אומר שממנטו זרע הרס בקורבן המסכן.

מה שממנטו אומר לנו כאן הוא שברגע שמתרחשת דליפת סוד, כמו מפתחות גישה של AWS בדוגמה, צריך לבטל את הסוד (לסובב את המפתחות הנ"ל). מידתמיד יש חלון חשיפה בין הדליפות commit והפסול הסודי; שכתוב היסטוריית גיט קשה (אפילו המדינה האוטוריטרית הקשוחה ביותר ניסתה שכתוב היסטוריה כזה, ללא הועיל) וכנראה לא יעילה (ייתכן שחברינו שיבטו לפני המאגר עם הדליפה הסודית) commitסובבו את המקשים באופן מיידי, והתפללו תוך כדי קריאת יומני פעילות עבור החשבון הממוקד במהלך חלון החשיפה!

כנראה שארגונים צריכים איסור שימוש בסודות לטווח ארוך ב CI/CD pipelines, ולהחליף אותם באישורים זמניים. בדוגמה הקודמת עם מפתחות AWS בפעולות GitHub, בטוח יותר להשתמש ב- ספק OpenID Connect (OIDC) כדי לקבל אישורים קצרי מועד הנדרשים לפעולות.

זעם הביצההיה לך מזל גדול! דליפת סקריפטים עם מפתחות קשיחים הייתה נוהג נפוץ בימים עברו, אפילו בדלי S3 נגישים לציבור. כל מה שהיית צריך לעשות הוא לחצות את האובייקטים בדלי ולבצע קצת גרפינג כדי למצוא דברים מעניינים.

לעיתים, האזור ששימש לפריסה (בדוגמה זו, דלי 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 הפופולריים ביותר.

זעם הביצההאם אתה זוכר את תיבת הסימון "הפעל אבטחה" בג'נקינס, וכמה ארגונים בחרו לא להפעיל אותה למען הנוחות? ואלה "כל אחד יכול לעשות הכל"שילובי הרשאות כברירת מחדל? והתוספים המעצבנים של ג'נקינס, כמו ה- תוסף GitHub OAuthהבחור שהגדיר את זה בחר גם "הענק הרשאות קריאה לכל המשתמשים המאומתים" וגם "השתמש בהרשאות מאגר GitHub", מה שנתן לנו גישה לכל הפרויקטים שלו.

(סליחה, ג'נקינס, על כך ששמתי אותך כדוגמה 😉)

הישארו בקיאים (אפילו מכורים) בעקרונות אבטחה. אחד מהם הוא ה מאובטח כברירת מחדל עיקרון: בקרות צריכות להיות מוגדרות כברירת מחדל להגדרות הבטוחות ביותר האפשריות. יש לשלב אבטחה CI/CD כלים ו pipelineמהיסוד, ולא מחשבה שנייה. אבל ידידותיות למשתמש ונוחות מתנגשות לעתים קרובות עם אבטחה.

עבור מקרה ג'נקינס, האימות המובנה שברירי מדי: לעולם אל תשתמש במנגנוני האימות המובנים בג'נקינסעדיף לבחור במנגנון צד שלישי (SAML, LDAP, גוגל...), עם תוסף אסטרטגיית הרשאה מבוססת תפקידים ("RBAC"). ונהיה זהירים ביותר עם ה- admin חֶשְׁבּוֹן.

תדאגו לאיך העבודה ו pipeline קבצים בג'נקינס מטופלים. אותו הדבר עם תוסף הגדרות כקוד וקבצי התצורה שלו, אשר חלים על תצורת Jenkins.

מעבר מאחסון עצמי CI/CD המעבר ממערכות SaaS למערכות SaaS מבוססות ענן מבטל חלק מהסיכונים הפוטנציאליים המאפשרים תנועה רוחבית בתוך רשת הארגון, אך הוסיף סיכונים נוספים, כמו הצורך לפתוח חיבורים חיצוניים בין מערכות פנימיות קיימות למערכות חיצוניות. CI/CD כלי.

ארגונים צריכים להתאמץcisזהירות נאותה בהקשחת ה- CI/CD המערכת, החל מההגדרות המגבילות ביותר ובהדרגה נפתחת עם ההרשאות המינימליות הנדרשות עבור pipeline צעדים.

הגדרת אבטחה ב CI/CD כלים יכולים להיות משימה מורכבת. לרבים מהם יש תוספים או הרחבות שיש בהם את רוב הפגיעויות ויש לעדכן אותם.

סורקי תצורה שגויה של אבטחה עבור כלים מורכבים כאלה, או מדדי ביצועים עשויים לעזור.

הזרקת קוד פנימה pipeline פקודות להנאה ולרווח

M3M3N70האם אי פעם השתמשת בבדיקות קוד לא מהימנות, אותן פעולות וסקריפטים פגיעים ופגיעים להזרקת פקודות?

סעיף זה מראה כי ה- pipeline עצמו עלול להכיל טעויות קידוד המאפשרות לגורמים רעים להזריק ביצוע קוד שרירותי ב pipeline מבלי לשנות את pipeline המקור עצמולדוגמה, שימוש ב-PR

דוגמה ראשונה של זרימת עבודה מצערת של GitHub:

# 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 מהמקור, מאגר לא מהימן,
  • להפעיל כל סקריפט שעשוי לפעול על תוכן הנשלט על ידי יחסי ציבור, כמו במקרה של npm install, ו
  • אי שימוש בתנאי להפעלה pull_request_target אירוע יפעל רק אם תווית כלשהי של 'פרטיות ציבורית זו נבדקה' מוקצית לפרטיות (משתמשים חיצוניים אינם יכולים להקצות תוויות לפרטיות).

דוגמה שנייה מקבלת קלט לא מהימן (מתוך בעיה, תגובה או pull request) כמקור לאיגומנטים המועברים אל pipeline פקודה באמצעות ביטויים. זהו ה- pipeline גרסה של פגיעות הזרקת פקודות של מערכת ההפעלה.

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

פעולת ההפעלה יוצרת סקריפט מעטפת זמני המבוסס על התבנית, עם $ הוחלפה, מה שהופך אותה לפגיעת הזרקת פקודות מעטפת. תוקף עם חשבון GitHub מזויף עלול ליצור בעיה עם כותרת a"; bad_code_goes_here;#, ובום! 

זעם הביצהאה, החבר'ה האלה פתחו את הדלת להזרקת פקודות פשוט על ידי פתיחת בעיה...

היו פגיעויות בביצוע קוד בפעולות GitHub, כמו תגובה של גאג'ירה, תוקן כעת. אנא קרא "קלט לא מהימן בזרימות עבודה של GitHub" לקבלת פרטים מלאים.

מוסר ההשכל של הסיפור: לעולם אל תבנו ותבנו יחסי ציבור ממקורות לא מהימנים מבלי לבדוק תחילה את יחסי הציבור. "'לא מהימן' כאן, אלא אם כן מדובר באימות דרקוני של המקור, יכול להתייחס לכל חשבון מפתח שעלול להיות נחטף."

 

פריסה לא מכוונת של תוכנות זדוניות כאן!

פריסה רציפה הוא שיא האוטומציה, אך שיא זה עלול להתסכל עקב היעדר בקרות אישור מתאימות ב- pipeline זרימה.

הסיכונים של פריסה אוטומטית לחלוטין מהמקור commit למערכות ייצור כוללים את האפשרות לפריסת קוד זדוני בסביבות ייצור מבלי שיתגלה, כמו גם את האפשרות לשגיאות בתהליך הפריסה שיגרמו לשיבושים או הפסקות פעילות.

על מנת למתן סיכונים אלה, מומלץ לעתים קרובות שארגונים יטילו "הפסקה קשה" (hard break) בתהליך הפריסה שלהם, הדורש אישור אנושי לפני פריסת גרסאות בסביבות קצה.

הם סוגרים את הדלתות

זעם הביצהסיסמאות ברירת המחדל המשמחות הללו ב CI/CD כלים נמחקים. גישה ל /var/lib/jenkins/secrets/initialAdminPassword הוא עכשיו מסלול מת. כלים רבים מספקים כעת 2FA, שקוביד הפך לפופולרי, ואפילו קוף הקוד הכי עצלן שיש משתמש בו!

M3M3N70אנחנו נלחמים ב-2FA, אבל זה לא כל כך קל. קשה לעשות פישינג על האנשים האלה, כי... "Scatter Swine" עשה עם טוויליועם מפתחות WebAuthn זה הרבה יותר קשה. לפחות, אנחנו יכולים לנסות גניבת עוגיות כדי לעקוף את MFA, אבל צריך לפרוץ לקופסת המפתחים.

אימות רב-גורמי הוא צעד טוב בכיוון הנכון להגבלת הסיכון לדליפות סודות אימות. רוב כלי ה-DevOps המודרניים תומכים ב-MFA. ומפתחות אימות תחת WebAuthn / U2F (ראה פרויקט FIDO2) הן אולי האפשרות הטובה ביותר עבור MFA ב-DevOps, אם ינוהלו כראוי.

זעם הביצהאנשי ה-DevOps מתעוררים. יש להם את עניין "הפריבילגיה הכי פחותה" בדם. והם כבר לא קופי קוד. עכשיו אנחנו נתפסים על חם על ידי מבקרים.

למעשה, pipelineכעת הם קצת יותר חזקים מאשר לפני כמה שנים, עם הסרת פעולות וסקריפטים חלשים, ועם שלבי בדיקת אבטחה נוספים שאפילו זיהו את ה-droppers שלנו מוסתרים בחשאיות. commitוחבילות שחטפנו.

שאלה לקורא: האם תהליך בניית התוכנה ממקורות ופריסתה לשלב הייצור הוא עסק מסוכן? האם אתם יכולים לראות את ה-DevOps שלכם בשלב של זמנים טובים בשביל הרעים?

המלצות אחרונות

מאיפה להתחיל CI/CD pipelines?

ההמלצה הראשונה פשוטה כאן: בזהירות סקירה pipelines (הם קריטי משאבים) לבעיות אבטחה. ביקורות יקרות אך הכרחיות, ויש לבצען כראוי. בודקים צריכים להיות מודעים למה לבחון. יש לבדוק כל שלב לאיתור פגמים.

אולי שילוב של בודקים מומחים חמושים בסורקי קוד זדוני אוטומטיים יוכל לעזור.

ההמלצה השנייה היא ל להכשיר מפתחים שכותבים pipelineולתחזק אותם תחת אבטחהדברים שיש לקחת בחשבון:

  • כיצד לטפל כראוי באימות עם שירותים פנימיים וענן, תוך הימנעות מהמטרד הכרוני בטיפול באישורים לטווח ארוך.
  • איך להגביל pipelineלקבוצת המשאבים המדויקת שאליה היא זקוקה גישה. עקרון הפריבילגיה הנמוכה ביותר זורח שוב.
  • איך לכתוב את השלבים ליצירת pipelineניתן לשחזור כמו הצמדת גרסה, והימנעות מפגיעויות של הזרקת פקודות.
  • כיצד לאשר פריסות מנקודת מבט ביטחונית (הן אחרות!): איזו אבטחה standardיש להתאים את ה-s וכיצד להוסיף בדיקות/שערים תואמים ב- pipelines.

המלצה שלישית היא ל להגדיר את CI/CD מערכת בזהירות הראויהאימות חזק, ללא סיסמאות ברירת מחדל או הגדרות לא מאובטחות, הרשאות מינימליות... טפלו בפגיעויות בתוספים ותוספים המותקנים. זה עשוי להיות מוקד הפוסטים הבאים, אנא המשיכו לעקוב.

ההמלצה הרביעית היא למנף את CI/CD pipelines לאוטומציה של אבטחהניתוח קוד מקור (SAST), ניתוח הרכב המקורות (SCA), ניתן להפעיל באופן שגרתי סריקת דליפות סודיות, כלי אנטי-וירוס, סורקי אבטחת מכולות או גלאי זמן ריצה אוטומטיים (DAST ותוכנות זדוניות) על ה- pipelineוהארגון שלך עשוי לאכוף standardלגבי כיסוי על סריקת אבטחה ב CI/CD.

הזכירו, כלים אלה עדיין לא מסירים את הביקורת המקצועית מהמשוואה, אחרת אתם עלולים לקבל תחושת ביטחון כוזבת.

אם אתם בקיאים בעשרת התוצאות הטובות ביותר של OWASP, פרויקט נחמד אחרון הוא ה- OWASP 10 הראשונים CI/CD סיכון ביטחוני.

הערת הצהרת אחריות

(1) הדוגמאות בפוסט הזה משתמשות ב-GitHub כ- SCM, AWS כספק ענן, ו-GitHub Actions או Jenkins כ- CI/CD כלי. הם לא חלשים יותר / בטוחים יותר מהחלופות שלהם. אין כוונה רעה לפרסום! כלים אלה חזקים ויש להשתמש בהם כראוי.

(2) M3M3N70 ו זעם הביצה הן דמויות בדיוניות. כל דמיון לאנשים או לקבוצות, חיים או מתים, הוא מקרי בלבד... או שמא לא?

לקריאה נוספת

כלי SCA לניתוח קומפוזיציה - תוכנה
תעדוף, תיקון ואבטחת סיכוני התוכנה שלך
קבל את החשבון החינמי שלך.
אין צורך בכרטיס אשראי.
התחל בחינם

אבטחו את פיתוח ואספקת התוכנה שלכם

עם חבילת המוצרים Xygeni

התחל בחינם
צא לסיור במוצר
לוגו Xygeni לבן

© 2026 Xygeni. כל הזכויות שמורות

קישורין-אין X-טוויטר YouTube

מוצרים

משאבים

החברה

משפטי