מה זה AppSec? הסבר פשוט + כמה משרות פתוחות בישראל

AppSec, אבטחת אפליקציות, הוא התחום שמוודא שהתוכנה עצמה נבנית מאובטחת - מהתכנון ועד הייצור - במקום לנסות להגן עליה מבחוץ אחרי שנכתבה. בלוח HiTakeJob פתוחות כרגע 47 משרות שמזכירות CI/CD, 28 בקטגוריית סייבר ו-18 שמזכירות אבטחה.

למה הגנה מבחוץ לא מספיקה

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

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

איפה אבטחה נכנסת לתהליך

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

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

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

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

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

מה זה מידול איומים

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

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

מה נשבר בפועל

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

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

אילו חולשות מופיעות הכי הרבה

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

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

מה התפקיד כולל בפועל

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

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

מה זה שרשרת האספקה של התוכנה

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

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

איך נכנסים לתחום

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

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

הרחבנו על הבדיקה החיצונית המשלימה במה זה PT אפליקטיבי ועל מודל ההרשאות במה זה Zero Trust.

שאלות נפוצות

מה ההבדל בין AppSec ל-DevSecOps?

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

מה זה OWASP?

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

האם כלי סריקה מספיקים?

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

צריך לדעת לפתח?

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

כמה משרות בתחום יש בישראל?

המאגר אינו מתייג AppSec בנפרד. בקטגוריית סייבר ואבטחת מידע פתוחות 28 משרות, 18 מזכירות אבטחה ו-47 מזכירות CI/CD - שהיא התשתית שבה התחום פועל. חלק מהמשרות מפורסמות כ-DevSecOps.

מאיפה מתחילים בארגון שאין בו כלום?

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