על SBOMs, BitBucket ו-OWASP Dependency Track

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

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

מאמר זה יסביר כיצד לשלוט בפגיעות כאלו באמצעות:

1. BitBucket pipes ליצירת SBOM, ו
2. כיצד Dependency Track של OWASP יכול לנתח אותו.

הכירו את הסיכון שלכם

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

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

הגרף הגדול באמצע מציג את מספר הפגיעות בכל הפרוייקטים שמתבצעת עליהם מעקב. מדדים לגבי פגיעות קריטיות, בינוניות ונמוכות מוצגים ממש מתחת. Dependency Track מביא פגיעות ידועות ממקורות אחד או יותר. המקור המפורסם ביותר בהם הוא רשימת פגיעות משותפות וחשיפות (CVE) ממסד הנתונים לפגיעות בטחוניות הלאומי של ארצות הברית מסד הנתונים לפגיעות בטחוניות. לכל CVE מוקצה רמת קריטיות מלאומית ונמוכה עד קריטית. ניתן להגדיר את ניתוח הסיכון הזה על ידי Dependency Track בפרקי זמן קבועים מאחורי הקלעים באמצעות כרטיס רלוונטי לפי חשבון חומרה לתוכנה (SBOM) כקלט. 

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

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

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

BitBucket מכין את הSBOM

הכנת הSBOM מתרחשת ב- BitBucket צינור CI/CDשמבצע לאחר שמיזם מושלם ממוזג לסניף הראשי. זהו מבטיח שהלוחות מחויבים תמיד עם מצב העניינים.

השתמשתי בצינור BitBucket שמקפיץ syft כדי ליצור SBOM בפורמט CycloneDX. פקודות ה-syft לחיפושי קוד וקונטיינרים שונות מעט.

סריקת קוד

הפקודה של syft לניתוח קוד משורש הפרויקט שלך היא כדלקמן:

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

פקודה זו מייצאת את ה-SBOM לקובץ בשם code-cdx-sbom.json ומשתמשת ברשת כדי לקבל מידע רשיונות מהאינטרנט; למשל, ממאגרי Maven המרכזיים.

הצינור של syft BitBucket מshiftleftcyber (תודה!) מוגדר אז בחסימת הסקריפט של צינור BitBucket כדי לעטוף את הפקודה syft כך:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_CMD_ARGS: '. --output cyclonedx-json=code-cdx-sbom.json'

    SYFT_JAVA_USE_NETWORK: 'true'

המדריך של פרויקט syft מציין מגוון מרשים של שפות נתמכות, אבל השתמשתי בו רק בJava ובJavaScript עם פרויקט Python ברשימה.

מה מסתתר במיכלים שלך?

כדי לסרוק מיכל מהרשימה שלך, יש להריץ את הפקודה הבאה בהקשר של "docker login":

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

הצינור המתאים של BitBucket הוא:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_REGISTRY_AUTH_USERNAME: sadilar

    SYFT_REGISTRY_AUTH_PASSWORD: $DOCKER_PWD

    SYFT_CMD_ARGS: 'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'

המפסק all-layers מצווה על syft לבדוק את כל השכבות של תמונת המיכל ולא רק את המוצר הסופי.

BitBucket כאמצעי הפקדה

כל מה שנותר הוא ש-Dependency Track יקבל את ה-SBOM. השתמשתי בצינור האחות של הצינור של BitBucket שיצר את ה-SBOM:

- pipe: docker://ccideas/sbom-utilities-pipe:1.5.0

  variables:

    PATH_TO_SBOM: code-cdx-sbom.json

    SEND_SBOM_TO_DTRACK: 'true'

    DTRACK_URL: https://deptrack.test.s2c.co.za

    DTRACK_PROJECT_ID: df3327b2-5439-43ab-bb33-1f24228b6074

    DTRACK_API_KEY: $DTRACK_TEST

ציינתי שלושה פרמטרי קלט:

1. כתובת URL של מופע Dependency Track
2. המזהה של פרויקט Dependency Track לטעינת SBOM
3. מפתח ה- API לאישור העלאה

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

ואז להעתיק את מזהה האובייקט בתחתית:

מפתח ה- API נמצא בשדה כניסה בשם זהה של צוות ה- Automation, הנגיש מתוך תפריט ה- Administration בפאנל השמאלי:

מסקנה

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

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

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