ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

Группа компаний «Солар» проверила, насколько хорошо большие языковые модели справляются с двумя самыми трудоёмкими задачами в безопасной разработке — триажем уязвимостей и их исправлением в коде. Итог исследования получился довольно показательный: популярные общедоступные модели ускоряют работу, но пока слишком часто ошибаются, чтобы полностью на них полагаться.

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

Главный вывод исследования простой: LLM действительно экономят время, но на самых ответственных этапах безопасной разработки универсальные модели пока не дают нужной надёжности. Если команда безоговорочно доверится таким инструментам, есть риск пропустить критичные уязвимости.

В «Соларе» также напоминают ещё об одной проблеме: использование облачных моделей может стать каналом утечки исходного кода. Поэтому для задач безопасной разработки компания рекомендует смотреть в сторону локальных моделей on-premise, которые работают в закрытом контуре и всё равно требуют проверки со стороны AppSec-инженера.

Россиянам разрешат запрещать банкам повышать лимиты по кредиткам

Россиянам могут разрешить заранее запрещать банкам повышать лимиты по кредитным картам. Сейчас граждане уже могут установить самозапрет на заключение новых договоров потребительского кредита. Однако на действующие кредитки этот механизм не распространяется: банк по-прежнему может увеличить доступный лимит.

Соответствующий законопроект внесён в Госдуму, сообщает ТАСС. Документ предлагает закрыть эту дыру отдельным запретом на повышение лимита.

Подключить или отключить его можно будет через Госуслуги либо МФЦ. Перед увеличением доступной суммы банк должен будет обратиться в бюро кредитных историй и проверить, не включил ли клиент финансовый предохранитель.

Если запрет установлен, поднимать лимит будет нельзя. А если банк всё-таки решит проявить инициативу, последствия окажутся для него неприятными: кредитная организация не сможет потребовать вернуть долг, образовавшийся сверх прежней суммы.

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

Иногда человеку действительно проще заранее закрыть себе путь к дополнительным кредитным деньгам, чем потом объяснять банку, что внезапные покупки совершал не он.

Создавать отдельную государственную платформу для механизма не потребуется. Информацию о запретах предлагают передавать через уже работающую инфраструктуру бюро кредитных историй.

RSS: Новости на портале Anti-Malware.ru