כיצד GitLab עוזר למנוע התקפות שרשרת אספקה ותוכנות זדוניות מלהיכנס לסביבות פיתוח
השימוש ב-GitLab כפלטפורמת ה-DevOps מקצה-לקצה שלך עוזר למנוע התקפות שרשרת אספקה (כמו הפריצה האחרונה ל-PyPI litellm) ולחסום כניסת תוכנות זדוניות לסביבה שלך על ידי אכיפת בקרות ישירות בצינור ה-CI/CD, בזרימת התלויות ובשכבת הזהות.
להלן האופן שבו זה ממפה את מודל האיומים הקונקרטי שלך.
הערה: יישום פרקטיקות אלו דורש מופע של GitLab (בניהול עצמי או SaaS) ומנוי GitLab Ultimate.
בנוסף, מומלצת הבנה בסיסית של DevOps, DevSecOps או AppSec.
אם אתם זקוקים לעזרה עם רישוי או יישום טכני, אתם מוזמנים לפנות לצוות שלנו בכתובת gitlab@almtoolbox.com או להתקשר אלינו.
1. חסימת תלויות זדוניות או פגיעות
כאשר חבילה כמו litellm מורעלת ונדחפת ל-PyPI, יכולה GitLab להפחית או למנוע את ההשפעה באמצעות:
- סריקת תלויות (Dependency Scanning): בודקת באופן אוטומטי את קבצי ה-requirements.txt, package-lock.json שלכם וכד'
ומסמנת חבילות פגיעות או שנפרצו (כולל אלו שנמשכו מ-PyPI) בכל צינור (pipeline). - SBOM ותרשים תלויות: GitLab יכולה לייצר רשימת חומרי תוכנה (Software Bill of Materials) ולעקוב אילו פרויקטים תלויים באילו גרסאות; לאחר מכן תוכלו לחסום או לתקן גרסאות מסוכנות לפני שהן מגיעות לייצור.
- פרוקסי / חומת אש לתלויות: אם אתם משתמשים בפרוקסי של GitLab לפיד ה-PyPI/NPM שלכם וכו', תוכלו להגביל גרסאות מורשות ולאכוף שימוש רק במקורות (upstreams) "מאושרים בלבד".
השפעה מעשית: גם אם מישהו כותב pip install litellm בקובץ requirements.txt, יכולה GitLab להכשיל את המשימה או לחסום את הבנייה אם הגרסה המותקנת מופיעה במדיניות הפגיעויות/הרשימה המורשית שלכם.
2. הקשחת צינור ה-CI/CD עצמו
המתקפה בסגנון litellm חשפה דפוס שבו ספריות זדוניות ב-CI/CD גונבות אסימונים וסודות; GitLab מפחיתה סיכון זה על ידי:
- הגנה על .gitlab-ci.yml ומשתנים:
- דרישת ענפים מוגנים (protected branches), שינויים מבוקרי CODEOWNERS בקובץ .gitlab-ci.yml וגישה קפדנית מבוססת תפקידים, כדי שתוקפים לא יוכלו להזריק משימות זדוניות.
- שימוש במשתנים מוגנים וסודות מוסווים (masked secrets) כך שרק צינורות (pipelines) מאושרים יוכלו לראות אותם.
- אבטחת ה-Runners:
- שימוש ב-"protected runners" וב-runners ייעודיים לפרויקט, כך שהרעלת פרויקט אחד לא תעניק גישה רחבה לכל ה-CI/CD שלכם.
- זיהוי סודות (Secret Detection): סריקת קומיטים (commits) ובקשות מיזוג (MRs) לאיתור מפתחות API, אסימונים או סודות שהועלו בטעות; מונע מהם להגיע לענף הראשי (main) מלכתחילה.
השפעה מעשית: אם תוקף מצליח איכשהו להזריק סקריפט זדוני למשימה, צמצום טווח המשתנים ובידוד ה-runners מגבילים את הנתונים שהוא יכול לגנוב או את היכולת שלו להתפשט.
3. מניעת כניסת קוד דמוי תוכנה זדונית לסביבה שלכם
GitLab פועלת כ"שער" לפני שקוד ותוצרים מגיעים לייצור:
- סריקות אבטחה בגישת Shift-left בכל צינור (pipeline):
- סריקות SAST (פגיעויות ברמת הקוד), DAST (זמן ריצה), סריקת קונטיינרים ותאימות רישוי פועלות בכל משימה, כך שתוכלו לזהות מוקדם דפוסים דמויי סוס טרויאני, דלתות אחוריות או קוד שנראה זדוני.
- שערי אישור (Approval gates) לפני פריסה:
- ניתן לאכוף אישורים, שערי סריקות אבטחה, ו"דרישת הצלחת צינור" עבור סביבות ייצור, כך שקומיט או תלות זדוניים לא יוכלו להיות נפרסים בשקט.
- יכולת מעקב ויומני ביקורת (Audit logs):
- GitLab עוקבת אחר כל שינוי, מיזוג, ריצת צינור ופריסה, מה שמקל על איתור המקור של חדירת תוכנה זדונית (למשל, דרך חבילה שהותקנה על ידי tox) ומאפשר לבטל או לחסום אותה.
השפעה מעשית: כל שינוי "בסגנון תוכנה זדונית" (למשל, חבילה חדשה שמתחילה לקרוא לנקודות קצה מוזרות או לשנות קבצים) אמור להיתפס בסריקה, להיחסם על ידי מדיניות, או להשאיר נתיב ביקורת ברור שניתן לעקוב אחריו.
4. בקרות זהות, גישה ו-Zero-Trust
התקפות שרשרת אספקה מסתמכות לעיתים קרובות על הרשאות גנובות ותפקידים מתירניים מדי. GitLab עוזרת בכך באמצעות:
- RBAC פרטני ו-2FA: אכיפת אימות דו-שלבי, תפקידי הרשאה מינימלית (least-privilege) ואישורים עבור שינויים ברמת הייצור.
- קומיטים חתומים ומחברים מאומתים: דרישת קומיטים חתומים ב-GPG ואימות מי באמת ביצע את הדחיפה (push); GitLab יכולה לדחות קומיטים לא חתומים או מחברים לא מהימנים, ובכך להפחית מקרים של התחזות.
- רישום יומנים מוכן לביקורת: סקירת מי שינה את צינור ה-CI/CD, אילו תלויות נוספו, ואילו סביבות הושפעו לאחר אירוע.
השפעה מעשית: הדבר מקשה על תוקף לחטוף חשבון של מפתח או להזריק קוד נגוע מבלי שיזוהה במהירות.
איך זה נוגע אליכם אם אתם ארכיטקטים של DevOps / DevSecOps?
כארגון המשתמש ב-GitLab, אתם יכולים:
- להתייחס ל-GitLab כמנוע המדיניות המרכזי עבור:
- גרסאות תלויות מותרות.
- סריקות אבטחה נדרשות.
- ענפים וסביבות מוגנים.
- להשתמש ב-Dependency Scanning + SBOM + אישורים של GitLab כדי:
- לזהות ולחסום חבילות מורעלות כמו litellm (גם אם הן עדיין לא במאגרי CVE).
- לאכוף "חסימת תלויות ברמת CVE או מפרות מדיניות" בשערי בקשות המיזוג (MR).
ALM Toolbox סייעה למאות לקוחות בתמיכה ב-GitLab, בבחירת המהדורה והרישיון המתאימים ובתכנון היישום והפריסה של המוצר.
אנו שותפים רשמיים של GitLab מאז 2016 ומחזיקים בתארים שהוענקו על ידי חברת GitLab:
Selected Partner, GitLab Hero ו-"GitLab Champion", וכן בהסמכות מקצועיות רשמיות של GitLab לאחר מעבר מבחני הסמכה.
לאחרונה, נבחרנו גם על ידי חברת המחקר STKI כ-"GitLab Selected Partner" לשנת 2025.
ניתן ליצור איתנו קשר בדוא"ל בכתובת gitlab@almtoolbox.com או להתקשר אלינו:
072-240-5222
