Използване на AST в работния процес и кодирането на сигурността

Информатек Дигитал » Ресурси » Използване на AST в работния процес и кодирането на сигурността

Когато говорим за AST в кода за работни процеси , всъщност обединяваме няколко свята, които, макар и на пръв поглед различни, са все по-взаимосвързани: традиционно софтуерно инженерство , сигурност на приложенията, автоматизация на процеси с RPA, генериране на код с AI и, интересното, дори превенция на професионални рискове. Всичко се върти около това как моделираме, анализираме, автоматизираме и защитаваме работните процеси, които управляват сложни системи.

Абстрактните синтактични дървета (AST) са се превърнали в ключов инструмент за разбиране и трансформиране на код, автоматизиране на одити, генериране на тестове, засилване на сигурността и дори графично представяне на бизнес работни процеси. В същото време, акронимът AST обхваща концепции като Тестване на сигурността на приложенията и Анализ на сигурността на работата, които сочат към друга основна идея: подлагането на работните процеси (софтуерни или човешки) на систематичен анализ за откриване на недостатъци, рискове и възможности за подобрение.

AST като абстрактно синтактично дърво в работни процеси и генериране на код

При разработването на персонализиран софтуер, използването на абстрактни синтактични дървета (AST) ви позволява да преминете от непрозрачен код към визуални и разбираеми структури, които точно описват логиката на работния процес. AST разделя програмата на възли, които представляват операции, контролни структури, извиквания на функции, данни и връзки между тях, така че логиката престава да бъде „хлабави редове код“ и се превръща в навигируема графика.

Това представяне е особено полезно при управление на агенти с изкуствен интелект или разпределени архитектури, където работните потоци са сложни и трудни за следване наум. Чрез трансформиране на кода на работния процес в AST (Автоматичен софтуерен анализ) е възможно да се генерират диаграми, които интуитивно показват разклоненията на решенията, зависимостите на компонентите, реда на изпълнение и критичните точки на процеса, улеснявайки разработването, прегледа и вземането на технически решения.

Компании, специализирани в разработването на персонализиран софтуер, като например Q2BSTUDIO , използват тези синтактични дървета, за да трансформират сложни работни процеси в достъпни, визуално ясни и най-вече функционално полезни диаграми. Не става въпрос само за „рисуване на кутии“, а за наличието на структуриран модел, който може да се използва за усъвършенстване на алгоритми, идентифициране на пречки, локализиране на логически грешки и проправяне на пътя за бъдещи оптимизации.

Голямото предимство на AST в този контекст е, че е независим от крайния език за програмиране . От едно и също дърво, потокът може да бъде компилиран или трансформиран в различни езици или платформи (например, различни облачни среди за изпълнение като AWS или Azure), като същевременно се поддържа последователна бизнес логика. Това позволява по-гъвкави, преносими и поддържаеми архитектури, където ядрото на процеса е дефинирано абстрактно, а изпълнимият код е контролирано производно.

Друг ключов момент е повторното използване на възли в рамките на AST . Възможно е да се дефинират логически блокове (например, валидации на входни данни, модели за достъп до данни или механизми за одит), които се използват повторно като сигурни и вече валидирани компоненти. Ако тези възли са известни и на генериращия код изкуствен интелект, той може да ги препраща, вместо да ги измисля от нулата, което значително увеличава сигурността и съгласуваността на генерирания софтуер.

Генериране на характеристики, задвижвани от AST и изкуствен интелект: сигурност, валидност и доверие

Появата на модели на изкуствен интелект, генериращи код, отвори нов фронт : как можем да се доверим на функции, написани от изкуствен интелект, без ръчно да преглеждаме всеки ред? Солидно решение не е директно да се изисква „изпълним код“, а по-скоро структурирано представяне на логиката, използвайки AST (Automatic Support Tool), което след това се валидира и трансформира в код от надежден инструмент.

Работейки с AST вместо с обикновен код , изкуственият интелект генерира възли, операции, контролни структури и потоци от данни, които могат да бъдат автоматично анализирани: типове, пътища на изпълнение, консистентност на параметрите, обработка на грешки, гранични условия и други свойства се проверяват, преди да достигнат до компилатора или интерпретатора. Този филтър драстично намалява риска от изпълнение на злонамерен или просто неправилен код.

Q2BSTUDIO и други организации, изследващи тези техники, поставят особен акцент върху осигуряването на проследимост и проверка на генерираната от изкуствен интелект логика. AST (Автоматизиран системен анализ) се превръща в „междинната истина“, върху която се прилагат правила за сигурност, стандарти за качество, вътрешни политики и анализи на въздействието. По този начин всяка генерирана функция се вписва в библиотека от защитени възли, използвайки предварително одитирани елементи.

Този подход отваря вратата и към многоцелеви компилации : от един и същ AST може да се генерира код на различни езици (например Python за микросървиси, C# за вътрешни услуги или специализирани скриптове за облачни оркестратори). За компании, работещи в хибридни или мултиоблачни среди, това е особено привлекателно, защото гарантира, че бизнес потокът е последователен, независимо от крайния стек.

И накрая, използването на многократно използваеми възли в AST позволява изграждането на сертифицирани „логически библиотеки“. Вместо да измисля модели за достъп до база данни, валидации за сигурност или следи от регистриране, изкуственият интелект ги изгражда от тези градивни елементи, подобрявайки както сигурността, така и производителността и улеснявайки последващите анализи в инструменти като Power BI или други платформи за бизнес разузнаване.

AST, приложен към интелигентно тестване в Python и максимално покритие на кода

AST е и основата на усъвършенствани решения за автоматизирано тестване , като например някои инструменти с отворен код за Python, които използват структурата на кода, за да генерират тестови пакети с много по-високо покритие, отколкото обикновено се постига чрез писане на ръка.

Този тип инструмент комбинира три основни възможности : автоматично генериране на модулни тестове за конкретен Python файл, насочено размиване (fuzzing) за подлагане на критични функции на екстремни и деформирани входни данни и генериране на тестове, ориентирани към покритие, където AST се анализира щателно, за да се локализират всички възможни разклонения, цикли, условия и пътища за изключения.

Ключът е, че инструментът изгражда AST (аналогов тестов актив) на Python кода и от него идентифицира пътища за изпълнение, които все още не са покрити от тестове. С тази информация той възлага на AI модел (например Gemini) да създаде тестови случаи, специално проектирани да активират всеки път. След това изпълнява тестовете и измерва покритието с инструменти като coverage.py, като по този начин затваря автоматизиран цикъл на непрекъснато подобрение.

Този подход не просто генерира първоначална партида тестове ; той позволява итерация и подобрение. Ако след първи кръг все още има маршрути, които не са тествани, те се преразглеждат с помощта на AST (Advanced Test Assay) и от изкуствения интелект се изискват нови случаи. Това прави процеса адаптивен както към нов код, така и към наследени кодови бази с малко или никакво предварително тестване.

Проектът е настроен като MCP (Model Context Protocol) сървър , така че функционира като локална услуга, която може да бъде извикана от редактора или командния ред. Използването на BAML гарантира, че генерираният тестов код се придържа към точен формат, лесен е за анализ и не нарушава инструментите за непрекъсната интеграция, които го консумират.

AST като анализ на безопасността на работното място: безопасни потоци в работната среда

Под същия акроним AST откриваме друга широко използвана концепция в превенцията на професионалния риск: Анализ на безопасността на работното място (Job Safety Analysis). Въпреки че работи на различно ниво от кода, той споделя с абстрактните синтактични дървета идеята за разделяне на поток (в този случай на човешки задачи) на етапи, идентифициране на рискове и дефиниране на контроли преди изпълнение.

Анализът на безопасността на работното място е превантивен процес , прилаган предимно за дейности с висок риск, като работа на височина, работа със сложни машини или боравене с опасни вещества. Работният процес е разделен на стъпки и за всяка стъпка се идентифицират специфични опасности, оценява се нивото на риск и се определят контролни мерки (лични предпазни средства, сигнализация, инструкции за аварийни ситуации и др.).

Ключовите ползи от оценките на безопасността на работното място включват намаляване на злополуките, подобрено съответствие с регулаторните изисквания, повишена оперативна ефективност и засилена култура на безопасност. Ясното разпределение на работата намалява импровизацията, предотвратява прекъсванията поради инциденти и намалява разходите, свързани с наранявания, санкции или спиране на производството.

Типичната процедура за провеждане на JSA в работна среда включва: точно дефиниране на задачата и нейния контекст (среда, оборудване, материали), разделянето ѝ на етапи, идентифициране на опасностите и рисковете на всеки етап (падания, излагане на химикали, заклещвания, повреди на оборудването), установяване на специфични контролни мерки, комуникация и обучение на участващите работници и провеждане на непрекъснат мониторинг и последващи действия за коригиране на анализа, ако условията се променят.

За да бъде този анализ наистина ефективен, е препоръчително да се използват матрици на риска, контролни списъци и все по-често дигитални инструменти, които улесняват документирането, мониторинга и проследимостта на предприетите мерки. Консултантски фирми като GMS Consulting интегрират тези анализи на безопасността на работното място (JSAs) в системи за управление като ISO 45001, помагайки на организациите да преминат вътрешни и външни одити и да поддържат цикъл на непрекъснато подобряване на безопасността и здравето при работа.

Тестване на сигурността на приложенията (AST): SAST, DAST, IAST, MAST и други

В областта на киберсигурността, AST обикновено се отнася до тестване на сигурността на приложенията (Application Security Testing) , т.е. набор от техники и инструменти, насочени към откриване на уязвимости в съвременни приложения, адаптиращи се към гъвкави методологии и нарастващата сложност на софтуера.

AST решенията са крайъгълен камък на всяка стабилна AppSec програма, тъй като ръчните прегледи на кода и традиционните тестови планове са бавни и не се мащабират добре към постоянната поява на нови уязвимости. Освен това, множество разпоредби и регулаторни рамки (като PCI-DSS, наред с други) изрично изискват използването на такива инструменти.

В рамките на тестването за сигурност на приложенията днес можем да различим няколко основни категории : статичен анализ (SAST), динамичен анализ (DAST), интерактивни и хибридни техники (IAST), тестване, специфично за мобилни приложения (MAST) и други допълнителни услуги като SCA, RASP, откриване на приложения, тестване като услуга или инструменти за корелация и покритие.

Технологията Static AST (SAST) анализира код в състояние на покой (изходен код, байткод или двоичен файл) по време на фазите на програмиране и тестване от жизнения цикъл на разработка на софтуер. Счита се за тест на „бяла кутия“, защото анализаторът има достъп както до кода, така и до дизайна на приложението. Тези инструменти търсят слабости като числови грешки, проблеми с валидирането на входа, условия на състезание, опасни препратки, препълвания и т.н.

Технологията Dynamic AST (DAST), от друга страна, се фокусира върху работещото приложение , обикновено в контролирани тестови или производствени среди. Симулираните атаки се стартират отвън, за да се открият проблеми като инжекции, грешки при удостоверяване, лошо управление на сесии, грешки в интерфейса или проблеми с обработката на отговори. Това е подход на „черна кутия“, при който не се предполага познаване на вътрешния код.

Технологиите IAST съчетават най-доброто от SAST и DAST . Приложението е инструментализирано (например с агент в JVM или .NET CLR), за да наблюдава поведението му отвътре, докато се изпълняват динамични тестове. Това позволява корелация на потоците от данни и изпълнение, разбиране дали дадена теоретична уязвимост е действително експлоатируема и намаляване на фалшивите положителни резултати чрез валидиране на откритията в движение.

MAST, или тестване за сигурност на мобилни приложения , прилага комбинация от статичен, динамичен и криминалистичен анализ, специално за приложения за iOS и Android, включително техните backend компоненти. Тези решения обръщат особено внимание на сценарии като руутвани или отключени устройства, фалшиви Wi-Fi мрежи, неправилно управление на сертификати, изтичане на чувствителни данни и други характеристики на мобилната среда.

Допълнителни услуги: SCA, RASP, откриване, бази данни и оркестрация на ASTO

Много доставчици на AST разшириха предлаганите от тях ключови допълнителни услуги , за да обхванат цялата екосистема за сигурност на приложенията и управление на риска в киберсигурността , от композирането на софтуер до създаването на бази данни и оркестрацията на всички инструменти.

Анализът на състава на софтуера (SCA) се фокусира върху идентифицирането на компоненти от трети страни и с отворен код, включени в дадено приложение, и сравняването им с известни бази данни за уязвимости, като NIST NVD, CVE и търговски хранилища като VulnDB. Тези инструменти могат да откриват остарели версии или такива с чакащи корекции за сигурност, но обикновено не идентифицират уязвимости в собствения код на приложението.

RASP (Runtime Application Self-Protection - Самозащита на приложенията по време на изпълнение) отвежда инструментацията на по-високо ниво, използвайки техники, подобни на IAST, за наблюдение на работещото приложение и блокиране на атаки в реално време, конкурирайки се по някакъв начин с традиционните WAF-ове. Много екипи започват с активиране на инструментацията само за диагностични цели (режим IAST) и след като са уверени в резултатите, преминават към режим RASP с ефективно блокиране на атаки.

Също така е от значение възможността за откриване на приложения , която анализира уеб екосистемата на организацията и локализира всички открити сайтове и услуги, включително тези, които са били забравени, но остават потенциална входна точка.

На ниво слой данни , инструментите за анализ на сигурността на базите данни преглеждат версии, корекции, конфигурации, пароли, политики за достъп и други уязвимости, както за данни в покой, така и, в някои продукти, за данни в процес на пренос. Това е от решаващо значение, защото много от експлоатираните уязвимости произтичат от лошо управление на базата данни, а не от недостатъци в кода на приложението.

Моделът ASTaaS (Тестване на сигурността на приложенията като услуга) възлага част или целия процес на тестване за сигурност на специализиран доставчик, комбинирайки статичен и динамичен анализ, тестване за проникване, оценка на API и анализ на риска. Той е особено привлекателен в облачни среди, където настройването и мащабирането на тестови среди е по-лесно.

За да се справят с потопа от открития от множество инструменти, се появиха решения за корелация на резултатите и анализатори на покритие. Първите обединяват и приоритизират уязвимостите, открити от различни решения като SAST, DAST, IAST, MAST и др., докато вторите измерват какъв процент от кода или логическите клонове действително са тествани, което помага за установяване на приемливи прагове за качество и откриване на непроверим код.

Накрая, оркестрацията за тестване на сигурността на приложенията (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) са по-фокусирани върху качеството на кода, отколкото върху чистата сигурност, и пълният им потенциал се реализира, когато са интегрирани от самото начало на проекта, което не винаги се случва. В среди, където съществуващ код – често написан от трети страни – се одитира, тези инструменти могат да се окажат недостатъчни, което налага изграждането на персонализирани анализатори, съобразени с нуждите на екипа.

Процесът на изграждане на статичен анализатор обикновено е организиран като конвейер: започва се с изходния код (генерираният код, двоичните файлове или машинният код не са включени в тази категория), извършва се процес на интернализация, за да се създаде абстрактен модел, верен на оригиналния код (обикновено обогатен AST), извеждат се модели на обекти и изпълнение, прилагат се техники за анализ и накрая се генерират отчети. Качеството на целия процес зависи критично от фазата на интернализация.

Интернализация и генериране на AST: фронтенди, граматики и неясноти

Етапът на интернализация има за цел да преведе изходния код в структура, управляема от парсера, обикновено AST или подобен граф. Това може да се постигне с помощта на интерфейси на съществуващи компилатори (като GCC за C, Mono за .NET или Eclipse JDT за Java), които предоставят доказани и ефикасни структури.

Разчитането на тези интерфейси обаче има недостатъци . Много от тях са проектирани да се интегрират с IDE, изискват създаване на допълнителни проекти и конфигурации и генерират модели, насочени към взаимодействие с потребителя, а не към мащабен анализ. Освен това, те често работят с предварително обработен код (например C с разрешени макроси), което може да доведе до несъответствия с оригиналния изходен код при докладване на грешки.

Когато тези опции са недостатъчни , става необходимо да се прибегне до класически техники на теорията на компилаторите: конструиране на граматики, дефиниране на парсери с инструменти като ANTLR, Bison или Flex, или дори програмиране на комбинатори на парсери или PEG-базирани решения. Това изисква задълбочено разбиране на синтаксиса и семантиката на обработвания език.

Често срещани проблеми на този етап включват синтактични неясноти (изрази, които граматиката може да интерпретира по няколко валидни начина), контекстно-зависими или семантични неясноти (напр. разграничаване дали даден фрагмент представлява декларация на умножение или указател) и разрешаване на препратки (да се знае при всяко използване коя променлива, тип или член всъщност се цитира).

В сложни езици като C++ или в смесени среди – например ASPX с C#, Android с Java/Dalvik – тези неясноти се умножават. Дори усъвършенстваните IDE показват грешки при оцветяване или разпознаване на символи в трудни фрагменти, което илюстрира нивото на трудност за тези, които изграждат свои собствени инструменти за анализ.

Изводът е, че няма магически решения : трябва да овладеете граматиката, семантиката, модела на паметта на езика, правилата за разрешаване на имена и да имате много ясна цел за анализа, защото е лесно да се изгубите в детайли на имплементацията, които не добавят стойност към одита или разглеждания случай на употреба.

Разширени техники за анализ: информационни потоци и модели на изпълнение

След като са налице стабилни вътрешни модели (AST, памет и модели за изпълнение) , започва същинската фаза на анализ. Анализът на потока от данни е ключов тук, като се изучава как информацията се разпространява през приложението от ненадеждни източници (потребителски входове, файлове, сокети и др.) до потенциално опасни поглъщатели ( SQL заявки , системни команди, неекранирано HTML рендиране и др.).

Анализът на потока ви позволява да изучавате всички възможни пътища на изпълнение, свързващи вход с уязвима точка, както напред, така и назад, което е от съществено значение за техниките за анализ на замърсявания. Той изисква прецизно разбиране на модела на паметта на езика и имплицитните механизми за разпространение (предаване по стойност или препратка, затваряния, непроменими обекти, нишки и др.).

Необходимо е също така да се моделира или включи поведението на библиотеки на трети страни , тъй като голяма част от бизнес логиката и точките за вход/изход се намират в тях. Ако те не се вземат предвид, анализите могат да генерират голям брой фалшиви положителни или, още по-лошо, фалшиви отрицателни резултати, които остават незабелязани.

Илюстративен пример е анализът на приложение, уязвимо към SQL инжекция : кодът може да изглежда прост, но чрез taint анализ може да се наблюдава как контролиран от потребителя параметър се разпространява през няколко функции, докато достигне конструкцията на заявката, която се изпълнява без подходяща параметризация. Без подробен модел на потока и паметта, тези зависимости са трудни за автоматично откриване.

Друг, по-сложен случай включва споделени статични променливи, обратни извиквания или събития , където стойността, достигаща до приемник, зависи от предишни изпълнения или по-малко очевидни пътища. Тук моделът на изпълнение – представляващ състояния, преходи и контексти – комбиниран с AST е това, което ни позволява да сглобим пъзела и да направим надеждни заключения относно сигурността на кода.

Въпреки че тези техники въвеждат допълнителни предизвикателства , като например междуезичен анализ или точна оценка на изрази в силно динамична среда, те носят високо качество на резултата: по-малко грешки при интерпретация, по-бързи процеси след изграждане на инфраструктурата и стандартизирана рамка, която може да се адаптира към различни проекти и технологии.

Автоматизация на работни процеси с RPA в AST (Арагонски телематични услуги)

Освен анализа на кода, работните процеси в публичната администрация се оптимизират и чрез технологии за роботизирана автоматизация на процесите (RPA). Илюстративен случай е този на Aragonesa de Servicios Telemáticos (AST), публична организация, която предоставя ИКТ услуги на правителството на Арагон и действа като телекомуникационен оператор за автономната общност.

AST управлява широк каталог от дигитални услуги – управление на документи, електронен подпис, платежни шлюзове, бизнес разузнаване, инфраструктури за пространствени данни, хостинг на приложения, работни станции, свързаност и услуги с добавена стойност – и се сблъска с критично пречка: ръчният процес на създаване на фактури, който консумираше голямо количество време и ресурси в много концентрирани периоди.

За да се справи с това предизвикателство, Hiberus беше привлечена , предлагайки RPA-базирано решение, използващо UiPath. Подходът следваше структурирана последователност: създаване на специализиран Agile център (RPA консултанти, архитекти, разработчици, тестери), консултиране на процеси за идентифициране на автоматизирани данни, системи и работни потоци, разработване на PDD документ с функционално определение и оттам - изграждане на средата и разработване на решението.

Автоматизацията включваше интеграция с корпоративната платформа за цифров подпис , ключова система за подписване на фактури, дори добавяне на система за предупреждения, която липсваше в оригиналния инструмент. Бяха внедрени среди за разработка и производство и беше изпълнен специфичен план за тестване, насочен към предпроизводствените системи, което позволи на AST да валидира робота, без да се отразява на ежедневните му операции.

След валидиране, решението беше внедрено в производство , възползвайки се от силните страни на UiPath: способност за автоматизиране на сложни и високообемни процеси, ниски изисквания за програмиране, лесно хоризонтално мащабиране, бързина на разработка, вградена система за известия и възможност за спиране на изпълнението, ако бъдат открити проблеми.

Проектът беше завършен с подробно обучение за AST персонала , съвместно подготвени ръководства за потребителя и практически сесии, за да се гарантира, че мениджърите могат да работят с инструмента самостоятелно, да коригират настройките и да разбират резултатите, без постоянно да разчитат на доставчика.

Количествените резултати бяха изключително значителни : за двумесечен период бяха генерирани над 500 фактури, с 60% повече от предходната година, а времето за обработка на фактура намаля от 10 минути на приблизително 2, което представлява 80% намаление на средното време за обработка. В средносрочен план се очакват спестявания на стотици часове ръчен труд, в допълнение към качествени ползи като елиминиране на човешките грешки, по-голяма гъвкавост при повторно подаване на фактури, повишена производителност и по-добро съответствие с целите за фактуриране.

От стратегическа гледна точка , този пилотен проект за RPA е в съответствие с плана на AST за въвеждане на роботизирана автоматизация на процесите и автоматизирани административни процедури в рамките на администрацията на Арагон. Освен това, той послужи за преглед и изясняване на бизнес правилата в процеса на фактуриране, подобряване на споделянето на информация между заинтересованите страни и идентифициране на нови процеси, които биха могли да бъдат автоматизирани в следващите фази.

Взета заедно, цялата тази картина показва как концепцията за AST , в различните ѝ значения, е в основата на подобряването на работните процеси: моделиране на програмната логика с помощта на абстрактни синтактични дървета за интелигентна разработка и тестване, изследване на сигурността на приложенията със специализирани инструментариуми, разделяне на работните задачи за елиминиране на рисковете или оркестриране на роботи, които се грижат за повтарящи се задачи, така че хората да могат да се съсредоточат върху дейности с по-висока стойност.