מנכ"לים של חברות סטארט-אפ רבות נוטים להשקיע הרבה מחשבה, מטבע הדברים, בקצב הפיתוח, בהשגת המטרות העסקיות ועוד. אחד הנושאים שמטריד אותם פחות הוא סוגיות של רישוי ואבטחת מידע של הקוד. הנקודה היא שנושאים אלה עשויים לבוא לידי ביטוי בשלבים מתקדמים יותר בעת ביצוע עסקאות מול לקוחות ואף בעת מכירת החברה עצמה, ובשלב זה כבר יהיה קושי רב להתמודד איתם.
אפשר להבין את צוות הפיתוח, הם צריכים לעמוד בלוחות זמנים קצרים, וקוד פתוח, מטבע הדברים, עבר כבר עיניים בוחנות ושיפורים והכי חשוב שזה בחינם. אז למה לא?
אני מזמין אתכם לחשוב על התרחיש הבא: לקוח חשוב פונה אליכם בעקבות סריקת פגיעויות שביצע. מתברר שזוהתה פגיעות, שפורסמה לאחרונה באחת מספריות הקוד הפתוח ששולבה אצלכם במערכת. אתם בכלל לא מודעים לכך, מאחר שאינכם עוקבים אחר ספריות הקוד הפתוח ואינכם מנהלים את הנושא. מה יהיה ה-SLA שתציעו ללקוח לטיפול בבעיה? מה אם יתברר שהספרייה כבר לא מתוחזקת כנדרש אצל המפתחים המקוריים, אבל היא מהווה חלק מהותי אצלכם בקוד?
נתחיל עם סוגיית הקוד הפתוח שמדאיגה מרכזי פיתוח רבים. הרישוי הנוח ביותר הוא מסוג Permissive Licenses דוגמת MIT License. הוא מאפשר שימוש, שינוי והפצה של הקוד גם בפיתוח תוכנה שלכם והמגבלות הן מינימליות. לצדו קיים רישוי נוקשה יותר שמחייב מתן קרדיט למי שכתב את הקוד המקורי, דוגמת MPL.
אבל אם המפתחים שילבו קוד עם רישוי מסוג Copyleft Licenses דוגמת GPL, השילוב יוצר סיכון. במקרה כזה הקוד שכתבתם יידרש להיות פתוח ומותר לשימוש עבור כולם, ויתרה מזאת עליכם אף לפרסם אותו. במילים אחרות הקוד שפיתחתם כבר אינו רק שלכם אלא של כולם ואתם איבדתם את ה-IP-Intellectual Property הייחודי שלכם. נושא זה הופך היום למורכב יותר, מאחר שמפתחים רבים משתמשים ב-AI, דוגמת: ChatGPT. החשש הוא שהקוד שייווצר בעזרת AI ישלב בתוכו קטעי קוד פתוח עם רישוי מסוג GPL בלי שתהיו מודעים לכך והקוד האיכותי שקיבלתם עשוי לפגוע בכם בהמשך.
עכשיו אנו מגיעים לסוגיה הבאה, והיא היכולת לעקוב אחר פרסומים על פגיעויות שנתגלו בספריות קוד פתוח שמשולבות בקוד שלכם. מן הסתם אתם אחראים לאבטחת הקוד שפיתחתם, וכל עסקה עם לקוח רציני שפועל תחת רגולציה כלשהי: CMMC, HIPAA, GDPR, SOC2, תחייב אתכם להציג בפניו ניהול מסודר של ספריות הקוד הפתוח, כחלק מתוכנית SBOM (Software Bill of Materials) מסודרת. אם אין לכם תיעוד מסודר של ספריות הקוד הפתוח ואתם לא מבצעים מעקב אחר פגיעויות שמתפרסמות, לא תדעו על הפגיעות שפורסמה ולא תוכלו להיערך בהתאם.
כל הסוגיות הללו קשורות לשילוב של קוד זר במערכת שלכם. לכך יש להוסיף את החשש הסביר שהקוד שהצוות מפתח בעצמו אינו מוקשח כנדרש, ועליכם מוטלת האחריות לבדוק אותו כחלק אינטגרלי מתהליך האוטומציה של CI/CD אצלכם בארגון. לעתים קרובות מפתחים כותבים באופן בלתי מאובטח, וגם הקישוריות עם מערכות נוספות דוגמת API גוררות עמן מורכבויות, דוגמת: הקפדה על אימות, הזדהות והעברת מידע באופן מוצפן.
אז מה מומלץ לעשות? ראשית יש לבצע סקר סיכונים לאופן פיתוח הקוד אצלכם. לאחר מכן מומלץ לשלב בצוות הפיתוח איש אבטחת מידע שמתמצא בפיתוח (DevSecOps) ושידאג לכל הנושאים הללו באופן שוטף. הוא יגדיר מדיניות למפתחים וידריך אותם, יבצע בדיקות באופן שוטף לקוד כולל ממשקי API תוך שימוש בכלים מתאימים, ימפה את ספריות הקוד הפתוח על מנת לבחון בעיות רישוי וחולשות, ויאפשר לארגון לפתח באופן מאובטח וללא בעיות רישוי.
ועכשיו נחזור לתרחיש שציינתי בתחילת המאמר. בהנחה שאצלכם עוקבים אחר פרסומים אודות חולשות שרלוונטיות לספריות הקוד הפתוח שברשותכם, הייתם אמורים להיות מודעים וערוכים ואולי אף עדכנתם מראש את הלקוח. כך הלקוח יבין שאתם מעודכנים, עוקבים אחר הפרסומים ומנסים לסייע בפתרון הבעיה במסגרת SLA תקין.
הנושאים האלה יעמדו במרכז בוקר מקצועי לבכירים המובילים פיתוח בארגון, בהובלת Madsec מקבוצת SQlink
במהלך האירוע ירצו מומחים בכירים מעולמות הפיתוח, ה-AppSec והרגולציה שיציגו גישות מעשיות לשילוב אבטחת מידע כבר בשלבי הארכיטקטורה והפיתוח.
יום שני, 10.11 בשעות 9:00-12:00
במתחם SQlink Innvation, מנחם בגין 11, ר"ג, קומה 30
ההשתתפות ללא עלות, בהרשמה מראש >>
בשיתוף Madsec security
