Як GPT-5.5-Cyber допомагає знаходити вразливості та аналізувати код

Знайти вразливість стало дешево. Виправити її — ні. Саме це OpenAI назвала головним зрушенням 2026 року: AI настільки прискорив discovery, що bottleneck перемістився від «пошуку» до «патчингу». GPT-5.5-Cyber — спроба атакувати саме цей bottleneck. У цій статті — технічний розбір того, як це виглядає зсередини: архітектура, реальні приклади з кодом, обмеження і те, де людина залишається незамінною.

📌 Це третя стаття серії про AI в кібербезпеці 2026. Першу — про архітектуру GPT-5.5-Cyber і Daybreak — читайте тут. Порівняння GPT-5.5-Cyber з Claude Opus і Gemini — тут.

📚 Зміст статті

• Архітектура AI для кібербезпеки: LLM, Tool Calling, Agentic Workflow, RAG
• Як GPT-5.5-Cyber аналізує вихідний код
• Пошук OWASP Top 10: що знаходить AI, а що пропускає
• Аналіз malware: від дизасемблювання до звіту
• Reverse Engineering бінарних файлів
• AI-агенти для автоматичного пошуку вразливостей
• Реальні кейси: що вже знайшов GPT-5.5
• Обмеження: де AI помиляється і чому людина незамінна
• Майбутнє AI в кібербезпеці: що вже реально, що ще ні
• Висновки
• FAQ

⚙️ Архітектура AI для кібербезпеки: LLM, Tool Calling, Agentic Workflow, RAG

Перш ніж розбирати конкретні задачі, важливо розуміти, з яких блоків складається сучасна AI security-система. GPT-5.5-Cyber — не просто «чат-бот, який знає CVE». Це оркестратор, що об'єднує кілька різних технологічних компонентів.

LLM як reasoning-ядро

Базова мовна модель (у нашому випадку — GPT-5.5) виконує роль центрального reasoning-шару: розуміє природну мову, аналізує код, будує гіпотези про вразливості, пояснює знахідки і генерує патчі. Але сама по собі LLM — це лише «думки». Щоб перетворити їх на дії, потрібні Tool Calling і Agent Loop.

Tool Calling: AI, що взаємодіє з реальними інструментами

Tool Calling (або Function Calling в термінології OpenAI API) дозволяє моделі викликати зовнішні функції і інструменти, отримувати їхні результати і продовжувати reasoning на основі реальних даних. У security-контексті типові інструменти, які може викликати GPT-5.5-Cyber:

• Static analyzers — Semgrep, CodeQL, Bandit; модель формулює правило пошуку, інструмент сканує кодову базу, результати повертаються в контекст
• CVE databases — NVD, OSV, Snyk Advisor; запит по назві бібліотеки і версії, отримання відомих вразливостей
• Decompilers — Ghidra, IDA Pro (через API), Binary Ninja; завантаження бінарника, отримання дизасемблованого коду для аналізу
• Network tools — nmap, Shodan (через API); reconnaissance і fingerprinting авторизованого цілі
• Code execution environments — sandbox для тестування PoC без впливу на реальні системи

Практичний приклад з Codex Security (офіційний інструмент OpenAI): модель генерує Semgrep rule для пошуку SQL injection паттернів → Semgrep сканує репозиторій → повертає SARIF-файл з локаціями → модель аналізує знахідки і ранжує за severity. Це не одноразовий запит, а цикл інструментів.

Agentic Workflow: Plan → Tool Call → Observe → Revise

На відміну від простого чат-запиту, agentic workflow означає, що модель сама планує кроки і вирішує, який інструмент викликати наступним, виходячи з попередніх результатів. Спрощений цикл:

1. Plan — модель отримує задачу («знайди SQL injection вразливості у цьому Node.js додатку») і будує план кроків
2. Tool Call — викликає перший інструмент (наприклад, Semgrep з OWASP Top 10 конфігурацією)
3. Observe — аналізує результати: які знахідки є, яка confidence, чи потрібне глибше дослідження
4. Revise — коригує план: якщо Semgrep знайшов підозрілий pattern, модель може запустити додатковий аналіз data flow або запитати більше контексту файлу
5. Report — генерує структурований звіт з severity, affected location, attack path і рекомендованим патчем

Саме цей цикл AISI оцінює у своєму бенчмарку «The Last Ones» (TLO) — 32-крокова симуляція атаки на корпоративну мережу, де модель сама визначає наступну дію на основі попередніх результатів (AISI, квітень 2026).

RAG: заземлення на актуальні дані

Retrieval-Augmented Generation вирішує ключову проблему LLM для security-задач: знання моделі обмежені датою тренування, а вразливості з'являються щодня. RAG дозволяє «підключити» модель до актуальних баз даних:

• NVD / CVE database — актуальні описи вразливостей, CVSS scores, affected versions
• OSV (Open Source Vulnerabilities) — база Google для open source; Sec-Gemini v1 використовує OSV нативно
• Mandiant threat intelligence — реальні TTPs, IOCs від атакувальників (Google AI Threat Defense)
• Власна кодова база організації — векторна база з семантичним пошуком по всьому репозиторію
• CISA KEV (Known Exploited Vulnerabilities) — список вразливостей, що активно експлуатуються — найвищий пріоритет для патчингу

Детальніше про архітектуру RAG-систем і практичну реалізацію з pgvector і Spring AI — у нашій статті «Як працює RAG: Retrieval-Augmented Generation з Spring AI і pgvector».

🔍 Як GPT-5.5-Cyber аналізує вихідний код

Аналіз вихідного коду — найпоширеніший і найбільш зрілий сценарій використання AI в кібербезпеці. Тут GPT-5.5 (і GPT-5.5-Cyber) показують найбільш передбачувані і перевірені результати.

Статичний аналіз: що AI бачить у коді

Класичний статичний аналіз — це пошук вразливостей у коді без його виконання. LLM робить це інакше, ніж традиційні SAST-інструменти на кшталт Checkmarx чи Fortify. Де традиційний SAST будує AST (Abstract Syntax Tree) і шукає паттерни за заздалегідь прописаними правилами, GPT-5.5 розуміє семантику коду — може виявити вразливість, що виникає з бізнес-логіки, яку неможливо описати простим правилом.

Наприклад, традиційний SAST легко знайде query = "SELECT * FROM users WHERE id = " + userId як SQL injection. Але він пропустить вразливість типу IDOR (Insecure Direct Object Reference), де логічний контроль доступу реалізований неправильно — бо тут немає «поганого паттерну» на рівні синтаксису, є помилка в бізнес-логіці.

Типовий промпт для code review у форматі Trusted Access for Cyber:

Analyze the attached code snippet within the context of the OWASP Top 10.
Identify any potential injection points or broken access control issues.
Then, provide a validated patch that adheres to secure coding best practices
and explain how to test this patch in a sandbox environment.

Codex Security (плагін OpenAI для code repositories) реалізує цей підхід у промисловому масштабі: він генерує severity-rated reports з affected code locations, attack path tracing і codebase-specific patches для human review. З березня по червень 2026 він просканував 30+ млн комітів у 30 000+ репозиторіях (Cyber Security News).

Пошук паттернів вразливостей: taint analysis через LLM

Класична taint analysis відстежує «забруднені» (tainted) дані від джерела (user input) до «приймача» (sink — функції, що виконують небезпечні операції), перевіряючи чи є санітизація між ними. LLM робить семантичний еквівалент цього процесу:

1. Ідентифікує всі точки вхідних даних: HTTP параметри, заголовки, файли, змінні середовища
2. Відстежує flow даних через функції і трансформації
3. Знаходить «sinks» — місця, де ці дані використовуються небезпечно: SQL query, shell command, HTML render
4. Аналізує чи є між ними валідація, санітизація або параметризація

Контекстне розуміння застосунку

Головна перевага LLM перед традиційними SAST-інструментами — здатність розуміти контекст. GPT-5.5 з великим контекстним вікном (1M токенів) може тримати весь репозиторій у пам'яті і виявляти вразливості, що виникають із взаємодії між модулями. Приклад: вразливість авторизації, де модуль A правильно перевіряє права, але модуль B, що викликає A, передає user ID в обхід, залишить традиційний SAST сліпим — LLM побачить cross-module flow.

⚠️ Критичне застереження: 45% AI-згенерованого коду у 2026 містить вразливості OWASP (Digital Applied). AI, що шукає вразливості в коді — і AI, що генерує цей код — це часто одна і та сама модель. Людський review залишається обов'язковим для обох сторін цього процесу.

🎯 Пошук OWASP Top 10: що знаходить AI, а що пропускає

OWASP Top 10 — стандартний список найпоширеніших вразливостей веб-застосунків. Розберемо кожну категорію з точки зору того, наскільки добре AI справляється з її пошуком, і де залишаються сліпі зони.

SQL Injection (A03:2021)

AI знаходить добре: конкатенація рядків у SQL-запитах, відсутність параметризованих queries, використання string formatting замість prepared statements.

Приклад вразливого коду, який AI виявить миттєво:

// Node.js — вразливий код
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`;
db.execute(query);

// Правильний варіант (AI запропонує саме так)
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [req.body.email]);

AI може пропустити: second-order SQL injection (де дані спочатку зберігаються «безпечно», а потім використовуються у вразливому запиті пізніше); injection через stored procedures з динамічним SQL всередині.

Cross-Site Scripting — XSS (A03:2021)

AI знаходить добре: reflected XSS через прямий рендеринг user input в HTML; stored XSS через запис у БД і подальший рендеринг без escaping; innerHTML / document.write з user-controlled даними.

// Вразливий React код (AI знайде)
function Comment({ text }) {
  return <div dangerouslySetInnerHTML={{ __html: text }} />;
}

// Безпечний варіант
function Comment({ text }) {
  return <div>{text}</div>;
}

AI може пропустити: DOM-based XSS у складних SPA з непрямими маніпуляціями DOM через event handlers; mXSS (mutation XSS), де sanitizer трансформується в браузері у небезпечний markup.

Server-Side Request Forgery — SSRF (A10:2021)

AI знаходить добре: функції fetch/curl з user-controlled URL без валідації; webhook-функціонал без allowlist; URL redirects, що можуть бути використані для SSRF.

// Python — вразливий код (SSRF)
@app.route('/fetch')
def fetch_url():
    url = request.args.get('url')
    response = requests.get(url)  # Без валідації!
    return response.text

# Безпечний варіант — AI запропонує allowlist
ALLOWED_DOMAINS = {'api.trusted.com', 'cdn.trusted.com'}

def is_safe_url(url):
    parsed = urlparse(url)
    return parsed.hostname in ALLOWED_DOMAINS

AI може пропустити: Blind SSRF без прямого response leakage; SSRF через DNS rebinding; SSRF через redirects у сторонніх бібліотеках з автоматичним слідуванням redirects.

Insecure Direct Object Reference — IDOR (A01:2021)

IDOR — найважча для AI категорія, бо це про бізнес-логіку, а не синтаксис. Вразливість виникає коли додаток використовує предсказуваний ідентифікатор для доступу до об'єкту без перевірки, чи має поточний користувач право на цей об'єкт.

// Express.js — вразливий код (IDOR)
app.get('/api/orders/:orderId', async (req, res) => {
  const order = await Order.findById(req.params.orderId);
  res.json(order); // Немає перевірки: чи належить замовлення req.user?
});

// Безпечний варіант
app.get('/api/orders/:orderId', async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.orderId,
    userId: req.user.id  // Перевірка власника
  });
  if (!order) return res.status(403).json({ error: 'Forbidden' });
  res.json(order);
});

AI знаходить IDOR краще, ніж традиційні SAST — але лише якщо у контексті є схема даних і authorization middleware. Без розуміння структури прав доступу модель часто дає false positives або навпаки пропускає реальні проблеми.

Command Injection (A03:2021)

AI знаходить добре: виклики shell з user-controlled параметрами; exec(), system(), subprocess.call(shell=True) з конкатенацією.

# Python — вразливий код (Command Injection)
import subprocess
filename = request.form['filename']
result = subprocess.run(f'cat /uploads/{filename}', shell=True, capture_output=True)

# Безпечний варіант — AI рекомендує
result = subprocess.run(['cat', f'/uploads/{filename}'], capture_output=True)
# Або ще краще — уникати shell взагалі і читати файл через Python

🦠 Аналіз malware: від дизасемблювання до звіту

Аналіз malware — одна з задач, де GPT-5.5-Cyber показує суттєву перевагу над базовою GPT-5.5: більше дозволених операцій з підозрілими зразками, менше відмов при роботі з exploit-like кодом.

Розбір функцій підозрілого коду

Типовий workflow аналізу malware з AI-асистентом:

1. Завантажити зразок у sandbox-середовище (ніколи на production!)
2. Отримати дизасемблований або декомпільований код через Ghidra/IDA Pro
3. Подати в GPT-5.5-Cyber для семантичного аналізу

Ефективний промпт для аналізу malware-функції:

You are a malware analyst. Analyze the following decompiled function.
Identify: 1) What this function does technically,
2) Any indicators of malicious behavior (C2 communication, persistence,
evasion, data exfiltration), 3) MITRE ATT&CK techniques if applicable,
4) Suspicious strings, API calls, or obfuscation patterns.

[decompiled function code here]

Виявлення підозрілої поведінки

AI особливо ефективний для виявлення таких класів підозрілої поведінки:

• C2 communication patterns — encoded URLs, DGA (Domain Generation Algorithms), незвичні порти або протоколи
• Persistence mechanisms — запис у реєстр, планувальник задач, startup folders, cron jobs
• Evasion techniques — sleep loops для обходу sandbox, перевірка кількості процесорів або мишки, обфускація рядків
• Anti-analysis tricks — IsDebuggerPresent, антиVM перевірки, перевірка username/hostname на типові sandbox назви
• Data exfiltration — збір системної інформації, keylogging паттерни, скріншоти, пошук файлів за розширеннями

Автоматичне створення звітів

Після аналізу GPT-5.5-Cyber може генерувати структурований IOC-звіт у форматах STIX/TAXII або markdown з:

• Хешами файлів (MD5, SHA-256)
• Підозрілими рядками і IP-адресами для блокування
• MITRE ATT&CK тактиками і техніками (T-номерами)
• Yara rules для детекції подібних зразків
• Рекомендаціями для EDR і SIEM

⚠️ Важливо: Аналіз malware потрібно завжди проводити в ізольованому sandbox-середовищі. Ніколи не запускайте підозрілі файли на робочій машині, навіть якщо «просто хочете перевірити один файл». GPT-5.5-Cyber аналізує код, а не запускає його — але завантажені файли необхідно ізолювати до початку аналізу.

🔧 Reverse Engineering бінарних файлів

Reverse engineering — технічно найскладніша область, де AI-асистент може суттєво прискорити роботу досвідченого аналітика, але не замінить його.

Розбір дизасемблованого коду

Процес із GPT-5.5-Cyber:

1. Завантажити бінарник у Ghidra або IDA Pro
2. Експортувати дизасемблований або декомпільований псевдокод
3. Подати функції в GPT-5.5-Cyber для пояснення

// Приклад: пояснення підозрілої функції через промпт
"Explain what this decompiled C function does. Focus on:
- Data structures it manipulates
- Network or file system operations
- Crypto operations (if any)
- Potential vulnerabilities or malicious patterns
- Rename variables to meaningful names based on context"

AI добре справляється з:

• Переіменуванням нечитаємих var_8, param_1 у семантично значущі назви
• Поясненням алгоритмів шифрування і хешування у псевдокоді
• Ідентифікацією відомих бібліотечних функцій у stripped бінарниках
• Розпізнаванням паттернів типових exploit primitives

Пошук індикаторів компрометації (IOC)

Після розбору бінарника AI може автоматично екстрагувати IOC:

• Hardcoded strings — C2 адреси, URL, паролі, ключі
• Mutex names — унікальні mutex для single-instance malware
• Registry keys — persistence механізми через реєстр
• File paths — де malware розміщує свої компоненти
• API call patterns — характерні послідовності Windows API викликів

Приклад автоматичного Yara rule, згенерованого GPT-5.5-Cyber на основі аналізу зразка:

rule Suspicious_AsyncRAT_Variant {
    meta:
        description = "Detects AsyncRAT-like malware based on behavioral patterns"
        date = "2026-06"
        severity = "high"
    strings:
        $mutex = "AsyncMutex_6SI8OkPnk" nocase
        $c2_pattern = /[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{4,5}/
        $anti_vm1 = "VBOX" nocase
        $anti_vm2 = "vmware" nocase
        $persistence = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run" nocase
    condition:
        uint16(0) == 0x5A4D and
        $mutex and
        $c2_pattern and
        ($anti_vm1 or $anti_vm2) and
        $persistence
}

🤖 AI-агенти для автоматичного пошуку вразливостей

Агентний режим — принципово інший рівень можливостей порівняно з простим code review. Тут модель не відповідає на запитання, а самостійно виконує multi-step завдання в авторизованому середовищі.

Як виглядає Agent Loop на практиці

AISI у своєму бенчмарку описує агентний цикл GPT-5.5 так: модель «placed on the network with an objective and must find and execute the full attack path autonomously» (AISI, 2026). Але для практичного penetration testing агент виглядає так:

// Псевдокод агентного vulnerability scanning workflow

Objective: "Find and document OWASP vulnerabilities in the authorized
           target application at https://authorized-target.internal"

Step 1: Reconnaissance
  → tool_call: nmap_scan(target="authorized-target.internal")
  → observe: "Open ports: 80 (HTTP), 443 (HTTPS), 3306 (MySQL)"

Step 2: Technology fingerprint
  → tool_call: whatweb_scan(url="https://authorized-target.internal")
  → observe: "Node.js 20.x, Express 4.x, MySQL 8.0, React 18"

Step 3: Static analysis
  → tool_call: semgrep_scan(repo_url="...", config="p/owasp-top-ten")
  → observe: "17 findings: 3 HIGH (SQL injection), 8 MEDIUM, 6 LOW"

Step 4: Deep analysis of HIGH findings
  → tool_call: get_file_context(file="src/api/users.js", lines="45-67")
  → reason: "Confirm if SQLi is exploitable given ORM usage"
  → observe: "Raw query construction confirmed in line 52"

Step 5: PoC generation (GPT-5.5-Cyber only, authorized target)
  → tool_call: execute_in_sandbox(payload="' OR 1=1 --")
  → observe: "200 OK, returned 847 user records — CONFIRMED exploitable"

Step 6: Patch generation + report
  → generate: parameterized query fix
  → generate: CVSS score, remediation guidance, test case

Tool Use: які інструменти інтегрує Codex Security

Оновлений Codex Security плагін (22 червня 2026) підтримує інтеграцію з:

• SARIF exports — стандартний формат для інтеграції з GitHub Advanced Security, Azure DevOps
• CodeQL queries — модель може генерувати CodeQL запити для специфічних вразливостей
• Vulnerability management pipelines — інтеграція з Jira, ServiceNow для автоматичного створення тікетів
• CI/CD hooks — GitHub Actions workflow для автоматичного сканування на PR

Приклад GitHub Actions workflow з Codex Security і AI-assisted review:

name: security-review
on:
  pull_request:
  push:
    branches: [ main ]
jobs:
  static-security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep (OWASP Top 10)
        run: |
          pipx install semgrep
          semgrep scan --config p/owasp-top-ten --sarif \
            --output semgrep.sarif || true
      - name: Upload security artifacts
        uses: actions/upload-artifact@v4
        with:
          name: security-artifacts
          path: semgrep.sarif
      # Далі Codex Security аналізує sarif і генерує
      # severity-rated report з патчами для human review

Джерело workflow: Penligent AI, червень 2026.

📋 Реальні кейси: що вже знайшов GPT-5.5

Це найважливіший розділ для оцінки реальних можливостей — не бенчмарки, а підтверджені публічні кейси.

CVE-2026-8390: WebAssembly у Firefox

OpenAI Preparedness виявила use-after-free вразливість у JavaScript/WebAssembly компоненті Firefox під час safety evaluations, використовуючи GPT-5.5. Mozilla отримала звіт і випустила патч у Firefox 150.0.3 за два дні до Pwn2Own Berlin — тобто до того, як зовнішні дослідники могли б публічно продемонструвати вразливість (Developer Tech).

Чому це важливо: AI виявив вразливість у браузерному двигуні — складній системі з мільйонами рядків коду — самостійно, без цільового пошуку саме в WebAssembly. Це ілюструє здатність агентного підходу знаходити вразливості там, де ніхто не шукав.

dnsmasq: чотири CVE до офіційного виправлення

Trail of Bits із Codex Security побудували fuzzing lab, що покривала десятки entry points для проєкту dnsmasq. Результат — виявлення паттернів, що відповідали чотирьом CVE до їх зовнішнього виправлення у версії 2.92rel2:

• CVE-2026-4890 — DNSSEC validation infinite-loop flaw (remote DoS)
• CVE-2026-4891 — heap-based out-of-bounds read у DNSSEC validation
• CVE-2026-4892 — heap-based out-of-bounds write у DHCPv6 implementation
• CVE-2026-5172 — додаткова DNSSEC/DHCP вразливість

Джерело: Penligent AI | CERT/CC advisory

HTTP/2 Bomb: 880 000 серверів під загрозою

Calif (партнер Patch the Planet) використав Codex Security для виявлення HTTP/2 Bomb — техніки denial-of-service, що зачіпала Apache, NGINX, IIS і Pingora. За оцінкою, більше 880 000 інтернет-серверів були вразливі (Developer Tech). Coordinated disclosure дозволила мейнтейнерам підготувати патчі до публічного розкриття.

Chrome V8 і Safari WebKit

OpenAI дослідники задокументували і відповідально розкрили:

• 5 exploitable вразливостей у Chrome V8 JavaScript engine
• 10+ вразливостей у Safari WebKit

⚠️ Обмеження: де AI помиляється і чому людина незамінна

Чесна оцінка інструменту вимагає розуміти не тільки що він вміє, але і де він регулярно помиляється.

False positives: хибні спрацювання

За даними OWASP, традиційні SAST-інструменти генерують від 35% до 80% false positives залежно від налаштувань. AI-assisted аналіз покращує цей показник через семантичне розуміння контексту — але не усуває проблему. Типові джерела false positives для LLM:

• Санітизація, реалізована в окремому middleware, яку модель не бачить у локальному контексті
• ORM, що приховує небезпечні операції за безпечним API (ActiveRecord, Hibernate)
• Vendor-specific security controls, не описані в загальнодоступній документації
• Test code, що навмисно містить «вразливий» код для тестування safety controls

Hallucinated security fixes: найнебезпечніший вид помилки

Якщо AI генерує false positive — команда витрачає час даремно. Якщо AI генерує hallucinated security fix — ситуація гірша: код виглядає безпечним, проходить review, деплоїться у продакшн і залишає реальну вразливість відкритою.

Приклад: AI може запропонувати «виправлення» SQL injection через escape() функцію, яка дійсно існує, але не є достатнім захистом у конкретному контексті БД. Або запропонувати HTML encoding як захист від SSRF — що взагалі не вирішує проблему. Ось чому всі AI-generated патчі вимагають обов'язкового тестування у staging середовищі (MindWired AI).

Runtime vs static: головна архітектурна межа

AI (включно з GPT-5.5-Cyber у більшості workflow) підтверджує вразливість статично. Реальна exploitability залежить від runtime-стану: active sessions, in-memory стану, мережевих правил, WAF-налаштувань. Без runtime validation частина «підтверджених» знахідок виявляється non-exploitable у конкретному production середовищі. MindFort AI описує це як «10 000 maybes instead of verified findings».

Обмеження доступу: реальна проблема для більшості команд

GPT-5.5-Cyber — лише для Daybreak-партнерів. TAC — вимагає верифікації. Навіть базовий GPT-5.5 з TAC недоступний без проходження процесу перевірки. Для більшості security-команд у 2026 році реально доступні інструменти: GPT-5.5 стандартний (з обмеженнями), Claude Opus 4.8, Gemini. Не плануйте workflow навколо GPT-5.5-Cyber, якщо ви ще не маєте TAC-доступу.

Рекомендована модель роботи: п'ять фаз з чітким розподілом

Penligent AI пропонує практичну модель, де AI і людина мають чіткі зони відповідальності (Penligent AI):

💡 Ключовий принцип з Penligent AI: «Blocking decisions should be based on confidence, severity, and maturity of the rule or finding type. AI can summarize artifacts, propose patches, and draft tickets. Blocking decisions should remain with humans.» Машина автоматизує стадії 1–4; людина залишається власником рішення на кроці 5.

🔮 Майбутнє AI в кібербезпеці: що вже реально, що ще ні

Автоматичне виправлення вразливостей: вже частково реальне

CodeMender (Google) і Codex Security (OpenAI) вже генерують патчі автоматично. Але «автоматичне виправлення» у 2026 означає: AI пропонує патч → людина перевіряє → людина мерджить. Повністю автономний цикл «знайшов → виправив → задеплоїв без людини» — поки не реальний для production-систем із обґрунтованих причин безпеки.

AI Bug Bounty: нова динаміка

AI суттєво знизив бар'єр входу в bug bounty. Але це створює нову проблему — flood of low-quality AI-generated reports. OpenSSF у лютому 2026 провів окрему дискусію про «AI Junk Reports»: тільки ~5% bounty submissions від AI-assisted дослідників були реальними вразливостями (Moomoo). Провідні bug bounty платформи вже вводять або обговорюють нові правила щодо AI-assisted submissions.

Автономні security-агенти: frontier вже зараз, загальний доступ — у майбутньому

Claude Mythos і GPT-5.5-Cyber вже демонструють near-autonomous vulnerability discovery: 73% CTF success rate (AISI), завершення 32-step corporate network attack simulation. Але ці можливості закриті за верифікацією. Для широкого ринку перехід від «AI-assisted» до «AI-autonomous» security — питання 2-3 років, не сьогодні.

Найточніший прогноз сформулювала Digital Applied: «The scarce, defensible human work migrates to judgment — deciding which findings are real and reachable, whether a machine-generated patch is safe to merge, and how to sequence disclosure responsibly. The tools change which step is the bottleneck; they do not remove the need for a human to own the decision at the merge button.» (Digital Applied)

✅ Висновки

Технічний розбір GPT-5.5-Cyber у 2026 році дає чітку картину: AI-assisted vulnerability research перейшов від «цікавого експерименту» до «промислового інструменту» — але з дуже конкретними межами.

• 🔍 Static code analysis — зрілий і корисний вже зараз; AI суттєво прискорює triage і знаходить business-logic вразливості, які традиційний SAST пропускає
• 🦠 Malware analysis — суттєве прискорення для досвідченого аналітика; автоматична генерація IOC і Yara rules реально економить години
• 🤖 Agentic vulnerability discovery — потужний, але потребує авторизованого середовища і верифікованого доступу; для більшості команд — прийде через 1-2 роки
• ⚠️ Головне обмеження — AI не підтверджує exploitability в runtime без спеціального middleware; 45% AI-коду містить вразливості OWASP; людина залишається на merge button
• 🎯 Правильна роль AI — прискорювач для фаз discovery і remediation-draft; не замінник human judgment на фазі validation і merge

Якщо хочете почати з практики прямо зараз — без TAC-верифікації і спеціального доступу — відмінна точка входу: Claude Opus 4.8 для code review і vulnerability triage вашого власного коду. Додайте Semgrep з OWASP Top 10 конфігурацією до CI/CD pipeline. Це дасть 80% практичної цінності AI-assisted security вже сьогодні.

❓ FAQ

📚 Джерела

• OpenAI — Scaling Trusted Access for Cyber (7 травня 2026)
• AISI — Our evaluation of OpenAI's GPT-5.5 cyber capabilities (квітень 2026)
• Cyber Security News — GPT-5.5-Cyber Full Release (22 червня 2026)
• Penligent AI — GPT-5.5-Cyber and Patch the Planet
• Digital Applied — GPT-5.5-Cyber and Codex Security: AI Patches at Scale
• Developer Tech — OpenAI deploys GPT-5.5-Cyber for open-source vulnerability fixes
• Sophos — GPT-5.5-Cyber for defenders at the frontier (травень 2026)
• MindWired AI — How to unlock AI's real security potential (травень 2026)
• OWASP — Static Code Analysis
• Moomoo — Claude Opus 4.8 Discovers a $4.5 Billion Bug (червень 2026)