מפתחים משתמשים באופן שגרתי בקוד של צד שלישי כדי לבנות את היישומים שלהם למען יעילות וחיסכון בזמן. עם זאת, הסתמכות זו על רכיבים חיצוניים, ובמיוחד תוכנות קוד פתוח (OSS), מציגה סיכונים משמעותיים, כולל פגיעויות ובעיות רישוי. על פי סקר GitHub משנת 2023 , 31% מהמפתחים רואים במציאה ותיקון פגיעויות אבטחה את המשימה השנייה בחשיבותה, מיד לאחר כתיבת קוד (32%).
כתוצאה מכך, ארגונים רבים מודאגים מהתלות שלהם ב-OSS, שכן הוא מטרה תכופה של האקרים. ארגונים מתמודדים עם אתגרים של פגיעות מוגברת לאורך שרשרת האספקה של תוכנה ובהבנה כיצד להפחית סיכונים ביעילות בעקבות התקפות מתוקשרות אחרונות.
דו"ח מחקר של ESG מגלה כי 91% מהארגונים חוו תקרית בשרשרת האספקה של תוכנה ב-12 החודשים האחרונים. התקריות הנפוצות ביותר כוללות:
פגיעויות בולטות כמו Log4J, Curl, Apache Struts ו-OpenSSL הובילו כולן למקרים רבים של נזק תפעולי. אלה מדגישות את ההשפעה החמורה הנגרמת על ארגונים כאשר חולשה אחת בשרשרת אספקת התוכנה מנוצלת. בתגובה לסיכונים הגוברים הללו, גופים רגולטוריים ברחבי העולם מדגישים שקיפות ואבטחת תוכנה. אימוץ של Bill of Materials (SBOM) Software (SBOM) הופך לאסטרטגיה מרכזית לניהול סיכוני שרשרת אספקת תוכנה .
תקנות SBOM צוברות תאוצה
תקנות SBOM הופכות נפוצות יותר ויותר. ממשלות רבות פרסמו המלצות בנוגע ליישום SBOM. בארה"ב, המלצות SBOM כלולות במספר הנחיות ממשלתיות, ביניהן:
באירופה, סוכנות האיחוד האירופי לאבטחת סייבר (ENISA) פרסמה "הנחיות לאבטחת Supply Chain עבור האינטרנט של הדברים", המציע לארגונים תובנות חשובות לשיפור אבטחת הסייבר וניהול סיכוני שרשרת האספקה הקשורים לתוכנה.
מדינות אחרות פרסמו הנחיות דומות, ביניהן:
מייעץ לארגונים להשתמש ב-SBOMs כדי להעריך את הסיכונים הכרוכים ברכיבי התוכנה שהם משתמשים בהם, ולזהות ולטפל בפגיעויות ברכיבים אלה.
ב"מדריך אבטחת מידע: הנחיות עבור Software "פיתוח", ה-ACSC ממליץ להשתמש ב-SBOMs כדי לשפר את שקיפות שרשרת האספקה בסייבר, תוך הקלה על זיהוי וניהול סיכוני אבטחה הקשורים לרכיבי תוכנה בודדים המשמשים ביישומים.
כיצד PCI DSS מחייב יצירת SBOM
מתוך הכרה בסיכונים הגוברים לנתוני כרטיסי תשלום, תקן אבטחת הנתונים של תעשיית כרטיסי התשלום (PCI DSS) הפך לכוח מניע לאימוץ SBOM. הגרסה האחרונה, PCI DSS 4.0, מחייבת את השימוש ב-SBOM, ומדגישה את תפקידם הקריטי בהגנה על מידע רגיש. על ידי אספקת רשימה מפורטת של רכיבי תוכנה, SBOM מעצימים ארגונים לזהות ולטפל בפגיעויות באופן יזום, ובכך מפחיתים את הסיכון לפריצות נתונים יקרות ולהפסדים כספיים.
תקן PCI DSS, שנוסד בשנת 2004, הוא תקן אבטחה מקיף שנועד להגן על מידע בכרטיסי אשראי. הוא מתווה סט של דרישות מחמירות לעסקים המטפלים בעסקאות בכרטיסי אשראי, המותאמות לנפח העסקאות המעובדות מדי שנה. גרסה 4.0 של PCI DSS בשנת 2022 הציגה שינויים משמעותיים, כולל חובת SBOM, כדי להתמודד עם איומים מתפתחים. עמידה בתקן PCI DSS גרסה 4.0 היא חובה עד אפריל 2024, כאשר דרישות ספציפיות ייכנסו לתוקף בהדרגה עד ה-31 במרץ 2025.
על ידי חקיקת SBOMs, PCI DSS מאפשר לארגונים להשיג הבנה מקיפה של מערכת התוכנה שלהם, ומאפשר להם לזהות ולטפל בפגיעויות באופן יזום. גישה זו מפחיתה משמעותית את הסיכון לפריצות נתונים יקרות ולהפסדים כספיים.
גרסה חדשה יותר של PCI DSS, גרסה 4.0.1 , שוחררה באמצע 2024. משמעות הדבר היא שהגרסה הקודמת, 4.0, לא תהיה תקפה עוד לאחר 31 בדצמבר 2024. עם זאת, הגרסה החדשה אינה מוסיפה או מסירה כללים ואינה משנה את המועדים האחרונים. לכן, המידע אודות דרישות SBOM בבלוג זה חל הן על גרסאות 4.0 והן על גרסאות 4.0.1.
עמידה בדרישת PCI DSS 6.3.2
דרישת ה-SBOM ב-PCI DSS גרסה 4.0 היא חלק מהשיפורים הרחבים יותר שבוצעו ב-PCI DSS בגרסה האחרונה שלו. דרישת ה-SBOM, שהוצגה כחלק מ-64 הדרישות החדשות שנוספו בגרסה 4.0, מטפלת ספציפית בצורך של ארגונים לתחזק מלאי של רכיבי תוכנה, תוך התמקדות בתוכנה בהתאמה אישית ובהתאמה אישית.
דרישה זו מסווגת תחת דרישת PCI DSS מספר 6, המחייבת יצירה ותחזוקה של מערכות ויישומים מאובטחים באמצעות יישום אמצעי אבטחה חזקים וביצוע שוטף של הערכות ועדכוני פגיעויות. דרישה זו חיונית להפחתת הסיכונים הנשקפים מפגיעויות תוכנה ולהגנה על נתוני בעלי כרטיסי אשראי. סעיף 6 מכסה חמישה תחומים עיקריים:
- 6.1 תהליכים ומנגנונים לפיתוח ותחזוקה של מערכות ותוכנות מאובטחות מוגדרים ומובנים.
- 6.2 תוכנה בהתאמה אישית ומותאמת אישית מפותחת בצורה מאובטחת.
- 6.3 זוהו ומטופלות פגיעויות אבטחה.
- 6.4 יישומי אינטרנט הפונים לציבור מוגנים מפני התקפות.
- 6.5 שינויים בכל רכיבי המערכת מנוהלים בצורה מאובטחת.
באופן ספציפי יותר, דרישה 6.3.2 היא עדכון חשוב שנבע ממספר פרצות שבהן פגיעויות ברכיבים של צד שלישי, או פרצות של ספקי רכיבים של צד שלישי, הובילו לפגיעה בנתוני בעלי כרטיסי אשראי. הדרישה קובעת כדלקמן:
6.3.2.b בדיקת תיעוד התוכנה, כולל תוכנה בהתאמה אישית ותוכנה המשלבת רכיבי תוכנה של צד שלישי, והשוואה למלאי כדי לוודא שהמלאי כולל את התוכנה בהתאמה אישית ותוכנה של צד שלישי.
ארגונים חייבים לתעד ולנהל ביסודיות את הרכיבים והשירותים הספציפיים המשמשים ביישומים שלהם. בעוד שחלק מהמידע הזה אולי כוסה בדיאגרמות זרימת נתונים, הדרישות החדשות דורשות תיעוד מפורט הרבה יותר. מעקב אחר פרטים אלה יכול להיות מאתגר ככל שרכיבים מתעדכנים ומשתנים. מומלץ להשתמש בתבנית סטנדרטית ללכידת מידע זה. בנוסף, מאגרי קוד מקור מסוימים, כמו GIT, עשויים להציע כלים לייצוא רשימה של רכיבים בשימוש. לכל הפחות, המלאי שלך צריך לכלול:
- רכיבי אפליקציה (בדרך כלל פרויקטים של מאגרים)
- רשימת רכיבים של צד שלישי
- רשימת תלויות יישומים (למשל Tomcat, Jboss, .NET, Middleware)
- רשימת סקריפטים של דפי תשלום מורשים
אֵיך OPSWAT SBOM יכול לסייע בעמידה בדרישות PCI DSS
תקנות דורשות יותר ויותר מ-SBOMs להבטיח את אבטחת שרשרת האספקה של תוכנה. עם זאת, ארגונים מתקשים לבנות מלאי מדויק של הרכב קוד התוכנה שלהם.
מקור: דוח EGS 2024
עם זאת, יצירתם של SBOMs מדויקים ומקיפים מציבה אתגר משמעותי בפני ארגונים. מסמכים אלה דורשים רישום מלאי קפדני של רכיבי תוכנה, המחייב מידע מפורט על מקורותיהם, גרסאותיהם ותלותם ההדדית. ללא SBOMs מדויקים, ארגונים מתקשים לזהות, להעריך ולמתן ביעילות את הסיכונים הטמונים בשרשרת האספקה של התוכנה שלהם.
הנחיות ליצירת SBOMs
OPSWAT SBOM מאפשר אוטומציה של יצירת SBOM עבור קוד ומכולות, משפר את האבטחה ומסייע בתאימות בשרשרת האספקה של התוכנה.
- זהה את כל הרכיבים והתלות
זהה במדויק את כל רכיבי התוכנה, כולל ספריות קוד פתוח וספריות של צד שלישי, יחד עם הגרסאות והתלות שלהן. זה מהווה את הבסיס ל-SBOM חזק. - הערכת סיכוני OSS
הערך את הסיכונים הפוטנציאליים הקשורים לרכיבי OSS. יש לקחת בחשבון גורמים כגון תאימות רישיונות, פגיעויות אבטחה ומצב תחזוקה. קבע סדרי עדיפויות לרכיבים על סמך קריטיותם לתוכנה. - סרוק אחר פגיעויות OSS
השתמש בכלים לסריקת פגיעויות וביצירת SBOM כדי לזהות פגיעויות ידועות ברכיבי ה-OSS. קבע סדרי עדיפויות לפי חומרתן והשפעתן הפוטנציאלית על התוכנה.
שימוש OPSWAT SBOM
OPSWAT SBOM מאפשר אוטומציה של יצירת SBOM עבור קוד ומכולות, משפר את האבטחה ומסייע בתאימות בשרשרת האספקה של התוכנה.
כך תוכלו לנצל OPSWAT SBOM ליצירת SBOMs ביעילות:
על ידי מתן רשימה של כל הספריות והרכיבים בקוד פתוח המשמשים בתוך יישום, OPSWAT SBOM מסייע בניהול פגיעויות תלות בשרשרת האספקה של תוכנה , ומאפשר למשתמשים לזהות ולתקן פגיעויות ביישומים ביעילות.
בנוסף לזיהוי נקודות תורפה, OPSWAT SBOM מאמת רישיונות הקשורים לכל רכיב תוכנה. זה מבטיח עמידה בתנאי הרישוי ונמנע ממלכודות משפטיות פוטנציאליות. למידע נוסף על התפקיד המכריע של זיהוי רישיונות ב-OSS .
OPSWAT SBOM תומך ביותר מ-10 שפות תכנות, כולל Java, JavaScript, Go, PHP ו-Python. תמיכה רחבה זו מבטיחה גישה מקיפה vulnerability detection במערכות אקולוגיות שונות של פיתוח תוכנה.
עונשים על אי ציות
ארגונים שאינם עומדים בתקני PCI DSS, כולל דרישת SBOM, עלולים לספוג קנסות כספיים הנעים בין 5,000 ל-100,000 דולר לחודש. קנסות אלה עלולים להסלים עם הזמן אם בעיות התאימות נותרות בלתי פתורות.
בנוסף לעונשים כספיים, אי עמידה בדרישות PCI DSS עלולה להוביל לאתגרים משפטיים ותפעוליים משמעותיים. ההשלכות המשפטיות עשויות לכלול תביעות משפטיות, הוצאות הגנה והסדרים משמעותיים. יתר על כן, אי עמידה בדרישות עלולה לגרור ביקורות פדרליות על ידי סוכנויות כמו ועדת הסחר הפדרלית (FTC), מה שיוביל לעונשים נוספים.
השלבים הבאים לתאימות לתקן PCI DSS 4.0
שילוב SBOM במסגרת PCI DSS 4.0 מסמל שינוי מרכזי לעבר שרשרת אספקה של תוכנה מאובטחת יותר. על ידי מינוף כלים מתקדמים כמו OPSWAT בעזרת SBOM, ארגונים יכולים לנהל ביעילות סיכוני קוד פתוח, לשפר את התאימות ולהגן מפני פרצות נתונים יקרות.
שימוש ב-SBOMs כבר אינו אופציה אלא הכרח. על ידי נקיטת צעדים פרואקטיביים להבנה וטיפול בתלות תוכנה, ארגונים יכולים לבנות בסיס אבטחה איתן המגן על פעילותם ובונה אמון לקוחות.
