Добици:
- Способност верификације АИ излаза на три слоја: тачност, безбедност и извор/лиценца
- Способност покривања ризика као што су ињекције, пакети халуцинација и закопане тајне са сигурним калупима и алатима
- Способност представљања безбедносно критичног кода на одобрење надлежног инжењера и разумевање непреносивости одговорности
Генерисање АИ кода је лако; Веровати му је скупо. Једина сврха ове јединице је да трансформише принцип „верификације“, који смо понављали у свим претходним јединицама, у систематску инжењерску дисциплину. Зато што код који производи вештачка интелигенција, чак и ако се на први поглед чини исправним, носи три одвојене опасности: нефункционисање/нетачност (халуцинације), несигурност (рањивост) и ризик од правног/лиценцирања. Познавање ова три и успостављање врата за свако од њих чини вас професионалцем.
Овде разматрамо „валидацију“ на три слоја: исправност (да ли код заиста ради свој посао?), безбедност (да ли издржава злонамерни унос?) и порекло/лиценцу (да ли имам право да користим овај код?). Сваки слој има своја средства контроле и ниједан од њих се не може заобићи са „то је оно што је АИ рекла“.
Три слоја ризика
1. Ризик од тачности (халуцинације). Модел може позвати непостојећу функцију, злоупотребити АПИ, тихо заобићи ивични случај. Код изгледа „разумно“, али је погрешан. Протуотров: компилација, тестирање, статичка анализа и визуелни преглед.
2. Безбедносни ризик. АИ може поновити несигурне обрасце у подацима за обуку: упит рањив на СКЛ ињекцију, неауторизован кориснички унос, слабо шифровање, несигурна десериализација, отворено преусмеравање. Код ради, али је подложан нападима. Протуотров: преглед фокусиран на безбедност, аутоматизовани скенери (САСТ) и наметање познатих безбедних образаца.
3. Ризик извора/лиценце. АИ може произвести излаз који веома личи на заштићени ауторским правима или рестриктивни лиценцни код, или може сугерисати неодговарајућу лиценцирану зависност. Протуотров: провера зависности и лиценце, провера оригиналности, корпоративна политика.
Опрез: Најподмуклији од ова три ризика је безбедност; јер код може да прође тестирање, да ради глатко у производњи, а рањивост се открива само када је нападач пронађе. „Радити“ није исто што и „безбедно“.
Корак по корак: Вишеслојна капија за аутентификацију
- Читајте са разумевањем. Заиста разумете код пре него што га прихватите; Не спајајте код који не разумете. Ако не можете да објасните „зашто функционише“, то још није потврђено.
- Проверите да ли постоји. Потврдите да свака функција, АПИ и пакет који се користе заиста постоје и да се правилно користе (капија халуцинације).
- Покрените аутоматизоване алате. Компајлер, линтер (скенер стилова/грешака), провера типа, јединични тестови и, ако је могуће, САСТ (Статиц Апплицатион Сецурити Тестинг — алатка која скенира изворни код у потрази за рањивостима).
- Посматрајте то из безбедносне перспективе. Да ли је унос потврђен? Да ли је упит параметризован? Да ли је тајна закопана? Да ли постоји контрола ауторизације?
- Проверите извор и лиценцу. Да ли су нове зависности лиценциране? Да ли излаз изгледа превише слично познатој бази кода?
- Ако је безбедносно критичан, затражите одобрење стручњака. Независна провера од стране инжењера компетентног у областима као што су аутентификација, плаћање, криптографија, контрола приступа је обавезна.
Три мини кућишта
Случај 1 — СКЛ ињекција ухваћена на капији за инспекцију. Код генерисан од вештачке интелигенције који спаја кориснички унос директно у СКЛ упит за крајњу тачку претраге ("... ВХЕРЕ наме = '" + к + "'"). Код је радио и прошао је тест. Инспекција усмерена на безбедност и САСТ скенирање су открили ово; Конвертован је у параметризовани упит (припремљени исказ). Да није ухваћен, то би била класична рањивост на цурење података.
Случај 2 — Халуцинациони пакет. АИ је предложио непостојећи нпм пакет (фаст-сафе-парсе) за задатак. Када је програмер покушао да га инсталира, пакет није пронађен. Још горе: у неким случајевима, нападачи могу да попуне такве "духове" називе пакета стварним, злонамерним пакетима (збрка зависности). Лекција: проверите сваки препоручени пакет у односу на званични регистар и историју преузимања/одржавања.
Случај 3 — Некомпатибилност лиценце. Одлична пратећа библиотека коју је предложила АИ имала је јаку копилефт лиценцу која није компатибилна са лиценцом за производ институције. Скенирање лиценце зависности је ово пријавило; Тим је заменио лиценцу одговарајућом алтернативом. Без провере, настао би правни терет у дистрибуцији производа.
Четири шаблона за копирање
Самопровера пре уписа:
Пре него што прихватите следећи код генерисан од вештачке интелигенције, проверите: 1) Да ли свака функција/АПИ/пакет који користи заиста постоји? Означите осумњичене.2) Да ли постоје непотврђени унос, СКЛ/командна конкатенација, скривена тајна, слаба шифра?3) Које су нерешене грешке/ивични случајеви? Означите сваки налаз као „известан/вероватан“ и предложите исправке.{{цоде}}
Преглед усредсређен на безбедност:
Испитајте овај код сигурносним оком. Потражите уобичајене рањивости у стилу ОВАСП-а: убризгавање, покварена аутентификација/ауторизација, откривање осетљивих података, несигурна десериализација, неауторизовано преусмеравање. За сваки налаз: ризик, сценарио експлоатације, санација. Ово је прелиминарни скрининг; упутити критичне налазе на преглед људске безбедности.{{цоде}}
Провера зависности и лиценце:
Наведите зависности које додаје/предлаже овај код. За сваки: да ли пакет заиста постоји, да ли се одржава, која би била његова типична лиценца (МОРА БИТИ ВЕРИФИКОВАНА), и да ли је заиста потребан за пројекат или се то може урадити помоћу постојеће алатке?{{код или листа зависности}}
Безбедно постављање оплате (у производњи):
Напишите код за {{задатак}}. ОБАВЕЗНА безбедносна правила:- Потврдите/санитирајте сав екстерни унос.- Користите само параметризовани упит у приступу бази података.- Немојте уграђивати тајне у код; претпоставити променљиву окружења/тајни менаџер - Не гутајте грешке; Размотрите то смислено. Објасните како је код у складу са овим правилима у 3 ставке.
Слаби промпт / Јаки промпт
Слабо: „Напишите упит који претражује по корисничком имену.“ (Може се појавити код подложан убризгавању.)
Снажно: „Напишите функцију која претражује по корисничком имену. Никада немојте спајати кориснички унос у упит као стринг; користите параметризовани упит (припремљени исказ). Потврдите унос за дужину и карактер. Објасните у 2 реченице зашто је код затворен за убризгавање.“
Јака верзија намеће сигуран образац од почетка; На тај начин обезбеђује да се рањивост уопште не појави, уместо да је касније ухвати. Међутим, неопходно је проћи генерисани код кроз капије за верификацију.
Слој за аутентификацију
Алат/метод
Да ли је "АИ рекао" довољно?
тачност
Састављање, тестирање, визуелни преглед
бр
Реалност АПИ/пакета
Контрола службених докумената/записа
бр
Безбедност
САСТ, безбедносни преглед
бр
Лиценца/извор
Провера зависности и лиценце
бр
Безбедносно-критичка логика
Одобрење стручног инжењера
Апсолутно не
Одговорност се не може пренети
Одговорност за грешке, рањивости или кршења која произилазе из кода произведеног помоћу АИ алата припада тиму који саставља и дистрибуира тај код, а не добављачу алата. Ово је професионална чињеница као и правна: потписујете. Дакле, „АИ је произвео“ није изговор, већ оправдање за додатни опрез. Нарочито у системима критичним за безбедност, АИ излаз ни под којим околностима није замена за преглед и одобрење од стране квалификованог инжењера; Највише, АИ пружа нацрт који убрзава тог инжењера.
Савет: Направите кратку контролну листу у свом тиму коју називате „капија за валидацију кода генерисаног вештачком интелигенцијом“ (израда + тестирање + безбедносно скенирање + визуелна инспекција). Када ова капија постане навика, губитак брзине је минималан, а смањење ризика максимално.
Уобичајене грешке
- Бркање "ради" са "безбедним". Код који прође тестирање може бити подложан нападима.
- Коришћење пакета/АПИ-ја без његове провере. Халуцинаторни пакети су оштећени и представљају безбедносни ризик.
- Заобилазећи аутоматизоване алате. Линтер, провера типова и САСТ јефтино хватају оно што људима недостаје.
- Игнорисање лиценце. Неправилна зависност од лиценце ствара правни терет за дистрибуцију.
- Стављање одговорности на возило. Тим је одговоран за код у производњи; „АИ је то урадио“ није изговор.
Укратко
Прихватање АИ излаза захтева три слоја верификације: исправност (компилација, тестирање, визуелна инспекција), безбедност (САСТ и преглед фокусиран на безбедност) и извор/лиценца (провера зависности). Потврдите да сваки пакет и АПИ који се користе заиста постоје, примените безбедне обрасце од самог почетка и пошаљите безбедносно критични код на одобрење од стране квалификованог инжењера. „Ради“ не значи безбедно, а „произведена вештачка интелигенција“ не отклања одговорност. Капија за верификацију је цена професионализма, а не брзине.
Задатак апликације
Намерно дајте АИ задатак осетљив на безбедност (нпр. „функција која претражује базу података са корисничким уносом“), овог пута без наметања безбедног узорка. Проследите долазни код кроз шаблоне „самоконтроле пре пријема“ и „преглед усредсређен на безбедност“: да ли постоји било каква ињекција, скривена тајна, халуцинисани пакет или неауторизовани унос? Затим поново поставите исти задатак са шаблоном „безбедно наметање шаблона“ и упоредите два излаза. Ако је могуће, покрените линтер/САСТ алат и упоредите налазе са саморегулацијом АИ.
контролна листа
- [ ] Проверавам АИ излаз на три слоја: тачност, безбедност и лиценца.
- [ ] Потврђујем да свака функција, АПИ и пакет који се користе заиста постоје.
- [ ] Покрећем алате за компајлирање, тестирање, линтер и, ако је могуће, САСТ.
- [ ] Од почетка намећем сигурне обрасце (параметризовани упит, валидација уноса, тајно управљање).
- [ ] Проверавам лиценцирање и захтеве нових зависности.
- [ ] Предајем безбедносно критични код на одобрење од стране надлежног инжењера и разумем да сам одговоран.