Kaip kurti programinę įrangą reguliuojamoje įmonėje

Padėkite daugiau žmonių paversti idėjas programine įranga

CTO gali pakviesti žmones iš visos organizacijos kurti prototipus su DI. Finansų komandos žino savo tvirtinimo problemas. Eksploatavimo komandos žino pasikartojančias rankines užduotis. Skirkite joms laiko ir įrankių geresnei darbo eigai parodyti.

Leiskite idėjas tyrinėti skirtingais įrankiais, laikantis aiškių diegimo, paskyrų ir leidžiamų įvesties duomenų taisyklių. Suteikite sintetinių duomenų rinkinių, bandomosios aplinkos API ir praktinės pagalbos. Žmonėms turi būti aišku, kaip parodyti vertę neprijungiant produkcinių sistemų.

Tada apibrėžkite kitą sprendimą: ką būtina patikrinti prieš suteikiant programai konfidencialią informaciją, tikrų API teises ar produkcinį srautą? Prototipo kūrėjas turi suprasti šį kelią.

Kas pasikeičia, kai prototipui prireikia tikros prieigos?

Veikianti funkcija yra tik viena paslaugos dalis. Organizacija taip pat turi paaiškinti, kas gali ja naudotis, kaip ji tvarko duomenis ir kaip atkuriama po sutrikimo. Ši atsakomybė išlieka ir po išleidimo.

Taikomi reikalavimai priklauso nuo paslaugos, sektoriaus, jurisdikcijos, sutarčių ir duomenų. Paprašykite atsakingų teisės, privatumo ir saugumo specialistų juos nustatyti. Kūrimo sistema ar tiekėjo sertifikatas nepatvirtina konkrečios jūsų paslaugos atitikties.

Toliau pateikti žingsniai sudaro inžinerinę darbo eigą. Jais susiekite reikalavimus su sprendimais ir įrodymais. NIST SSDF pateikia saugaus kūrimo praktikas, kurios gali papildyti esamą SDLC. Tai nepakeičia pareigos nustatyti taikomus įsipareigojimus.

1. Naudingą prototipą paverskite paslaugos užduoties aprašu

Paprašykite kūrėjo aprašyti problemą, parodyti darbo eigą ir užregistruoti, ką sužinojo naudotojai. Įtraukite kūrėją toliau kaip srities ekspertą. Techninį vertinimą ir nuolatinį eksploatavimą priskirkite už tai atsakingoms komandoms.

Užrašykite naudotojo užduotį, numatytą rezultatą ir sutrikimo pasekmes. Nurodykite produkto savininką, už paslaugą atsakingą asmenį, saugumo kontaktą ir asmenį, kuris gali priimti likutinę riziką. Sutarkite, kas gali sustabdyti išleidimą.

Pavyzdžiui, klientų duomenų eksportui reikia daugiau nei atsisiuntimo mygtuko. Apibrėžkite, kas gali eksportuoti kuriuos įrašus, kokiu tikslu ir kiek laiko juos saugoti. Nustatykite, kas tiria neleistiną eksportą. Tai išgalvotas pavyzdys.

Išsaugotini įrodymai: paslaugos užduoties aprašas, atsakomybės žemėlapis ir patvirtinti priėmimo kriterijai.

Toliau skaitykite apie reikalavimus ir atsekamumą bei atsakomybę už paslaugą.

2. Patikrinkite ribą prieš suteikdami duomenų ar API prieigą

Nustatykite konfidencialią informaciją, asmens duomenis, prisijungimo duomenis ir kitą ribojamą medžiagą. Nubraižykite, kur keliauja užklausos modeliui, gautas kontekstas, žurnalai ir sugeneruoti rezultatai. Patikrinkite pasirinktos paslaugos duomenų saugojimo, mokymo, prieigos ir regioninio apdorojimo sąlygas.

Tyrinėdami idėją naudokite sintetinius ar patvirtintus bandomuosius duomenis. Sėkmingas prototipas neįrodo, kad jo teikėjas gali apdoroti produkcinius duomenis. Patikrinkite kiekvieną teikėją ir diegimo konfigūraciją.

Antradienį sukurta išgalvota banko suvestinė gali gerai veikti su išgalvotomis operacijomis. Net tik skaitymo prieiga prie sąskaitos gali atskleisti konfidencialius įrašus. Mokėjimų teisės gali sukelti finansinių pasekmių. Prieš įjungdami jungtį patikrinkite tikrąją teisių apimtį, prisijungimo duomenų tvarkymą, autorizavimą ir veikimą sutrikus. Išnagrinėkite banko prototipo pavyzdį.

Ši peržiūra privaloma prieš pirmą jautrią įvestį ar tikrą jungtį. Pavadinus programą prototipu, jos jau turimos teisės nesumažėja.

Agentams suteikite tik užduočiai būtinus įrankius ir teises. Kodo saugyklos failus ir gautus dokumentus laikykite nepatikima įvestimi. Neįtraukite paslapčių į užklausas modeliui.

Išsaugotini įrodymai: duomenų srautų diagrama, teikėjo vertinimas ir teisių politika.

Skaitykite apie duomenų ribas ir agentų teises.

3. Suteikite palaikomą kelią į produkcinę aplinką

Įtraukite paslaugą į organizacijos tapatybės, tinklo, žurnalų ir diegimo kontrolės priemones. Apibrėžkite palaikomas aplinkas ir infrastruktūrą kaip kodą. Konteineris ir duomenų bazė nesudaro visos eksploatavimo aplinkos.

Kai politika reikalauja nuosavos infrastruktūros, patikrinkite diegimą į jūsų debesijos paskyras ar tinklus. Vykdymo kontrolės priemones tikrinkite atskirai nuo kūrimo ir modelių duomenų srautų. Priegloba jūsų paskyroje nepatvirtina atitikties ir neužtikrina, kad kiekviena DI užklausa liks toje paskyroje.

Palaikomas kelias gali remtis vidine platforma, programinės įrangos gamykla arba abiem. Apibrėžkite, ką kiekviena suteikia patikrinimui, diegimui, pažeidžiamumų taisymui ir eksploatavimui. Prototipui gali reikėti pakeitimų ar pakaitinio kodo, kad jis galėtų naudotis šiuo keliu.

Sutarkite dėl priimtinos sutrikimo trukmės ir duomenų praradimo: RTO ir RPO. Pagal šiuos tikslus pasirinkite prieinamumo ir atkūrimo mechanizmus. Multi-AZ, keli regionai ir atsarginės kopijos sprendžia skirtingus sutrikimų scenarijus. Išbandykite visą atkūrimo procesą, įskaitant priklausomybes ir atkurtus duomenis.

Išsaugotini įrodymai: architektūros sprendimo įrašas, aplinkų apibrėžtys ir išmatuoti atkūrimo rezultatai.

Išnagrinėkite įmonės infrastruktūrą bei RTO ir RPO. Tada atlikite atkūrimo užduotį.

4. Kurkite nedidelius pakeitimus su patikrinamais reikalavimais

Pateikite programuotojui ar agentui aiškią užduotį ir priėmimo kriterijus. Susiekite reikalavimą su jo įgyvendinimu, testais ir peržiūra. Pakeitimai turi būti pakankamai maži, kad juos būtų galima patikrinti.

Prieš testuodami apibrėžkite saugumo reikalavimus. OWASP ASVS pateikia programų saugumo patikrinimo reikalavimus. Pasirinkite aktualius reikalavimus ir užregistruokite jų apimtį. Vien skenerio rezultatas nepatikrina programos veikimo.

Testuokite ir atmestus, ir sėkmingus veiksmus. Eksporto pavyzdyje patikrinkite, ar neįgaliotas naudotojas negali paprašyti kito kliento įrašų.

Išsaugotini įrodymai: reikalavimas, pakeitimo diff, testų rezultatai ir peržiūros sprendimas.

Toliau skaitykite apie testus kaip įrodymus ir DI sugeneruoto kodo peržiūrą.

5. Padarykite išleidimo sprendimą atkuriamą

Iš peržiūrėtos kodo versijos sukurkite identifikuojamą artefaktą. Užregistruokite tikslinę aplinką, konfigūraciją, privalomas patikras, likusią riziką ir išleidimo sprendimą. Išbandykite grąžinimo į ankstesnę versiją ar atkūrimo būdą prieš jo prireikiant.

Nuspręskite, kada būtinas žmogaus leidimas. Išsaugokite išimties atsakingą asmenį, priežastį, apimtį ir galiojimo pabaigos datą. Nelaikykite patvirtintos išimties nuolatiniu politikos pakeitimu.

Išsaugotini įrodymai: artefakto tapatybė, išleidimo įrašas, patvirtinimas ar politikos sprendimas ir grąžinimo į ankstesnę versiją instrukcijos.

Skaitykite apie išleidimo sprendimus ir atitikties įrodymus.

6. Prižiūrėkite programinę įrangą po diegimo

Skenuokite priklausomybes ir įdiegtus komponentus, ieškodami naujai paskelbtų pažeidžiamumų. Paslauga gali tapti pažeidžiama be naujo kodo commit. Kiekvienam radiniui paskirkite atsakingą asmenį ir sprendimą dėl ištaisymo.

Patikrinkite pataisą, įdiekite ją ir patvirtinkite veikiančią versiją. Užregistruokite priimtą riziką ir peržiūrėkite ją iš naujo, kai pasikeičia sąlygos. Šio nuolatinio darbo dažnai trūksta, kai prototipas laikomas baigtu produktu.

Išsaugotini įrodymai: komponentų inventorius, skenavimo data, pirminio vertinimo sprendimas, taisomasis pakeitimas ir diegimo patikrinimas.

Vadovaukitės nuolatinio pažeidžiamumų valdymo darbo eiga.

7. Eksploatuokite, reaguokite ir tobulinkite

Stebėkite naudingus paslaugos rezultatus, sutrikimus ir saugumo signalus. Sutarkite dėl incidentų vaidmenų, eskalavimo kelių ir SOC bei SIRT atsakomybės. Išbandykite šią tvarką.

NIST Cybersecurity Framework susieja rizikos valdymą su valdymu, apsauga, aptikimu, reagavimu ir atkūrimu. Apibrėždami eksploatavimo modelį remkitės šiuo gyvavimo ciklo požiūriu.

Incidentus ir pasikartojančias problemas paverskite peržiūrėtais pakeitimais. Apribokite automatinį atsikūrimą leidžiamais veiksmais su patikrinimu ir stabdymo sąlygomis. Automatinis paleidimas iš naujo neįrodo, kad pradinis defektas ištaisytas.

Išsaugotini įrodymai: paslaugos rodikliai, incidentų įrašai, atkūrimo rezultatai ir patikrinti tobulinimo pakeitimai.

Išnagrinėkite incidentų valdymą ir ribotą automatinį atsikūrimą.

8. Nuspręskite, kurias atsakomybes vykdysite patys, o kurias pirksite

Palyginkite vidinę platformą, programavimo asistentus ir DI programinės įrangos gamyklą pagal tuos pačius reikalavimus. Klauskite, kas atlieka kiekvieną užduotį, kokie įrodymai prieinami ir už ką liekate atsakingi jūs. Įtraukite priežiūros, atkūrimo, integravimo ir pasitraukimo sąnaudas.

Žmonės gali pasilikti mėgstamus idėjų tyrinėjimo įrankius, o organizacija gali išlaikyti bendrą kelią į produkcinę aplinką. Patikrinkite, kokį kodą, specifikacijas ir testus galima perkelti tarp įrankių. Reikalaukite parodyti diegimą į reikiamą infrastruktūrą ir visą priežiūros procesą.

Taiga skelbia valdymo informaciją ir bendros atsakomybės aprašą. Vertinkite juos kaip vieno tiekėjo medžiagą pagal savo reikalavimus. Taiga leidžia šią mokymosi svetainę; šios nuorodos nėra nepriklausomos rekomendacijos.

Pradėkite nuo atsakomybės palyginimo. Tada Taiga mokymosi kryptis parodys, kaip šie klausimai siejasi su konkrečiomis produkto darbo eigomis.

Dažniausi klausimai

Ar reguliuojamoje įmonėje galima naudoti vibe coding?

Taip. Suteikite žmonėms sintetinių duomenų, bandomosios aplinkos API ir įrankių pasirinkimą, laikantis aiškių organizacijos ribų. Leiskite jiems išbandyti idėjas ir perkelti naudingus prototipus į palaikomą kūrimo ir diegimo kelią. Patikrinkite kontrolės priemones prieš suteikdami konfidencialius duomenis ar tikras teises, net prieš oficialų perkėlimą į produkcinę aplinką. Skaitykite apie vibe coding naudojimą ir ribas.

Ar DI sugeneruotam kodui reikia kitokių priėmimo kriterijų?

Privalomas veikimas ir rizikos kontrolės priemonės lieka galioti. DI prideda klausimų apie kontekstą, duomenų tvarkymą, teises ir rezultato patikimumą. Peržiūrėkite tikrąjį pakeitimą ir jo įrodymus, nepriklausomai nuo to, kas jį sukūrė.

Ką turėtume parengti pirmiausia?

Parenkite idėjų tyrinėjimo aplinką su sintetiniais duomenimis ir nurodykite asmenį, į kurį kreiptis dėl kito žingsnio. Naudingam prototipui dokumentuokite paskirtį, numatytus duomenis, atsakingus asmenis, reikalavimus ir atkūrimo tikslus. Naudodami programinės įrangos gyvavimo ciklo užduotį nustatykite trūkstamus sprendimus prieš išplėsdami prieigą.