תוכנות העושות שימוש בקוד פתוח נמצאות בכל מקום. החל מהשרתים בהם אנו עושים שימוש ועד  הדברים הכי קטנים בחיים שלנו כמו צמידי כושר. השימוש בקוד פתוח הופך נפוץ יותר ויותר כאשר למעלה מ- 90% מהמפתחים מסתמכים על הקוד הפתוח לאורך תהליך הפיתוח שלהם.

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

מהי אבטחת קוד פתוח (ותפקידו של מי זה)?

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

עם זאת, אין דבר מושלם בחיים ואף בפתרון הקוד הפתוח ישנם חסרונות. ה- FOSS  (free open-source software) אינו נבדק היטב והתהליך מתועד לעיתים רחוקות. יתרה מכך, לשקיפות הקוד ישנו גם סיכון – נקודת תורפה של תוקפים פוטנציאליים לניצול.

יותר ויותר חברות תוכנה משלבות קוד פתוח בקוד שלהן, וכתוצאה מכך הצורך לפקח באופן יזום על פרויקטים לצורך המשכיות שלמות המידע – CI (continuous integration) ואספקה רציפה – CD (continuous delivery) באמצעות DevSecOps  הפך להיות חשוב מאין כמוהו.

התפקיד של DevSecOps כולל מספר פעולות ומשימות המכסות את כל שלבי הפיתוח, לפני ואחרי:

• יש ליצור SBOM (Software Bill of Materials), רשימה של רכיבי OSS וספריות המשולבים בתוצרת הסופית.
• הגבלת החשיפה על ידי תיעדוף ספריות OSS המהוות את הסיכון הנמוך ביותר.
• מעקב אחר DEPENDENCIES LIBRARY נדרש לצורך שילוב קוד OSS כדי להבטיח שלא יוכנס לתוך הפרויקט קוד ממקור לא ידוע.
• צמצום השימוש במספר ספריות המציעות פונקציונליות דומה, על ידי סטנדרטיזציה של הספריות הזמינות למפתחים בפרויקט.
• ניתוח נתונים בזמן ריצה לפי השימוש, כדי לעקוב אחר נקודות תורפה אפשריות של OSS על ידי חקירת התנהגות האפליקציה.
• זיהוי וחסימה של התקפות מתוך היישום עצמו באמצעות הגנה עצמית של יישום בזמן ריצה (RASP).
• סקירה של הקוד הן באופן ידני והן באמצעות תוכנות אוטומטיות.
• סריקת בעיות התאמה לרישיונות, אימות התאמה בין רישיונות הקוד הפתוח לרשיון הפרויקט, והצעת חלופות בעת הצורך.

מדוע ספריות קוד פתוח חשופות במיוחד להתקפות סייבר?

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

שירותי סייבר שתוכלו לקבל ב Cybersafe:

• חברת אבטחת מידע לעסקים
• ייעוץ אבטחת מידע
• שירותי SIEM SOC
• טיפול בוירוס כופר
• מבדקי חדירה Pen Testing

מדוע אבטחת קוד חשובה כעת יותר מתמיד?

ככל שגדל השימוש בספריות קוד פתוח, מספר הפגיעויות המתגלות גדל באופן משמעותי. בשנת 2019, 968 נקודות תורפה חדשות קיבלו מספר CVE  (פגיעויות וחשיפות נפוצות), לעומת 421 בשנת 2018, עלייה של 224% משנה לשנה. נוסיף לכך את העובדה כי ל- 7 מתוך 10 יישומים יש חולשת אבטחה בספריית קוד פתוח, בעוד שהתקפות המכוונות לרכיבי קוד פתוח עלו ב – 430%.

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

דוגמאות לחולשות אבטחה שנוצלו:

1. ספריות Python גנבו מפתחות SSH ו- GPG.
2. פגיעויות קריטיות נמצאו בSALTSTACK – בכלי האוטומציה וניהול תצורה.

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

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