Nano-analyzer

Минимальный сканер zero-day уязвимостей на основе LLM от AISLE.

Исследовательский прототип для демонстрации. Это простой однофайловый инструмент, способный обнаруживать реальные zero-day уязвимости. Обратите внимание, что это прототип, ориентированный на ошибки безопасности памяти в C/C++, и он будет выдавать ложные срабатывания. Мы публикуем его как есть в духе открытых исследований — ожидайте острых углов.

Что он делает

Nano-analyzer — это простой однофайловый сканер на Python, который пропускает исходный код через трёхэтапный конвейер LLM:

1. Генерация контекста — модель пишет сводку по безопасности файла: что он делает, куда поступают недоверенные данные, какие буферы существуют и их размеры.
2. Сканирование уязвимостей — та же модель, получившая контекст, ищет zero-day ошибки по функциям и выводит структурированные находки.
3. Скептическая проверка — каждая находка оспаривается в нескольких раундах скептическим рецензентом, который может выполнять grep по кодовой базе, чтобы подтвердить (или опровергнуть) защитные меры. Арбитр выносит окончательное решение.

Результаты сохраняются в файлы Markdown и JSON для просмотра человеком.

Текущие ограничения

Это прототип v0.1. Пожалуйста, учитывайте следующее:

• Склонность к C/C++. Промпты, few-shot примеры и эвристики сильно заточены под уязвимости безопасности памяти в C/C++ (переполнения буфера, разыменования NULL, целочисленные переполнения, путаница типов). Он может сканировать другие языки, но там гораздо менее эффективен.
• Ложные срабатывания. Даже после нескольких раундов проверки ожидайте находок, которые не подтвердятся при детальном рассмотрении. Всегда проверяйте вручную.
• Ложные пропуски. Сканер может пропускать целые классы уязвимостей — логические ошибки, состояния гонки, криптографические проблемы, обходы аутентификации и т. д. Чистый результат сканирования не означает, что код безопасен.
• Однофайловый анализ. Каждый файл сканируется независимо. Межфайловые уязвимости, зависящие от взаимодействия между единицами компиляции, скорее всего, будут пропущены.
• Зависимость от LLM. Результаты различаются в зависимости от используемой модели. Разные модели будут находить разные вещи и генерировать разные ложные срабатывания.

Установка

Требования

• Python 3.8+
• API-ключ OpenAI (для моделей OpenAI) или API-ключ OpenRouter (для других провайдеров)
• Опционально: ripgrep (rg) для поиска grep при проверке
• Опционально: Google codesearch (csearch/cindex) для более быстрого grep на больших репозиториях

Установка

git clone https://github.com/weareaisle/nano-analyzer.git
cd nano-analyzer
# Установка зависимостей не требуется. Запускайте напрямую:
python3 scan.py --help

API-ключи

Установите ваш API-ключ как переменную окружения:

# Для моделей OpenAI (имена моделей без слэша, например "gpt-5.4-nano"):
export OPENAI_API_KEY=sk-...

# Для моделей OpenRouter (имена моделей со слэшем, например "qwen/qwen3-32b"):
export OPENROUTER_API_KEY=sk-or-...

Сканер определяет, какой ключ использовать, по имени модели: если оно содержит /, запрос направляется через OpenRouter; в противном случае используется API OpenAI напрямую.

Использование

Базовое сканирование

# Сканировать один файл
python3 scan.py ./path/to/file.c

# Сканировать директорию рекурсивно
python3 scan.py ./path/to/src/

Часто используемые опции

# Использовать другую модель
python3 scan.py ./src --model gpt-5.4

# Управление параллелизмом
python3 scan.py ./src --parallel 30

# Указать корень репозитория для grep при проверке (полезно при сканировании поддиректории)
python3 scan.py ./lib/crypto/ --repo-dir ./

# Показывать только находки с высокой уверенностью
python3 scan.py ./src --min-confidence 0.7

# Больше раундов проверки для повышения точности (по умолчанию: 5)
python3 scan.py ./src --triage-rounds 7

Все флаги

Вывод

Результаты сохраняются в ~/nano-analyzer-results/<timestamp>/ (или в --output-dir):

<timestamp>/
├── summary.json              # машиночитаемая сводка сканирования
├── summary.md                # человекочитаемая сводка сканирования
├── <filename>.md             # необработанный вывод сканера для каждого файла
├── <filename>.context.md     # контекстная сводка для каждого файла
├── <filename>.json           # полные данные результата для каждого файла
├── triages/                  # детальное обоснование проверки
│   └── T0001_<file>_<title>.md
├── findings/                 # находки, прошедшие проверку
│   └── VULN-001_<file>.md
├── triage.json               # все вердикты проверки
└── triage_survivors.md       # сводка подтверждённых находок

Как работает проверка

Когда сканер находит проблему уровня серьёзности medium или выше, запускается конвейер проверки:

1. Скептический рецензент изучает находку на основе фактического кода и может выполнять grep по кодовой базе, чтобы подтвердить или опровергнуть заявленные защиты.
2. Это повторяется в течение нескольких раундов (по умолчанию: 5), при этом каждый рецензент видит предыдущие аргументы и поощряется находить новые доказательства, а не повторять старые пункты.
3. Финальный арбитр читает все раунды и выносит вердикт VALID (ПОДТВЕРЖДЕНО) или INVALID (НЕ ПОДТВЕРЖДЕНО).
4. Оценка уверенности (например, 80% [VVIVV→V]) показывает долю раундов, в которых было сказано VALID.

Находки, прошедшие проверку, записываются в директорию findings/ с полными цепочками рассуждений.

Отказ от ответственности

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

Лицензия

Лицензия Apache 2.0