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

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

מהיר יותר = בטוח יותר

מאת עודד שופן

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

אבל המשפט הזה לא סתם שגוי. הוא בדיוק מה שהצד התוקף הכי אוהב לשמוע. לא מדובר פה ברעיון חדשני – כבר ב-2017 פרסמנו ב-Pivotal (היום חלק מ-VMware Tanzu) מניפסט אבטחה עם הכותרת: Faster is Safer. הרעיון נשמע אז כמעט חצוף: במקום להקשיח מערכות ולהקפיא אותן, צריך להזיז אותן כל הזמן.

לפני כמה שבועות פרסמנו עדכון לאותו מניפסט, תחת הכותרת "Faster is Still Safer". הפעם זו כבר לא פרובוקציה ארכיטקטונית, אלא תיאור של מציאות. מה שהשתנה בדרך הוא התוקף.

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

כמו לעמוד בתוך סופת ברקים

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

מחקר חדש שפרסמנו ממחיש מה המודלים המתקדמים ביותר מסוגלים לעשות בתחום גילוי וניצול חולשות, ומצייר תמונה אחרת: מודלי AI מכווצים את חלון הזמן שבין פרסום חולשה לניצול פעיל שלה משבועות לשעות – בהתמדה ובקנה מידה שאף תוקף אנושי לא מתקרב אליהם. ברגע שתיקון אבטחה רואה אור, מודלים עוינים מנתחים את ה-Changelog ואת ה-Diff ומהנדסים מהם את ה-Exploit לאחור. יום פרסום ה-Patch הוא כבר לא סוף הסיפור, אלא יריית הפתיחה של מרוץ, והמרוץ הזה קצר מאי פעם. תוסיפו לכך סוכני AI שיודעים לשרשר כמה פוגענים ברמת סיכון נמוכה ש"לא מזיקים" ל-Remote Code Execution מלא, ותגיעו גם אתם למסקנה שהובילה את המחקר: אם ההגנה שלכם נשענת על ועדת שינויים שצריכה לאשר כל תיקון בנפרד – אתם לא משחקים הגנה. אתם עומדים במקום בתוך סופת ברקים.

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

מכאן נולדו שלושת ה-R-ים: Rotate,‏ Repave,‏ Repair.

Rotate: הרשאות עם תאריך תפוגה

פעם הכוונה הייתה להחלפת סיסמאות, מפתחות API ותעודות TLS בתדירות של ימים או שעות, כדי שהרשאה שדלפה תהיה חסרת ערך. אך ב-2026 הבעיה החריפה: אפליקציות מודרניות הן כבר לא רק קוד שמדבר עם דאטה בייס, אלא סוכני AI שמפעילים כלים, קוראים ל-APIs חיצוניים ורצים בלולאות אוטונומיות. מפתח התחברות סטטי שנחשף בתוך הלוג של הסוכן, או חולץ ממנו בהתקפת Prompt Injection, נסרק ומנוצל על ידי סקריפטים עוינים באופן כמעט מיידי.

לכן, העיקרון המנחה הוא שזהות צריכה להיות דינמית וקצרת-חיים: Secrets מוזרקים ב-Runtime במקום לחיות בקוד, בקונפיגורציה או בריפו; כל קריאה לשירות נשענת על זהות מאומתת עם תוקף קצר (OIDC עושה כאן עבודה יפה); ותעודות מתחלפות אוטומטית לפני שפגו. המבחן פשוט: אם מפתח דלף – עד שמישהו ינסה להשתמש בו, הוא כבר אמור להיות חסר ערך.

Repave: השרת שנולד מחדש כל כמה שעות

ה-R השני הוא הרדיקלי מהשלושה, ולטעמי גם החזק שבהם: להרוס ולבנות מחדש את הסביבה כולה – מכונות וירטואליות, קונטיינרים, הכל – ממצב ידוע ונקי (Known Good State), באופן שגרתי ומתוזמן. לא כשיש סיבה לעשות את זה, אלא כל הזמן.

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

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

Repair: לתקן במהירות של מכונה

כאן אנחנו מגיעים לכאב האמיתי. ההמלצה שלנו מ-2017 – להטמיע Patches תוך שעות מפרסומם – נשמעה אז שאפתנית. אבל היום היא רף מינימלי, כי כפי שראינו, ה-Patch עצמו הוא חומר הגלם של ניצול החולשה הבא.

המכשול לעדכון מהיר הוא כמעט אף פעם לא מודעות – אלא Dependency Debt וחיכוך תפעולי. בסביבה טיפוסית, תיקון חולשה במערכת ההפעלה או ב-Runtime מחייב אלפי מפתחים לעדכן Dockerfiles, לבנות מחדש עשרות אימג'ים ולהעביר הכל דרך פייפליין בדיקות אינסופי. עד שזה מסתיים יכולים לעבור שבועות, והאורח הלא קרוא כבר בפנים.

הפתרון הארכיטקטוני הוא הפרדה בין קוד האפליקציה לשכבות שמתחתיו: מערכת ההפעלה, ה-Runtime והתלויות. כשהשכבות מופרדות, מתקנים פעם אחת ברמת הפלטפורמה – Base Image מוקשח, Buildpack מעודכן – והתיקון מתגלגל אוטומטית לכל האפליקציות בצי, בלי שמפתח נוגע בשורת קוד. יש לנו לקוחות שמריצים כך יותר מ-100 אלף עדכוני פלטפורמה בחודש, ואחד מהם מתכנן להגיע ל-250 אלף – לא בחלונות תחזוקה ליליים, אלא כשגרה שקופה שאיש אינו מרגיש בה. ב-Charles Schwab, שמריצים כך 120 אלף קונטיינרים, תיארו איך זה נראה ביום שבו פרצת ה-Log4j הגיעה לעולם: "עד שאחרים הספיקו לקבוע פגישות כדי לדון איך מתקנים, אנחנו כבר סיימנו לתקן". כשזה המצב, CVE חדש מפסיק להיות אירוע חירום עם חדר מלחמה, והופך לעוד תיקון שנסגר בקצב התפעול הרגיל.

ומה עם אפליקציית ה-Spring ההיא מ-2019?

כאן אני רוצה לעלות מרמת התשתית למקום שמפתחי Java בישראל מכירים מקרוב. נתח עצום מהבקאנד הארגוני – אצלנו ובעולם – רץ על Spring, וכמעט בכל ארגון שאני פוגש יש את "האפליקציה ההיא": היא רצה על Spring Boot 2.7 או ותיקה יותר, עובדת מצוין ואף אחד לא נוגע בה.  "אם זה עובד, לא נוגעים". הבעיה היא שכל גרסת Boot Spring מקבלת תיקונים בקוד הפתוח במשך כשנה בלבד, ומי שנשאר מאחור נותר ללא תיקוני אבטחה – דווקא בעידן שבו כל CVE הופך ל-Exploit בתוך שעות.

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

• לקנות זמן בצורה אחראית. תמיכה מסחרית ב-Spring ממשיכה לספק תיקוני אבטחה לגרסאות ישנות – כולל תיקוני Zero-Day לחולשות קריטיות, גם לגרסאות Spring Framework ו-Spring Boot שכבר עברו את סוף התמיכה הקהילתית. זאת לצד עשרות פרויקטים נוספים של Spring ,OpenJDK ו-Tomcat. המשמעות בשטח: האפליקציה הוותיקה ממשיכה לקבל Patches בזמן שאתם מתכננים מיגרציה בקצב שלכם, ולא בקצב שמכתיב לכם התוקף.
• להוזיל את השדרוג עצמו. הסיבה שכולם דוחים שדרוגים היא שהם יקרים וכואבים. בשוק קיימים כלים שפותרים את הנקודה הזאת: הם ממפים את פורטפוליו האפליקציות, בונים תוכנית שדרוג מדורגת ופותחים Pull Requests אוטומטיים שמעדכנים גם את קובצי ה-Build וגם את הקוד עצמו (מתחת למכסה המנוע רצים מתכונים של OpenRewrite – בלי שתצטרכו לכתוב או לתחזק אותם בעצמכם). ברגע שצוות הפיתוח כבר לא צריך לגלות, לחקור ולתקן לבד, אלא פשוט לעשות Review ל-PR, השדרוג מפסיק להיות פרויקט רבעוני טראומטי והופך לזרם קבוע של שינויים קטנים. וזה בדיוק עקרון ה-Repair – הפעם על הקוד שלכם, ולא רק על התשתית.

כאן צריך לבוא גילוי נאות כפול. הראשון: אני עובד בצוות שבונה את הכלים האלה. השני: אפשר לעשות את זה גם לבד. OpenRewrite הוא פרויקט קוד פתוח, וכל העקרונות במאמר הזה ישימים בכל סטאק. המחיר הוא שאת "המתכונים" – ההוראות שאומרות לכלי מה בדיוק לשנות בקוד בכל שדרוג – תצטרכו לכתוב ולתחזק בעצמכם, ולעדכן אותם בכל פעם שיוצאת גרסה חדשה. זה בדיוק היתרון של Vendor: ב-Spring, הצוות שכותב את הגרסה החדשה של Spring Boot הוא גם הצוות שכותב את המתכון שמשדרג אתכם אליה. מי שיודע מה השתנה בקוד יודע גם איך לשדרג אליו, ואתם מקבלים את זה ביום הפרסום, לא אחרי שמישהו בקהילה יתפנה לזה.

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

אז מה עושים מחר בבוקר?

הנה חמישה צעדים מעשיים, בסדר עולה של מאמץ:

1. מדדו את זמן התגובה האמיתי שלכם לחולשות. כמה זמן עבר בפעם האחרונה מפרסום CVE קריטי ועד שהתיקון רץ בסביבת ייצור? אם התשובה נמדדת בשבועות – זה ה-KPI שכדאי לתקוף, לפני כל רכישה של עוד כלי אבטחה.
2. מפו את החשיפה. הכינו SBOM עדכני: אילו גרסאות של NET ,Spring. ו-Dependencies רצות ואיפה. כמה מסביבת הייצור שלכם רץ על גרסאות שכבר לא מקבלות עדכונים? אי אפשר לתקן את מה שלא יודעים שקיים.
3. התחילו לחסל Secrets סטטיים. כל מפתח או סיסמה שיושבת בקוד, בקונפיגורציה או במשתנה סביבה באופן קבוע הם Security Debt. עברו לזהויות קצרות-חיים ולהזרקה ב-Runtime.
4. קבעו Repave כשגרה, אפילו אם בהתחלה זה יהיה רק אחת לשבוע: בנייה מחדש של הסביבה מ-Base נקי, אוטומטית, בלי סיבה מיוחדת. עצם היכולת לעשות את זה בביטחון היא מדד הבשלות הטוב ביותר שיש. אם אין לכם מספיק משאבים לזה, בשוק קיימות פלטפורמות שעושות זאת עבורכם באופן אוטומטי לחלוטין.
5. הפכו שדרוגים מאירוע לשגרה. Pull Requests קטנים ותכופים במקום מגה-פרויקט שנתי – ידנית אם צריך, אוטומטית אם אפשר.

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

הכותב הוא Principal Solutions Architect ב-VMware Tanzu by Broadcom ו-Developer Advocate של פרויקט Spring