Как да изградим програма за Application Security през 2026 г.?

2:38↗защото води със себе си ужасно много допълнителна работа, която не винаги е напълно смислена. Какъв е правилният модел от моята гледна точка през 2026 година? Трябва да имплементираме сигурност във всеки един етап от създаването на софтуера. В дизайн фазата, писането на кода, селекцията на depънситата, в билда, вплойването, рънтайма- мониторинг на рънтайма и предоставяне на фийдбек. Всичко това е изключително важна част от пълния цикъл на създаване на сигурна апликация, продукт и така нататък. Бих искал да запомните няколко неща от лекцията днес и едно от тях, на което наистина държа, е да разберем, че application security-то е engниing capability, а не просто имплементиране на един securриity scanner. Това е нещо, което е изключително важно. Application security е ангажимент на инженениринга. Генерално какво се промени през 2026? Еa навлезе все повече и повече.

3:56↗Ако към днешна дата някои от вас си зададат въпроса какъв процент от кода, който отива на продакшъ всъщност е разработено от девелопъри. Би ми било интересно да разбера какъв е отговорът. Разбира се, след лекцията ще имаме възможност да го обсъдим. Но реално в към днешна дата кодът идва от девелопърите, които го пишат. Open source API AI MCP-та и AI агенти, Infrastructure S code, Cloud и SAS, както и контейнери. Тоест ние имаме множество източници на този код, което за нас, хората, които се занимаваме с информационна сигурност, означава множество таг вектори, което означава много проблеми. И това е едно от големите предизвикателства за application securityто през 2026 година. Има едно нещо, което а някои наричат илюзията за скорост или така наречения Velocity Inusion. Какво означава това? Според някои изследвания на def.to А съм публикувал тук 41% от целия код в глобален мащаб,

5:11↗който отива на продакшън е генериран от AI. Това обаче идва с пак според публикуваната статия с определени изисквания за ревю, допълнителни секюрити сканирания, което намалява стабилността на генерирания код със 7%. Тоест ние печелим привидно бързина, но това идва с допълнителни изисквания, за да сме сигурни, че това, което ще стигне до продадукшън в крайна сметка е адекватно.

5:48↗Площта на Атака в 2026 се промени адски много. Не е достатъчно да гледаме само кода. Има много други вектори, през които може да бъде компрометиран един продукт. Разбира се, кренли на девелопъри. Тук вече може да има компрометирано ID или съответно някакви акаунти. Може да има secкрети в Git, където имаме експознати ключове или токъни. Другото, което е много популярно, особено в а последните няколко години, са злонамерените пакети. Ако аз искам да кажем популярно хакна или компрометирам една организация, не е необходимо директно да я атакувам. Мога просто да компрометирам пакети, които тя използва и така да успея да а наруша нейната сигурност. И разбира се компрометиране на пайплайна. Тук имаме CICD манипулация, която може да доведе до огромно количество допълнителни атаки и проблеми. Това звучи супер, само че нека да видим в реалността как транслират всички тези

6:58↗рискове. Предполагам по-голямата част от вас са чували за хака срещу компанията BYBIT. А тук имаме класически случаи на компрометиране на девелопърски креншъли. Над 1 милиардла по последни статистики бяха откраднати. Има различни APT групи, които а са поставени във фокуса на разследванията, но в крайна сметка нямаме 100% потвърждения. Единно единствено спекулации. Как обаче се инициира този хак и откъде тръгва всичко? Хакерската група компрометира workкстшъна на разработчик на safe уallта, което всъщност е third party wallet инфраструктурата, която използваit. благодарение на което използват активни AWS session токъни, за да придобият достъп до AWS средата на safe и оттам нататък започва да навързва самата атака. Тоест това е един от атак векторите, които не само, че реално се експлоатира, а и довежда до един от най-мащабните финансови хакове в историята.

8:08↗Secr, разбира се, много популярната атака срещу Юбър от доста години, но това е много, много показателен случай. При нея атакуващият придобива достъп до едно частно репо на бер и намират креншъли, които позволяват да се а достигне съответно а облачната или cloud хостнатата дейта на Uber. Компрометиране на пайплайна тук. Преди седем-8сем години имаше а огромен огромен скандал с това нещо, защото а компрометираха Solar Winds. Solar Winds се използваше активно от много големи международни организации, както и държавни агенции. Така че това беше много, много голям скандал, като при неатакуващите успяха да компрометират софтуербилд процеса и успяха да вмъкнат злонамерен код вътре в Orion продукта. И разбира се зломерените пакети, кликфикса, а mpmите са the latest and greatest, а, което се използва от различните хакерски групи. Clickfix fitching пейджовете, remote access пак,

9:20↗което се доставя чрез различни mpm пакети, довеждат до тези компрометирания. Разбира се, пакетите не са единствените, които биват компрометирани. могат да бъдат mavн, могат да бъдат пайтънски. Това няма голямо значение. Въпросът е, че ние имаме атак вектор, който очевидно се експлоатира и от другата страна ние като хора, които се занимаваме с информационна сигурност, трябва да сме сигурни, че сме го адресирали адекватно. Как изглежда към 2026 година една зря програма за application security? Първо трябва да имаме или така нареченото управление. Тоест какви са правилата, които се следват? Имаме ли някакъв фреймърк? Имаме ли някакви рискове? Кои са приети и кои не са приети? След което минаваме към така наречения сигурен дизайн. При сигурния дизайн трябва да следваме няколко много семпли практики. да направим architкureвw и трет моделинг. За трет моделинга ще

10:25↗говорим малко по-късно, но това е нещо, което е а златният стандарт в сигурния дизайн, сигурния девелопмънт. Тук вече освен туловете, които ползваме за всичко това, имаме трейнинг на девелопъри, securриity champions, тоест да имаме по-добра интеракция с инженерните екипи, които да могат дори без нашето директно участване участие да пишат по-сигурен код. Automated Security, тоест автоматизираното тестване. Тук вече имаме голям набор от тулови и платформи, които можем да ползваме. Може да ползваме SAS toлове, може да ползваме Dust, което е dynamic application security testing, за да виждаме и да проверяваме third party dependencyтата. Все неща, които са много важни, secret scaning, разбира се, но това са неща, които се автоматизират и трябва да присъстват като част от процеса по разработка и създаване на продукти. софтуер suly chaйна разбира се тукбома изключително важен софтуер бил в

11:27↗materials трябва да знаем къде какво имаме и какво използваме и vulnerability мениджмънт и rйфдбека тук имаме много неща които можем да разглеждаме било то vulnerability скенери пентрейшън тестове баути програми голям е фокусът върху взаимодействието между секюрити екипите и а инженерните такива secюрити-то не е самоцел или единствена отговорност на само един екип. Както ви казах, основната идея е да има много добра колаборация, за да може чрез този фийдбек да има процес по създаване на все по-добри и все по-адекватни апликации по-сигурни. Какви биха били първите грешки, които правим ние? А, започвах ги с една Application security програма. Купуваме SAS Tool, защото сме чули, че е много важно да имаме SAS Tool. Купуваме SEA, купуваме Dust и нямаме APS инженер. Резултатът генерират се огромно количество алърти. Имаме адски много фолс позитиви, които в даден момент, знаете, когато се

12:33↗изсипт огромно количество а джиратики, които някой трябва да гледа и после да приоритизира и да поправя, това довежда до определен вид настроения спрямо хората, които ги създават. Така че това със сигурност не е добрият подход и крайният резултат е, че хората започват да игнорират все повече и повече това, което ние изпращаме като рискове. Какъв би бил правилният подход? Първо да разберем какви са рисковете. Това е най-важното нещо. Информационната сигурност и в частност application securриity-то работи с риск. Когато знаем какво може да се обърка и как може да се обърка, ние съответно можем да приоритизираме адресирането на този проблем адекватно, но ако не знаем какво да се може да се обърка, много трудно можем да съдействаме. Какви са апликациите, процеси, какви контроли има. Чак тогава да имплементираме някакви автоматизации и разбира се накрая да поставим

13:36↗туловете, но не в обратния ред. В никакъв случай. Първата стъпка е винаги да знаем какво всъщност предпазваме. Представете си, че а вие сте физическа охрана на дадена сграда и собственици на градата ви казват: "Немаме ви да пазите тази сграда, но не ви казват тази сграда има ли прозорци, има ли врати, има ли подземие, има ли таван, има ли друг, колко изхода има." Това всичко пречи вие да си свършите добре работа. Същото нещо е и с application. Ако не познавате един app какво прави, как работи, много трудно ще може да го предпазите адекватно. В случая можем да имаме някакъв payмън API. Оуъра, казваме кой е о ownра. Това е payмънс. Какви дати са каква да какви данни съдържа? Извинявайте. Данните са свързани с кредитни карти, PCI данни. Дали е достъпен от интернет, тоест дали интернет? Да. В резултат на това е критична апликация, тоест ние трябва да я приоритизираме

14:44↗много високо. Имаме и алтернативата, имаме някаква вътрешна HR система. Разбира се, по никакъв начин неглижираме а тези системи, но тук вече виждаме, че онер е екипът от HR. Данните са свързани с лични такива, но те не са изложени навън към интернет и съответно има по-малка критичност. Тоест, ние може да приоритизираме усилията си в опит да предпазим адекватно тези апликации. Много удобен начин за това нещо е да приложим степенуване по важност на тези апликации. Като тук съм предложил един модел, който от 0 доier 3. Ти 0 са най-високо рисковите апликации и критични такива. Те могат да включват апликации, payйment апликации, както и критична кор инфраструктура. В1, което е второто по критично ниво, имаме критични апликации, които са достъпни от клиентите. При Tier 2 имаме нормални prodъкшъ системи и при Tier 3 имаме някакви вътрешни и по-нискорискови.

15:57↗Занимавайки се с Application Security, ние трябва да си разпределим правилно усилията, за да не хабим такива за по-нискорискови апликации, да се концентрираме върху така наречените Crown Juals, тоест това, което наистина е изключително важно за нашата организация. При ти контроли, които можем да имплементираме, можем да сложим моделинг и някакви security requirement. Code review, SAS, SEA, сканиране за secr infrastructure cod container scanning, API testing, годишен penст и разбира се remediationa. Това е друго нещо, което бих искал да запомните от тази лекция и а да следите, ако се занимавате с Application Security. Усилията на един application security екип нямат голяма стойност, ако не се проследяваме диейшъна на уязвимостите, които бъдат намерени. Ако имате критична уязвимост, която отнема месец и половина или два, за да се фиксне, или риск апетита на

16:55↗организацията ви е много голям, или не ви е критична уязвимостта и нещо трябва да бъде а поправе направено в този случай. Но много е важно да има някакъв дефиниран за различните нива уязвимости, които се намерят и се потвърдят. За по-нискорискови апликации ние можем просто да пуснем SAS, да има един SEA и secret с scaning. Но този риск базиран подход е изключително важен. Може да се ползва и така наречената много популярна в българския жаргон раци matтрица. responsible accountable control the informed. Тук имаме различни апликации, които разбира се можете вие да категоризирате и кой за какво е отговорен. Много е важно да знаем, че една application security програма е отговорна и тя има отговорност всъщност за крайния изход от създаване на стандарти, но например фиксването на уязвимости, макар че е контролирано от application security екипа, е отговорност на продукта, а работата,

18:01↗тоест responsible, този, който трябва да извърши работата, реално са девелопърите. Така че използвайки раци, матрицата може по-лесно да ви изгради процеса за приоритизиране. Всички говорят последните години за така наречения Shift left в application security-то, тоест да имплементираме контроли и проверки за сигурност максимално в началната фаза на създаване на продукт. Аз не съм съгласен с това. Ако отиваш прекалено много наляво, изпускаш нещата, които се случват в края на самия продукшън процес. Така че, пак казвам, имплементиране на мерки за сигурност на всеки един етап, включително дизайн, ID-тата, pr C developм и Runтайма. Какво представляват моделиing? За tradлиing може много да се говори. има доста open source и платени платформи, които всеки от вас може да ползва, но голямата идея за това нещо като процес стои в рамките на четири въпроса, които може да си зададете.

19:09↗Какво изграждаме, какво може да се обърка, какво правим по този въпрос и дали това е достатъчно. Страйт моделът генерално създава насоки, но не е нещо, което трябва да следвате дословно. Отговаряйки се на тези въпроса, вие вече сте започнали да създавате модел за заплахите срещу това, което изграждате. Кога според мен е задължително да се прави трет моделинг? Когато имаме нов интернет. експлознат сървис, имаме някаква промяна вторизация или автентикация, а функционалност нова за плащане, нов API или trust boundary. Имаме някакъв някаква голяма промяна в архитектурата или някаква интеграция с AI LM. Разбира се, security requirement requirementмте са изключително важни, ако просто генерирате един PDF, който казва да направите това, това и това. не носи голяма стойност. Хубаво е да се адресират неща като автентикация, торизация, secтирипtion и logging, за

20:15↗които вие да предложите като хора, които занимават с application security какво да се направи и как да се направи. Колкото повече автоматизираме и спестим време на девелопърите от това да взимат решения за такива ключови а въпроси, толкова по-лесно би било и за нас да си вършим работата в идето. е много важно да имаме акцент от гледна точка на секюрити-то. Ако а копайт или генерират голяма част от кода, който се пише, ние като хора, които занимаваме с информационна сигурност, трябва да си отговорим на въпроса кого обучаваме, как да се пише сигурно, девелоopри или AI. Затова има много хубави secюрити плъгини за ID-тата, които аз лично адмирирам. Има, разбира се, и AI coding assistant политики, Secret detentions, Dependency Warning и Secure Templates. При P requестите много е важно да имаме а чекове, но трябва да внимаваме с имплементацията. Ако започнем да блокираме билдове на база на

21:26↗медиямости, това би попречило ужасно много на целия процес, което разбира се е контрапродуктивно. Трябва да можем правилно да валидираме и приоритизираме функционалности и чак тогава потенциално да блокираме билдове. Така че в началото, разбира се, когато стартираме програма, винаги можем да започнем само срнинги. Какво да измерваме извън стандартните неща за static application security testing в 2024? Е много важно да очакваме reachability и exploitable context. Тоест, ако има някаква критична уязвимост, да кажем SQL injection, но този тази база данни не може да бъде достигната, има в инпута някакъв лав, който може да спрее подобна атака или параметризирани клърита. някъде преди да се стигне до базата данни. Това означава, че тази атака има много нисък процент на reaчаability и exploйтабиity, което автоматично означава, че тази уязимост не е критична.

22:29↗Не трябва да измерваме ефективността на нашата application security програма с това колко общо уязвимости са намерили, а колко избегнали уязвимости имаме, какво е диейшъто, тоест колко време ни отнема да поправим тези уязвимости и дали се повтарят. Нивото на повтаряемост може да бъде много голям проблем. SEA или така наречения Softwareе Composition anal. А тук какво имаме? Тук имаме използване на различен вид библиотеки. Много често в създаването на код ние използваме библиотеки, но не сме сигурни дали тези библиотеки не реферират към други и съответно по този начин ние можем да бъдем компрометирани. Secrets manджм е изключително важен. Тук можем да ползваме най-добрият вариант е, разбира се, да имаме валидирани на secret мениджър, repository scaning. А разбира се, нещо, което също бих искал да запомните е, че най-добре защитената а тайна или така наречения

23:32↗The Best secret е даден креншъл, който експарва преди атакуващия да може да го използва. Това е най-добрият сикрет. Иначе много кратко живеещи креншали са а нещо, което е хубаво да имаме да използваме. Infrastrarch code. Всички или повечето а организации ползват terфоруum, cloud formation, cubernetis. Тук също трябва да можем да изградим някакви мерки за сигурност. Разбира се, Security policy чекове, terform planрев и чак тогава да плойваме. Всичко това ни помага да адресираме и този компонент от application security-то при CCD. А реално тук нямаме нужда, както коментирахме, да хакваме апликацията. Само трябва да компилираме с нашия собствен backкдор. Какво трябва да правим? Разбира се, налагане на мултифакторна автентикация, изолирани рънъри, имutable билдове, list приvilли, подписани артефакти. Това са все неща, които са изключително важни. Softare build of materials, най-общо казано,

24:42↗това е една база данни. За какво ни трябва? SБОМ ни трябва в ситуация, когато има дадена критична уязвимост и тя се е появила в дадена библиотека. На въпроса използваме ли някъде тази библиотека, софтуер бив материас ще ни даде възможност да отговорим в рамките на минути, а не в рамките на дни, което може да е голямата разлика между това дали успешно ни компрометират или не. Ето, разбира се, тук нагледно аа да видим съответните компоненти как имат пендънсите и разчитат една на друга и съответно можем да бъдем компрометирани без реално да знаем. Подписването на артефакти. Това е вариантът, който използваме, за да валидираме, че по никакъв начин не е променян този артефакт, което може също да ни отвори така наречения атак вектор. API Security изключително важен за всяка една зря application security програма. Тук знаем, че за доста организации API е равно на апликация, но какво ще стане,

25:50↗ако чрез софтуера, който а произвежда дадена организация и е свързан с някакви данни за плащания, различни а инвойси, които се произвеждат или клиентски сметки, може просто да се направи една дребна манипулация на API- така че да виждаме не само наш нашите данни, а данните на други клиенти, на фирми и така нататък. Това би бил огромен проблем. Подсигуряване на API-ите е супер важно. Говорихме пак за тази активна комуникация и за мен това е единственият правилен вариант да се извършва Application Security. активната комуникация и фидбек между инженерите и Application Security, а тимът е изключително важен, за да имаме по-адекватна сигурност. Както ви казах, аз не съм а фен на изцяло Shift Left. Аз смятам, че трябва да направим и завой надясно. Тук имаме Web Application Firewall, API телеметрия, Buck Bounty програма. Това е нещо, което смятам, че е задължително за

27:02↗всяка една организация модерна. Пък баутито позволява рисърчъри от целия свят постоянно да тестват вашата апликация. Много организации смятат, че това е скъпо удоволствие. Не е съвсем така. има платформи, които изобщо не изискват такава първоначална инвестиция, а ще дадат експозиция на хора в рамките на правила да тестват вашата а апликация и съответно да ви връщат различни уязвимости, вие да ги възнаграждавате за това нещо. Неминуема част и недрима част от всяка една смислен application securриity програма в 2026 година. Друго нещо важно, рискът се измерва по различен начин. В Application Security ние трябва да имаме предвид severity-то, exploitability-то, тоест дали може да бъде експлойтнато, exposure и бизнес импакта. Тоест някаква уязилност, която има CVSS скоро 9,8, но кодът е недостижим и е част от някакви вътрешни сървиси, е много по-ниско рискова от уязвимост, която има

28:09↗7,5 от десетобалната система, но е отворена към интернет, активно експлоитната и е някакъв payймънт API. Така че ние, пак казвам, трябва да си познаваме това, което пазим, за да можем да го а предпазим адекватно cycle или така наречения последователност на vulnerability мениджмънта, откриване, валидация. Не можем просто да изпратим на инженерен екип някаква уязвимост, без да сме сигурни тя доколко е реално оценена и съществуваща. Правилно приоритизиране на база на валидацията. Ние казваме да има такова нещо, не няма такова нещо, а сам имаме съответно тикета на тима и я поправяме. Друго нещо, накрая сме на времето, ще се постарая да се вместя, но а това е същото нещо, което искам да запомните от тази лекция, а именно Securриity Champion. Това е неформална титла, но това са хората, без които ние, които се занимаваме с информационна сигурност, не бихме могли да имаме пълноценна

29:10↗програма. Представете си компания, в която има 500 девелопъра и девелопъра и пет асек инженера. Това е мащаб едно към 100. Тоест на всеки 100 девелопри има по един асек инженер. Security champions са хора, които имат интерес към информационната сигурност. Те не е задължително да бъдат обучени. Те може просто да имат афинитет към това. Може някъде да са го учили, може да са се занимавали до някаква степен с него, но те са вашите посланници в различните девелопмънт екипи. Те казват, ако има някаква критична уязвимост, те пък могат да ви дават на вас обратна връзка за това дали има нещо, което е ново, нещо, което трябва да се адресира, нещо, което сте пропуснали. Добрата комуникация, изграждане на Security Champion ви дава възможност вие да имате една много силна application security програма. Така че всички и вас, които се занимавате с Application Security, търсете Securриity

30:06↗championните, търсете хората, които се занимават с аа това, което и ние правим. И последно да вмъкнем за AI-я. Ще Ще си позволя 15 секунди. AI пише софтуер, но ние благодарение на това отваряме съвсем нова врата на уязвимости, които изстигат при нас. prompt иjection, excessivey, data leakage, MCP сървъри, всичко това може да доведе до компрометиране. Да, ние трябва да го подсигурим, но ние можем и трябва да ползваме AI в application security-то. Не можем да се изолираме от него, а и той може много да ни помогне. Къде са най-добрите условия за ползване на AI? AI може да се използва за анализиране на уязвимости. Доста сас тулове вече имат AI промтове и прозорци, които ви казват, да, тук има някаква уязвимост. Може да бъде ремедиейтната по този начин и даже ви дават готовото парче код, което да замените. Разбира се, не става въпрос за директен копипейст. Всичко трябва да

31:06↗бъде а преглеждано, но тук може да бъде много полезен. Намаляване на нивото на false positiv. AI чрез агенти може да бъде полезен за това нещо, като се корелират сигнали от source кода, run time envirймтите и съответно се добавят различни а инфраструктур компоненти, за да се филтрира шума и да видим кои са смислените а уязвимости и кои не са. И AIPN тестинг платформи. Това тук е много стойностно. Една от най-големите драми за Application Security екипите е, че не винаги туловете могат да намерят така наречения Business Logic Fall. Business Logic Flow изисква познаване на това как работи апликацията. И тук идва на помощ AI, защото вие може да инструктирате агент коя точно функционалност да я тества и да го оставите да си свърши работата. Това е концепцията за този тип AIPN тестинг. Сега някои си правят собствени платформи. Има open source, има и платени такива. Аз съм със смесени

32:09↗чувства, но най-важното е вие да знаете, че благодарение на AI-я може най-накрая Application Security да се отърве от една от големите заплахи, които така и намират разрешение, а именно а BСКicфла. Ако трябва да инсталираме, ако трябва да стартираме програма, а за 30 дни в общи линии а трябва да направим няколко неща. Ако стигна и до края, ще е супер. Извинявам се за за тази артистична а това отклонение. Добре,

32:50↗една минута обещавам. Така, за да завършим лекцията адекватно, не мога да не ви прекарам през това, което аз смятам за правилния начин да си конструирате Application Security програма през 2026 година. Първите 30 дни правим инвентаризация, описваме кои са ни апликациите, ownersшипаline и съответно правим assessм на актуалното състояние. Първите 30 до 90 дни static application security testing 2,A, Secret Scanning, Infrastructure Code, PR integration и съответно vulnerability process. Това всичко е гъвкаво. Аз ви казвам в най-добрия сценарий кое би било работещо. От първите три до шест месеца трет моделинг интегрираме задължително създаване на Security Champions или поне поста полагане на основите им API Security Pesting страat и метрики и от 6 до 12 месеца Supply Chain Security Somaма, който може да ни помогне много и за Дора регулацията, имайки видимост

33:55↗върху third party, ford party, а risk man, incident man. R time feedback, AI security и continuous improvement. Като цяло последното нещо, което ще ви кажа е не е въпросът на това да въведем повече препятствия в изграждането на кода, а да изградим един сигурен начин на инженерване в нашата организация. Благодаря ви.