ПОСІБНИК ІЗ ПОВНОГО ЦИКЛУ
Як створювати програмне забезпечення в регульованому підприємстві
Допомагайте людям створювати прототипи з ШІ. Перевіряйте безпеку до надання реальних даних або доступу до API, а потім доставляйте й експлуатуйте програмне забезпечення за корпоративними вимогами.
Видавець TaigaЯк ми пишемо
Коротка відповідь
Надайте людям час, вибір інструментів, синтетичні дані та шлях від корисних прототипів до підтримуваних сервісів. До надання доступу до реальних API або конфіденційної інформації перевірте застосунок, платформу та потоки даних. Використовуйте внутрішню платформу або фабрику програмного забезпечення, щоб поєднати безпечну доставку, докази відповідності та експлуатацію. Вимагайте підзвітності від призначених відповідальних осіб протягом усього життєвого циклу.
Допоможіть більшій кількості людей перетворювати ідеї на програмне забезпечення
CTO може запросити людей з усієї організації створювати прототипи з ШІ. Фінансові команди знають свої проблеми зі схваленнями. Операційні команди знають свої повторювані ручні задачі. Надайте їм час та інструменти, щоб показати кращий робочий процес.
Дозволяйте різні інструменти для дослідження в межах чітких правил установлення, облікових записів і дозволених вхідних даних. Надавайте синтетичні набори даних, sandbox API та практичну допомогу. Люди мають мати зрозумілий шлях демонстрації цінності без підключення продуктивних систем.
Потім визначте наступне рішення: що потрібно перевірити до того, як застосунок отримає конфіденційну інформацію, права на реальні API або продуктивний трафік? Зробіть цей шлях зрозумілим людині, яка створила прототип.
Що змінюється, коли прототип потребує реального доступу?
Робоча функція — одна частина сервісу. Організація також має пояснити, хто може користуватися сервісом, як він обробляє дані та як відновлюється. Ці обов’язки продовжуються після випуску.
Застосовні вимоги залежать від сервісу, сектору, юрисдикції, договорів і даних. Попросіть відповідальних фахівців із права, приватності та безпеки визначити їх. Фреймворк розробки або сертифікат постачальника не встановлює відповідності вашого конкретного сервісу.
Наведені нижче кроки дають інженерний робочий процес. Використовуйте їх, щоб пов’язати вимоги з рішеннями та доказами. NIST SSDF надає практики безпечної розробки, що можуть підтримати наявний SDLC. Він не замінює визначення застосовних зобов’язань.
1. Перетворіть корисний прототип на опис сервісу
Попросіть його творця описати проблему, продемонструвати робочий процес і записати, що з’ясували користувачі. Залишайте творця залученим як експерта предметної сфери. Призначте технічне оцінювання та постійну експлуатацію командам із цими обов’язками.
Запишіть задачу користувача, бажаний результат і наслідки відмови. Назвіть відповідального за продукт, відповідального за сервіс, контакт із безпеки та людину, яка може прийняти залишковий ризик. Узгодьте, хто може зупинити випуск.
Наприклад, експорт даних клієнтів потребує більше, ніж кнопки завантаження. Визначте, хто може експортувати які записи, з якою метою та з яким строком зберігання. Визначте, хто розслідує несанкціонований експорт. Це вигаданий приклад.
Які докази зберігати: опис сервісу, карту відповідальності та схвалені критерії приймання.
Продовжіть із вимог і простежуваності та відповідальності за сервіс.
2. Перевірте межу до надання даних або доступу до API
Визначте конфіденційну інформацію, персональні дані, облікові дані та інші матеріали з обмеженим доступом. Відобразіть, куди потрапляють prompts, отриманий контекст, журнали та згенеровані результати. Перевірте умови вибраного сервісу щодо зберігання, навчання моделей, доступу та регіональної обробки.
Використовуйте синтетичні або схвалені тестові дані під час дослідження ідеї. Успішний прототип не доводить, що його постачальник може обробляти продуктивні дані. Перевіряйте кожного постачальника та конфігурацію розгортання.
Вигадана банківська панель, створена у вівторок, може добре працювати з вигаданими транзакціями. Доступ до рахунку лише для читання все ще може розкрити конфіденційні записи. Права на платежі можуть додати фінансових наслідків. Перевірте фактичний обсяг, обробку облікових даних, авторизацію та поведінку в разі відмови до ввімкнення з’єднання. Розгляньте приклад банківського прототипу.
Цей перегляд має відбутися до першого введення чутливих даних або реального підключення. Назва «прототип» не зменшує прав, які застосунок уже має.
Надавайте агентам лише потрібні для задачі інструменти та права. Ставтеся до файлів репозиторію й отриманих документів як до недовірених вхідних даних. Не включайте секретів до prompts.
Які докази зберігати: схему потоків даних, оцінювання постачальника та політику прав.
Прочитайте про межі даних і права агентів.
3. Надайте підтримуваний шлях до продуктивного середовища
Розмістіть сервіс у межах засобів контролю ідентичностей, мережі, журналювання та розгортання організації. Визначте підтримувані середовища та інфраструктуру як код. Контейнер і база даних не створюють повного операційного середовища.
Коли політика вимагає вашої інфраструктури, перевірте розгортання у ваших хмарних облікових записах або мережах. Перевіряйте засоби контролю виконання окремо від потоків даних розробки та моделей. Розміщення у вашому обліковому записі не встановлює відповідності та не утримує кожен запит ШІ в цьому обліковому записі.
Підтримуваний шлях може використовувати внутрішню платформу, фабрику програмного забезпечення або обидві. Визначте, що кожна надає для перевірки, розгортання, виправлення вразливостей і експлуатації. Прототип може потребувати змін або заміни коду, перш ніж зможе використовувати цей шлях.
Узгодьте прийнятні тривалість простою та втрату даних: RTO та RPO. Виберіть механізми доступності й відновлення за цими цілями. Multi-AZ, multi-region і резервні копії розв’язують різні сценарії відмов. Перевірте повний процес відновлення, включно із залежностями та відновленими даними.
Які докази зберігати: запис архітектурного рішення, визначення середовищ і виміряні результати відновлення.
Вивчіть корпоративну інфраструктуру та RTO і RPO. Потім виконайте вправу з відновлення.
4. Створюйте малі зміни з перевірюваними вимогами
Надайте розробнику або агенту чітку задачу та критерії приймання. Пов’яжіть вимогу з її реалізацією, тестами й переглядом. Робіть зміни достатньо малими для перевірки.
Визначте вимоги безпеки до тестування. OWASP ASVS надає вимоги для перевірки безпеки застосунків. Виберіть відповідні вимоги та запишіть їхню сферу. Сам результат сканера не перевіряє поведінки застосунку.
Перевіряйте відхилені дії так само, як успішні. У прикладі експорту перевірте, що неуповноважений користувач не може запитати записи іншого клієнта.
Які докази зберігати: вимогу, diff зміни, результати тестів і рішення перегляду.
Продовжіть із тестів як доказів та перегляду коду, згенерованого ШІ.
5. Зробіть рішення про випуск відтворюваним
Зберіть ідентифікований артефакт із переглянутої редакції. Запишіть цільове середовище, конфігурацію, потрібні перевірки, залишкові ризики та рішення про випуск. Перевірте спосіб відкату або відновлення до того, як він знадобиться.
Визначте, коли потрібен дозвіл людини. Зберігайте відповідального за виняток, його причину, обсяг і дату завершення дії. Не вважайте схвалений виняток постійною зміною політики.
Які докази зберігати: ідентичність артефакту, запис випуску, схвалення або рішення за політикою та інструкції відкату.
Прочитайте про рішення щодо випуску та докази відповідності.
6. Підтримуйте програмне забезпечення після розгортання
Скануйте залежності та розгорнуті компоненти на наявність вразливостей, про які щойно повідомлено. Сервіс може стати вразливим без нового commit коду. Для кожної знахідки призначте відповідального та ухваліть рішення про усунення.
Перевірте виправлення, розгорніть його та підтвердьте запущену версію. Записуйте прийняті ризики й переглядайте їх знову зі зміною умов. Ця постійна робота часто відсутня, коли прототип вважають завершеним продуктом.
Які докази зберігати: інвентар компонентів, дату сканування, рішення первинного оцінювання, зміну для усунення вразливості та перевірку розгортання.
Дотримуйтеся процесу безперервного керування вразливостями.
7. Експлуатуйте, реагуйте та поліпшуйте
Відстежуйте корисні результати сервісу, збої та сигнали безпеки. Узгодьте ролі інцидентів, шляхи ескалації та обов’язки SOC і SIRT. Відпрацьовуйте ці домовленості.
NIST Cybersecurity Framework пов’язує керування ризиками з governance, захистом, виявленням, реагуванням і відновленням. Використовуйте цей погляд життєвого циклу для визначення операційної моделі.
Перетворюйте інциденти й повторювані проблеми на переглянуті зміни. Обмежуйте самовідновлення дозволеними діями з перевіркою та умовами зупинки. Автоматичний перезапуск не є доказом виправлення початкового дефекту.
Які докази зберігати: показники сервісу, записи інцидентів, результати відновлення та перевірені зміни поліпшення.
Дослідіть керування інцидентами та обмежене самовідновлення.
8. Вирішіть, які обов’язки виконувати самим, а які купувати
Порівнюйте внутрішню платформу, асистентів програмування та фабрику програмного забезпечення з ШІ за тими самими вимогами. Запитуйте, хто виконує кожну задачу, які докази доступні та що залишається вашою відповідальністю. Включайте витрати обслуговування, відновлення, інтеграції та виходу.
Люди можуть зберегти бажані інструменти дослідження, а організація — підтримувати спільний шлях до продуктивного середовища. Перевірте, які код, специфікації та тести переносяться між інструментами. Вимагайте демонстрації розгортання в потрібній інфраструктурі та повного процесу обслуговування.
Taiga публікує інформацію про governance та опис спільної відповідальності. Використовуйте їх як матеріали одного постачальника для оцінювання за вашими вимогами. Taiga публікує цей навчальний сайт; ці посилання не є незалежними рекомендаціями.
Почніть із порівняння відповідальності. Потім навчальний шлях Taiga покаже, як ці питання стосуються конкретних робочих процесів продукту.
Поширені питання
Чи можна використовувати vibe coding у регульованому підприємстві?
Так. Надайте людям синтетичні дані, sandbox API та вибір інструментів у чітких організаційних межах. Дозвольте їм перевіряти ідеї та передавати корисні прототипи до підтримуваного шляху доставки. Перевіряйте засоби контролю до надання конфіденційних даних або прав доступу до реальних систем, навіть до формального початку використання в продуктивному середовищі. Дивіться vibe coding: застосування та межі.
Чи потребує код, згенерований ШІ, інших критеріїв приймання?
Потрібна поведінка та засоби контролю ризику залишаються чинними. ШІ додає питання щодо контексту, обробки даних, прав і надійності результату. Переглядайте фактичну зміну та її докази незалежно від того, хто або що її створило.
Що потрібно підготувати спершу?
Підготуйте середовище дослідження із синтетичними даними та названим контактом для наступного кроку. Для корисного прототипу документуйте мету, заплановані дані, відповідальних, вимоги та цілі відновлення. Використайте вправу життєвого циклу програмного забезпечення, щоб визначити відсутні рішення до розширення доступу.