Paper Files / DevSecOps

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

2007-07-20DevSecOpsHE

כותרת: מסגרת פורמלית ומוערכת כמותית לתזמור אדפטיבי של בקרות אבטחה ב־pipelines DevSecOps המבוססת על מידול איומים וניתוח סיכונים מתמשך תקציר: האימוץ הגובר של פרקטיקות DevOps שינה באופן רדיקלי את מחזור חיי פיתוח התוכנה, אך הכניס וקטורי תקיפה חדשים הנובעים מאוטומציה נרחבת, Infrastructure as Code ושרשראות אספקה מורכבות. אף ש־DevSecOps מציע אינטגרציה רציפה של אבטחה ל־pipeline הפיתוח, מרבית המימושים נותרו אד הוק, ללא פורמליזציה מתמטית, מידול איומים קפדני ומנגנוני עדיפות אדפטיביים של בקרות. בעבודה זו אנו מציעים מסגרת פורמלית לתזמור אדפטיבי של בקרות אבטחה ב־pipelines DevSecOps, המבוססת על מידול הסתברותי של סיכון ועל שילוב עם מטריצת MITRE ATT&CK. אנו מגדירים באופן פורמלי את בעיית מזעור הסיכון השיורי תחת אילוצי השהיה ועלות חישובית, תוך מידול ה־pipeline כגרף מכוון חסר מעגלים עם פונקציות סיכון המשויכות לכל שלב. פיתחנו שני אלגוריתמים מרכזיים: (i) מנגנון לתעדוף דינמי של בדיקות אבטחה המבוסס על סיכון שולי צפוי ו־(ii) מתזמר אדפטיבי שמגדיר מחדש את ה־pipeline בזמן אמת על בסיס טלמטריית ביצוע. מימשנו את המסגרת על גבי GitLab CI/CD, Kubernetes וכלים כגון SAST, DAST, SCA וסורקי IaC, והערכנו אותה ב־312 מאגרי קוד ארגוניים עם 4.8 מיליון שורות קוד. התוצאות מדגימות הפחתה ממוצעת של 37.4% בזמן הכולל של ה־pipeline, ירידה של 52.1% בסיכון השיורי המוערך והפחתה של 41.3% בחיוביים שגויים בהשוואה ל־pipelines סטטיים מסורתיים. בנוסף, נצפתה שיפור של 29.6% בזמן הממוצע לתיקון (MTTR). התוצאות מצביעות על כך שפורמליזציה מתמטית של תזמור DevSecOps מאפשרת רווחים מקבילים באבטחה וביעילות תפעולית, ותורמת להתבססות המדעית של התחום.

מבוא

הטרנספורמציה הדיגיטלית האיצה את האימוץ ההמוני של שיטות DevOps, המאופיינות באינטגרציה מתמשכת (CI), אספקה מתמשכת (CD) ותשתית כקוד (IaC). אולם, האוטומציה הנרחבת ומהירות ה-deploy הרחיבו את משטח התקיפה, והפכו צינורות תוכנה ליעדים מועדפים. אירועים אחרונים ממחישים מציאות זו. הניצול של פגיעות Log4Shell ‏(CVE-2021-44228) פגע באלפי שרשראות אספקה בשל הפצה אוטומטית של תלויות. מתקפת SolarWinds, הקשורה לטכניקה T1195 ‏(Supply Chain Compromise) של MITRE ATT&CK, הדגימה כיצד צינורות שנפגעו יכולים להפיץ ארטיפקטים זדוניים בהיקף נרחב. בדומה לכך, פגיעויות כגון CVE-2022-22965 ‏(Spring4Shell) חשפו חולשות בתהליכי עדכון מתמשכים.

דוחות כגון Verizon Data Breach Investigations Report ‏(2023) מצביעים על כך ש-74% מהפרות האבטחה מערבות טעות אנוש או כשלי קונפיגורציה, שלעתים קרובות קשורים לצינורות אוטומטיים. OWASP Top 10 ‏(2021) מדגיש כשלים בבקרת גישה, קונפיגורציות לא מאובטחות ופגיעויות ידועות כוקטורים חוזרים. למרות זאת, ארגונים רבים מיישמים DevSecOps באופן הדרגתי ולא שיטתי, ומוסיפים כלי ניתוח סטטי (SAST), דינמי (DAST) וניתוח הרכב תוכנה (SCA) ללא תיאום פורמלי.

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

ניסחנו את שאלות המחקר הבאות:

RQ1: כיצד ניתן למודל באופן פורמלי את הסיכון המצטבר בצינורות DevSecOps תוך התחשבות במגוון וקטורי תקיפה ותלויות בין שלבים?

RQ2: האם ניתן לצמצם בו־זמנית סיכון שיורי ושיהוי באמצעות תזמור אדפטיבי מבוסס-סיכון?

RQ3: אילו תועלות כמותיות ניתן להשיג בסביבות ארגוניות אמיתיות?

התרומות שלנו הן:

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

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

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

שאר המאמר מאורגן באופן הבא: סעיף 2 סוקר יסודות ועבודות קשורות; סעיף 3 מנסח פורמלית את מודל האיום; סעיף 4 מתאר את המתודולוגיה המוצעת; סעיף 5 מפרט את המימוש; סעיף 6 מציג את ההערכה הניסויית; סעיף 7 דן בהשלכות ובמגבלות; וסעיף 8 מסכם.

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

ניתן להגדיר DevSecOps באופן פורמלי כאינטגרציה מתמשכת של בקרות אבטחה $S = {s_1, s_2, …, s_m}$ בצינור פיתוח $P$ המורכב משלבים $V = {v_1, v_2, …, v_n}$. אנו מודלים את הצינור כגרף מכוון חסר מחזורים $G = (V, E)$.

הסיכון המשויך לשלב $v_i$ יכול להיות מיוצג כך:

$$ R(v_i) = P(\text{exploit} \mid v_i) \cdot I(v_i) $$

כאשר $P(\text{exploit} \mid v_i)$ היא ההסתברות המותנית לניצול ו-$I(v_i)$ הוא ההשפעה המשוערת.

עבודות קודמות מתמקדות באינטגרציה של כלים (Rahman et al., IEEE Software, 2019) או במסגרת מושגית (Myrbakken & Colomo-Palacios, Future Generation Computer Systems, 2017). מחקרים על אבטחה ב-CI/CD ‏(Zhang et al., USENIX Security, 2020) מנתחים פגיעויות מסוימות, אך אינם מציעים מודלים פורמליים של אופטימיזציה.

מבחינה טקסונומית, הגישות הקיימות מתחלקות ל:

אינטגרציה סטטית של כלים (צינורות קבועים).
מדיניות gating מבוססת ספים.
מערכות מבוססות-סיכון היוריסטיות.

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

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

אנו מניחים תוקף $\mathcal{A}$ עם יכולות המתאימות למודל Dolev-Yao המורחב עבור צינורות, כולל:

הזרקת תלויות זדוניות (MITRE T1195).
פגיעה באישורי CI (T1078).
ניצול כשלים בארטיפקטים שנוצרו.

לתוקף יש משאבי חישוב פולינומיאליים וגישה לרשת הארגונית.

אנו מגדירים את הבעיה כמזעור הסיכון השיורי הכולל:

$$ R_{total} = \sum_{i=1}^{n} R(v_i) \cdot (1 - C(v_i)) $$

כאשר $C(v_i)$ מייצג את הכיסוי האפקטיבי של הבקרות שיושמו.

בכפוף ל:

$$ \sum_{i=1}^{n} T(v_i) \leq T_{max} $$

כאשר $T(v_i)$ הוא זמן ההרצה ו-$T_{max}$ הוא אילוץ השיהוי.

התכונות הרצויות כוללות:

נכונות: גילוי פגיעויות בהסתברות ≥ $\alpha$.
יעילות: סיבוכיות פולינומיאלית.
אדפטיביות: עדכון דינמי של $R(v_i)$.

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

הארכיטקטורה המוצעת כוללת:

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

Algorithm 1: תעדוף מבוסס סיכון שולי

Input: V, S, T_max
Output: רשימת בקרות ממוינת

1. For each s_j in S:
2.     Calculate ΔR_j = expected risk reduction
3.     Calculate cost C_j = execution time
4.     Calculate score_j = ΔR_j / C_j
5. Sort S by score_j descending
6. Select controls until reaching T_max
7. Return selected list

Complexity: $O(m \log m)$.

Algorithm 2: Orchestration Adaptative

Input: Pipeline G, Telemetria τ
1. Update probabilities P(exploit | v_i)
2. Recalculate R(v_i)
3. Execute Algorithm 1
4. Reconfigure pipeline dynamically

Complexity: $O(n + m \log m)$.

מימוש

מימשנו את המסגרת על גבי GitLab CI/CD 16.4, Kubernetes 1.28 ורצים מבוזרים. השתמשנו ב:

SonarQube (SAST)
OWASP ZAP (DAST)
Trivy (SCA/IaC)
HashiCorp Vault לניהול סודות

מנוע הסיכון מומש ב-Go, עם התמדה ב-PostgreSQL ו-Redis לצורכי cache.

אימצנו ארכיטקטורת מיקרו-שירותים עם תקשורת באמצעות gRPC. המערכת תומכת בהרחבה אופקית, ומגיעה ל-1,200 צינורות במקביל.

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

Setup

Hardware: אשכול עם 32 צמתים, שלכל אחד מהם 32 vCPUs ו-128 GB RAM.

Dataset: 312 מאגרים (4.8 MLOC), 18,742 builds.

Baselines:

צינור סטטי מלא.
צינור עם gating קבוע.

Metrics:

זמן ממוצע של הצינור.
סיכון שיורי מוערך.
תוצאות חיוביות שגויות.
MTTR.

Results

הזמן הממוצע ירד מ-18.4 ± 2.1 דקות ל-11.5 ± 1.8 דקות (−37.4%).

הסיכון השיורי הממוצע ירד מ-0.182 ל-0.087 (−52.1%).

תוצאות חיוביות שגויות פחתו ב-41.3%.

MTTR ירד מ-3.7 ימים ל-2.6 ימים (−29.6%).

מבחני t הצביעו על $p < 0.01$ עבור כל המדדים.

דיון

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

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

מסקנה ועבודה עתידית

הצגנו מסגרת פורמלית ל-DevSecOps אדפטיבי עם מידול מתמטי של סיכון. הדגמנו הפחתות מהותיות בסיכון שיורי ובשיהוי, ובכך אימתנו את RQ1–RQ3.

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

References

[1] NIST, “Secure Software Development Framework (SSDF),” SP 800-218, 2022.
[2] MITRE, “ATT&CK Framework,” 2023.
[3] OWASP Foundation, “OWASP Top 10,” 2021.
[4] Verizon, “Data Breach Investigations Report,” 2023.
[5] M. Myrbakken and R. Colomo-Palacios, FGCS, 2017.
[6] F. Rahman et al., IEEE Software, 2019.
[7] Y. Zhang et al., USENIX Security, 2020.
[8] P. Mell et al., NIST SP 800-53, 2020.
[9] S. Jajodia et al., Springer, 2011.
[10] M. Howard and S. Lipner, Microsoft SDL, 2006.
[11] N. Antunes and M. Vieira, IEEE TDSC, 2014.
[12] B. Behl and K. Behl, IEEE Security & Privacy, 2016.
[13] Google, “SLSA Framework,” 2022.
[14] CNCF, “Cloud Native Security Whitepaper,” 2023.
[15] ENISA, “Threat Landscape,” 2022.
[16] ISO/IEC 27034, 2018.
[17] FIRST, “CVSS v3.1 Specification,” 2019.
[18] CISA, “Secure by Design,” 2023.
[19] J. Williams and J. Dabirsiaghi, IEEE S&P, 2008.
[20] A. Sabelfeld and A. Myers, IEEE S&P, 2003.