SecureTechTalks
303 subscribers
805 photos
1 video
1 file
803 links
Добро пожаловать на канал "SecureTechTalks"! Мы предлагаем вам увлекательное и информативное погружение в мир кибербезопасности. Здесь вы найдете актуальные новости, советы, методы и инсайты по инфобезу.
Download Telegram
🤖 Копай глубже: как AI-помощники пишут уязвимый код

Нам обещали революцию в разработке. Но пока Copilot и другие AI-ассистенты генерируют код за секунды — они же могут открывать дверь для хакеров. 🧨

Исследование от Silviu Asandei (Sonar) показало: популярные AI-инструменты автодополнения кода нередко подсовывают небезопасные конструкции. Причём не потому, что "плохой AI", а потому что он учится на реальном, но не всегда хорошем коде из open-source 🧠

🔍 Что конкретно не так?

🧱 AI повторяет небезопасные шаблоны
Если где-то в 10 тысячах GitHub-репозиториев есть copy-paste с уязвимостями, ассистент их "учтёт" — и предложит тебе как «решение».

🔐 Отсутствие контроля безопасности
AI не всегда может отличить eval(user_input) от безопасного парсинга. А разработчик, доверяя “умному” помощнику, реже перепроверяет предложения.

📉 Слепая генерация — без контекста
AI не знает специфики твоей системы, модели угроз или политик безопасности. Он просто... продолжает строку.

⚠️ Всплывают уязвимости вроде XSS, SQL-инъекций, SSRF и insecure deserialization.

📌 Пример: как Copilot подставил под атаку

🤖 Разработчик просит: "Напиши API-обработчик формы регистрации пользователей".
Copilot выдаёт рабочий код, но:
Не экранирует поля
Пропускает валидацию
Не ставит rate-limit
🎯 Идеально для злоумышленника.

📊 Что показало исследование Sonar?

🔎 Проведён анализ кода, сгенерированного в популярных IDE
📈 Значительное число сниппетов содержат:
- небезопасные функции
- прямые обращения к
- опасным API
- отсутствие проверки прав доступа

Иными словами, автоматизация ≠ безопасная разработка

🧰 Как себя защитить?

🛠 Используйте инструменты анализа:
SAST (Static Application Security Testing)
Linter'ы с поддержкой security-правил
AI-критики

📚 Обучайте разработчиков:

1⃣ Не полагаться слепо на AI
2⃣ Понимать OWASP Top 10
3⃣ Ставить "контрольные точки" в пайплайнах CI/CD

🧠 Доверяй, но проверяй. Особенно если код пишется за секунду.

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #AIcode #Copilot #CodeSecurity #AIrisks #DevSecOps #StaticAnalysis #Sonar #CyberSecurity #XSS #AIandIDE #OWASP #SecureByDesign #AIDangers
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧬 Код как отпечаток пальца: уязвимости начинают искать по стилю

Мы воспринимаем уязвимости, как локальный сбой. Где-то не проверили вход, где-то неверно обработали условие, где-то допустили лишний доступ. В такой логике ошибка - это случайность, которую можно найти и исправить.

Однако ошибки почти никогда не бывают случайными. Они воспроизводятся. Причём не потому, что разработчик копирует код, а потому что он воспроизводит собственный способ мышления. У каждого есть устойчивые паттерны, например, как упрощать проверки или как обходиться с исключениями. Эти решения повторяются, а вместе с ними повторяются и уязвимости.

⚙️ Стиль становится сигналом

Code stylometry - подход, который смотрит на код не как на программу, а как на поведение автора. Модель работает на уровне структуры, она анализирует абстрактные синтаксические деревья, последовательности токенов, частоту и комбинации конструкций.

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

Речь идет не о поиске конкретной уязвимости, а склонности к ней.

🧪 От поиска к предсказанию

Модель сначала извлекает стилевые признаки, затем сопоставляет их с обученными зависимостями и на выходе даёт оценку: насколько вероятно, что в этом коде есть уязвимости.

Технически за этим стоят обычные ML-пайплайны, обучение на размеченных данных, где известны уязвимости. 

Впервые объектом анализа становится не сам код, но и стиль его написания как фактор риска.

🧨 Почему это работает?

Причина в том, что разработчик не пишет код «с нуля» каждый раз. Он воспроизводит себя. Одни и те же способы обработки ошибок, одни и те же допущения кочуют из файла в файл. Если в одном месте это привело к уязвимости, в другом вероятность резко возрастает.

Модель, в отличие от человека, не ищет логическое объяснение. Она фиксирует статистическую закономерность.

🕵️‍♂️ Код рассказывает о человеке

Если стиль можно распознать и оценить, значит, можно сравнивать не только фрагменты кода, но и их авторов. Код начинает работать как отпечаток пальца. Через него проявляются привычки, уровень аккуратности, склонность к риску.

В прикладном смысле это означает, что анализ может сместиться. Не от кода к уязвимости, а от разработчика к зонам повышенного риска. В большом проекте это даёт возможность приоритизировать аудит, фокусироваться не на всём сразу, а на том, где вероятность ошибки статистически выше.

🔗 Подробнее с подходом можно ознакомиться в исследовании.

P.S. интересно будет составить список паттернов для каждой LLM.

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #CodeSecurity #VulnerabilityDetection #Infosec #CyberSecurity #StaticAnalysis #AIrisks #SecureTechTalks
👍1
🧠 AppSec переезжает в редактор кода

Сегодня Copilot или LLM способны генерировать целые фрагменты бизнес-логики за минуты.

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

⚙️ Security-проверки прямо во время написания кода

Heidi - open-source security plugin для IDE, который анализирует код прямо в процессе редактирования. Плагин отслеживает изменения в файлах и пытается находить опасные конструкции ещё до запуска приложения:
🔹 insecure API usage
🔹 hardcoded secrets
🔹 shell/command injection patterns
🔹 небезопасную работу с filesystem
🔹 потенциально опасную обработку пользовательского ввода

Анализ идёт не только по сигнатурам. Heidi пытается учитывать контекст: откуда приходят данные, проходят ли они sanitization и куда попадают дальше.

Например, плагин может заметить, что input пользователя без фильтрации уходит в SQL query, shell execution или filesystem operation.

🧪 Принцип работы

Под капотом Heidi использует инкрементальный анализ, т.к. плагин работает внутри IDE и не может позволить себе полноценный перескан проекта после каждого нажатия клавиши. Вместо этого анализируются только изменения и связанные с ними участки кода.

Инсирумент строит lightweight security-analysis pipeline прямо внутри editor runtime.
Для detection используются: 🔹 pattern-based rules
🔹 context-aware checks
🔹 анализ data flow между источниками input и sensitive operations

Система пытается видеть не только отдельную опасную строку, но и цепочку прохождения данных через код.

🧨 Главная проблема таких систем

Сделать security-плагин сложно не технически. Сложно сделать так, чтобы разработчики его не возненавидели.

Если система начинает агрессивно спамить warning’ами, люди быстро перестают обращать внимание на алерты. Если detection слишком мягкий, то реальные проблемы проходят мимо.

Особенно тяжело анализировать AI-generated code, ведь он часто выглядит syntactically clean, но содержит опасные assumptions, которые плохо ловятся простыми сигнатурами.

🔗 Ссылки для скачивания:
JetBrains 
VS Code Marketplace

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧨 Vibe coding создает новый класс уязвимых приложений

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

Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.

После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.

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

На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.

К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.

🔗 Исследование: https://arxiv.org/abs/2606.23130

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
👍2