שימוש ב-AST בתהליך עבודה ובקידוד אבטחה

אינפורמטק דיגיטל » Recursos » שימוש ב-AST בתהליך עבודה ובקידוד אבטחה

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

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

AST כעץ תחביר מופשט בזרימות עבודה ויצירת קוד

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

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

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

היתרון הגדול של AST בהקשר זה הוא שהוא בלתי תלוי בשפת התכנות הסופית . מאותו עץ, ניתן לקמפל או להמיר את הזרימה לשפות או פלטפורמות שונות (לדוגמה, זמני ריצה שונים בענן כמו AWS או Azure), תוך שמירה על לוגיקה עסקית עקבית. זה מאפשר ארכיטקטורות גמישות, ניידות וניתנות לתחזוקה יותר, שבהן ליבת התהליך מוגדרת באופן מופשט וקוד ההפעלה הוא גזירה מבוקרת.

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

יצירת תכונות המונעות על ידי AST ובינה מלאכותית: אבטחה, תוקף ואמון

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

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

Q2BSTUDIO וארגונים אחרים הבוחנים טכניקות אלו שמים דגש מיוחד על הבטחת מעקב ואימות של לוגיקה שנוצרת על ידי בינה מלאכותית. ניתוח מערכת אוטומטי (AST) הופך ל"אמת ביניים" שעליה מיושמים כללי אבטחה, תקני איכות, מדיניות פנימית וניתוחי השפעה. לפיכך, כל פונקציה שנוצרת משתלבת בספרייה של צמתים מאובטחים, תוך מינוף אלמנטים שעברו ביקורת בעבר.

גישה זו פותחת גם את הדלת לבניית קוד רב-תכליתית : מאותו AST, ניתן ליצור קוד בשפות שונות (לדוגמה, Python עבור מיקרו-שירותים, C# עבור שירותים פנימיים, או סקריפטים מיוחדים עבור תזמורי ענן). עבור חברות העובדות בסביבות היברידיות או מרובות עננים, זה אטרקטיבי במיוחד משום שזה מבטיח שזרימת העסקים תהיה עקבית ללא קשר לערימה הסופית.

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

AST מיושם על בדיקות חכמות בפייתון וכיסוי קוד מקסימלי

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

כלי מסוג זה משלב שלוש יכולות עיקריות : יצירה אוטומטית של בדיקות יחידה עבור קובץ Python ספציפי, עיבוד פונקציות מודרך (fuzzing) כדי לחשוף פונקציות קריטיות לקלטים קיצוניים ושגוי, ויצירת בדיקות מוכוונות כיסוי (coverage-oriented test), שבה ה-AST מנותח ביסודיות כדי לאתר את כל הענפים, הלולאות, התנאים ונתיבי החריגים האפשריים.

המפתח הוא שהכלי בונה את AST (Analog Test Asset) של קוד פייתון , ומתוך כך מזהה נתיבי ביצוע שעדיין לא מכוסים על ידי בדיקות. בעזרת מידע זה, הוא מטיל על מודל בינה מלאכותית (לדוגמה, Gemini) משימה ליצור מקרי בדיקה שתוכננו במיוחד להפעלת כל נתיב. לאחר מכן הוא מבצע את הבדיקות ומודד את הכיסוי בעזרת כלים כמו coverage.py, ובכך סוגר מעגל שיפור מתמיד אוטומטי.

גישה זו אינה רק מייצרת קבוצה ראשונית של בדיקות ; היא מאפשרת איטרציה ושיפור. אם, לאחר סבב ראשון, עדיין נותרו מסלולים שלא נבדקו, הם נבדקים מחדש באמצעות AST (Advanced Test Assay) ומקרים חדשים מתבקשים מהבינה המלאכותית. זה הופך את התהליך לניתן להתאמה הן לקוד חדש והן לבסיסי קוד מדור קודם עם מעט מאוד בדיקות מוקדמות, אם בכלל.

הפרויקט מוגדר כשרת MCP (Model Context Protocol) , כך שהוא מתפקד כשירות מקומי שניתן לקרוא לו מהעורך או משורת הפקודה. שימוש ב-BAML מבטיח שקוד הבדיקה שנוצר דבק בפורמט מדויק, קל לניתוח, ואינו מפריע לכלי האינטגרציה הרציפה שצורכים אותו.

AST כניתוח בטיחות בעבודה: זרימות בטוחות בסביבת העבודה

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

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

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

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

כדי שניתוח זה יהיה יעיל באמת, מומלץ להשתמש במטריצות סיכונים, רשימות תיוג, ובאופן גובר גם בכלים דיגיטליים המאפשרים את התיעוד, הניטור והמעקב אחר האמצעים שננקטו. חברות ייעוץ כמו GMS Consulting משלבות את ניתוחי בטיחות העבודה (JSA) הללו במערכות ניהול כגון ISO 45001, ועוזרות לארגונים לעבור ביקורות פנימיות וחיצוניות ולשמור על מעגל של שיפור מתמיד בבטיחות ובבריאות התעסוקתית.

בדיקות אבטחת יישומים (AST): SAST, DAST, IAST, MAST ועוד

בתחום אבטחת הסייבר, AST מתייחס בדרך כלל ל-Application Security Testing , כלומר, מכלול הטכניקות והכלים שמטרתם לאתר פגיעויות ביישומים מודרניים, תוך התאמה למתודולוגיות זריזות ולמורכבות הגוברת של תוכנה.

פתרונות AST הם אבן יסוד בכל תוכנית AppSec חזקה מכיוון שסקירות קוד ידניות ותוכניות בדיקה מסורתיות הן איטיות ואינן מתאימות היטב להופעה המתמדת של פגיעויות חדשות. יתר על כן, תקנות ומסגרות רגולטוריות רבות (כגון PCI-DSS, בין היתר) מחייבות במפורש את השימוש בכלים כאלה.

בתוך בדיקות אבטחת יישומים כיום אנו יכולים להבחין במספר קטגוריות עיקריות : ניתוח סטטי (SAST), ניתוח דינמי (DAST), טכניקות אינטראקטיביות והיברידיות (IAST), בדיקות ספציפיות ליישומים ניידים (MAST) ושירותים משלימים אחרים כגון SCA, RASP, גילוי יישומים, בדיקות כשירות או כלי קורלציה וכיסוי.

טכנולוגיית AST סטטית (SAST) מנתחת קוד במנוחה (קוד מקור, קוד בייט או קוד בינארי) במהלך שלבי התכנות והבדיקה של מחזור חיי פיתוח התוכנה. היא נחשבת לבדיקה של "קופסה לבנה" מכיוון שלמנתח יש גישה גם לקוד וגם לעיצוב האפליקציה. כלים אלה מחפשים חולשות כגון שגיאות מספריות, בעיות אימות קלט, תנאי מרוץ, הפניות לא בטוחות, גלישות וכן הלאה.

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

טכנולוגיות IAST משלבות את הטוב ביותר של SAST ו-DAST . האפליקציה מצוידת (לדוגמה, עם סוכן ב-JVM או ב-.NET CLR) כדי לצפות בהתנהגותה מבפנים בזמן שמתבצעות בדיקות דינמיות. זה מאפשר קורלציה של נתונים וזרימות ביצוע, להבין האם פגיעות תיאורטית ניתנת לניצול בפועל, ולהפחית תוצאות חיוביות שגויות על ידי אימות ממצאים תוך כדי תנועה.

MAST, או בדיקת אבטחת יישומים ניידים , מיישמת שילוב של ניתוח סטטי, דינמי ופורנזי ספציפי ליישומי iOS ואנדרואיד, כולל רכיבי ה-backend שלהם. פתרונות אלה מקדישים תשומת לב מיוחדת לתרחישים כגון מכשירים בעלי root או לא נעולים, רשתות Wi-Fi מזויפות, ניהול אישורים לא תקין, דליפות של נתונים רגישים ומאפיינים אחרים של סביבת המובייל.

שירותים נוספים: SCA, RASP, גילוי, מסדי נתונים ותזמור ASTO

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

ניתוח הרכב תוכנה (SCA) מתמקד בזיהוי רכיבים של צד שלישי וקוד פתוח הכלולים באפליקציה והשוואתם למאגרי מידע ידועים של פגיעויות כגון NIST NVD, CVE ומאגרים מסחריים כמו VulnDB. כלים אלה יכולים לזהות גרסאות מיושנות או כאלה עם תיקוני אבטחה ממתינים, אך בדרך כלל הם אינם מזהים פגיעויות בקוד של האפליקציה עצמה.

RASP (הגנה עצמית של יישומים בזמן ריצה) לוקחת את המכשור צעד קדימה, ומשתמשת בטכניקות דומות ל-IAST כדי לנטר את האפליקציה הפועלת ולחסום התקפות בזמן אמת, תוך תחרות במובנים מסוימים עם WAFs מסורתיים. צוותים רבים מתחילים בהפעלת מכשור למטרות אבחון בלבד (מצב IAST) וכאשר הם בטוחים בתוצאות, הם עוברים למצב RASP עם חסימת התקפות יעילה.

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

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

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

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

לבסוף, Application Security Testing Orchestration (ASTO) מציע לשלב את כל הכלים הללו באופן מתואם בתוך מחזור חיי פיתוח התוכנה (SDLC) וצנרת CI/CD, עם ניהול מרכזי של מדיניות, ביצועים ודיווח. למרות שזה עדיין תחום מתפתח, הוא עונה על הצורך להפוך בדיקות אבטחה לאוטומטיות ככל האפשר מבלי להאט את קצב האספקה.

ניתוח קוד מקור סטטי מוכוון אבטחה: סטנדרטים, טכניקות ואתגרים

ניתוח קוד מקור סטטי עם דגש על אבטחה הוא דרישה הולכת וגוברת עבור ארגונים המבקשים להתאים את עצמם לתקני פיתוח מאובטח ושיטות עבודה מומלצות. מסגרות עבודה כגון CLASP, OpenSAMM, Touchpoints ו-Microsoft SDL משלבות במפורש שלב זה במחזור חיי הפיתוח, ומחזקות את מושג "אבטחה מעצם עיצובה".

מתודולוגיות כגון OWASP ומסגרות SDLC מאובטחות מספקות הנחיות קונקרטיות לביצוע ניתוח סטטי, הגדרת קריטריונים לסקירה, ניצול תוצאות ומיפוי ממצאים מול מדדי ביצוע כגון OWASP Top 10 (XSS, SQL Injection, File Inclusion וכו'). כלי SAST קיימים - מסחריים וקוד פתוח כאחד - מסתמכים במידה רבה על תורת המהדרים, AST וניתוח זרימת מידע כדי להפיק ידע שימושי מהקוד.

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

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

אתגר מרכזי הוא שכלי SAST פופולריים רבים (כגון PMD, SonarQube או FindBugs) מתמקדים יותר באיכות הקוד מאשר באבטחה טהורה, והפוטנציאל המלא שלהם מתממש כאשר הם משולבים מתחילת הפרויקט, דבר שלא תמיד קורה. בסביבות בהן קוד קיים - שלעתים קרובות נכתב על ידי צדדים שלישיים - נבדק, כלים אלה עלולים להיכשל, מה שמחייב בניית מנתחים מותאמים אישית המותאמים לצורכי הצוות.

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

הפנמה ויצירת AST: ממשק משתמש, דקדוקים ועמימות

שלב ההפנמה שואף לתרגם את קוד המקור למבנה הניתן לניהול על ידי המנתח, בדרך כלל גרף AST או גרף דומה. ניתן להשיג זאת באמצעות חזיתות של מהדרים קיימים (כגון GCC עבור C, Mono עבור .NET, או Eclipse JDT עבור Java), המספקים מבנים מוכחים ויעילים.

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

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

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

בשפות מורכבות כמו C++ או בסביבות מעורבות - לדוגמה, ASPX עם C#, אנדרואיד עם Java/Dalvik - אי-בהירויות אלו מתרבות. אפילו IDEs מתקדמים מציגים שגיאות צביעה או זיהוי סמלים בקטעים קשים, דבר הממחיש את רמת הקושי עבור אלו הבונים כלי ניתוח משלהם.

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

טכניקות ניתוח מתקדמות: זרימת מידע ומודלים לביצוע

לאחר שמודלים פנימיים חזקים (AST, זיכרון ומודלים של ביצוע) קיימים , מתחיל שלב הניתוח בפועל. ניתוח זרימת נתונים הוא המפתח כאן, והוא בוחן כיצד מידע מתפשט דרך האפליקציה ממקורות לא מהימנים (קלטי משתמש, קבצים, שקעים וכו') ועד למקורות נקודתיים מסוכנים ( שאילתות SQL , פקודות מערכת, רינדור HTML לא מבוטל וכו').

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

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

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

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

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

אוטומציה של זרימות עבודה עם RPA ​​ב-AST (שירותי טלמטיקה אראגונזי)

מעבר לניתוח קוד, זרימות עבודה עוברות אופטימיזציה גם במינהל הציבורי באמצעות טכנולוגיות אוטומציה של תהליכים רובוטיים (RPA). מקרה לדוגמה הוא זה של Aragonesa de Servicios Telemáticos (AST), גוף ציבורי המספק שירותי טכנולוגיית מידע ותקשורת (ICT) לממשלת אראגון ומשמש כמפעיל התקשורת עבור הקהילה האוטונומית.

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

כדי להתמודד עם אתגר זה, גויסה Hiberus , והציעה פתרון מבוסס RPA באמצעות UiPath. הגישה התבססה על רצף מובנה: הקמת מרכז Agile ייעודי (יועצי RPA, אדריכלים, מפתחים, בודקים), ייעוץ תהליכי לזיהוי נתונים, מערכות וזרימות עבודה הניתנים לאוטומציה, פיתוח מסמך PDD עם הגדרה פונקציונלית, ומשם, בניית הסביבה ופיתוח הפתרון.

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

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

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

התוצאות הכמותיות היו משמעותיות ביותר : בתקופה של חודשיים נוצרו מעל 500 חשבוניות, 60% יותר מהשנה הקודמת, והזמן לחשבונית ירד מ-10 דקות לכ-2 דקות, מה שמייצג הפחתה של 80% בזמן העיבוד הממוצע. בטווח הבינוני, צפויה חיסכון של מאות שעות עבודה ידנית, בנוסף ליתרונות איכותיים כגון ביטול טעויות אנוש, גמישות רבה יותר בהגשת חשבוניות מחדש, עלייה בפריון והתאמה טובה יותר ליעדי החיוב.

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

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