בקשת בדיקת הנאותות של מיזוגים ורכישות מגיעה בבוקר יום שלישי: דוח תאימות רישיונות קוד פתוח מלא עבור כל התוכנות, צפוי להגיש ביום שישי. לצוות המשפטי יש שלושה ימים להפיק רשימה של כל רכיבי קוד פתוח בבסיס הקוד של המוצר כולו, כל רישיון רלוונטי, כל התחייבות שיש למלא לפני הבדיקה המשפטית של הרוכש. עבור ארגונים המתייחסים לתאימות רישיונות כאל תרגיל סקירה ידני תקופתי, בבוקר יום שלישי מתחיל אחד מתרגילי האש היקרים ביותר בתוכנה ארגונית. עבור ארגונים עם תשתית ניתוח תלות בוגרת, זה מתחיל בהפקת דוח.
תוכנה מורכבת לרוב, לא נכתבת. דו"ח OSSRA של Black Duck 2026 מצא כי 98% מבסיסי הקוד המסחריים מכילים רכיבי קוד פתוח, 87% מהם מכילים לפחות פגיעות ידועה אחת, ומספר הפגיעויות הממוצע לכל בסיס קוד הוכפל ביותר משנה לשנה. ביקורת תאימות רישיונות היא התחום שעונה על שאלה שונה אך קשורה: לא רק אילו רכיבים מכילים פגיעויות, אלא אילו רכיבים מטילים התחייבויות משפטיות על האופן שבו ניתן להפיץ, לשנות או למסחר את התוכנה. תלות GPL-2.0 שהוחמצה במוצר מסחרי קנייני אינה תקרית אבטחה. זוהי הפרת רישוי שיכולה לדרוש גילוי קוד מקור, הסדר משפטי או ביטול מוצר.
הבסיס של ביקורת תאימות רישיונות הוא ניתוח תלות, זיהוי שיטתי של כל רכיב תוכנה שבסיס קוד תלוי בו באופן ישיר או עקיף, עם ייחוס מלא של הרישיון השולט בכל רכיב. ניתוח תלות אינו סריקה של מניפסט החבילה. זוהי בדיקה מבנית מלאה של מה שהתוכנה כוללת בפועל בזמן הבנייה ובזמן הריצה, ללא קשר לשאלה האם ההכללות הללו מוצהרות, טרנזיטיביות, מופקות או מרומזות.
שינוי רישיון? דעו את ההשפעה.
SMART TS XL מייצר את מלאי הרכיבים עבור תוכנת מיינפריים שאליו מחוללי SBOM סטנדרטיים אינם יכולים להגיע.
גלו עוד…מדוע ניתוח תלות הוא הבסיס
תאימות רישיון היא בעיית תלות לפני שהיא בעיה משפטית. לא ניתן להעריך את התחייבויות הרישיון של מוצר תוכנה מבלי לדעת תחילה ממה המוצר עשוי, כל רכיב, כל ספרייה, כל קטע קוד שהועתק. ניתוח הרישיון הוא במורד הזרם של מלאי התלות. אם תטעו במלאי, ניתוח הרישיון בנוי על תמונה לא שלמה.
שלוש שאלות שניתוח תלות חייב לענות עליהן לצורך עמידה ברישיון:
אילו רכיבים כלולים? לא רק התלות הישירות המוצהרות ב package.json or pom.xml, אבל כל תלות טרנזיטיבית שהם מביאים, כל ספרייה של ספק שהועתקה לעץ המקור, כל רכיב המקושר סטטית שהוקמפל לקובץ הבינארי, וכל מודול שנטען דינמי נקרא בזמן ריצה. מנוע SCA טוב מצליב את הרכיבים הללו עם מסדי נתונים של פגיעויות כמו ה-NVD, בודק מטא-דאטה של רישיונות ומסמן פרצות ידועות או סיכונים משפטיים לפני שהם משפיעים על צינור האספקה שלך. אותו מנוע חייב להיות מדויק גם ברמת המלאי, מה שנמצא בפועל בתוכנה, לפני שניתן לסמוך על ניתוח הרישיונות.
תחת אילו רישיונות הם כפופים? לרכיב יכול להיות רישיון מוצהר יחיד, רישיון כפול עם אפשרויות, רישיונות מרובים החלים על קבצים שונים, או רישיון שהשתנה בין גרסאות. מנוע זיהוי הרישיונות של FOSSA טוען לדיוק של 99.8%, דבר שחשוב כאשר הצוות המשפטי שלך צריך לאמת התחייבויות קוד פתוח לצד מלאי האבטחה. זיהוי רישיון ברמת הרכיב הוא הכרחי אך אינו מספיק, זיהוי ברמת הקובץ או הקטע נדרש עבור רכיבים שבהם קבצים שונים נושאים רישיונות שונים.
אילו חובות מטילים רישיונות אלה? רישיון מתירני (MIT, Apache-2.0) מטיל דרישות ייחוס. רישיון זכויות יוצרים חלש (LGPL) מטיל חובות שונות בהתאם לקישור הרכיב באופן דינמי או סטטי. רישיון זכויות יוצרים חזק (GPL-2.0, GPL-3.0) עשוי לדרוש הפצת קוד המקור של כל היצירה המשולבת. הבנת החובה דורשת הבנת תנאי הרישיון, לא רק מזהה הרישיון.
ארבעת סוגי התלות היוצרות חשיפה לרישיון
לא כל התלות גלויות באותה מידה או נשלטות באותה מידה על ידי הכלים הקיימים. חשיפת רישיונות נובעת מארבעה סוגי תלות שונים, שכל אחד מהם דורש שיטות גילוי שונות:
1. תלויות של מנהל החבילות (מוצהרות וטרנזיטיביות)
השכבה הגלויה ביותר: תלויות המוצהרות בקבצי מניפסט (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) והתלות הטרנזיטיביות שהם פותרים בזמן הבנייה. תלויות של מנהל חבילות הן הקטגוריה המכוסה בצורה הטובה ביותר, כלי SCA סורקים מניפסטים, נועלים קבצים ומציגים ארטיפקטים של בנייה כדי למנות אותם.
ההבדל הקריטי הוא בין תלות ישירה לטרנזיטיבית. תלות ישירה היא זו שהמפתח בחר. תלות טרנזיטיבית היא מה שהתלות הישירה דורשת. מפתח שמוסיף יחיד react-data-grid ייתכן שחבילה לפרויקט Node.js מייבא עשרות תלויות טרנזיטיביות, שלכל אחת מהן רישיון משלה. המפתח לא בחר את הרישיונות הללו. הם קיימים בעץ התלויות בכל מקרה.
ג'סון
// package.json: 1 direct dependency declared
{
"dependencies": {
"react-data-grid": "^7.0.0"
}
}// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.מלכודת הרישיון הטרנזיטיבי: סיכון הרישיון אינו טמון במה שהצהרת. הוא טמון במה שהתלויות שלך הצהירו, ובמה שהתלויות שלהן הצהירו. עץ תלויות ישיר נקי עם רישיונות מתירים יכול להסתיר תלות טרנזיטיבית ברישיון GPL בעומק של שלוש רמות, אשר מטילה חובות זכויות יוצרים על כל ההפצה.
2. קוד מקור משווק ומועתק
קוד מקור מפרויקטים חיצוניים הועתק ישירות למאגר, דפוס נפוץ בפרויקטים של C/C++, פרויקטים של Go ללא מודולים ובסיסי קוד מדור קודם. קוד שנרכש אינו מופיע במניפסטים של מנהל החבילות מכיוון שהוא נוסף באמצעות העתקה-הדבקה ולא באמצעות מנהל תלויות.
הסריקה ברמת קטעי הקוד של SCANOSS חורגת הרבה מעבר לזיהוי מבוסס מניפסט, ומאפשרת התאמת קטעי קוד מקור מול למעלה מ-100 מיליון קבצי קוד פתוח ב-OSSKB. סריקה ברמת קטעי הקוד נדרשת כדי לזהות קוד של ספקים ופונקציות מועתקות, גישות שאינן מצהירות על תלות מניפסט אך נושאות התחייבויות רישיון מלאות כאילו הרכיב נכלל במפורש.
פונקציית שירות מועתקת מתשובה של Stack Overflow שמקורה בקוד מורשה על ידי GPL נושאת את אותה חובת זכויות יוצרים כמו תלות ישירה של GPL, אך היא לא מופיעה בשום מקום במניפסט החבילה, בקובץ הנעילה או בכל סריקה אוטומטית שקוראת רק תלויות מוצהרות.
3. ספריות מקושרות סטטית
ספריות קומפילציה ישירה לתוך קובץ בינארי של היישום בזמן הבנייה. בניגוד לספריות מקושרות באופן דינמי שקיימות כקבצים נפרדים בזמן ריצה, ספריות מקושרות באופן סטטי מוטמעות בקובץ ההפעלה. הן אינן גלויות במניפסטים של מנהל החבילות, הן מופיעות בתצורות הבנייה (Makefile, CMakeLists.txt, סקריפטי קישור) ובקובץ הבינארי הקומפילציוני עצמו.
עבור ספריות מורשות LGPL באופן ספציפי, ההבחנה בין קישור סטטי לבין קישור דינמי קובע את חובת הרישיון. LGPL מאפשר קישור דינמי ללא הפצת זכויות יוצרים; קישור סטטי עשוי להפעיל דרישות זכויות יוצרים על היצירה המשולבת. כלי ניתוח בינארי שבודק את הארטיפקט הקומפילציוני, ולא רק את מניפסט המקור, נדרש כדי לזהות רכיבים המקושרים סטטית ואת הרישיונות שלהם.
4. תלויות טעונות בזמן ריצה
ספריות נטענות באופן דינמי בזמן ריצה באמצעות ארכיטקטורות תוספים, קשירה מאוחרת או שילובי מנוע סקריפטים. ייתכן שתלות אלו אינן ניתנות לפתרון מניתוח קוד מקור בלבד, הן תלויות בסביבת זמן הריצה, בתצורה ובנתיב הביצוע. מנהלי התקנים של מסד נתונים שנטענים באמצעות השתקפות, תוספי ניתוח שהתגלו באמצעות מנגנוני טוען שירותים, והרחבות סקריפטים שנטענות מנתיבי מערכת קבצים בעת האתחול, כולם תלויות בזמן ריצה עם השלכות פוטנציאליות על הרישיון.
קטגוריות סיכון ברישיון וחובותיהן
רישיונות קוד פתוח נעים בין מתירני למגביל. הבנת מיקומם של כל רישיון בספקטרום זה קובעת את חובת הציות שהוא יוצר:
רישיונות מתירים (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)
חובה: ייחוס, הכללת טקסט הרישיון והודעת זכויות יוצרים בהפצות. גילוי קוד המקור אינו נדרש. שימוש מסחרי מותר ללא הגבלה. שילוב במוצרים קנייניים מותר.
רמת סיכון לתוכנה מסחרית: נמוכה. קל למלא ייחוס באופן אוטומטי.
רישיונות זכויות יוצרים חלשים (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)
חובה: יש לשתף ייחוס ושינויים לרכיב המורשה. עבור LGPL באופן ספציפי: קישור דינמי בדרך כלל עומד בדרישות הרישיון מבלי להפעיל זכויות יוצרים על קוד הקריאה; קישור סטטי עשוי שלא.
רמת סיכון לתוכנה מסחרית: בינונית. תלוי בשיטת הקישור. קישור דינמי הוא בדרך כלל בטוח; קישור סטטי דורש בדיקה משפטית מדוקדקת.
רישיונות זכויות יוצרים חזקים (GPL-2.0, GPL-3.0, AGPL-3.0)
חובה: ייחוס (Attribution) יחד עם כל העבודה המשולבת הכוללת את רכיב ה-GPL חייבים להיות זמינים תחת תנאי GPL (גילוי קוד מקור). AGPL מרחיב זאת גם לתוכנה אליה נגישה דרך רשת.
רמת סיכון לתוכנה מסחרית: גבוהה. רכיב בעל רישיון GPL המקושר סטטית למוצר מסחרי קנייני או נגזר ממנו עשוי לדרוש גילוי של קוד המקור הקנייני. זהו סיכון הרישיון שיוצר את ההסדרים המשפטיים הגדולים ביותר.
זכויות יוצרים ברשת (AGPL-3.0)
התחייבות: כל ההתחייבויות של GPL-3.0, בנוסף: משתמשים המקיימים אינטראקציה עם התוכנה דרך רשת נחשבים כמקבלים את התוכנה, מה שמפעיל את חובת גילוי המקור גם עבור מוצרי SaaS שלעולם לא מפיצים קבצים בינאריים.
רמת סיכון למוצרי SaaS: גבוהה מאוד. AGPL תוכנן במיוחד כדי לסגור את "פרצת SaaS" ב-GPL. מוצר SaaS מסחרי הכולל רכיב AGPL חייב לחשוף את מקורו לכל משתמש שמקיים איתו אינטראקציה דרך רשת.
רישיונות קנייניים ומסחריים
התחייבות: מוגדרת בהסכם הרישיון, משתנה מ"ללא הפצה מחדש" דרך "תמלוגים ליחידה" ועד "רישיון מושב ארגוני". אלה אינם קוד פתוח אך מופיעים בעצי תלות כאשר נעשה שימוש ברכיבים מסחריים.
רמת סיכון: משתנה בהתאם לתנאים. מתגלה לעיתים קרובות במהלך בדיקת נאותות של מיזוגים ורכישות כאשר מפורטות התחייבויות דמי הרישיון של מוצרים שנרכשו.
תאימות רישיון: המטריצה שחשובה
כאשר משולבים רכיבים עם רישיונות שונים במוצר תוכנה יחיד, הרישיונות חייבים להיות תואמים. שילובי רישיונות שאינם תואמים יוצרים סיכון משפטי שלא ניתן לפתור באמצעות ייחוס בלבד, השילוב עצמו עלול להפר רישיון אחד או את שניהם.
| משולב עם | MIT | אפאצ'י 2.0 | LGPL-2.1 | GPL-2.0 | GPL-3.0 | PLFA-3.0 |
|---|---|---|---|---|---|---|
| MIT | תוֹאֵם | תוֹאֵם | תוֹאֵם | תוֹאֵם | תוֹאֵם | תוֹאֵם |
| אפאצ'י 2.0 | תוֹאֵם | תוֹאֵם | תוֹאֵם | שאינו עולה בקנה אחד | תוֹאֵם | תוֹאֵם |
| LGPL-2.1 | תוֹאֵם | תוֹאֵם | תוֹאֵם | תוֹאֵם | שאינו עולה בקנה אחד | שאינו עולה בקנה אחד |
| GPL-2.0 | תוֹאֵם | שאינו עולה בקנה אחד | תוֹאֵם | תוֹאֵם | שאינו עולה בקנה אחד | שאינו עולה בקנה אחד |
| GPL-3.0 | תוֹאֵם | תוֹאֵם | שאינו עולה בקנה אחד | שאינו עולה בקנה אחד | תוֹאֵם | תוֹאֵם |
| קנייני | תוֹאֵם | תוֹאֵם | זהירות | שאינו עולה בקנה אחד | שאינו עולה בקנה אחד | שאינו עולה בקנה אחד |
חוסר התאימות המשמעותי ביותר עבור תוכנה מסחרית: Apache-2.0 ו-GPL-2.0 אינם תואמים. ספרייה מורשית של Apache-2.0 לא יכולה להיות משולבת עם רכיב מורשה של GPL-2.0 באותה עבודה. מכיוון שרבים מרכיבי הקוד הפתוח הבסיסיים (מודולי ליבת לינוקס, חלק מספריות ג'אווה ישנות יותר) הם GPL-2.0 ולא GPL-3.0, חוסר תאימות זה יוצר סיכון תאימות ממשי בעצי תלות מעורבים.
שורת AGPL-3.0 היא המגבילה ביותר עבור SaaS: למעשה שום דבר לא משתלב בצורה נקייה עם AGPL-3.0 במוצר מסחרי מבלי להפעיל את חובת זכויות היוצרים של הרשת.
אכיפת מדיניות רישיונות ב-CI/CD
תאימות רישיון שתלויה בביקורות תקופתיות נכשלת ברגע ההכנסה: תלות ה-GPL שמישהו הוסיף בספרינט האחרון הייתה בתהליך ייצור במשך שלושה שבועות לפני שהביקורת הרבעונית תופסת אותה. אכיפה רציפה בשער המיזוג היא הגישה היחידה המונעת מתלות שאינן תואמות להיכנס לבסיס הקוד.
יאמל
# GitHub Actions: license compliance gate on every PR
name: License Compliance Check
on:
pull_request:
jobs:
license-audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install license checker
run: npm install -g license-checker fossa-cli
- name: Scan dependency licenses
run: |
license-checker --summary --excludePrivatePackages \
--out license-report.json
- name: Enforce license policy
run: |
# Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
FORBIDDEN=$(license-checker --failOn \
"GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
--excludePrivatePackages 2>&1 || true)
if echo "$FORBIDDEN" | grep -q "FAIL"; then
echo "Forbidden license detected in dependencies"
echo "$FORBIDDEN"
exit 1
fi
- name: Generate SBOM artifact
run: |
# Generate CycloneDX SBOM for audit trail
npx @cyclonedx/cyclonedx-npm \
--output-file sbom-$(date +%Y%m%d).json
- name: Upload SBOM as artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom-*.jsonשימו לב: מדיניות הרישיונות ספציפית לארגון. רשימת הרישיונות האסורים בדוגמה לעיל משקפת מדיניות מסחרית נפוצה, אך הצוות המשפטי של הארגון שלכם חייב להגדיר אילו רישיונות מותרים, מסומנים לבדיקה ואסורים עבור סוג המוצר הספציפי שלכם, מודל ההפצה והסכמי הלקוחות. ספרייה המותרת בכלי פנימי עשויה להיות אסורה במוצר המופץ על ידי הלקוח.
יצירת SBOM ותקני עיצוב
רשימת חומרים של תוכנה (SBOM) היא רכיב מובנה שהופך את תאימות הרישיונות לניתנת לביקורת, לשיתוף ולאימות מכונה. צוותי תאימות יכולים לאשר התחייבויות רישיון ללא ביקורות ידניות כאשר SBOM מספק נתונים אלה. שני פורמטים שולטים בשוק:
CycloneDX , שפותח על ידי OWASP, מיועד למקרי שימוש באבטחה ובשרשרת אספקה. תומך ברכיבים, שירותים, פגיעויות (VEX), נוסחאות ובמודלים של למידת מכונה. הפורמט המועדף עבור SBOMs המתמקדים באבטחה והפורמט הנדרש על ידי רוב האינטגרציות המודרניות של כלי SCA.
SPDX, המתוחזק על ידי קרן לינוקס, תקן ISO/IEC (ISO 5962:2021). נדרש על ידי כמה תקני רכש ממשלתיים, כולל היבטים של EO 14028. מתמקד יותר בתאימות רישיונות מאשר באבטחה, עם שפת ביטוי רישיונות עשירה יותר (ביטויי SPDX יכולים ללכוד תרחישים מורכבים של רישוי מרוב: GPL-2.0-only AND MIT OR Apache-2.0).
EO 14028 כבר חוסם ספקים שאינם SBOM מחוזים פדרליים, ה-CRA מתחיל לאכוף דיווח על פגיעויות בספטמבר 2026, ו-PCI DSS 4.0 כבר נמצא בידי רואי החשבון. או שאתם שולחים SBOM או שאתם מפסידים עסקאות.
עבור מוצרי תוכנה ארגוניים, הפקת שני הפורמטים עולה מעט מעבר לייצור מאותו ניתוח תלות. קהל היעד של כל אחד מהם שונה: צוותי אבטחה ותהליכי עבודה לניהול פגיעויות צורכים את CycloneDX; צוותים משפטיים, רכש ותהליכי עבודה לציות לתקנות מעדיפים בדרך כלל את SPDX.
בעיית בסיס הקוד הישן: אין מנהל חבילות, אין מניפסט
כלי ניתוח התלות שתוארו לעיל, סורקי SCA, מנתחי קבצי נעילה ומחוללי SBOM, פועלים על ההנחה שתלויות תוכנה מנוהלות באמצעות מנהלי חבילות ומוצהרות בקבצי מניפסט. הנחה זו תקפה עבור פרויקטים מודרניים של Java, JavaScript, Python, Go ו-Rust. היא אינה תקפה עבור סביבות ארגוניות מדור קודם הבנויות על פלטפורמות COBOL, JCL ופלטפורמות מיינפריים.
בסביבת מחשב מרכזי, תלות בתוכנה של צד שלישי מתבטאת בשלוש דרכים שכלי SCA סטנדרטיים אינם יכולים לזהות:
מוצרי מיון ותשתיות מורשים. זרמי עבודה של JCL קוראים לתוכניות שירות, ממיינים מוצרים (DFSORT, SyncSort/Syncsort הידועים כיום בשם Precisely, CA Sort), כותבי דוחות (SAS, EASYTRIEVE) וכלי המרת נתונים, שהם תוכנות מסחריות מורשות עם תנאי רישיון משלהן, חוזי תחזוקה ודרישות תאימות. אלה מופיעים ב-JCL כ- PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, שמות תוכניות, לא מזהי חבילות. אין כלי SCA שקורא package.json or pom.xml ימצא אותם.
מחברות COBOL המסופקות על ידי הספק. ספקי תוכנה חיצוניים מספקים מחברות COBOL שהן תוכנה מורשית. ספק תוכנה בתחום הפינטק המספק תוכנות COBOL לעיבוד תשלומים עשוי לספק מחברות המגדירות את מבני הנתונים הקנייניים שלו. כל תוכנית COBOL הכוללת את המחברות הללו משתמשת בתוכנה מורשית. התחייבויות הרישיון הן אמיתיות; ערך מנהל החבילות אינו קיים.
אלגוריתמים מוטמעים ממקורות מורשים. מוסדות פיננסיים המריצים מערכות COBOL עשויים לשלב אלגוריתמים מורשים, שגרות חישוב אקטואריות, יישומים קריפטוגרפיים וספריות ניתוח מספרי, ישירות בקוד המקור של COBOL. ייתכן שאלו מקורם כמקור מורשה שהוקמפל לתוך בסיס הקוד ולא ניתן לזהותם ממנהלי חבילות.
עבור רכיבים אלה, שיטת הגילוי היא ניתוח קוד מקור: מעקב אחר פקודות CALL כדי לזהות תוכניות שנקראו, בחינת פקודות COPY כדי לזהות חברים כלולים, והתאמת שמות תוכניות מול רישום של רכיבים ידועים של צד שלישי. הפלט מזין את אותה זרימת עבודה של תאימות רישיונות, אך הוא דורש כלי שמבין סמנטיקה של COBOL ו-JCL, ולא רק פורמטים מודרניים של מניפסט חבילות.
בניית חבילת תאימות מוכנה לביקורת
כאשר מבקר משפטי, מבקר ציות או מבקר חיצוני מבקשים ראיות לתאימות רישיון, דוח סריקה הכרחי אך אינו מספיק. חבילת התאימות המוכנה לביקורת מכילה:
- מלאי תלויות מלא, כל רכיב, גרסה ורישיון, כולל תלויות טרנזיטיביות, מאורגנים לפי מוצר וגרסה
- מטריצת חובת רישיון, עבור כל קטגוריית רישיון קיימת, החובות הספציפיות (ייחוס, גילוי מקור, הודעת שינוי) וכיצד כל אחת מהן מתקיימת
- קובץ הודעות ייחוס, ערכו הודעות משפטיות עבור כל הרכיבים הדורשים ייחוס, בפורמט הנדרש על ידי כל רישיון (קובץ NOTICE עבור Apache-2.0, קובץ LICENSE עבור MIT וכו')
- ניתוח אי-תאימות, תיעוד כי אין שילובי רישיונות לא תואמים במוצר המשולב, עם נימוק משפטי לכל מקרה גבול
- חפץ SBOM, קובץ CycloneDX או SPDX עדכני, חתום ועם חותמת זמן, המכסה את כל הרכיבים הנכללים בהיקף
- תיעוד מדיניות, מדיניות הרישוי הכתובה של הארגון בקוד פתוח, כולל תהליך האישור לרישיונות חדשים
- רישומי אישור, עבור כל רישיון הדורש בדיקה משפטית לפני הכללתו, האישור המתועד וההצדקה העסקית
- היסטוריית תיקונים, תיעוד של כל הפרה שזוהתה בעבר והפעולות שננקטו כדי לפתור אותה
עבור בדיקת נאותות של מיזוגים ורכישות באופן ספציפי: רוכשים מבקשים יותר ויותר חבילה זו כחלק מבדיקת נאותות טכנית. חבילת תאימות נקייה ללא הפרות לא פתורות מאיצה את תהליך הבדיקה. חבילה שחושפת הפרות GPL לא פתורות במוצר קנייני בדרך כלל מביאה להתאמת מחיר, דרישות נאמנות או תיקון כתנאי לסגירה, שכולם יקרים יותר מתוכנית התאימות שהייתה מונעת אותן.
איך SMART TS XL תומך בתאימות רישיונות בבסיסי קוד ארגוניים
SMART TS XL"S מיפוי תלות יישומים מספק את שכבת ניתוח התלות המבנית עבור בסיסי קוד ארגוניים, במיוחד בסביבה מדור קודם שבה כלי SCA סטנדרטיים מגיעים לגבולותיהם.
עבור סביבות מיינפריים, מפת התלות מזהה כל תוכנית שנקראת על ידי כל תוכנית אחרת (המציגה קריאות תוכנה של צד שלישי המוטמעות ב-JCL וב-COBOL), כל ספר עותקים הכלול בכל תוכנית (המציגה תלויות ספר עותקים שסופקו על ידי הספק), וכל מערך נתונים אליו ניגשת כל תוכנית (המציגה תלויות בשכבת הנתונים על מוצרי מסד נתונים מורשים). ניתוח זה מייצר את מלאי הרכיבים שהוא התנאי המוקדם לביקורת תאימות רישיונות בסביבות בהן לא קיים מנהל חבילות.
יכולת ניתוח הקוד הסטטי מזהה דפוסי קוד הקשורים לרכיבים ספציפיים של צד שלישי: חתימות קריאה קנייניות של API, מוסכמות מבנה נתונים ספציפיות לספק, ויישומים של אלגוריתמים מורשים המוטמעים במקור COBOL מותאם אישית. ממצאים אלה משלימים את המלאי מבוסס המניפסט עם תלויות ברמת הקוד שסריקת המניפסט אינה יכולה להגיע אליהן.
יכולת ניתוח ההשפעה הופכת שינויים במדיניות רישיון לניתנים לפעולה: אם רישיון של רכיב משתנה, תלות עוברת רישיון מחדש מ-MIT ל-AGPL-3.0, ספק משנה את תנאיו, ניתוח ההשפעה מזהה כל תוכנית בתיק התיק שתלויה ברכיב זה, באופן ישיר או זמני. פעולה זו ממירה אירוע שינוי רישיון מסיכון לא ידוע להיקף תיקון מוגדר.
יכולת החיפוש הארגוני הופכת את מלאי התלות לניתן לשאילתה למטרות תאימות: מצא כל תוכנית שקוראת לכלי שירות ספציפי, כל ספר עותקים הכולל חבר מסוים שסופק על ידי הספק, כל תוכנית שתלויה ברכיב מורשה ספציפי, תוך שניות, על פני כל תיק העבודות הקודם. יכולת חיפוש זו היא הכלי המעשי לבקשת ביקורת מיזוגים ורכישות בבוקר יום שלישי: שאילתה במקום סקירה ידנית.
עבור ארגונים הבונים כיסוי SBOM מקיף המשתרע על פני מערכות מודרניות ומסורות, SMART TS XL מספק את מלאי הרכיבים הישן שמחוללי SBOM סטנדרטיים אינם יכולים לייצר, ומשלים כלים כמו Syft, FOSSA ו-Dependency-Track עבור המחסנית המודרנית.
הביקורת שלעולם לא צריכה להפתיע
ביקורת תאימות רישיונות היא אחת מתחומי הרגולציה הבודדים שבהם העונש על אי-ציות מתגלה לעתים קרובות לא על ידי הרגולטור, אלא על ידי שותף עסקי, רוכש, צוות משפטי של לקוח או מפיץ שקורא את תנאי הרישיון ומבקש ראיות לעמידה בתנאי הרישיון. עלות הגילוי נעה בין מביכה לקיומית, בהתאם לחומרת ההפרה ולשלב העסקה.
תוכנת ניתוח התלות שמונעת גילוי זה מלהיות הפתעה אינה יקרה יחסית לסיכון שהיא מפחיתה. היא דורשת לדעת מה נמצא בתוכנה, כל רכיב, כל תלות טרנזיטיבית, כל קטע קוד של ספק, כל תוכנת שירות מדור קודם, ולבדוק כל אחד מהם מול מדיניות הרישיונות של הארגון באופן רציף ולא תקופתי. הכלים קיימים. התקנים (SBOM, SPDX, CycloneDX) קיימים. המנדט הרגולטורי (EO 14028, CRA, PCI-DSS 4.0) קיים. החלק החסר היחיד, עבור רוב הארגונים, הוא המשמעת להתייחס לניתוח תלות כתשתית ולא כתרגיל ביקורת.
בוקר יום שלישי שמתחיל בדוח במקום בתרגיל אש הוא בוקר יום שלישי שהתאפשר בזכות תשתית ניתוח התלות.
