Vibe coding: приложения и ограничения

Дайте на хората възможност да създават

CTO в голяма организация може да помогне на повече хора да превърнат знанията си в идеи за софтуер. Поканете хора от финансите, операциите, продажбите и инженерните екипи. Дайте им време, синтетични данни, sandbox API и подкрепа.

Нека използват различни инструменти за проучване на идеи в ясни граници за инсталиране, акаунти и допустими входни данни. Инструмент за създаване на приложения в браузъра, помощник за програмиране или локален агент може да помогне при проверката на идея. Изборът на инструмент не дава разрешение за качване на фирмена информация или свързване на действаща система.

Публикувайте лесен начин за предаване на полезен прототип към инженерния екип или екипа на платформата. Авторът предоставя проблема, примерния работен процес и наблюдаваната стойност. Не е необходимо да поема ролята на екип за сигурност и експлоатация на услугата.

Определете какво трябва да научите

Vibe coding обикновено започва с описание на желания софтуер. Приемате генериран код и насочвате следващата промяна според видимия резултат. Терминът има различни значения. В този наръчник човекът, който насочва работата, не разбира непременно всяко решение за реализацията.

Този метод може да Ви помогне да научите нещо. Прост интерфейс може да покаже, че процесът на одобрение има твърде много стъпки. Временен скрипт може да помогне при оценката на файлов формат. Прототипът дава конкретен проект за обсъждане. Можете да запазите наученото, дори да изхвърлите кода.

Първо определете въпрос с наблюдаем отговор. Например: „Може ли ръководител на екип да разбере този процес на одобрение?“ Въпросът има ясен обхват. Искането за система за разходи включва също защита на данните, контрол на достъпа, експлоатация и отговорност.

Банковият прототип от вторник

Разгледайте измислен пример. Във вторник колега от финансовия екип използва Lovable, за да създаде табло с измислени банкови трансакции. То групира разходите и показва неплатените фактури. Екипът вече може да обсъди полезен работен процес.

Някой предлага да свържете банковата сметка на компанията. Това променя последствията, дори приложението още да носи етикета „прототип“.

Според API достъпът за четене може да разкрие салда, история на трансакциите, имена на клиенти или основания за плащане. Ако връзката позволява и плащания, грешките могат да прехвърлят реални пари. Потвърдете действителния обхват на правата; банковата връзка невинаги включва право на плащане.

Демонстрацията не доказва, че потребителят вижда само сметките, за които има права. Скрит бутон не осигурява спазването на правата за достъп. OWASP описва как липсващи проверки за сметка или запис могат да разкрият данните на друг потребител.

При API за плащания идемпотентност означава, че повторна заявка не повтаря предвидения ефект. Stripe документира една реализация. Проверете поведението, ограниченията и правилата за повторни опити на действителния доставчик. Връщането на предишна версия на приложението не отменя плащане, което банката е обработила.

Този пример не е доказателство за дефект в Lovable. Собствените указания за сигурност на Lovable изискват защитени тайни стойности, проверки на сървъра, тествани политики за данните и постоянен преглед. Прилагайте същия стандарт за доказателства към всеки инструмент за създаване на приложения, агент или ръчно написано приложение.

Проверете достъпа, преди да свържете реални системи

Продължете да тествате работния процес със синтетични данни и sandbox акаунти. Преди реалния достъп отговорниците за услугата, сигурността и платформата трябва да проверят приложението и средата му за работа.

Използвайте одобрения процес за свързване на банката или доставчика. Дайте достъп само до необходимите сметки и права. Пазете тайните данни за удостоверяване в одобрено хранилище за тайни стойности, извън промптовете и кода на браузъра. Определете одобрения и лимити за плащанията, когато са необходими плащания. Проверете как се отнема достъп, как се разследват откази и как се реагира на подозрителна дейност.

Тези решения трябва да предхождат въвеждането на поверителни данни или реални данни за удостоверяване в системата. Изчакването до официалното пускане в продукционна среда може да е твърде късно. Продължете с границите за данните и инфраструктурата на организацията.

Определете отговорностите, преди да разширите използването

Експеримент с измислени данни може да има кратък живот и малка аудитория. Когато други хора разчитат на приложението, определете отговорностите за използването му.

1. Посочете отговорника.
2. Определете разрешените потребители и данни.
3. Определете реакцията при отказ.
4. Пазете изходния код и конфигурацията в хранилище.
5. Проверете дали друг човек може да прегледа и възпроизведе системата.

Не всеки скрипт се нуждае от корпоративна платформа. Личен инструмент за форматиране без чувствителни данни изисква по-малко контроли от приложение за одобрение на плащания. Оценете последствията от грешка. Проверете дали можете да я откриете и да отмените ефектите ѝ.

Преди да разширите прототипа, разграничете наученото за проблема от доказателствата за реализацията. Можете да запазите интерфейса и да замените вътрешния код. Можете да ограничите предвидената употреба. Можете и да оставите прототипа като временен експеримент.

Планирайте работа по уязвимостите след демонстрацията

Успешната демонстрация може да скрие сериозна липса на поддръжка. За зависимост може да се появи ново съобщение за уязвимост, без да променяте кода си. Сканирането при пускане описва един момент във времето.

Ако приложението остава в употреба, някой трябва постоянно да намира, оценява и отстранява уязвимости. Поправката трябва да достигне продукционната среда и да бъде проверена успешно. Скенер без този процес на реакция оставя риска неотстранен.

Проверете какво предоставят действителният инструмент и конфигурацията. По-късно непрекъснатото управление на уязвимости обяснява целия процес, включително неуспешните сканирания и внедрените версии.

Направете следващата промяна лесна за преглед

Дайте на агента една малка промяна с изрични критерии за приемане. Посочете кои действия може да извършва. Прегледайте получения diff. Изпълнете проверки, които могат да отхвърлят неправилна реализация. Пазете внедряването като отделно решение, докато отговорностите за пускането станат ясни.

NIST Secure Software Development Framework описва по-широки практики за сигурна разработка. Използвайте го като справочник при оценката на липсващите контроли. Не е необходимо да запомняте рамката. Трябва да установите липсващите доказателства, преди софтуерът да засегне други хора.