Печалби:
- Възможност за използване на изкуствен интелект като второ око и маркиране на уязвимости на клас OWASP (инжектиране, твърд секрет, контрол на достъпа) в кода чрез даване на контекст
- Възможност за елиминиране на фалшиви положителни резултати, произведени от изкуствен интелект с контекст, и предотвратяване на третирането на всяко откритие като истинска уязвимост, без да го валидира
- Възможност за разпознаване, че корекцията, предложена от изкуствения интелект, може да въведе нови уязвимости/бъгове и да премине всяка корекция през портала за преглед и тестване
Уязвимостите в софтуера са сред най-скъпите уязвимости, защото са вградени в продукта от самото начало и са разпространени до милиони потребители. Прегледът на защитения код е процесът на четене на изходния код ред по ред и улавяне на уязвимости — SQL инжектиране, уязвимост при удостоверяване, твърдо кодирана парола, неправилно оторизиране — преди да влязат в производство. Когато се прави на ръка, е бавно и изморително; Лесно е да пропуснете уязвимост в голяма кодова база.
AI е мощен при преглед на код по две причини: кодът също е език и AI е добър в разпознаването на шаблони. AI може бързо да маркира опасни модели в част от код (поставяне на въведени от потребителя данни директно в заявката, некриптирано съхранение на данни, липсващо валидиране на вход), да обясни защо всеки е рисков и да предложи поправка. Но AI не вижда целия оперативен контекст на кода (входът може да се изчиства на друг слой), той може да измисли уязвимост, която не съществува (фалшиво положително) или да пропусне истинска уязвимост (фалшиво отрицателно), и най-важното, „поправката“, която предлага, може да въведе нова уязвимост или грешка. AI е второ око и показалец в прегледа на кода; Разработчикът и експертът по сигурността решават дали дадено откритие е реална уязвимост и дали корекцията е правилна и безопасна.
Стъпки на преглед на кода
- Дайте обхват и контекст. Кой език, коя рамка, къде този код приема вход, къде дава изход, на кой слой работи? Прегледът на код без контекст води до фалшиви положителни резултати.
- Сканирайте за опасни модели. Търсете известни класове уязвимости на AI (като OWASP Топ 10): инжектиране, удостоверяване, разкриване на чувствителни данни, контрол на достъпа.
- Обосновайте всяка констатация. За всеки флаг: кой ред, кой клас на уязвимост, как може да се използва, какви са доказателствата. Необоснованата констатация не се приема сериозно.
- Елиминирайте фалшивите положителни резултати. Дали входът наистина се изчиства, този път наистина ли е достъпен - проверете с контекста.
- Проверете корекцията. Потвърдете, че корекцията, препоръчана от AI, действително затваря уязвимостта, не въвежда нови уязвимости/бъгове и е преминала тестване.
- Човешко одобрение. Разработчик + експерт по сигурността преглежда находката и коригира; Така влиза в хранилището на кода.
Условия: SAST (Static Application Security Testing — статичен тест за сигурност, който анализира изходния код, без да го изпълнява). DAST (Динамичен — динамично тестване, което тества външно работещото приложение). Топ 10 на OWASP е стандартният списък с най-често срещаните уязвимости в уеб приложенията. Инжектирането е уязвимост, причинена от интерпретирането на въвеждане от потребителя като команда/заявка (напр. SQL инжектиране). Параметризираната заявка е правилният метод, който предотвратява инжектирането чрез отделяне на входа от кода.
Таблица с общи класове на уязвимост
Клас на уязвимост
Симптом (в код)
правилното решение
Капанът на AI
SQL инжекция
Присъединяване на вход към заявка
Параметризирана заявка
Може да игнорира дезинфекция
твърдо кодирана тайна
Парола/въведете код
Таен сейф (трезор), окол
Фалшив положителен резултат (проба/тест)
Слаба автентификация
Липсващ/неправилен контрол
Мощен, централизиран контрол
пропуска контекст
Дефектен контрол на достъпа
Няма проверка за оторизация
Оторизация от страна на сървъра
Не разбира сложния поток
Разкриване на чувствителни данни
Съхранение/регистриране без парола
Криптиране, маскиране
Не може да знае критичността
Несигурна сериализация
Десериализирайте ненадеждни данни
Сигурно анализиране
Липсва рядък модел
три мини калъфа
Случай 1 — Улавяне на действителното инжектиране. Разработчикът кара AI да изследва функция за достъп до данни. AI маркира реда, където стойността на userId от потребителя е свързана директно в SQL текста и казва „това е класическо SQL инжектиране, превърнете го в параметризирана заявка“; Осигурява корекция на пробата. Разработчикът потвърждава, че входът не е дезинфекциран другаде, проверява дали това е реална уязвимост, прилага предложената параметризирана заявка и пише тест. AI подчерта уязвимостта; тестването за проверка и корекция дойде от разработчика.
Случай 2 — Фалшива положителна фиксирана тайна. AI вижда паролата = "test1234" ред във файл и казва "критично: твърдо кодирана парола". Разработчикът проверява контекста: това е единичен тестов файл, фиктивни тестови данни, които не са пуснати в производство и не са пренесени в реална система. Находката е фалшиво положителна. Разработчикът документира това, но не предприема действия, защото не е истинска тайна. Урок: Знакът „твърда тайна“ на AI трябва да бъде елиминиран от контекста; Не всеки низ е тайна.
Случай 3 — Нова корекция на уязвимост. AI предлага корекция за XSS (скриптиране между сайтове) уязвимост; но кодът, който той предлага, изчиства входа на грешното място и пропуска изходното кодиране в друга област; В резултат на това празнината не се затваря напълно. Експертът по сигурността преглежда корекцията, забелязва липсващото кодиране и я коригира на правилния слой. Урок: Пачът, който AI препоръчва, не е автоматично защитен; Всяка поправка се преглежда и тества.
Слаба подкана / Силна подкана
Слаба подкана:
Има ли вратичка в този код, поправете я: [код]
Тази подкана не дава контекст (език, рамка, източник на вход), не изисква обосновка, не поставя под въпрос фалшивото положително и е отворена за сляпо приемане на корекцията, произведена от AI. AI смесва признаци както на реална уязвимост, така и на несъществуваща.
Мощна подкана:
Вашата роля: асистент, който е ВТОРОТО ОКО на разработчика при преглед на защитен код. Вземане на решения; считайте корекцията директно приложена. Код: [посочете език/рамка]. Контекст: тази функция [източник на вход: напр. получава [външна HTTP заявка], пише в [изходна дестинация]. Вашата задача: (1) маркирайте възможни уязвимости с класа OWASP, дайте номер на ред + защо е рисковано + как да се използва + доказателства за всяка, (2) напишете поне 1 фалшиво положителен сценарий за всяка констатация (напр. ако входът е дезинфекциран в друг слой), (3) предложете корекция, но със знака „[преглед + напишете тест]“; Също така преценете дали корекцията въвежда нови уязвимости/бъгове. Добавяне на фалшива уязвимост.[код]
Силната подкана дава контекст, изисква OWASP клас и доказателства, поставя под въпрос фалшиви положителни резултати и рискове от отстраняване, принуждава преглед от човек.
Копируеми шаблони за подкана
ШАБЛОН ЗА СКАНИРАНЕ НА УЯЗВИМОСТИ Разгледайте [език/рамка] код за OWASP Топ 10. За всяка възможна констатация: номер на ред, клас на уязвимост, защо е рисковано, примерен експлойт, сила на доказателствата (сигурни/вероятни/слаби). Контекст: вход [източник], изход [цел]. Добавяне на измислени констатации; Ако не сте сигурни, въведете „[трябва да бъде потвърдено]“. Код: [поставете]
ФАЛШИВО ПОЛОЖИТЕЛЕН ОБРАЗЕЦ НА ЕЛИМИНИРАНЕ За следното намиране на код, избройте сценариите, в които НЯМА реална уязвимост: може ли входът да бъде изчистен на друг слой, този път достъпен ли е, тази стойност тест/проба ли е, рамката автоматично ли е защитена. Напишете как да потвърдите за всеки един. Намиране: [поставяне]
ШАБЛОН ЗА ОЦЕНКА НА КОРЕКЦИЯ препоръчвам корекция за следната уязвимост; след това критикувайте собствената си корекция: (1) наистина ли затваря уязвимостта, (2) въвежда ли нова уязвимост/бъг, (3) какъв тест трябва да напиша (положителен и отрицателен случай), (4) въздействие върху производителността/функционалността. Ще прегледам и тествам корекцията. Уязвимост + код: [поставяне]
СИГУРЕН ШАБЛОН ЗА ОБУЧЕНИЕ за клас на уязвимост [напр. SQL инжектиране] сравнително показват шаблон за безопасно въвеждане и често срещани грешни шаблони в този език/рамка. Общо правило + дайте примерен код; но искам да попитате контекста, преди да го внедрите в моя код. Език/рамка: [пишете]
Често срещани грешки
- Преглед без контекст. Без език, рамка и входно/изходен контекст, AI обърква както реални, така и фалшиви открития; Не забравяйте да посочите контекст.
- Грешно приемане на всеки знак за истинска слабост. AI произвежда фалшиви положителни резултати (данни от теста, входът е почистен на друг слой); Пресейте всяка констатация с контекста.
- Сляпо прилагане на корекцията на AI. Препоръчаната корекция може да въведе нови уязвимости/бъгове; преглед и писане на тестове.
- Доверяване на фалшивия отрицателен резултат. Дори ако AI каже "няма уязвимости", проверете сами критичните пътища; Статичното сканиране не открива всяка уязвимост.
- Предоставяне на кода/тайната на външния инструмент. Частният код и истинските тайни (ключ, парола) са интелектуална собственост и уязвимост; анонимизирайте или използвайте корпоративни изолирани инструменти.
Съвет: Когато разполагате с кода за преглед на AI, най-ефективният филтър е да поискате „силата на доказателствата“ (сигурни/вероятни/слаби) за всяко откритие. Повечето открития, отбелязани като „слаби“, са фалшиви положителни резултати; разпределяте енергията си към „сигурните“.
Внимание: предложената от AI корекция на сигурността не трябва да влиза в склада, без да бъде тествана. Една неправилна „корекция“ може както да остави уязвимостта отворена, така и да доведе до функционална грешка в производството; Всяка корекция минава през портала за преглед и тестване.
В обобщение
Сигурният преглед на кода е най-евтиният начин за улавяне на уязвимости, преди да бъдат пуснати в производство, и тъй като кодът е език, AI се превръща в мощно второ око тук: маркира опасни модели, обяснява риска, предлага корекции. Но изкуственият интелект не вижда целия оперативен контекст, произвежда фалшиви положителни и фалшиви отрицателни резултати и корекцията, която препоръчва, може да въведе нови уязвимости. Така че прегледът има шест стъпки (контекст, проверка, обосновка, елиминиране на фалшиви положителни резултати, проверка на корекцията, одобрение от човек) и решението е на разработчика и експерта по сигурността. Три принципа: никое откритие не се интерпретира без контекст, всеки знак се елиминира с контекста, нито една корекция не отива в хранилището нетествана. И кодът/тайната никога не се дава на външен инструмент без анонимизиране.
Задача за приложение
Вземете примерен кодов фрагмент (или премахване на чувствителни части от вашия собствен код, или примерен код с уязвимости). Накарайте AI да го изследва с шаблона „Сканиране на уязвимости“; Приложете шаблона „Елиминиране на фалшиви положителни резултати“ за всяка констатация и елиминирайте истинските. Вземете корекцията на най-сериозната констатация с шаблона „Оценка на санирането“, прегледайте я сами и напишете един положителен + един отрицателен тестов случай. Обърнете внимание колко констатации са фалшиви положителни резултати.
контролен списък
- [ ] Дадох езика, рамката и входно/изходния контекст, преди да прегледам кода.
- [ ] Поисках номер на ред, клас на уязвимост, път на експлоатиране и доказателства за всяко откритие.
- [ ] Проверих всяко откритие за фалшиви положителни резултати с контекст.
- [ ] Не приложих сляпо корекцията на AI; Прегледах и написах тест.
- [ ] Въпреки изхода „Няма уязвимости“, аз лично проверих критичните пътища.
- [] Анонимизирах кода/тайните или използвах корпоративни изолирани инструменти.
- [ ] Преминах откриването и корекцията чрез одобрение от програмист + защита.