Прибыль:
- Возможность использовать искусственный интеллект в качестве второго глаза и отмечать уязвимости класса OWASP (внедрение, жесткий секрет, контроль доступа) в коде, предоставляя контекст.
- Способность устранять ложные срабатывания искусственного интеллекта с учетом контекста и предотвращать рассмотрение каждого обнаружения как реальной уязвимости без его проверки.
- Способность распознавать, что исправление, предложенное искусственным интеллектом, может привести к возникновению новых уязвимостей/ошибок, и пропускать каждое исправление через ворота проверки и тестирования.
Уязвимости в программном обеспечении являются одними из самых дорогостоящих уязвимостей, поскольку они встроены в продукт с самого начала и распространяются среди миллионов пользователей. Проверка безопасного кода — это процесс чтения исходного кода построчно и выявления уязвимостей — внедрения SQL, уязвимости аутентификации, жестко запрограммированного пароля, неправильной авторизации — прежде чем они попадут в производство. Если делать это вручную, это медленно и утомительно; В большой базе кода легко не заметить уязвимость.
ИИ эффективен при проверке кода по двум причинам: код — это тоже язык, а ИИ хорош в распознавании образов. ИИ может быстро отметить опасные шаблоны в фрагменте кода (ввод пользовательских данных непосредственно в запрос, незашифрованное хранение данных, отсутствие проверки ввода), объяснить, почему каждый из них является рискованным, и предложить исправление. Но ИИ не видит всего рабочего контекста кода (ввод может очищаться на другом уровне), он может изобрести уязвимость, которой не существует (ложное срабатывание) или пропустить реальную уязвимость (ложное отрицание), и самое главное, предлагаемое им «исправление» может привнести новую уязвимость или ошибку. ИИ — это второй глаз и указатель при проверке кода; Разработчик и эксперт по безопасности решают, является ли обнаружение реальной уязвимостью и является ли исправление правильным и безопасным.
Этапы проверки кода
- Укажите масштаб и контекст. Какой язык, какая платформа, где этот код принимает входные данные, где он выдает выходные данные, на каком уровне он работает? Проверка кода без контекста дает ложные срабатывания.
- Сканируйте опасные шаблоны. Найдите известные классы уязвимостей ИИ (например, OWASP Top 10): внедрение, аутентификация, раскрытие конфиденциальных данных, контроль доступа.
- Каждый вывод должен быть обоснован. По каждому флагу: какая строка, какой класс уязвимости, как ее можно эксплуатировать, какие доказательства. Необоснованный вывод не воспринимается всерьез.
- Устранение ложного срабатывания. Действительно ли ввод очищается, действительно ли этот путь доступен — проверьте контекст.
- Проверьте исправление. Убедитесь, что исправление, рекомендованное ИИ, действительно закрывает уязвимость, не создает новых уязвимостей/ошибок и прошло тестирование.
- Человеческое одобрение. Разработчик + эксперт по безопасности проверяет обнаружение и исправление; Вот так он попадает в репозиторий кода.
Термины: SAST (Static Application Security Testing — статическое тестирование безопасности, при котором анализируется исходный код без его запуска). DAST (Динамическое — динамическое тестирование, которое проверяет работающее приложение извне). OWASP Top 10 — это стандартный список наиболее распространенных уязвимостей веб-приложений. Внедрение — это уязвимость, вызванная интерпретацией пользовательского ввода как команды/запроса (например, SQL-инъекция). Параметризованный запрос — это правильный метод, который предотвращает внедрение путем отделения входных данных от кода.
Таблица распространенных классов уязвимостей
Класс уязвимости
Симптом (в коде)
правильное решение
Ловушка ИИ
SQL-инъекция
Объединение входных данных в запрос
Параметризованный запрос
Может игнорировать санитарную обработку
жестко закодированный секрет
Пароль/ключ в коде
Секретный сейф (хранилище), окр.
Ложноположительный результат (проба/тест)
Слабая аутентификация
Отсутствует/неправильный контроль
Мощное централизованное управление
упускает контекст
Неправильный контроль доступа
Без проверки авторизации
Авторизация на стороне сервера
Не понимает сложного потока
Раскрытие конфиденциальных данных
Хранение/регистрация без пароля
Шифрование, маскировка
Не могу знать критичность
Небезопасная сериализация
Десериализовать ненадежные данные
Безопасный анализ
Пропускает редкий образец
три мини-кейса
Случай 1 — Улов фактического впрыска. Разработчик поручил ИИ проверить функцию доступа к данным. ИИ отмечает строку, где значение userId пользователя объединяется непосредственно с текстом SQL, и говорит: «Это классическая SQL-инъекция, превратите ее в параметризованный запрос»; Обеспечивает коррекцию образца. Разработчик подтверждает, что входные данные не подвергались очистке где-либо еще, проверяет, что это реальная уязвимость, реализует предложенный параметризованный запрос и пишет тест. ИИ подчеркнул уязвимость; Проверочное и корректирующее тестирование пришло от разработчика.
Случай 2 — Ложноположительный фиксированный секрет. ИИ видит строку пароля = «test1234» в файле и говорит «критично: жестко закодированный пароль». Разработчик проверяет контекст: это файл модульного теста, фиктивные тестовые данные, не выпущенные в производство и не портированные на реальную систему. Результат является ложноположительным. Разработчик документирует это, но не предпринимает никаких действий, поскольку это не является настоящим секретом. Урок: знак «жесткой тайны» ИИ должен быть исключен из контекста; Не каждая строка является секретом.
Случай 3 — Новое исправление уязвимости. ИИ предлагает исправление уязвимости XSS (межсайтовый скриптинг); но код, который он предлагает, очищает ввод не в том месте и пропускает кодирование вывода в другой области; В результате разрыв не закрывается полностью. Эксперт по безопасности просматривает исправление, замечает недостающий код и исправляет его на нужном уровне. Урок: патч, который рекомендует ИИ, не является автоматически безопасным; Каждое исправление проверяется и тестируется.
Слабая подсказка / Сильная подсказка
Слабая подсказка:
Есть ли в этом коде лазейка, исправьте ее: [код]
Эта подсказка не дает контекста (язык, структуру, источник входных данных), не запрашивает обоснования, не ставит под сомнение ложное срабатывание и открыта для слепого принятия исправлений, внесенных ИИ. ИИ смешал признаки как реальной уязвимости, так и несуществующей.
Мощная подсказка:
Ваша роль: помощник, который является ВТОРЫМ ГЛАЗОМ для разработчика при проверке безопасного кода. Принятие решений; рассмотрите возможность непосредственного применения исправления. Код: [укажите язык/фреймворк]. Контекст: эта функция [источник входных данных: например. получает [внешний HTTP-запрос], записывает в [назначение вывода]. Ваша задача: (1) отметить возможные уязвимости с помощью класса OWASP, указать номер строки + почему рискованно + как использовать + доказательства для каждой, (2) написать как минимум 1 ложноположительный сценарий для каждого обнаружения (например, если входные данные очищаются на другом уровне), (3) предложить исправление, но со знаком «[проверка + запись теста]»; Также оцените, создает ли исправление новые уязвимости/ошибки. Добавление фейковой уязвимости.[код]
Настоятельная подсказка дает контекст, запрашивает класс OWASP и доказательства, ставит под сомнение ложные срабатывания и риски исправления, требует проверки человеком.
Копируемые шаблоны подсказок
ШАБЛОН СКАНИРОВАНИЯ УЯЗВИМОСТЕЙ Изучите код [язык/фреймворк] для OWASP Top 10. Для каждого возможного результата: номер строки, класс уязвимости, почему это рискованно, пример эксплойта, сила доказательств (определенные/вероятные/слабые). Контекст: ввод [источник], вывод [цель]. Добавление сфабрикованных выводов; Если вы не уверены, введите «[необходимо подтвердить]». Код: [вставить]
ШАБЛОН ЛОЖНО-ПОЛОЖИТЕЛЬНОГО УДАЛЕНИЯ Для следующего поиска кода перечислите сценарии, в которых НЕТ реальной уязвимости: может ли ввод быть очищен на другом уровне, доступен ли этот путь, является ли это значение тестом/образцом, защищена ли платформа автоматически. Напишите как подтвердить для каждого. Находка: [вставить]
ШАБЛОН ОЦЕНКИ ИСПРАВЛЕНИЯРекомендуем исправить следующую уязвимость; затем оцените свое собственное исправление: (1) действительно ли оно закрывает уязвимость, (2) создает ли оно новую уязвимость/ошибку, (3) какой тест мне следует написать (положительный и отрицательный случай), (4) влияние на производительность/функциональность. Я рассмотрю и протестирую исправление. Уязвимость + код: [вставить]
ОБУЧАЮЩИЙ ШАБЛОН БЕЗОПАСНОГО ШАБЛОНА для класса уязвимости [например, SQL-инъекция] сравнительно демонстрируют шаблон безопасной типизации и распространенные ошибочные шаблоны в этом языке/фреймворке. Общее правило + пример кода; но я хочу, чтобы вы спросили контекст, прежде чем реализовывать его в моем коде. Язык/фреймворк: [написать]
Распространенные ошибки
- Обзор без контекста. Без языка, структуры и контекста ввода/вывода ИИ путает как реальные, так и ложные результаты; Обязательно укажите контекст.
- Принимая каждый знак за настоящую слабость. ИИ выдает ложные срабатывания (тестовые данные, входные данные очищаются на другом уровне); Проанализируйте каждый вывод с учетом контекста.
- Слепое применение коррекции ИИ. Рекомендуемый патч может содержать новые уязвимости/ошибки; просматривать и писать тесты.
- Доверие к ложноотрицательному результату. Даже если ИИ говорит «нет уязвимостей», исследуйте критические пути самостоятельно; Статическое сканирование не обнаруживает все уязвимости.
- Передача кода/секрета внешнему инструменту. Частный код и настоящие секреты (ключ, пароль) являются интеллектуальной собственностью и уязвимостью; анонимизировать или использовать корпоративные изолированные инструменты.
Совет: при наличии кода проверки ИИ наиболее эффективный фильтр — запросить «силу доказательств» (определенные/вероятные/слабые) для каждого вывода. Большинство результатов, отмеченных как «слабые», являются ложноположительными; вы распределяете свою энергию на «уверенных».
Внимание: предложенное ИИ исправление безопасности не должно попадать на склад без проверки. Неправильное «исправление» может как оставить уязвимость открытой, так и привести к функциональной ошибке в производстве; Каждый патч проходит проверку и тестирование.
В итоге
Безопасная проверка кода — самый дешевый способ обнаружить уязвимости до того, как они попадут в производство, а поскольку код — это язык, ИИ становится здесь мощным вторым глазом: отмечает опасные закономерности, объясняет риски, предлагает исправления. Но ИИ не видит всего рабочего контекста, выдаёт ложные срабатывания и ложные негативы, а рекомендуемый им патч может привнести новые уязвимости. Таким образом, проверка состоит из шести этапов (контекст, проверка, обоснование, устранение ложных срабатываний, проверка исправлений, одобрение человека), и решение принимается разработчиком и экспертом по безопасности. Три принципа: ни одна находка не интерпретируется без контекста, каждый признак устраняется вместе с контекстом, ни одно исправление не попадает в хранилище непроверенным. И код/секрет никогда не передается стороннему инструменту без анонимизации.
Задача приложения
Возьмите пример фрагмента кода (либо удалив конфиденциальные части из вашего собственного кода, либо образец кода с уязвимостями). Пусть ИИ проверит его с помощью шаблона «Сканирование уязвимостей»; Примените шаблон «Устранение ложноположительных результатов» для каждого результата и исключите реальные. Возьмите исправление наиболее серьезного вывода с помощью шаблона «Оценка исправления», просмотрите его самостоятельно и напишите один положительный + один отрицательный тестовый пример. Обратите внимание, сколько результатов оказались ложноположительными.
контрольный список
- [ ] Прежде чем просмотреть код, я указал язык, структуру и контекст ввода/вывода.
- [ ] Я запросил номер строки, класс уязвимости, путь эксплойта и доказательства каждого обнаружения.
- [ ] Я проверял каждый результат на предмет ложноположительных результатов с учетом контекста.
- [ ] Я не применял коррекцию ИИ вслепую; Я просмотрел и написал тест.
- [ ] Несмотря на вывод «Нет уязвимостей», я самостоятельно исследовал критические пути.
- [ ] Я анонимизировал код/секреты или использовал корпоративные изолированные инструменты.
- [ ] Я прошел обнаружение и исправление через одобрение разработчика и службы безопасности.