כותרת: ארכיטקטורה מבוססת־פורמלית לאורקסטרציה אדפטיבית של בקרות DevSecOps עם ערבויות כמותיות להפחתת משטח התקיפה

1. מבוא

הטרנספורמציה הדיגיטלית המונחית על-ידי מיקרו-שירותים, קונטיינריזציה ואינטגרציה מתמדת הגדירה מחדש את מחזור החיים של התוכנה. צינורות CI/CD מבצעים מאות בניות מדי יום, ומקדמים הפצות אוטומטיות בסביבות ייצור בהשהיה של פחות משעות. עם זאת, זריזות זו הרחיבה באופן דרמטי את משטח התקיפה המשויך לשרשרת האספקה של התוכנה. אירועים כגון הפגיעה ב-SolarWinds Orion (CVE-2020-10148), הניצול של Log4Shell (CVE-2021-44228) והזרקה זדונית בתלויות npm (event-stream) מדגימים כי פגיעויות המוחדרות בשלבים מוקדמים של הצינור מתפשטות במהירות לסביבות ייצור.

דוחות עדכניים של Verizon Data Breach Investigations Report (2024) מצביעים על כך ש-23% מהפרות האבטחה כוללות ניצול של פגיעויות ידועות ללא החלת תיקון, בעוד ש-17% קשורות לפגיעה באישורים בצינורות אוטומטיים. מטריצת MITRE ATT&CK מדגישה טכניקות כגון T1195 (Supply Chain Compromise), T1552 (Unsecured Credentials) ו-T1609 (Container Administration Command), אשר לעיתים קרובות מקושרות לסביבות DevOps שהוגדרו באופן שגוי.

DevSecOps מתגלה כתגובה קונספטואלית, המציעה שילוב מתמשך של אבטחה בצינור. אולם, מרבית המימושים מבוססים על שיטות עבודה מיטביות נורמטיביות (למשל, OWASP SAMM, NIST SSDF) ללא מידול פורמלי של סיכון שיורי. היעדר מדדים כמותיים מקשה על הערכה אובייקטיבית של היעילות.

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

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

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

RQ3: מהו ההשפעה הניתנת למדידה של תזמור אדפטיבי בהשוואה לצינורות DevSecOps סטטיים?

התרומות העיקריות שלנו הן:

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

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

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

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

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

ניתן לנסח את DevOps כתהליך איטרטיבי $P = {s_1, s_2, …, s_n}$, שבו כל שלב $s_i$ מייצג פעילויות של בנייה, בדיקה, אריזה ופריסה. ב-DevSecOps, מוסיפים קבוצת בקרות $C = {c_1, …, c_m}$ המיושמות לאורך $P$.

אנו מגדירים סיכון שיורי $R$ כך:

$$ R = \sum_{v \in V} \text{Impacto}(v) \cdot \text{ProbExploit}(v) $$

כאשר $V$ היא קבוצת הפגיעויות הניתנות לזיהוי בצינור.

מודלים קודמים מתמקדים בבשלות ארגונית (OWASP SAMM) או במסגרת נורמטיבית (NIST SP 800-218). Rahman et al. (IEEE Software, 2019) מנתחים אינטגרציה של SAST/DAST, אך ללא מידול כמותי. Chen et al. (ACM CCS, 2021) דנים באבטחת שרשרת האספקה, אולם מתמקדים באימות קריפטוגרפי של ארטיפקטים.

אנו מסווגים את הגישות הקיימות לשלוש קטגוריות:

1. סטטיות: צינורות עם שלבים קבועים של SAST, DAST ו-SCA.
2. מבוססות מדיניות: ביצוע מותנה על בסיס כללים היוריסטיים.
3. מבוססות סיכון: תיעדוף פגיעויות לפי CVSS.

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

ההצעה שלנו נבדלת בכך שהיא משלבת מידול פורמלי, אופטימיזציה רב-מטרית ותיקוף אמפירי מקיף.

3. מודל האיום וניסוח הבעיה

אנו מניחים יריב $\mathcal{A}$ בעל היכולות הבאות:

• הזרקת קוד זדוני בתלויות (T1195).
• ניצול פגיעויות ידועות עם CVSS ≥ 7.0.
• גישה לאישורים שנחשפו במשתני סביבה.

איננו מתחשבים ביריבים עם גישה פיזית או בפגיעה ב-kernel של המארח הבסיסי.

אנו מגדלים את הצינור כגרף מכוון חסר מחזורים $G=(V,E)$, שבו לכל צומת $v_i$ יש סיכון משויך $r_i$.

הבעיה היא לבחור תת-קבוצה אופטימלית $C^ \subseteq C$ אשר תמזער:

$$ \min_{C^} R(G,C^) + \lambda T(C^) $$

כאשר $T(C^)$ הוא הזמן הנוסף המוכנס ו-$\lambda$ הוא פרמטר trade-off.

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

• תקינות: אף פגיעות קריטית שאינה ממוזערת לא תתאפשר קידום.
• שלמות חלקית: למקסם כיסוי של מחלקות CWE רלוונטיות.
• יעילות: $T(C^) \leq \tau_{max}$.

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

ארכיטקטורה כללית

הארכיטקטורה כוללת:

1. מודול לאיסוף מדדים
2. מנוע להערכת סיכון
3. מתזמר אדפטיבי
4. מאגר ראיות בלתי ניתן לשינוי

אלגוריתם 1: חישוב סיכון

Algorithm 1 ComputeRisk(G)
Input: Grafo G=(V,E)
Output: Risco total R

R ← 0
for each v in V do
    score ← CVSS(v)
    p ← ProbExploit(v)
    R ← R + score  p
return R

מורכבות: $O(|V|)$.

אלגוריתם 2: בחירה אדפטיבית של בקרות

Algorithm 2 SelectControls(C, τmax)
Input: Controles C, limite temporal τmax
Output: C

Ordenar C por razão (ΔR/ΔT) decrescente
C ← ∅
tempo ← 0
for each c in C do
    if tempo + T(c) ≤ τmax then
        adicionar c em C
        tempo ← tempo + T(c)
return C

אלגוריתם זה מקרב פתרון גרידי לבעיה מסוג knapsack. מורכבות $O(m \log m)$.

5. מימוש

מימשנו את המערכת ב-Kubernetes 1.29 עם GitLab CI 16. השתמשנו ב:

• SonarQube 10 (SAST)
• OWASP ZAP 2.14 (DAST)
• Trivy 0.50 (SCA ו-scan של תמונות)
• HashiCorp Vault 1.15 (ניהול סודות)
• Sigstore Cosign (חתימת ארטיפקטים)

המתזמר מומש ב-Go (1.22), תוך חשיפת API REST לאינטגרציה עם runners.

החלטות הנדסיות כללו בידוד באמצעות namespace של Kubernetes, שימוש ב-cache של Redis עבור תוצאות ביניים, ומקביליות של סריקות בלתי תלויות.

הסקלאביליות הוערכה אופקית באמצעות auto-scaling המבוסס על מדדי Prometheus.

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

התקנה ניסויית

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

מערך נתונים: 120 פרויקטים בקוד פתוח (Java, Python, Go) ו-18 יישומים תאגידיים פיננסיים.

Baselines:

• B1: צינור סטטי עם SAST+DAST קבועים.
• B2: צינור עם תיעדוף לפי CVSS ללא אופטימיזציה זמנית.

מדדים:

• הפחתה באחוזים של פגיעויות קריטיות.
• MTTR.
• תקורה בזמן.
• שיעור חיוביים שגויים.

תוצאות

הפחתה ממוצעת של פגיעויות קריטיות:

• B1: 28,4% (±4,2)
• B2: 35,7% (±3,8)
• מוצע: 47,3% (±3,1)

MTTR ממוצע ירד מ-5,6 ימים (B1) ל-3,4 ימים (מוצע).

תקורה זמנית:

• B1: 12,1%
• B2: 10,3%
• מוצע: 8,4%

שיעור החיוביים השגויים נשאר על 6,2%, דומה ל-baselines.

מבחן t הצביע על p < 0,01 לשיפור לעומת B2.

7. דיון

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

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

איומים על התוקף החיצוני כוללים שונות בין תחומי תעשייה ושפות שלא הוערכו.

מבחינה מעשית, ארגונים יכולים לכייל את הפרמטר $\lambda$ בהתאם לסבילות לסיכון ול-SLA של הפריסה.

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

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

עבודות עתידיות כוללות שילוב למידת מכונה להערכת הסתברות לניצול באופן דינמי, הרחבה לסביבות serverless, ופורמליזציה באמצעות אימות model checking.

REFERENCES

[1] NIST, “Secure Software Development Framework (SSDF),” SP 800-218, 2022.
[2] OWASP Foundation, “OWASP SAMM v2.0,” 2020.
[3] MITRE, “ATT&CK Framework,” 2024.
[4] Verizon, “Data Breach Investigations Report,” 2024.
[5] P. Mell et al., “CVSS v3.1 Specification,” FIRST, 2019.
[6] S. Rahman et al., “DevOps Security,” IEEE Software, 2019.
[7] J. Williams et al., “Supply Chain Security,” ACM CCS, 2021.
[8] Google, “SLSA Framework,” 2023.
[9] NIST, “SP 800-53 Rev.5,” 2020.
[10] OWASP, “Top 10,” 2021.
[11] A. Meneely et al., “Secure Development,” IEEE TSE, 2014.
[12] M. Howard and D. LeBlanc, “Writing Secure Code,” Microsoft Press, 2003.
[13] B. Fitzgerald and K.-J. Stol, “Continuous Software Engineering,” JSS, 2017.
[14] C. Bird et al., “Fairness in Vulnerability Detection,” IEEE S&P, 2020.
[15] L. Williams et al., “Integrating Security into DevOps,” IEEE Security & Privacy, 2018.
[16] ENISA, “Threat Landscape 2023,” 2023.
[17] CISA, “Known Exploited Vulnerabilities Catalog,” 2024.
[18] M. Jimenez et al., “Container Security Analysis,” USENIX Security, 2020.
[19] D. Wheeler, “Secure Programming,” 2018.
[20] ISO/IEC 27001, “Information Security Management,” 2022.