Vibe coding: paskirtis ir ribos

Suteikite žmonėms galimybę kurti

Didelės organizacijos CTO gali padėti daugiau žmonių paversti savo žinias programinės įrangos idėjomis. Įtraukite finansų, eksploatavimo, pardavimo ir inžinerijos darbuotojus. Suteikite jiems laiko, sintetinių duomenų, bandomųjų API ir pagalbą.

Leiskite žmonėms tyrinėti idėjas įvairiais įrankiais, aiškiai apibrėžę diegimo, paskyrų ir leidžiamos įvesties ribas. Naršyklėje veikianti programų kūrimo priemonė, programavimo asistentas ar vietinis agentas gali padėti patikrinti idėją. Pasirinktas įrankis nesuteikia leidimo įkelti įmonės informaciją ar prijungti tikrą sistemą.

Paskelbkite paprastą tvarką, kaip naudingą prototipą perduoti inžinerijos ar platformos komandai. Kūrėjas pateikia problemą, darbo eigos pavyzdį ir pastebėtą vertę. Jis neturi tapti paslaugos saugumo ir eksploatavimo komanda.

Nustatykite, ką reikia sužinoti

Vibe coding paprastai prasideda norimos programinės įrangos aprašymu. Priimate sugeneruotą kodą ir pagal matomą rezultatą nurodote kitą pakeitimą. Šis terminas vartojamas įvairiai. Šiame vadove darbą nukreipiantis žmogus nebūtinai supranta kiekvieną įgyvendinimo sprendimą.

Šis metodas gali padėti mokytis. Paprasta sąsaja gali parodyti, kad patvirtinimo procese yra per daug žingsnių. Laikinas scenarijus gali padėti įvertinti failo formatą. Prototipas suteikia žmonėms konkretų sprendimą, kurį galima aptarti. Šios žinios išlieka net atsisakius kodo.

Pirmiausia suformuluokite klausimą, kurio atsakymą galima stebėti. Pavyzdžiui: „Ar komandos vadovas supranta šį patvirtinimo procesą?“ Tokio klausimo apimtis aiški. Prašymas sukurti išlaidų sistemą apima ir duomenų apsaugą, prieigos kontrolę, eksploatavimą bei atsakomybę.

Antradienio banko prototipas

Apsvarstykite išgalvotą pavyzdį. Antradienį finansų skyriaus kolega su Lovable sukuria suvestinę iš išgalvotų banko operacijų. Ji grupuoja išlaidas ir rodo neapmokėtas sąskaitas faktūras. Dabar komanda gali aptarti naudingą darbo eigą.

Kažkas pasiūlo prijungti įmonės banko sąskaitą. Tai keičia pasekmes, net jeigu programa vis dar vadinama „prototipu“.

Skaitymo teisės gali atskleisti likučius, operacijų istoriją, klientų vardus ar pavadinimus arba mokėjimų nuorodas. Tai priklauso nuo API. Jei ryšys leidžia ir mokėti, klaidos gali pervesti tikrus pinigus. Patvirtinkite tikrąją teisių apimtį: banko prijungimas ne visada suteikia mokėjimo teises.

Demonstracija neįrodo, kad naudotojas gali matyti tik jam leidžiamas sąskaitas. Paslėptas mygtukas neužtikrina teisių kontrolės. OWASP aprašo, kaip neatlikti sąskaitos ar įrašo patikrinimai gali atskleisti kito naudotojo duomenis.

Mokėjimo API idempotentiškumas reiškia, kad pakartota užklausa nepakartoja numatyto poveikio. Stripe dokumentuoja vieną įgyvendinimą. Patikrinkite konkretaus teikėjo veikimą, ribas ir pakartotinių bandymų taisykles. Programos grąžinimas į ankstesnę versiją neatšaukia banko jau apdoroto mokėjimo.

Šis pavyzdys neįrodo Lovable trūkumo. Pačios Lovable saugumo gairės reikalauja saugoti paslaptis, tikrinti serverio pusėje, išbandyti duomenų taisykles ir nuolat peržiūrėti sistemą. Taikykite tą patį įrodymų reikalavimą bet kuriai kūrimo priemonei, agentui ar rankomis parašytai programai.

Patikrinkite prieigą prieš prijungdami tikras sistemas

Toliau bandykite darbo eigą su sintetiniais duomenimis ir bandomosiomis paskyromis. Prieš suteikiant tikrą prieigą, už paslaugą, saugumą ir platformą atsakingi asmenys turi patikrinti programą bei jos eksploatavimo aplinką.

Naudokite banko ar teikėjo patvirtintą prijungimo eigą. Suteikite tik būtinas sąskaitas ir teises. Privačius prisijungimo duomenis laikykite patvirtintoje paslapčių saugykloje, o ne užklausose modeliui ar naršyklės kode. Kai mokėjimai būtini, nustatykite jų patvirtinimus ir limitus. Patikrinkite, kaip atšaukti prieigą, tirti sutrikimus ir reaguoti į įtartiną veiklą.

Šiuos sprendimus reikia priimti prieš konfidencialiai įvesčiai ar tikriems prisijungimo duomenims patenkant į sistemą. Laukti oficialaus išleidimo į produkcinę aplinką gali būti per vėlu. Toliau skaitykite apie duomenų ribas ir organizacijos infrastruktūrą.

Apibrėžkite atsakomybes prieš plėsdami naudojimą

Bandymas su išgalvotais duomenimis gali būti trumpalaikis ir skirtas nedidelei auditorijai. Kai nuo programos priklauso kiti žmonės, apibrėžkite naudojimo atsakomybes.

1. Įvardykite atsakingą asmenį.
2. Nurodykite leidžiamus naudotojus ir duomenis.
3. Apibrėžkite reakciją į sutrikimą.
4. Laikykite pirminį kodą ir konfigūraciją kodo saugykloje.
5. Patikrinkite, ar kitas žmogus gali išnagrinėti ir atkurti sistemą.

Ne kiekvienam scenarijui reikia organizacijos platformos. Asmeninei formatavimo priemonei be jautrių duomenų reikia mažiau kontrolės priemonių nei mokėjimų patvirtinimo programai. Įvertinkite klaidos pasekmes. Patikrinkite, ar galite aptikti klaidą ir panaikinti jos poveikį.

Prieš plėsdami prototipą, atskirkite tai, ką sužinojote apie problemą, nuo įgyvendinimo įrodymų. Galite palikti sąsają ir pakeisti vidinį kodą. Galite apriboti numatytą naudojimą. Taip pat galite palikti prototipą laikinu bandymu.

Suplanuokite pažeidžiamumų tvarkymą po demonstracijos

Sėkminga demonstracija gali slėpti rimtą priežiūros spragą. Apie priklausomybės pažeidžiamumą gali pasirodyti naujas pranešimas, nors jūsų kodas nepasikeitė. Išleidimo metu atliktas skenavimas apibūdina tik vieną laiko momentą.

Jei programa lieka naudojama, kas nors turi toliau ieškoti pažeidžiamumų, juos vertinti ir taisyti. Pataisa turi pasiekti produkcinę aplinką ir būti patikrinta. Skenavimo priemonė be tokio reagavimo proceso palieka riziką nepašalintą.

Patikrinkite, ką suteikia jūsų konkretus įrankis ir jo konfigūracija. Vėlesnė pamoka apie nuolatinį pažeidžiamumų valdymą paaiškina visą procesą, įskaitant skenavimo sutrikimus ir įdiegtas versijas.

Padarykite kitą pakeitimą lengvai peržiūrimą

Paveskite agentui vieną nedidelį pakeitimą su aiškiais priėmimo kriterijais. Nurodykite, kokius veiksmus agentas gali atlikti. Peržiūrėkite gautą diff. Atlikite patikrinimus, kurie gali atmesti neteisingą įgyvendinimą. Kol išleidimo atsakomybės neaiškios, sprendimą diegti priimkite atskirai.

NIST Secure Software Development Framework aprašo platesnę saugaus kūrimo praktiką. Remkitės juo vertindami trūkstamas kontrolės priemones. Sistemos nereikia išmokti atmintinai. Reikia nustatyti trūkstamus įrodymus prieš programinei įrangai paveikiant kitus žmones.