WEBA

נעילת גרסאות ב-GitHub Actions: הגנה רק לעשירים

פיצ'ר חדש מונע הרצת קוד עוין מתגיות Git שנחטפו בלי להקריב את קריאות ה-YAML, אבל GitHub השאירה את רוב המפתחים בחוץ.

558 מילים25 עובדות אומתו

לתת לפייפליין שלכם להריץ תגית כמו v4 זה כמו להשאיר מפתח מתחת לשטיח ולקוות שהפורץ לא מכיר את השיטה. השבוע, ב-14 באוקטובר 2026, השיקה GitHub מענה לתופעה: נעילת תלויות באמצעות קובץ lockfile בתהליכי עבודה. המנגנון מאפשר להשאיר שמות תגיות קריאים ונוחים בתוך קובץ ה-YAML, אבל בפועל להריץ אך ורק קומיט SHA ספציפי שננעל מראש ונשמר בקובץ ייעודי בנתיב actions.lock. זה חוסם מתקפות שרשרת אספקה שבהן תוקף משתלט על מאגר חיצוני ומזיז את התגית לגרסה זדונית.

זה שינוי מתבקש.

סוף למלכודת התגיות הזזות

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

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

מנגנון הנעילה החדש מקפיא את מזהה הקומיט המדויק מאחורי הקלעים, כך שגם אם תגית ב-Git תידרס על ידי גורם עוין, מנוע הריצה יסרב להריץ את השינוי. הקובץ actions.lock מייצר תמונת מצב של כל התלויות, כולל תלויות מעבר ופעולות שמופעלות מתוך תהליכי עבודה לשימוש חוזר. על הפתרון עבדו ב-GitHub בשנה האחרונה בצמוד עם מפתחים בקהילה כמו Andrew Nesbitt ו-William Woodruff, כדי לוודא שהכלי אכן עונה על צרכים אמיתיים בשטח.

רק למנויי Enterprise Cloud

הבשורות הטובות נעצרות ברגע שמגיעים למודל הרישוי. התכונה זמינה כעת בתצוגה מקדימה ציבורית אך ורק ללקוחות GitHub Enterprise Cloud, כולל מסלולים עם תושבות מידע ייעודית. אם הארגון שלכם מנוי למסלול Team או מריץ פרויקטים במסלול החינמי, נשארתם בחוץ. אותו הדבר נכון גם לגבי מי שמתחזק שרת פנימי מסוג GitHub Enterprise Server, שאינו מקבל תמיכה כרגע.

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

אימוץ הדרגתי ועדכונים אוטומטיים

העבודה השוטפת עם המנגנון אינה דורשת שינוי מיידי של כלל המאגרים בארגון. יצירת הקובץ actions.lock ותחזוקתו מתבצעות דרך תוסף רשמי ל-GitHub CLI בשם gh actions-lock. הכלי מאפשר לצרף כל קובץ תהליך עבודה באופן הדרגתי, ובודק אם קובץ הנעילה אינו מעודכן מבלי לבצע שינויים בקוד, בדיקה שמתאימה להרצה ישירה כחלק מבדיקות ה-CI עצמן.

כדי למנוע תקיעות של גרסאות ישנות, המערכת משתלבת ישירות עם Dependabot. כאשר הכלי מזהה גרסה חדשה ופותח בקשת מיזוג לעדכון הפעולה, הוא מעדכן במקביל ובאותו שינוי גם את הרשומה התואמת בקובץ הנעילה. מנהלי מערכת שרוצים לכפות יישור קו גורף יכולים להפעיל את המדיניות Require lockfile ברמת הארגון, המאגר או התאגיד, ולחסום הרצה של תהליכים שלא עברו צירוף מסודר.

קובץ נעילה אינו תעודת הכשר

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

ההגנה דורשת בדיקה מוקדמת.

לא ידוע מתי תיפתח תמיכה בשרתי GHES מקומיים, או כיצד יטופלו קונפליקטים מורכבים במיזוג קובץ הנעילה בסביבות מרובות מפתחים. כלי ניהול תלויות חיצוניים כמו Renovate כבר הוסיפו תמיכה ייעודית בהפקת actions.lock באמצעות תוסף ה-CLI הרשמי. אם אתם לא מחזיקים בחשבון Enterprise Cloud, מומלץ להמשיך להשתמש בנעילת קומיט SHA ידנית ישירות ב-YAML. בינתיים, רוב המפתחים ימשיכו לנעול את הדלת עם חוט תיל.

השוואת שיטות ההגנה מפני תגיות זזות ב-GitHub Actions
שיטהקריאות בקובץ YAMLהגנה מהזזת תגיותתמיכה בחשבונות חינםעדכון אוטומטי
שימוש בתגית גרסה (v4)גבוההאיןנתמךקליטת עדכונים של התגית בלבד
הצמדת commit SHA ידניתנמוכהמלאהנתמךדורש כלים חיצוניים
קובץ נעילה (actions.lock)גבוההמלאהלא נתמךנתמך דרך Dependabot
מה לעשות עכשיובדקו אם הארגון שלכם זכאי ל-Enterprise Cloud, ואם כן התקינו את gh actions-lock לפרויקטים רגישים; אם לא, המשיכו להיצמד לנעילת commit SHA ידנית.

מקורות

הידיעה נכתבה מהמקורות שלמעלה בתאריך הפרסום, וכל טענה בה נבדקה מולם. מצאתם טעות? כתבו.

מה שואלים על זה

איך יוצרים את קובץ הנעילה במאגר?

מתקינים את ההרחבה הרשמית gh actions-lock דרך ה-GitHub CLI. הפקודה מייצרת את הקובץ github/workflows/actions.lock. המכיל את מזהי הקומיט של הפעולות ותלויות המשנה שלהן, ואותו שומרים במאגר.

האם התכונה נתמכת בהתקנות מקומיות של GitHub Enterprise Server?

לא. בשלב התצוגה המקדימה הנוכחי, המנגנון זמין רק למשתמשי GitHub Enterprise Cloud, כולל ארגונים במסלול של תושבות מידע ייעודית.

מה קורה כשתגית חיצונית זזה או נדרסת אחרי יצירת ה-lockfile?

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

האם Dependabot יודע לעדכן את קובץ הנעילה באופן עצמאי?

כן. כאשר Dependabot פותח בקשת מיזוג (Pull Request) לעדכון גרסת פעולה בתהליך עבודה שכבר מנוהל במערכת, הוא מעדכן אוטומטית גם את הרשומה התואמת בקובץ actions.lock ללא צורך בהגדרה נוספת.