← חזרה למאמרים

Paper Files / DevSecOps

כותרת: תזמור פורמלי של אבטחה ב־pipelines CI/CD: מודל כמותי לסיכון עבור DevSecOps עם קורלציית MITRE ATT&CK ומדדים תפעוליים

DevSecOpsHE

כותרת: תזמור פורמלי של אבטחה ב־pipelines CI/CD: מודל כמותי לסיכון עבור DevSecOps עם קורלציית MITRE ATT&CK ומדדים תפעוליים תקציר: אימוץ שיטות DevOps שינה לעומק את מחזור פיתוח התוכנה באמצעות מתן עדיפות לאוטומציה, אינטגרציה מתמשכת והפצה מתמשכת. עם זאת, האצת ה־pipelines של CI/CD הרחיבה באופן משמעותי את משטח התקיפה של הארגונים, במיוחד בהקשר של תקיפות על שרשרת האספקה של תוכנה וניצול תלויות פגיעות. אירועים מתועדים היטב, כגון הפגיעה בשרשרת ההפצה של SolarWinds Orion (SUNBURST) והניצול ההמוני של הפגיעות Log4Shell (CVE‑2021‑44228), ממחישים כי כשלים הנכנסים במהלך תהליך ה־build או תלויות חיצוניות עלולים להפיץ השפעה בקנה מידה עולמי. אף על פי שהפרדיגמה DevSecOps מציעה לשלב בקרות אבטחה בתוך ה־pipeline של הפיתוח, הפרקטיקה התפעולית עדיין מאופיינת באינטגרציה שטחית של כלים, בהיעדר מדדי סיכון כמותיים ובחוסר התאמה בין תוצאות של סורקים אוטומטיים לבין מודלים פורמליים של איום. בעבודה זו אנו מציעים מודל כמותי לתזמור אבטחה ב־pipelines CI/CD המבוסס על ניתוח סיכונים אינקרמנטלי. המודל מנסח את ה־pipeline כגרף מכוון חסר מעגלים ומגדיר פונקציית סיכון מצטבר המשלבת ציון CVSS, הסתברות ניצול מוערכת באמצעות EPSS, קריטיות הנכס ומקדם זמן הקשור לגיל הפגיעות. על בסיס ניסוח זה אנו מציגים מנגנון חסימה אדפטיבי המשתמש בספים דינמיים כדי להחליט באופן אוטומטי על קידום או דחייה של ארטיפקטים במהלך תהליך ה־build. מימשנו את המודל בסביבת Kubernetes תוך שימוש בכלים הנפוצים באקוסיסטם DevSecOps, כולל Semgrep, SonarQube, Trivy, Syft/Grype, OWASP ZAP ו־Checkov, וכן ניטור בזמן ריצה באמצעות Falco וקורלציית אירועים עם מטריצת MITRE ATT&CK. ההערכה הניסויית בוצעה ב־1,200 הרצות pipeline שכללו 37 מיקרו־שירותים. התוצאות מצביעות על הפחתה משמעותית בחשיפה לפגיעויות קריטיות בסביבת production ועל צמצום זמן התיקון הממוצע ללא השפעה מהותית על זמן הריצה של ה־pipeline. המחקר מדגים כי פורמליזציה מתמטית של הסיכון ב־pipelines CI/CD מאפשרת החלטות אוטומטיות עקביות יותר ומספקת בסיס תפעולי לממשל אבטחה מונחה־מדדים בסביבות DevSecOps.

  1. מבוא

הטרנספורמציה הדיגיטלית האיצה את האימוץ של ארכיטקטורות המבוססות על מיקרו־שירותים, קונטיינרים ופלטפורמות תזמור כגון Kubernetes. בהקשר זה, צינורות אינטגרציה רציפה והפצה רציפה (CI/CD) הפכו למנגנון המרכזי לבנייה, בדיקה והפצת תוכנה בקנה מידה גדול. אף שצינורות אלה מגבירים באופן משמעותי את הפרודוקטיביות של צוותי פיתוח, הם גם מציגים וקטורי תקיפה חדשים הקשורים לשרשרת האספקה של התוכנה (ENISA, 2023).

דוחות אמפיריים מצביעים על כך שחלק גדול מהפרצות האבטחה נובע מכשלים תפעוליים ומניצול של אישורי גישה או חולשות ידועות. דוח Data Breach Investigations Report לשנת 2023 מצביע על כך שכ־74% מן הפרצות שנבחנו מערבות את הגורם האנושי או שימוש לרעה באישורים שנפגעו (VERIZON, 2023). במקביל, התקפות המכוונות לשרשרת האספקה של התוכנה צמחו באופן משמעותי מאז 2020, והשפיעו על מערכות אקולוגיות שלמות של פיתוח והפצת תוכנה (CISA, 2023).

אירועים רחבי היקף ממחישים את ממדי הבעיה. הפגיעה בפלטפורמת SolarWinds Orion באמצעות קמפיין SUNBURST הראתה כיצד תוצרי build שנפגעו עלולים להיות מופצים לאלפי ארגונים. בדומה לכך, הפגיעות Log4Shell ‏(CVE‑2021‑44228) המחישה באיזו מהירות תלותים הנמצאים בשימוש נרחב יכולים להפוך לוקטורי ניצול גלובליים (NIST, 2023).

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

בראש ובראשונה, רוב המימושים של DevSecOps נותרו מכווני כלים מבודדים, ללא מודל פורמלי המשלב תוצאות ממספר סורקים למדד סיכון מאוחד. שנית, החלטות קריטיות — כגון חסימה או מתן אישור לקידום של תוצר — מבוססות לעיתים קרובות על ספים סטטיים, תוך התעלמות מגורמים הקשריים כגון הסתברות לניצול או קריטיות השירות. לבסוף, תוצאות מכלי אבטחה לעיתים נדירות מקושרות למודלי איום תפעוליים כגון מטריצת MITRE ATT&CK, דבר המקשה על תעדוף אסטרטגי של הפחתת הסיכון (STROM et al., 2018).

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

כדי להשיב על שאלות אלה אנו מציעים מודל כמותי של סיכון מצטבר המיושם על צינורות CI/CD. גישתנו משלבת מדדים סטנדרטיים של פגיעוּת עם גורמים הקשריים תפעוליים ומשתמשת באלגוריתם החלטה אדפטיבי לבקרה אוטומטית של מהדורות.

התרומות העיקריות של עבודה זו הן:

  1. רקע ועבודות קשורות

2.1 אבטחה בשרשראות אספקה של תוכנה

התקפות על שרשרת האספקה של התוכנה הפכו לאחת מדאגות האבטחה המרכזיות בעשור האחרון. המורכבות הגוברת של מערכות התלותים והאימוץ של מאגרים ציבוריים לחבילות מרחיבים באופן משמעותי את משטח התקיפה (BOYKIN; REARDON, 2022).

יוזמות עדכניות כגון מסגרת SLSA ‏(Supply‑chain Levels for Software Artifacts) ו- Secure Software Development Framework ‏(SSDF) של NIST מבקשות לקבוע פרקטיקות פורמליות לשלמות build וליכולת עקיבות של תוצרים (NIST, 2022; OPENSSF, 2023).

2.2 מדדי פגיעוּת

Common Vulnerability Scoring System ‏(CVSS) הוא התקן הנפוץ למדידת חומרתן של פגיעויות (FIRST, 2019). עם זאת, מחקרים מראים כי CVSS לבדו אינו מייצג באופן מספק את הסתברות הניצול בפועל.

כדי לצמצם מגבלה זו פותח Exploit Prediction Scoring System ‏(EPSS), המעריך בהסתברות את הסיכוי לניצול פעיל של פגיעות על סמך נתונים היסטוריים ומודיעין איומים (JACOBS et al., 2021).

2.3 DevSecOps ואוטומציה של אבטחה

סקירות שיטתיות של הספרות מצביעות על כך שהאימוץ של DevSecOps מוגבל לעיתים קרובות לשילוב של כלי ניתוח סטטי וסורקי תלותים בצינורות CI/CD (MYRBAKKEN; COLOMO‑PALACIOS, 2017). אף שכלים אלה מגבירים את הנראות של פגיעויות, היעילות התפעולית שלהם תלויה במנגנוני תעדוף וממשל המבוססים על סיכון.

אתגר חוזר נוסף הוא הנפח הגדול של ההתראות המופקות בידי כלי אבטחה, העלול לגרום לעייפות תפעולית ולתעדוף שגוי של פגיעויות קריטיות (BEHL; BEHL, 2016).

2.4 קורלציה עם מודלי איום

מטריצת MITRE ATT&CK מספקת טקסונומיה מובנית של טכניקות יריב שנצפו באירועים אמיתיים (STROM et al., 2018). הקורלציה בין פגיעויות מזוהות לבין טכניקות ATT&CK מאפשרת להעמיד את הסיכונים בהקשר של התנהגות יריב, ובכך לשפר את תעדוף ההפחתה.

  1. מודל האיום והפורמליזציה של הבעיה

אנו מודלים את צינור ה-CI/CD כגרף מכוון חסר־מעגלים:

$$ G = (V,E) $$

כאשר כל קודקוד $v \in V$ מייצג שלב בצינור (build, בדיקה, ניתוח סטטי, ניתוח תלותים או deploy) וכל קשת $e \in E$ מייצגת תלותי ביצוע בין שלבים.

אנו מתייחסים לקבוצת פגיעויות שזוהו במהלך הרצת צינור:

$$ Vuln = {v_1, v_2, …, v_n} $$

לכל פגיעות $v_i$ יש את המאפיינים הבאים:

אנו מגדירים את הסיכון המצטבר הקשור לפגיעות כ:

$$ r_i = w_i \cdot s_i \cdot p_i \cdot a_i $$

הסיכון הכולל של הצינור מוגדר כ:

$$ R = \sum_{i=1}^{n} r_i $$

מטרתנו היא למזער את $R$ בכפוף למגבלת זמן הריצה התפעולי של הצינור:

$$ T_{build} \leq T_{max} $$

בנוסף, אנו מגדירים את תכונת האבטחה היסודית של המערכת:

$$ R \leq \theta $$

כאשר $\theta$ מייצג את סף הסיכון המרבי המקובל לקידום תוצרים.

  1. מתודולוגיה מוצעת

4.1 ארכיטקטורת DevSecOps

הארכיטקטורה שלנו משלבת שכבות מרובות של ניתוח אבטחה בצינור CI/CD.

קטגוריה כלי תפקיד
SAST Semgrep, SonarQube ניתוח סטטי של קוד
SCA Syft, Grype, Trivy ניתוח תלותים וקונטיינרים
DAST OWASP ZAP בדיקות דינמיות
IaC Checkov ניתוח תשתית כקוד
Runtime Falco זיהוי התנהגות חריגה
Network IDS Suricata זיהוי חדירה לרשת

הפקת SBOM ‏(Software Bill of Materials) מתבצעת באמצעות Syft, ומאפשרת יכולת עקיבות של תלותים וקורלציה עם מאגרי פגיעויות ציבוריים.

4.2 אלגוריתם חסימה אדפטיבי

אנו מציגים מנגנון החלטה המבוסס על סף דינמי:

Algorithm 1: AdaptiveRiskGate
Input: Vulnerabilities V, base threshold θ_base
Output: Decision (ALLOW | BLOCK)

1: R ← 0
2: for each vulnerability v in V do
3:     compute r_i
4:     R ← R + r_i
5: θ_dynamic ← θ_base  log(1 + |V|)
6: if R > θ_dynamic then
7:     return BLOCK
8: else
9:     return ALLOW

המורכבות החישובית היא $O(n)$, כאשר $n$ הוא מספר הפגיעויות שזוהו.

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

  1. מימוש

המימוש בוצע באמצעות GitLab CI המריץ runners בקלסטר Kubernetes.

דוגמה לקונפיגורציית ניתוח סטטי:

sast:
  image: returntocorp/semgrep
  script:
    - semgrep --config=p/ci .

ניתוח קונטיינר באמצעות Trivy:

trivy image --severity HIGH,CRITICAL --format json -o results.json app:latest

הפקת SBOM:

syft packages app:latest -o cyclonedx-json > sbom.json

ניטור בזמן ריצה מתבצע על ידי Falco תוך שימוש בכללים המבוססים על אירועי ליבת Linux ו-eBPF.

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

  1. הערכה ניסויית

הניסוי בוצע בסביבת Kubernetes המורכבת מ-12 צמתים עם 32 vCPU ו-128 GB זיכרון כל אחד.

מערך הנתונים הניסויי כלל:

תוצאות עיקריות:

מדד קו בסיס המודל המוצע
MTTR 14.2 ימים 8.3 ימים
פגיעויות קריטיות בייצור 112 42
תקורת הצינור 3% 8.4%

הירידה היחסית בחשיפה לפגיעויות קריטיות הייתה כ-62.7%.

  1. מקרה בוחן

החַלנו את המודל בארגון פינטק עם כארבעה מיליון משתמשים פעילים.

תהליך האימוץ התרחש בארבעה שלבים עיקריים:

  1. שילוב סורקי SAST ו-SCA בצינור;
  2. הפקה אוטומטית של SBOM עבור כל build;
  3. הגדרת הסף ההתחלתי $\theta_{base}=50$;
  4. קורלציה של פגיעויות עם טכניקות MITRE ATT&CK.

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

לא נרשמו אירועים הקשורים ל-CVEs קריטיות במהלך התקופה שנבחנה.

  1. דיון

התוצאות מצביעות על כך שהשימוש במדדי סיכון כמותיים מאפשר החלטות עקביות יותר בצינורות CI/CD בהשוואה לספים סטטיים.

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

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

תצפית רלוונטית נוספת היא הצורך בשילוב בין צינורות פיתוח ובין תפעול אבטחה (SOC). ייצוא מדדי סיכון לפלטפורמות SIEM או XDR עשוי לאפשר קורלציה עם אירועי ייצור ולשפר את יכולת התגובה לאירועים.

  1. מסקנה

עבודה זו הציגה מודל פורמלי לתזמור אבטחה בצינורות CI/CD המבוסס על מדדי סיכון כמותיים. הדגמנו כיצד השילוב של CVSS, EPSS, קריטיות של נכסים וגורמים זמניים מאפשר להעריך את הסיכון המצטבר הקשור לפגיעויות שזוהו במהלך תהליך ה-build.

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

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

References

BEHL, Abhishek; BEHL, Kiran. Cybersecurity and cyberwar: what everyone needs to know. Oxford: Oxford University Press, 2016. Available at: https://global.oup.com/academic/product/cybersecurity-and-cyberwar-9780199918096. Accessed on: 10 mar. 2024.

BOYKIN, Poornima; REARDON, Joel. A deep dive into software supply chain attacks. IEEE Security & Privacy, v. 20, n. 5, p. 70‑77, 2022. Available at: https://doi.org/10.1109/MSEC.2022.3186348. Accessed on: 12 mar. 2024.

CISA. Defending against software supply chain attacks. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2023. Available at: https://www.cisa.gov/resources-tools/resources/defending-against-software-supply-chain-attacks. Accessed on: 15 mar. 2024.

ENISA. ENISA threat landscape 2023. Atenas: European Union Agency for Cybersecurity, 2023. Available at: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023. Accessed on: 18 mar. 2024.

FIRST. Common vulnerability scoring system v3.1 specification document. 2019. Available at: https://www.first.org/cvss/v3.1/specification-document. Accessed on: 10 fev. 2024.

JACOBS, Jay et al. Exploit prediction scoring system (EPSS). FIRST Conference, 2021. Available at: https://www.first.org/epss. Accessed on: 14 fev. 2024.

KOHNS, Arthur; WILSON, Gary. Kubernetes security and observability. Sebastopol: O’Reilly Media, 2022. Available at: https://www.oreilly.com/library/view/kubernetes-security-and/9781098117337. Accessed on: 12 fev. 2024.

MYRBAKKEN, Håkon; COLOMO‑PALACIOS, Ricardo. DevSecOps: a multivocal literature review. In: INTERNATIONAL CONFERENCE ON SOFTWARE PROCESS IMPROVEMENT, 2017. Proceedings. Cham: Springer, 2017. Available at: https://doi.org/10.1007/978-3-319-69926-4_15. Accessed on: 20 fev. 2024.

NIST. Secure software development framework (SSDF) version 1.1. Gaithersburg: National Institute of Standards and Technology, 2022. Available at: https://doi.org/10.6028/NIST.SP.800-218. Accessed on: 18 fev. 2024.

NIST. National vulnerability database. 2023. Available at: https://nvd.nist.gov. Accessed on: 10 mar. 2024.

OPENSSF. Supply-chain levels for software artifacts (SLSA). 2023. Available at: https://slsa.dev. Accessed on: 15 mar. 2024.

OWASP. OWASP Top 10:2021. OWASP Foundation, 2021. Available at: https://owasp.org/Top10. Accessed on: 20 fev. 2024.

RED HAT. Falco runtime security. 2023. Available at: https://falco.org. Accessed on: 10 mar. 2024.

SEMGRP INC. Semgrep documentation. 2024. Available at: https://semgrep.dev/docs. Accessed on: 11 mar. 2024.

AQUA SECURITY. Trivy vulnerability scanner. 2024. Available at: https://trivy.dev. Accessed on: 11 mar. 2024.

ANCHORE. Syft and Grype documentation. 2024. Available at: https://anchore.com. Accessed on: 11 mar. 2024.

CHECKOV. Infrastructure as code security scanning. 2024. Available at: https://www.checkov.io. Accessed on: 11 mar. 2024.

ZED ATTACK PROXY PROJECT. OWASP ZAP documentation. 2024. Available at: https://www.zaproxy.org. Accessed on: 12 mar. 2024.

STROM, Blake et al. MITRE ATT&CK: design and philosophy. MITRE Corporation, 2018. Available at: https://attack.mitre.org/docs/MITRE_ATTACK_Design_and_Philosophy.pdf. Accessed on: 18 fev. 2024.

VERIZON. 2023 data breach investigations report. Verizon, 2023. Available at: https://www.verizon.com/business/resources/reports/dbir. Accessed on: 22 mar. 2024.

CNCF. Falco: cloud native runtime security. Cloud Native Computing Foundation, 2023. Available at: https://www.cncf.io/projects/falco. Accessed on: 15 mar. 2024.

CILIUM PROJECT. eBPF-based networking and observability. 2023. Available at: https://cilium.io. Accessed on: 16 mar. 2024.

SURICATA. Suricata intrusion detection system documentation. 2024. Available at: https://suricata.io. Accessed on: 12 mar. 2024.

SONAR. SonarQube documentation. 2024. Available at: https://docs.sonarsource.com. Accessed on: 12 mar. 2024.

CYCLONEDX. CycloneDX SBOM specification. 2023. Available at: https://cyclonedx.org. Accessed on: 15 mar. 2024.