Печалби:
- Възможност за проверка на AI изхода на три слоя: точност, сигурност и източник/лиценз
- Възможност за покриване на рискове като инжектиране, пакети за халюцинации и заровени тайни с безопасни форми и инструменти
- Способност за представяне на критичен за сигурността код за одобрение от компетентен инженер и разбиране на непрехвърляемостта на отговорността
Генерирането на AI код е лесно; Доверяването му е скъпо. Единствената цел на тази част е да трансформира принципа "проверка", който сме повтаряли във всички предишни части, в систематична инженерна дисциплина. Тъй като кодът, произведен от AI, дори и да изглежда правилен на пръв поглед, носи три отделни опасности: да не работи/не е правилен (халюцинация), да е несигурен (уязвимост) и да носи правни/лицензни рискове. Познаването на тези три и създаването на врата за всяка от тях ви прави професионалист.
Тук разглеждаме „валидирането“ на три нива: коректност (кодът действително ли върши работата?), сигурност (издържа ли на злонамерено въвеждане?) и произход/лиценз (имам ли право да използвам този код?). Всеки слой има свои собствени средства за контрол и никой от тях не може да бъде заобиколен с „това каза AI“.
Три нива на риск
1. Риск от точност (халюцинации). Моделът може да извика несъществуваща функция, да използва неправилно API, тихо да заобиколи крайния случай. Кодът изглежда „разумен“, но е грешен. Антидот: компилация, тестване, статичен анализ и визуална проверка.
2. Риск за сигурността. AI може да повтори несигурни модели в данните за обучение: заявка, уязвима за SQL инжектиране, неавтентифициран потребителски вход, слабо криптиране, несигурна десериализация, отворено пренасочване. Кодът работи, но е уязвим за атака. Противоотрова: преглед, фокусиран върху сигурността, автоматизирани скенери (SAST) и налагане на известни сигурни модели.
3. Риск от източник/лиценз. AI може да произведе изход, който много наподобява защитен с авторски права или ограничителен лицензиран код, или може да предложи неподходящо лицензирана зависимост. Противоотрова: проверка на зависимост и лиценз, проверка на оригиналност, корпоративна политика.
Внимание: Най-коварният от тези три риска е сигурността; тъй като кодът може да премине тестване, да работи безпроблемно в производството и уязвимостта се разкрива само когато атакуващият я открие. „Работещ“ не е същото като „сигурен“.
Стъпка по стъпка: Портал за многослойна автентификация
- Четете с разбиране. Наистина разберете кода, преди да го приемете; Не обединявайте код, който не разбирате. Ако не можете да обясните "защо работи", значи все още не е валидиран.
- Уверете се, че съществува. Потвърдете, че всяка използвана функция, API и пакет действително съществува и се използва правилно (порта за халюцинации).
- Стартирайте автоматизирани инструменти. Компилатор, линтер (скенер за стил/грешки), проверка на типа, модулни тестове и, ако е възможно, SAST (тестване на сигурността на статично приложение — инструмент, който сканира изходния код за уязвимости).
- Погледнете го от гледна точка на сигурността. Въведеното валидно ли е? Параметризирана ли е заявката? Погребана ли е тайната? Има ли контрол на авторизацията?
- Проверете източника и лиценза. Лицензирани ли са новите зависимости? Резултатът изглежда ли прекалено подобен на известна кодова база?
- Ако е критично за сигурността, поискайте експертно одобрение. Независим преглед от инженер, компетентен в области като удостоверяване, плащане, криптография, контрол на достъпа е задължителен.
Три мини калъфа
Случай 1 — SQL инжектиране, уловено на вратата за проверка. Кодът, генериран от изкуствен интелект, който обединява въведеното от потребителя директно в SQL заявката за крайна точка за търсене ("... WHERE name = '" + q + "'"). Кодът работеше и премина теста. Инспекцията, фокусирана върху сигурността, и SAST сканирането уловиха това; Той беше преобразуван в параметризирана заявка (подготвен оператор). Ако не беше хванат, това щеше да е класическа уязвимост за изтичане на данни.
Случай 2 — Пакет за халюцинации. AI предложи несъществуващ npm пакет (fast-safe-parse) за задача. Когато разработчикът се опита да го инсталира, пакетът не беше намерен. Още по-лошо: в някои случаи нападателите могат да запълнят такива имена на "призрачни" пакети с истински, злонамерени пакети (объркване на зависимостта). Урок: проверете всеки препоръчан пакет спрямо официалния регистър и хронологията на изтегляне/поддръжка.
Случай 3 — Несъвместимост на лиценза. Красива придружаваща библиотека, предложена от AI, имаше силен лиценз за копилефт, който беше несъвместим с лиценза за продукти на институцията. Сканирането на лиценз за зависимост отчете това; Екипът замени лиценза с подходяща алтернатива. Без проверка би възникнала правна тежест при разпространението на продукта.
Четири копируеми шаблона
Самопроверка преди прием:
Преди да приемете следния код, генериран от AI, проверете: 1) Съществува ли действително всяка функция/API/пакет, който използва? Маркирайте заподозрените. 2) Има ли някакви непроверени входни данни, конкатенация на SQL/команда, скрита тайна, слаба крипто? 3) Какви са неадресираните грешки/крайни случаи? Етикетирайте всяко откритие като „сигурно / вероятно“ и предложете поправки.{{code}}
Преглед, фокусиран върху сигурността:
Разгледайте този код със защитно око. Потърсете често срещани уязвимости в стил OWASP: инжектиране, нарушено удостоверяване/упълномощаване, разкриване на чувствителни данни, несигурна десериализация, неавтентифицирано пренасочване. За всяка констатация: риск, сценарий на експлоатация, възстановяване. Това е предварителен преглед; отнесете критичните констатации към преглед на човешката сигурност.{{code}}
Проверка на зависимост и лиценз:
Избройте зависимостите, добавени/предложени от този код. За всеки: действително ли съществува пакетът, поддържа ли се, какъв би бил типичният му лиценз (ТРЯБВА ДА БЪДЕ ПРОВЕРЕН) и действително ли е необходим за проекта или може да се направи със съществуващ инструмент?{{код или списък със зависимости}}
Безопасно полагане на кофраж (в производство):
Напишете код за {{задача}}. ЗАДЪЛЖИТЕЛНИ правила за сигурност: - Валидирайте/дезинфекцирайте целия външен вход. - Използвайте само параметризирана заявка при достъп до база данни. - Не вграждайте тайни в кода; приемете променлива на средата/таен мениджър - Не преглъщайте грешки; Обмислете го смислено. Обяснете как кодът отговаря на тези правила в 3 елемента.
Слаба подкана / Силна подкана
Слабо: „Напишете заявка, която търси по потребителско име.“ (Може да възникне код, уязвим за инжектиране.)
Силно: "Напишете функция, която търси по потребителско име. Никога не присъединявайте въведеното от потребителя към заявка като низ; използвайте параметризирана заявка (подготвен оператор). Валидирайте въвеждането за дължина и знак. Обяснете в 2 изречения защо кодът е затворен за инжектиране."
Силната версия налага защитен модел от самото начало; По този начин той гарантира, че уязвимостта изобщо не се появява, вместо да я хване по-късно. Важно е обаче да прекарате генерирания код през вратите за проверка.
Слой за удостоверяване
Инструмент/метод
„AI каза“ достатъчно ли е?
точност
Съставяне, тестване, визуална проверка
не
API/реалност на пакета
Официален контрол на документи/записи
не
сигурност
SAST, преглед на сигурността
не
Лиценз/източник
Проверка на зависимост и лиценз
не
Критична за сигурността логика
Одобрение от експертен инженер
Категорично не
Отговорността не може да бъде прехвърляна
Отговорността за грешки, уязвимости или нарушения, произтичащи от кода, създаден от AI инструмент, принадлежи на екипа, който сглобява и разпространява този код, а не на доставчика на инструмента. Това е както професионален, така и юридически факт: вие подписвате. Така че „AI го е произвел“ не е извинение, а оправдание за допълнителна предпазливост. Особено в критични за безопасността системи, AI изходът не е заместител на прегледа и одобрението от квалифициран инженер при никакви обстоятелства; Най-много AI предоставя план, който ускорява този инженер.
Съвет: Създайте кратък контролен списък във вашия екип, който наричате „врата за валидиране на код, генериран от AI“ (изграждане + тест + сканиране за сигурност + визуална проверка). След като тази врата стане навик, загубата на скорост е минимална и намаляването на риска е максимално.
Често срещани грешки
- Объркване на "работи" с "безопасно". Кодът, който преминава теста, може да е уязвим за атака.
- Използване на пакет/API без проверка. Халюцинаторните пакети едновременно повреждат и представляват риск за сигурността.
- Заобикаляне на автоматизирани инструменти. Linter, проверка на типа и SAST улавят евтино това, което хората пропускат.
- Пренебрегване на лиценза. Неправилната лицензирана зависимост създава правна тежест върху разпространението.
- Прехвърляне на отговорността върху автомобила. Екипът отговаря за кода в производството; „ИИ го направи“ не е извинение.
В обобщение
Приемането на AI изход изисква три слоя проверка: коректност (компилиране, тестване, визуална проверка), сигурност (SAST и преглед, фокусиран върху сигурността) и източник/лиценз (проверка на зависимост). Потвърдете, че всеки използван пакет и API действително съществува, наложете защитени модели от самото начало и изпратете критичен за сигурността код за одобрение от квалифициран инженер. „Работи“ не означава безопасно, а „произведено от AI“ не премахва отговорността. Портата за проверка е цената на професионализма, а не на скоростта.
Задача за приложение
Умишлено дайте на AI задача, чувствителна към сигурността (напр. „функция, която търси в базата данни с въвеждане от потребителя“), този път без налагане на безопасен модел. Прекарайте входящия код през шаблони за „самопроверка преди приемане“ и „преглед, фокусиран върху сигурността“: има ли някакво инжектиране, скрита тайна, халюциниран пакет или неудостоверен вход? След това задайте отново същата задача с шаблона „сигурно налагане на шаблон“ и сравнете двата резултата. Ако е възможно, стартирайте инструмент linter/SAST и сравнете констатациите със саморегулирането на AI.
контролен списък
- [ ] Проверявам изхода на AI на три нива: точност, сигурност и лиценз.
- [ ] Потвърждавам, че всяка използвана функция, API и пакет действително съществува.
- [ ] Пускам инструменти за компилиране, тестване, линтер и, ако е възможно, SAST.
- [ ] Налагам сигурни модели (параметризирана заявка, проверка на въвеждане, управление на тайни) от самото начало.
- [ ] Проверявам лицензирането и изискването за нови зависимости.
- [ ] Изпращам критичен за сигурността код за одобрение от компетентен инженер и разбирам, че нося отговорност.