Прибуток:
- Можливість використовувати штучний інтелект як друге око та позначати вразливості класу OWASP (впровадження, жорсткий секрет, контроль доступу) у коді, надаючи контекст
- Можливість усунення помилкових спрацьовувань, створених штучним інтелектом із контекстом, і запобігання розгляду кожної знахідки як справжньої вразливості без її перевірки
- Здатність розпізнавати, що виправлення, запропоноване штучним інтелектом, може створити нові вразливості/помилки, і пропускати кожен патч через ворота для перевірки та тестування
Уразливості в програмному забезпеченні є одними з найдорожчих уразливостей, оскільки вони вбудовані в продукт із самого початку та поширені мільйонам користувачів. Перевірка захищеного коду — це процес читання вихідного коду рядок за рядком і виявлення вразливостей — впровадження SQL, уразливість автентифікації, жорстко закодований пароль, неправильна авторизація — перед тим, як вони почнуть працювати. Коли це робиться вручну, це повільно і виснажливо; Легко пропустити вразливість у великій кодовій базі.
AI є потужним у перевірці коду з двох причин: код також є мовою, і AI добре розпізнає шаблони. ШІ може швидко позначити небезпечні шаблони у фрагменті коду (введення даних користувача безпосередньо в запит, незашифроване зберігання даних, відсутність перевірки введення), пояснити, чому кожен ризикований, і запропонувати виправлення. Але штучний інтелект не бачить усього робочого контексту коду (вхідні дані можуть бути очищені на іншому рівні), він може винайти вразливість, якої не існує (хибний спрацьовування) або пропустити реальну вразливість (хибно-негативний), і, що найважливіше, запропоноване ним «виправлення» може створити нову вразливість або помилку. AI є другим оком і вказівником у перевірці коду; Розробник і експерт з безпеки вирішують, чи є виявлена вразливість справжньою, а також чи є виправлення правильним і безпечним.
Етапи перевірки коду
- Надайте масштаб і контекст. Яка мова, який фреймворк, де цей код приймає вхідні дані, де він дає вихідні дані, на якому рівні він працює? Огляд коду без контексту дає помилкові спрацьовування.
- Пошук небезпечних шаблонів. Шукайте відомі класи вразливостей штучного інтелекту (наприклад, OWASP Top 10): впровадження, автентифікація, розкриття конфіденційних даних, контроль доступу.
- Обґрунтуйте кожен висновок. Для кожного прапора: яка лінія, який клас уразливості, як це можна використовувати, які докази. Необґрунтований висновок не сприймається серйозно.
- Усуньте помилкові спрацьовування. Чи дійсно введення очищається, чи цей шлях справді доступний — перевірте в контексті.
- Перевірте виправлення. Переконайтеся, що патч, рекомендований штучним інтелектом, справді закриває вразливість, не створює нових уразливостей/помилок і пройшов тестування.
- Людське схвалення. Розробник + експерт із безпеки перевіряє знахідку та виправляє; Таким чином він потрапляє в сховище коду.
Терміни: SAST (Static Application Security Testing — статичне тестування безпеки, яке аналізує вихідний код без його запуску). DAST (Dynamic — динамічне тестування, що перевіряє запущену програму зовні). Топ-10 OWASP — це стандартний список найпоширеніших уразливостей веб-додатків. Ін’єкція — це вразливість, спричинена інтерпретацією введення користувача як команди/запиту (наприклад, ін’єкція SQL). Параметризований запит — це правильний метод, який запобігає ін’єкції шляхом відділення вхідних даних від коду.
Таблиця загальних класів уразливості
Клас уразливості
Симптом (в коді)
правильне рішення
Пастка ШІ
SQL ін'єкція
Об'єднання введення в запит
Параметризований запит
Може ігнорувати дезобробку
жорстко закодований секрет
Пароль/введіть код
Секретний сейф (сховище), окр
Хибнопозитивний (зразок/тест)
Слабка автентифікація
Відсутній/неправильний контроль
Потужне централізоване керування
пропускає контекст
Несправний контроль доступу
Без перевірки авторизації
Авторизація на стороні сервера
Не розуміє складного потоку
Розкриття конфіденційних даних
Зберігання/реєстрація без пароля
Шифрування, маскування
Не може знати критичності
Небезпечна серіалізація
Десеріалізуйте ненадійні дані
Безпечний аналіз
Пропускає рідкісний візерунок
три міні-чохла
Випадок 1 — Зловлювання фактичної ін’єкції. Розробник пропонує штучному інтелекту перевірити функцію доступу до даних. AI позначає рядок, де значення userId від користувача з’єднане безпосередньо з текстом SQL, і говорить «це класична ін’єкція SQL, перетворіть її на параметризований запит»; Забезпечує корекцію зразка. Розробник підтверджує, що вхідні дані не були оброблені деінде, перевіряє, що це справжня вразливість, реалізує запропонований параметризований запит і пише тест. ШІ підкреслив вразливість; перевірка та тестування корекції надійшли від розробника.
Випадок 2 — Хибний позитивний фіксований секрет. ШІ бачить у файлі рядок password = "test1234" і каже "критично: жорстко закодований пароль". Розробник перевіряє контекст: це модульний тестовий файл, фіктивні тестові дані, не випущені у виробництво та не перенесені на реальну систему. Висновок хибнопозитивний. Розробник документує це, але не вживає заходів, оскільки це не є справжньою таємницею. Урок: знак ШІ «твердий секрет» має бути усунений контекстом; Не кожен рядок є секретом.
Випадок 3 — нове виправлення вразливості. AI пропонує виправити вразливість XSS (міжсайтовий сценарій); але код, який він пропонує, очищає введення в неправильному місці та пропускає вихідне кодування в іншій області; В результаті щілина не закривається повністю. Експерт із безпеки переглядає виправлення, помічає відсутній код і виправляє його на правильному рівні. Урок: патч, який рекомендує ШІ, не є автоматично безпечним; Кожне виправлення перевіряється та тестується.
Слабка підказка / Сильна підказка
Слабка підказка:
Чи є в цьому коді лазівка, виправте її: [код]
Ця підказка не містить контексту (мова, структура, джерело вхідних даних), не запитує обґрунтування, не ставить під сумнів хибне спрацьовування та відкрита для сліпого прийняття виправлень, створених ШІ. AI змішав ознаки як реальної вразливості, так і неіснуючої.
Потужна підказка:
Ваша роль: помічник, який є ДРУГИМ ОКОМ для розробника в перевірці безпечного коду. Прийняття рішень; вважати виправлення безпосередньо застосованим. Код: [вкажіть мову/фреймворк]. Контекст: ця функція [джерело введення: напр. отримує [зовнішній HTTP-запит], записує в [призначення виведення]. Ваше завдання: (1) позначити можливі вразливості за допомогою класу OWASP, указати номер рядка + чому ризиковано + як використовувати + докази для кожної, (2) написати принаймні 1 хибнопозитивний сценарій для кожного висновку (наприклад, якщо вхідні дані дезінфікуються на іншому рівні), (3) запропонувати виправлення, але зі знаком «[переглянути + написати тест]»; Також оцініть, чи виправлення вводить нові вразливості/помилки. Додавання фальшивої вразливості.[код]
Сильна підказка надає контекст, запитує клас OWASP і докази, ставить під сумнів помилкові спрацьовування та ризики виправлення, змушує перевіряти людину.
Шаблони підказок, які можна копіювати
ШАБЛОН СКАНУВАННЯ ВРАЗЛИВОСТІ Перевірте код [мова/фреймворк] для OWASP Top 10. Для кожного можливого результату: номер рядка, клас уразливості, чому це ризиковано, зразок експлойту, сила доказів (певні/вірогідні/слабкі). Контекст: вхід [джерело], вихід [ціль]. Додавання сфабрикованих знахідок; Якщо ви не впевнені, введіть "[має бути перевірено]". Код: [вставити]
ХИБНОПОЗИТИВНИЙ ШАБЛОН УСУНЕННЯ Для наступного пошуку коду перелічіть сценарії, у яких НЕ ІСНУЄ справжньої вразливості: чи вхідні дані можна очистити на іншому рівні, чи доступний цей шлях, чи є це значення тестом/зразком, чи захищено фреймворк автоматично. Напишіть, як підтвердити для кожного. Знахідка: [вставити]
ШАБЛОН ОЦІНКИ ВИПРАВЛЕННЯ рекомендуємо виправити наступну вразливість; потім критикуйте своє власне виправлення: (1) чи справді воно закриває вразливість, (2) чи вводить нову вразливість/помилку, (3) який тест я маю написати (позитивний і негативний випадок), (4) вплив на продуктивність/функціональність. Я перегляну та протестую виправлення. Уразливість + код: [вставити]
БЕЗПЕЧНИЙ ШАБЛОН НАВЧАННЯ для класу вразливості [напр. SQL injection] порівняльно показують шаблон безпечного введення та типові помилкові шаблони в цій мові/фреймворку. Загальне правило + наведіть приклад коду; але я хочу, щоб ви запитали контекст, перш ніж реалізувати це в моєму коді. Мова/фреймворк: [написати]
Поширені помилки
- Огляд без контексту. Без мови, інфраструктури та контексту вводу/виводу ШІ плутає як реальні, так і фальшиві висновки; Обов’язково надайте контекст.
- Приймаючи кожну ознаку за справжню слабкість. ШІ створює помилкові спрацьовування (тестові дані, вхідні дані очищені на іншому рівні); Просійте кожну знахідку з контекстом.
- Сліпе застосування виправлення ШІ. Рекомендований патч може ввести нові вразливості/помилки; перевірити та написати контрольні роботи.
- Довіряючи помилковому негативу. Навіть якщо штучний інтелект скаже «немає вразливостей», перевірте критичні шляхи самостійно; Статичне сканування не виявляє кожну вразливість.
- Передача коду/секрету зовнішньому інструменту. Приватний код і справжні секрети (ключ, пароль) є інтелектуальною власністю та вразливістю; анонімізувати або використовувати корпоративні ізольовані інструменти.
Порада: коли є код перевірки штучного інтелекту, найефективнішим фільтром є запит на «силу доказів» (певні/імовірні/слабкі) для кожного висновку. Більшість знахідок, позначених як «слабкі», є хибнопозитивними; ви розподіляєте свою енергію на «впевнених».
Застереження: запропоноване ШІ виправлення безпеки не повинно надходити на склад без перевірки. Неправильне «виправлення» може залишити вразливість відкритою та призвести до функціональної помилки у виробництві; Кожен патч проходить перевірку та тестування.
Підсумовуючи
Захищена перевірка коду — це найдешевший спосіб виявити вразливості до того, як їх запустять у виробництво, а оскільки код — це мова, ШІ тут стає потужним другим оком: позначає небезпечні моделі, пояснює ризики, пропонує виправлення. Але штучний інтелект не бачить повного робочого контексту, створює помилкові спрацьовування та помилкові негативи, а рекомендований ним патч може ввести нові вразливості. Отже, перевірка має шість етапів (контекст, перевірка, обґрунтування, усунення помилкових позитивних результатів, перевірка виправлення, схвалення людиною), і рішення залишається за розробником і експертом з безпеки. Три принципи: жодна знахідка не інтерпретується без контексту, кожен знак усувається разом із контекстом, жодне виправлення не потрапляє на зберігання без перевірки. І код/секрет ніколи не передається зовнішньому інструменту без анонімізації.
Аплікаційне завдання
Візьміть зразок фрагмента коду (або видаліть конфіденційні частини з вашого власного коду, або зразок коду з уразливими місцями). Нехай ШІ перевірить його за допомогою шаблону «Сканування вразливостей»; Застосуйте шаблон «Усунення хибних позитивних результатів» для кожної знахідки та видаліть справжні. Візьміть виправлення найсерйознішого висновку за допомогою шаблону «Оцінка відновлення», перегляньте його самостійно та напишіть один позитивний + один негативний тестовий випадок. Зверніть увагу, скільки знахідок були хибнопозитивними.
контрольний список
- [] Я вказав мову, структуру та контекст введення/виведення перед переглядом коду.
- [ ] Я попросив номер рядка, клас уразливості, шлях експлойту та докази для кожної знахідки.
- [] Я перевірив кожну знахідку на помилкові спрацьовування з контекстом.
- [ ] Я не застосовував наосліп виправлення ШІ; Переглянув і написав контрольну.
- [ ] Незважаючи на висновок «Немає вразливостей», я перевірив критичні шляхи самостійно.
- [ ] Я анонімізував код/секрети або використав корпоративні ізольовані інструменти.
- [ ] Я пройшов пошук і виправлення через схвалення розробника та безпеки.