Kiro добавил в спека-первую разработку шаг безопасности: 60 CWE-мэппингов дописывают требования до кода
Этап AI SDLC: Требования → Спека-агентКоманда Kiro (AWS) выпустила specification hardening: детерминированный движок проверяет EARS-требования по библиотеке из 60 CWE-мэппингов и дописывает security-обязательства прямо в requirements.md до генерации кода. Код открыт, лицензия MIT-0.
Что произошло
Команда Kiro (AWS) представила specification hardening — плагин (Kiro Power) и CLI, которые добавляют в спека-первую разработку шаг безопасности между требованиями и планированием. Движок детерминированный: читает requirements.md в формате EARS, лексически ищет признаки слабых мест и дописывает недостающие ограничения прямо в спеку пунктами с тегом [SECURITY: …] и трассируемыми ID. Основа — библиотека из 60 CWE-мэппингов по восьми доменам (инъекции, аутентификация, авторизация, хранение паролей, загрузка файлов и другие), отобранных по OWASP Top 10 и детекторам Amazon Q. Код открыт в aws-samples под MIT-0, диф ревьюится в git, повторный запуск обрабатывает только новые и изменённые требования.
Авторы честно очерчивают границы: это контрольная точка вверх по потоку, а не рантайм-граница. Лексический детектор не видит слабых мест, не выраженных в формулировках, — например, пропущенной проверки владения объектом; такие кандидаты выносит на подтверждение семантическое ревью агента или человека. SAST, DAST и ревью кода это не заменяет. В примере из блога движок дописал семь ограничений против SQL-инъекции и отсутствия аутентификации, а доменное правило авторизации (врач видит только своих пациентов) добавил ревьюер.
Почему это важно
Этап требований — самое дешёвое место для безопасности в агентной разработке: агент строит код против того, что написано в спеке, и без явного ограничения переключается на дефолты фреймворка, которые могут оставить дыру. Функциональная формулировка сама по себе не заставит агента ни проверить авторизацию, ни экранировать вывод — об этом нужно написать в требованиях. Детерминированность и трассируемые ID делают такие дописывания ревьюемыми, а инкрементальный режим позволяет встроить шаг в обычный процесс: изменил требование — прогнал hardening, посмотрел диф.
Для команд, внедряющих SDD, это готовый шаблон: security-обязательства как проверяемые пункты спеки, а не абстрактное «учесть безопасность» где-то в конце.
Что с этим делать
- Если пишете спеки для агентов — прогнать hardening по requirements.md и разобрать диф; добавить security-ревью спеки в definition of done.
- Библиотеку CWE→EARS можно использовать и без Kiro: движок и CLI открыты, формат маппингов простой.
- Держать человека в контуре для слабых кандидатов: лексика не ловит авторизационные пробелы, их подтверждает ревьюер.