Добивки:
- Способност да се потврди излезот на вештачката интелигенција во три слоја: точност, безбедност и извор/лиценца
- Способност да се покријат ризиците како што се инјекции, пакети со халуцинации и закопани тајни со безбедни калапи и алатки
- Способност да се претстави критичниот безбедносен код на одобрение од компетентен инженер и да се разбере непреносливоста на одговорноста
Лесно е да се генерира код за вештачка интелигенција; Да му веруваш е скапо. Единствената цел на оваа единица е да го трансформира принципот „провери“, кој го повторивме во сите претходни единици, во систематска инженерска дисциплина. Бидејќи кодот произведен од вештачката интелигенција, дури и ако изгледа точен на прв поглед, носи три посебни опасности: да биде неработен/неточен (халуцинација), да биде несигурен (ранливост) и да носи правни/лиценцирски ризици. Познавањето на овие три и воспоставувањето врата за секој од нив ве прави професионалец.
Овде ја разгледуваме „валидацијата“ на три слоја: исправност (дали кодот всушност ја врши работата?), безбедност (дали издржува злонамерен влез?) и потекло/лиценца (дали имам право да го користам овој код?). Секој слој има свои средства за контрола, а ниту еден од нив не може да се заобиколи со „така рече вештачката интелигенција“.
Три слоја на ризик
1. Ризик од точност (халуцинација). Моделот може да повика непостоечка функција, да злоупотреби API, тивко да заобиколи рабови. Кодот изгледа „разумен“, но е погрешен. Противотров: компилација, тестирање, статичка анализа и визуелна инспекција.
2. Безбедносен ризик. Вештачката интелигенција може да повторува несигурни обрасци во податоците за обуката: барањето ранливо на инјектирање SQL, неавтентициран кориснички внес, слаба шифрирање, несигурна десериализација, отворено пренасочување. Кодот работи, но е ранлив на напад. Противотров: преглед фокусиран на безбедноста, автоматски скенери (SAST) и наметнати познати безбедни обрасци.
3. Ризик од извор/лиценца. Вештачката интелигенција може да произведе излез што многу наликува на заштитен код со авторски права или ограничувачки лиценциран код, или може да сугерира несоодветно лиценцирана зависност. Противотров: проверка на зависност и лиценца, проверка на оригиналност, корпоративна политика.
Внимание: Најподмолниот од овие три ризици е безбедноста; бидејќи кодот може да помине тестирање, да работи непречено во производството, а ранливоста се открива само кога напаѓачот ќе ја пронајде. „Работењето“ не е исто што и „безбедно“.
Чекор по чекор: Слоевна порта за автентикација
- Читајте со разбирање. Навистина разберете го кодот пред да го прифатите; Не спојувајте код што не го разбирате. Ако не можете да објасните „зошто функционира“, сè уште не е потврдено.
- Потврдете дека постои. Потврдете дека секоја користена функција, API и пакет навистина постојат и се користат правилно (халуцинација порта).
- Стартувај автоматизирани алатки. Компајлер, линтер (скенер за стил/грешки), проверка на типови, тестови на единици и ако е можно SAST (Static Application Security Testing — алатка која го скенира изворниот код за пропусти).
- Погледнете го од безбедносна перспектива. Дали внесувањето е потврдено? Дали барањето е параметрирано? Дали тајната е закопана? Дали има контрола за овластување?
- Проверете го изворот и лиценцата. Дали новите зависности се лиценцирани? Дали излезот изгледа премногу слично на познатата база на кодови?
- Ако е безбедносно критично, побарајте одобрение од експерт. Задолжителен е независен преглед од инженер компетентен во области како што се автентикација, плаќање, криптографија, контрола на пристап.
Три мини футроли
Случај 1 - SQL инјекција фатена на инспекциската порта. Генериран код со вештачка интелигенција што го поврзува внесувањето на корисникот директно во SQL барањето за крајна точка за пребарување („... WHERE name = '“ + q + „'“). Кодот работеше и го помина тестот. Инспекцијата фокусирана на безбедноста и скенирањето SAST го открија ова; Тој беше претворен во параметрирано барање (подготвена изјава). Ако не беше фатен, тоа ќе беше класична ранливост за истекување на податоци.
Случај 2 - Пакет за халуцинации. AI предложи непостоечки npm пакет (брзо безбедно анализирање) за задача. Кога развивачот се обиде да го инсталира, пакетот не беше пронајден. Уште полошо: во некои случаи, напаѓачите можат да ги пополнат таквите имиња на пакети „дух“ со вистински, злонамерни пакети (конфузија на зависноста). Лекција: потврдете го секој препорачан пакет според официјалниот регистар и историјата на преземање/одржување.
Случај 3 - Некомпатибилност на лиценцата. Вешта придружна библиотека предложена од AI имаше силна лиценца за copyleft што не беше компатибилна со лиценцата за производ на институцијата. Скенирањето лиценца за зависност го објави ова; Тимот ја замени лиценцата со соодветна алтернатива. Без верификација, ќе настане правен товар при дистрибуцијата на производите.
Четири шаблони за копирање
Самопроверка пред прием:
Пред да го прифатите следниот код генериран со вештачка интелигенција, проверете: 1) Дали секоја функција/API/пакет што го користи навистина постои? Означете ги осомничените.2) Дали има некаков невалиден влез, спојување SQL/команда, закопана тајна, слаб крипто?3) Кои се неадресираните грешки/рабови случаи? Обележете го секој наод како „одреден/веројатен“ и предложете поправки.{{ код}}
Преглед фокусиран на безбедноста:
Проверете го овој код со безбедносно око. Побарајте вообичаени пропусти во стилот на OWASP: вбризгување, скршена автентикација/овластување, откривање чувствителни податоци, небезбедна десериализација, неавтентицирано пренасочување. За секој наод: ризик, сценарио за експлоатација, санација. Ова е прелиминарен скрининг; упатете ги критичните наоди на прегледот на човековата безбедност.{{code}}
Проверка на зависност и лиценца:
Наведете ги зависностите додадени/предложени од овој код. За секој од нив: дали пакетот навистина постои, дали се одржува, каква би била неговата типична лиценца (МОРА ДА БИДЕ ПОВЕРИРАНА) и дали е навистина потребен за проектот или може да се направи со постоечка алатка?{{ код или листа на зависности}}
Безбедно наметнување на кофражни (во производство):
Напишете код за {{задача}}. ЗАДОЛЖИТЕЛНИ безбедносни правила: - валидирајте/исчистете ги сите надворешни влезови.- Користете само параметрирано барање за пристап до базата на податоци.- Не вметнувајте тајни во кодот; претпостави променлива на животната средина/менаџер на тајни - Не голтај грешки; Разгледајте го значајно. Објаснете како кодот е во согласност со овие правила во 3 ставки.
Слаб промпт / Силен промпт
Слаб: „Напишете барање што пребарува по корисничко име“. (Може да се појави код ранлив на инјектирање.)
Strong: "Напишете функција која пребарува по корисничко име. Никогаш не придружувајте го корисничкиот влез во барањето како низа; користете параметризирано барање (подготвена изјава). Потврдете го влезот за должина и карактер. Објаснете во 2 реченици зошто кодот е затворен за инјектирање."
Силната верзија ја наметнува сигурната шема од самиот почеток; Така, осигурува ранливоста да не се појави воопшто, наместо да ја фати подоцна. Сепак, од суштинско значење е генерираниот код да се помине низ портите за верификација.
Слој за автентикација
Алатка/метод
Дали е доволно „речено со АИ“?
точност
Компилација, тестирање, визуелна инспекција
бр
Реалност на API/пакет
Контрола на службен документ/запис
бр
Безбедност
SAST, безбедносен преглед
бр
Лиценца/извор
Проверка на зависност и лиценца
бр
Безбедносно-критична логика
Одобрување од стручен инженер
Апсолутно не
Одговорноста не може да се пренесе
Одговорноста за грешки, пропусти или прекршувања кои произлегуваат од кодот произведен од алатка за вештачка интелигенција припаѓа на тимот што го составува и дистрибуира тој код, а не на давателот на алатката. Ова е и професионален факт, но и правен: вие потпишувате. Значи „ВИ го произведе“ не е изговор, туку оправдување за дополнителна претпазливост. Особено во безбедносните критични системи, излезот на ВИ не е замена за преглед и одобрување од квалификуван инженер под никакви околности; Најмногу, вештачката интелигенција обезбедува план што го забрзува тој инженер.
Совет: Направете кратка листа за проверка на вашиот тим што ја нарекувате „порта за валидација за кодот генериран од вештачка интелигенција“ (изградба + тест + безбедносно скенирање + визуелна проверка). Штом оваа порта ќе стане навика, губењето на брзината е минимално, а намалувањето на ризикот е максимално.
Вообичаени грешки
- Збунувачки „работи“ со „безбедно“. Кодот што го поминува тестирањето може да биде ранлив на напад.
- Користење на пакетот/API без да го потврдите. Халуцинаторните пакети и корумпираат и претставуваат безбедносен ризик.
- Заобиколувајќи ги автоматските алатки. Линтер, проверка на типови и SAST ефтино го фаќаат она што луѓето го пропуштаат.
- Игнорирање на лиценцата. Несоодветната лиценцирана зависност создава правен товар на дистрибуцијата.
- Префрлање на одговорноста на возилото. Тимот е одговорен за кодот во производството; „Ви го направи тоа“ не е оправдување.
Сумирано
Прифаќањето на излезот со вештачка интелигенција бара три нивоа на проверка: исправност (компајлира, тестирање, визуелна проверка), безбедност (SAST и преглед фокусиран на безбедноста) и извор/лиценца (проверка на зависност). Потврдете дека секој пакет и API што се користат навистина постојат, наметнете безбедни обрасци од самиот почеток и поднесете безбедносно-критична код за одобрување од квалификуван инженер. „Работи“ не значи безбедно, а „произведена вештачка интелигенција“ не ја отстранува одговорноста. Верификациската порта е цената на професионализмот, а не на брзината.
Задача за апликација
Намерно дајте ВИ задача чувствителна на безбедноста (на пр. „функција што ја пребарува базата на податоци со внесување на корисникот“), овој пат без да наметнете безбедна шема. Пренесете го дојдовниот код преку шаблоните „само-ревизија пред прием“ и „преглед фокусиран на безбедноста“: дали има некакво инјектирање, закопана тајна, халуциниран пакет или неавтентициран влез? Потоа повторно прашајте ја истата задача со шаблонот „безбедно наметнување шема“ и споредете ги двата излеза. Ако е можно, вклучете ја алатката linter/SAST и споредете ги наодите со саморегулирањето на вештачката интелигенција.
листа за проверка
- [ ] Го потврдувам излезот на вештачката интелигенција во три слоја: точност, безбедност и лиценца.
- [ ] Потврдувам дека секоја користена функција, API и пакет всушност постојат.
- [ ] Ги извршувам алатките за компајлирање, тестирање, линтер и, ако е можно, SAST.
- [ ] Наметнувам безбедни обрасци (параметризирано барање, валидација на влез, управување со тајни) од самиот почеток.
- [ ] Ги проверувам лиценцирањето и барањата за нови зависности.
- [ ] Поднесувам безбедносно-критична шифра за одобрување од надлежен инженер и разбирам дека сум одговорен.