Security Gate ב-CI/CD: חסימה אוטומטית של פריסה

Security Gate לא עוצר את הדיפלוי: איפה הבקרה נשברת

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

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

הסיבה השלישית, הפחות בולטת — חריגים. כל התראה "מוכרת" נסגרת בכלל התעלמות, הרשימה גדלה, ובשלב מסוים היא מכסה את רוב הבדיקות הקריטיות. הפגיעות במהדורה נשארות בדוחות, אבל מפסיקות להשפיע על משהו.

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

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

מה נותנת חסימה אוטומטית של דיפלוי לפי בדיקות

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

מחלקת כשלים שנמנעה

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

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

מהירות הבנייה והשחרור

הבדיקות רצות במקביל ורק על נתיבים שהשתנו — הבקרה מוסיפה לבנייה דקות, ולא עשרות דקות. אישורים ידניים מוחלפים בכלל: הפייפליין ב-GitLab CI מפעיל את ההעלאה בעצמו אם כל הבקרות ירוקות.

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

אפשרויות בקרה: חסימה, התראה, כללים סלקטיביים

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

חסימה קשיחה בענפים מוגנים

הכלל פועל לפני המיזוג: הפייפליין לא מעביר שינוי עד שעברו בדיקות חובה של תלויות, סודות וניתוח סטטי. ב-GitLab זה מורכב מהגנת ענף ומדוחות חובה — אפשר לעקוף רק בהחלטה מפורשת של בעל המאגר, וההחלטה הזו נשארת בהיסטוריה.

מצב משולב לצוותים בוגרים

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

שלבי הטמעת בדיקות בפייפליין הבנייה והשחרור

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

ביקורת הפייפליין ומלאי הבדיקות

1. אוספים מפת פייפליין: שלבים בבנייה ולפני העלאה, סביבות, אישורים ידניים, זמן מעבר ממוצע.
2. עורכים מלאי של הבדיקות הקיימות — סורק תלויות, ניתוח סטטי, איתור סודות, בדיקת תמונות. לכל אחת מתעדים מצב: חוסמת, מתריעה או כותבת דוח שאף אחד לא קורא.
3. מתכננים סכמת נקודות בקרה: מה בודקים לפני מיזוג, מה בבניית הארטיפקט, מה לפני העלאה לסביבת הייצור. לכל נקודה מגדירים את מחלקת הממצאים שעוצרת אותה.
4. מגדירים כללים: ספים לפי קריטיות, קו בסיס לקוד ישן, חריגים עם בעלים ותאריך סקירה. כלל בלי בעלים הופך מהר לרעש נצחי.

הרצה מוקדמת במתאר בדיקות

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

מה מוסרים: כללי בדיקה, מדיניות גישה, נהלים

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

תצורות וניהול גרסאות של כללים

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

תיעוד ונוהל תגובה

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

מקרה בוחן: שיעור מהדורות החירום ירד פי שלושה

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

מה היה לפני ההטמעה

את הסורקים הפעילו ידנית לפני מהדורות גדולות, הדוח הגיע במייל למחרת — עד הקריאה חלק מהממצאים כבר עלה לפרודקשן. שיעור מהדורות החירום (חזרה לאחור או תיקון חם ביממה הראשונה) החזיק סביב 18%: כמעט כל מהדורה חמישית דרשה עבודה לא מתוכננת. בדיקה ידנית של שירות אחד ארכה 30-40 דקות של מהנדס, ובזרם פשוט דילגו עליה.

מה השתנה אחרי

הבדיקות שולבו ישירות בפייפליין הבנייה ב-GitLab: פגיעויות תלויות, סודות בקוד ובתצורות, הרשאות במניפסטים. ממצא קריטי עוצר את הדיפלוי עד לתיקון, ממצא בינוני עובר כמשימה לטרקר עם בעלים ומועד. זמן הבדיקה הצטמצם ל-4-6 דקות והוא רץ במקביל לבנייה — המהדורה לא מחכה לאדם נפרד. שיעור מהדורות החירום ירד ל-6%, כלומר פי שלושה.

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

במה Security Gate שונה מבדיקות בתוך הפייפליין?

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

Security Gate הוא מדיניות שחרור: מערך תנאים שבהם הארטיפקט מותר בכניסה למתאר היעד, ואם לא מתקיימים — המהדורה נאסרת בלי אישור ידני.

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

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

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

ספקות טכניים נפוצים לגבי בדיקות חוסמות

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

מה עושים עם התראות שווא?

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

אפשר לעקוף את החסימה?

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

יש לנו פייפליין פרוס — צריך לכתוב מחדש?

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

יהיה צריך להחליף את הכלים הנוכחיים?

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

נדון בסכמת הבדיקות ונחזור עם תוכנית הטמעה

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.