# Lagune

> Security-Driven Hardening для будь-якої кодової бази

Lagune є робочим процесом Security-Driven Hardening (SDH) з відкритим кодом, суто оборонним. Він допомагає вашому ШІ-агенту посилити захист будь-якої кодової бази будь-якою мовою на кожному етапі: фаза charter встановлює правила безпеки ще до розробки, універсальна команда /lagune посилює захист роботи під час написання коду, а п'ятифазний процес Blue Team визначає, що насправді робить ваша система, і спрямовує виправлення, важливі для цього контексту. Його команди встановлюються у ваш агент через CLI skills, і API-ключ не потрібен.

---

# Встановлення: посилення захисту для будь-якого ШІ-агента

> Встановіть Lagune у будь-який проєкт як плагін, якщо ваш агент його підтримує, або через CLI skills в інших випадках, а потім оберіть спеціалізації з безпеки, що йому підходять.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs
Мова: uk-UA
Оригінал: https://lagune.ai/docs
Останнє оновлення: 2026-11-03

**Lagune** допомагає вашому ШІ-агенту зробити проєкт безпечнішим. Ви спрямовуєте його на свій код, агент з'ясовує, що насправді робить ваша система, а потім веде вас через роботу з безпеки, важливу саме для неї. **Lagune** є першим проєктом методології [Security-Driven Hardening (SDH)](https://lagune.ai/uk-UA/docs/references/paper).

**Підтримайте відкритий код**

Подобається **Lagune**? [Поставте нам ⭐ на **GitHub**](https://github.com/wellwelwel/lagune)

## Оберіть свій агент

- [Claude Code](https://lagune.ai/uk-UA/docs/install/claude-code): Агентний інструмент для програмування від Anthropic
- [Codex](https://lagune.ai/uk-UA/docs/install/codex): Агент для програмування від OpenAI
- [Cursor](https://lagune.ai/uk-UA/docs/install/cursor): Редактор коду зі ШІ
- [GitHub Copilot](https://lagune.ai/uk-UA/docs/install/github-copilot-cli): ШІ-напарник для програмування від GitHub
- [Gemini CLI](https://lagune.ai/uk-UA/docs/install/gemini-cli): Термінальний агент з відкритим кодом від Google
- [Antigravity](https://lagune.ai/uk-UA/docs/install/antigravity-cli): Платформа агентної розробки від Google
- [OpenCode](https://lagune.ai/uk-UA/docs/install/opencode): Агент для програмування з відкритим кодом
- [Devin for Terminal](https://lagune.ai/uk-UA/docs/install/devin-cli): Термінальний агент від Cognition
- [Factory Droid](https://lagune.ai/uk-UA/docs/install/factory-droid): Агент для розробки програмного забезпечення від Factory
- [Grok Build](https://lagune.ai/uk-UA/docs/install/grok-build): Агент для програмування від xAI
- [Qwen Code](https://lagune.ai/uk-UA/docs/install/qwen-code): Термінальний агент для програмування від Qwen
- [Kimi Code](https://lagune.ai/uk-UA/docs/install/kimi-code): Агент для програмування від Moonshot AI
- [Muse Code](https://lagune.ai/uk-UA/docs/install/muse-code): Агент для програмування від Meta
- [Pi](https://lagune.ai/uk-UA/docs/install/pi): Мінімалістичний термінальний агент для програмування
- [Hermes Agent](https://lagune.ai/uk-UA/docs/install/hermes-agent): Агент з відкритим кодом від Nous Research
- [Універсально](https://lagune.ai/uk-UA/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed та інші (66)

**Інформація**

- Під капотом **Lagune** працює на **Node.js**, але ви використовуєте будь-яку мову, яку хочете.
- Щоб працювати повністю офлайн, встановіть **Lagune** у свій проєкт командою `npm i -D lagune@0.16.0`.

## Категорії

Знання **Lagune** з безпеки надходять у вигляді [**спеціалізацій**](https://lagune.ai/uk-UA/docs/catalog), згрупованих у [**категорії**](https://lagune.ai/uk-UA/docs/categories).

- **OWASP** (`owasp`): Захищає від ризиків безпеки застосунків, які відстежує OWASP: ін'єкцій, порушень контролю доступу, збоїв автентифікації й криптографії
- **Інфраструктура** (`infra`): Захищає конфігурацію контейнерів, робочих навантажень і serverless: Dockerfile, Compose, безпеку Pod, IAM і тригери FaaS
- **ШІ / LLM** (`ai`): Захищає інтеграції зі ШІ та LLM від prompt injection і небезпечного підключення інструментів, агентів, пошуку даних і MCP
- **Lovable** (`lovable`): Захищає згенеровані ШІ застосунки на Supabase (Lovable і подібні): прогалини в RLS, витоки ключів service_role і небезпечні налаштування за замовчуванням
- **JavaScript** (`javascript`): Захищає JavaScript і його середовища виконання від RCE через eval і child_process, path traversal і prototype pollution
- **Python** (`python`): Захищає Python від RCE через десеріалізацію pickle і YAML, обходу через форматні рядки str.format і class pollution
- **Rust** (`rust`): Захищає Rust від некоректних unsafe API, неправильного використання transmute, переповнення цілих чисел і невизначеної поведінки на межі FFI
- **Java** (`java`): Захищає Java від ланцюжків гаджетів при десеріалізації через ObjectInputStream, що закінчуються віддаленим виконанням коду
- **Ruby** (`ruby`): Захищає Ruby від ланцюжків гаджетів при десеріалізації через Marshal.load і YAML, що ведуть до віддаленого виконання коду
- **PHP** (`php`): Захищає PHP від обходу автентифікації через type juggling, ланцюжків гаджетів через object injection і небезпечних налаштувань конфігурації за замовчуванням
- **Go** (`go`): Захищає Go від помилок із typed nil в інтерфейсах, data races між горутинами й небезпечної конкурентності в критичних для безпеки ділянках коду
- **C / C++** (`c-cpp`): Захищає C і C++ від помилок форматних рядків, переповнень буфера й записів за межі пам'яті, що дають змогу виконати код
- **.NET** (`dotnet`): Захищає .NET і C# від RCE через десеріалізацію BinaryFormatter і від обходів кодувальників, що ведуть до XSS

Виконайте `npx lagune write add --categories` з ключами обраних категорій.

**Порада**

Проєкт починає з `owasp`, а [`/lagune-charter`](https://lagune.ai/uk-UA/docs/commands/charter) додає категорії, які підтверджує її аналіз проєкту.

## Вимоги

У вашій системі має бути встановлено [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager).

## Додайте бейдж ✨

Використовуєте **Lagune**? Додайте бейдж у свій **README**:

**Двоколірний**

![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)

```md
[![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai)
```

![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)

```md
[![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai)
```

![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)

```md
[![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai)
```

**Суцільний**

![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

## Далі

Дізнайтеся, що робить кожна з [**навичок**](https://lagune.ai/uk-UA/docs/get-started/commands) **Lagune**.

## Часті запитання

### Що таке Lagune?

Lagune є робочим процесом безпеки з відкритим кодом, суто оборонним, який допомагає вашому ШІ-агенту посилити захист будь-якої кодової бази. Ви спрямовуєте його на свій код, він визначає, що насправді робить ваша система, а потім спрямовує виправлення безпеки, важливі саме для цього контексту.

### Як встановити Lagune?

Оберіть свій агент: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI і Hermes Agent встановлюють Lagune як плагін, Gemini CLI і Qwen Code як розширення, Pi як пакет, а будь-який інший агент через npx skills add wellwelwel/lagune. Lagune працює як у нових, так і в наявних проєктах.

### Чи потрібен Lagune API-ключ?

Ні. Lagune працює через вашого власного ШІ-агента, тож API-ключі не потрібні.

### Які вимоги?

У вашій системі має бути встановлено Node.js (LTS).

### Які мови програмування підтримує Lagune?

Будь-які. Під капотом Lagune працює на Node.js, але перевіряє й посилює захист проєктів, написаних будь-якою мовою програмування.

### Що Lagune додає до мого проєкту?

Каталог .lagune/ зі станом безпеки вашого проєкту, який створює перша команда, що щось записує. CLI skills також встановлює slash-команди в проєкт, звідки їх читає ваш агент, а плагін тримає їх усередині агента.

### Як оновити Lagune?

Так само, як ви його встановили. Сторінка встановлення кожного агента показує, як оновити там Lagune, а CLI skills оновлює його командою npx skills update. Ваші принципи безпеки, артефакти фаз і власні спеціалізації залишаються недоторканими.

### Які спеціалізації використовує проєкт?

Вбудовані спеціалізації його категорій, а також власні. Фаза charter записує категорії, які підтверджує її аналіз проєкту, а npx lagune write add --categories їх змінює.

### Чи треба завершити розробку, перш ніж захищати проєкт?

Ні. Команда /lagune посилює захист роботи під час написання коду: вона приймає будь-який промпт, створює те, що ви попросили, і посилює захист безпечними налаштуваннями за замовчуванням, керуючись принципами безпеки. П'ятифазний процес Blue Team перевіряє те, що вже існує.

### Чи може Lagune перевірити наявний проєкт?

Так. П'ятифазний процес Blue Team перевіряє те, що вже існує: charter встановлює ваші правила безпеки, detect визначає, що робить система і де ризики, plan оцінює кожну знахідку й підбирає до неї виправлення, harden застосовує виправлення, а verify доводить, що вони діють, і закриває їх.

### Чим відрізняється використання Lagune від простого прохання до агента знайти вразливості й недоліки безпеки?

Агент, що читає код сам, знаходить те, що схоже на вразливість, і пропускає те, що схоже на засіб захисту. Список заблокованих адрес виглядає так, ніби хтось уже впорався з ризиком, тож ніхто не перевіряє, що він пропускає більшість із них, і код іде в реліз. Lagune перевертає це припущення: засіб захисту, що вже є в коді, вважається недоведеним, доки його не перевірено, кожна спеціалізація з каталогу отримує явний вердикт, а verify питає, чи зник ризик, а не чи є засіб захисту. Кожна знахідка також залишається одним відстежуваним елементом між запусками, тож можна довести, що її закрито, і зняти її з обліку, тоді як звичайне прохання щоразу дає інший звіт, який нема з чим порівняти.

### Чим відрізняється розробка з Lagune від простого прохання до агента писати безпечний код?

Прохання про безпечний код залишає визначення безпеки агенту й припускає, що ви знаєте, про що просити. Вимога зазвичай уже міститься у вашому запиті, хоч ні ви, ні агент її не бачите: прохання про сторінку з курсами, до яких користувач має доступ, задає правило авторизації, а перевірка, яку так і не написали, не залишає в коді нічого, що можна помітити. Команда /lagune завантажує ваші принципи безпеки й спеціалізації, що відповідають тому, що зараз створюватиметься, ще до першого рядка коду, а потім перечитує результат з огляду на захист, який використала. Безпечний варіант рідко коштує більше за небезпечний, тож результат визначає знання, який із них обрати, і саме це знання надходить заздалегідь.

### Чи виконує Lagune DAST (Dynamic Application Security Testing) або тестує мій запущений застосунок?

Ні. Lagune читає код і ніколи не запускає вашу систему й не надсилає їй підроблених запитів. Verify підтверджує, що засіб захисту наявний і коректний у вихідному коді, а це інше питання, ніж те, чи витримає він атаку на робочу систему, тож "cannot tell from the code" є законним вердиктом, а не тихим проходженням перевірки. DAST відповідає на питання про час виконання, а Lagune на питання про вихідний код, тож жоден не замінює іншого. Навіть необов'язкова команда prove дотримується цієї межі: її тести перевіряють безпечну поведінку, а не payload атаки.

### Чи замінює Lagune пентест (тест на проникнення)?

Ні, точно ні! Пентест є авторизованою роботою, у якій фахівець застосовує власне судження до вашої робочої системи, поєднує знахідки в ланцюжки й досліджує бізнес-логіку, яку не описує жодне правило для окремої поверхні. Знахідки з пентесту можуть увійти в процес Blue Team від Lagune через фазу detect як занепокоєння, тож те, про що звітує фахівець, буде сплановано, захищено й перевірено.

## Політика безпеки

Ознайомтеся з [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md).

## Ліцензія

**Lagune** поширюється за ліцензією [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE).

Copyright © 2026-дотепер [Weslley Araújo](https://github.com/wellwelwel) і [контриб'ютори](https://github.com/wellwelwel/lagune/graphs/contributors).

---

# Встановлення Lagune в Antigravity CLI як плагіна

> Встановіть Lagune в Antigravity CLI як плагін, підтримуйте його оновленим і заздалегідь дозвольте роботу його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/antigravity-cli
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/antigravity-cli
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity
```

## Оновлення

Щоб оновити **Lagune**, встановіть його знову:

```bash
agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity
```

## Команди

Вводьте команди з назвою плагіна, як-от `/lagune:lagune-charter` для `/lagune-charter`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. Команда, надіслана першим повідомленням сесії, виконується до того, як вони завантажаться, тож натомість використовує **npx**. Щоб дозволити інструменти й **npx** заздалегідь, додайте ці правила до `~/.gemini/antigravity-cli/settings.json`:

```json
{
  "permissions": {
    "allow": [
      "mcp(lagune_lagune/lagune_read)",
      "mcp(lagune_lagune/lagune_write)",
      "command(regex:npx --yes lagune@[0-9.]+)"
    ]
  }
}
```

## Часті запитання

### Як встановити Lagune в Antigravity CLI?

Виконайте agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity.

### Як оновити Lagune в Antigravity CLI?

Знову виконайте agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity.

### Як запускати команди Lagune в Antigravity CLI?

Вводьте їх з назвою плагіна, як-от /lagune:lagune-charter.

### Чи може Antigravity CLI запускати Lagune, не питаючи дозволу?

Так. Дозвольте mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) і command(regex:npx --yes lagune@[0-9.]+) у налаштуваннях Antigravity CLI. Правило для npx охоплює команду, надіслану першим повідомленням сесії.

---

# Встановлення Lagune у Claude Code як плагіна

> Встановіть Lagune у Claude Code як плагін у терміналі, розширенні чи десктопному застосунку, підтримуйте його оновленим і заздалегідь дозвольте роботу його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/claude-code
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/claude-code
Останнє оновлення: 2026-11-03

**Термінал**

Встановіть плагін із термінала:

```bash
claude plugin install lagune --marketplace wellwelwel/lagune
```

Або із сесії **Claude Code**:

```text
/plugin marketplace add wellwelwel/lagune
/plugin install lagune@lagune
```

**Розширення**

- Введіть `/plugin` і виберіть **Manage plugins**.
- Додайте `wellwelwel/lagune` на вкладці **Marketplaces**.
- Встановіть `lagune` на вкладці **Plugins**.

**Десктоп**

- Встановіть **Lagune** з термінала чи розширення, вибравши в розширенні **Install for you**.
- Почніть нову сесію в десктопному застосунку, який завантажує плагіни, встановлені вами для себе.

## Оновлення

**Термінал**

Щоб оновити **Lagune**, виконайте:

```bash
claude plugin marketplace update lagune
claude plugin update lagune@lagune
```

Щоб оновлення відбувалися автоматично, виберіть **Enable auto-update** для маркетплейсу `lagune` у `/plugin`.

**Розширення**

- Введіть `/plugin` і виберіть **Manage plugins**.
- Відкрийте вкладку **Marketplaces**.
- Натисніть значок оновлення біля `lagune`.

**Десктоп**

- Оновіть **Lagune** з термінала чи розширення.
- Почніть нову сесію в десктопному застосунку.

## Команди

Вводьте команди за назвою, як-от `/lagune-charter`, або з назвою плагіна, як-от `/lagune:lagune-charter`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. Щоб дозволити їх заздалегідь, додайте ці правила до `.claude/settings.json` для одного проєкту або до `~/.claude/settings.json` для всіх:

```json
{
  "permissions": {
    "allow": [
      "mcp__plugin_lagune_lagune__lagune_read",
      "mcp__plugin_lagune_lagune__lagune_write"
    ]
  }
}
```

Коли рушій працює через **npx**, як із **skills.sh**, дозвольте `Bash(npx --yes lagune@*)`. Якщо ввімкнено пісочницю, також додайте `registry.npmjs.org` до `sandbox.network.allowedDomains`.

## Часті запитання

### Як встановити Lagune у Claude Code?

Виконайте claude plugin install lagune --marketplace wellwelwel/lagune. У сесії чи розширенні додайте маркетплейс wellwelwel/lagune у менеджері плагінів і встановіть lagune. Десктопний застосунок завантажує його, щойно ви встановите його для себе в терміналі чи розширенні.

### Як оновити Lagune у Claude Code?

Виконайте claude plugin marketplace update lagune, а потім claude plugin update lagune@lagune, або виберіть Enable auto-update для маркетплейсу lagune у /plugin. У розширенні відкрийте Manage plugins через /plugin і натисніть значок оновлення біля маркетплейсу lagune. Десктопний застосунок завантажує оновлення в наступній сесії.

### Як запускати команди Lagune у Claude Code?

Вводьте їх за назвою, як-от /lagune-charter, або з назвою плагіна, як-от /lagune:lagune-charter.

### Чи може Claude Code запускати Lagune, не питаючи дозволу?

Так. Дозвольте mcp__plugin_lagune_lagune__lagune_read і mcp__plugin_lagune_lagune__lagune_write у налаштуваннях Claude Code, а також Bash(npx --yes lagune@*), коли рушій працює через npx.

---

# Встановлення Lagune в Codex CLI як плагіна

> Встановіть Lagune в Codex CLI як плагін, підтримуйте його оновленим і запускайте його рушій у пісочниці.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/codex
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/codex
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
codex plugin marketplace add wellwelwel/lagune
codex plugin add lagune@lagune
```

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
codex plugin marketplace upgrade lagune
```

## Команди

Введіть `$` і команду з назвою плагіна, а потім свої вхідні дані, як-от `$lagune:lagune-charter` для `/lagune-charter`. Якщо ввести `$`, з'явиться список команд, а вибір однієї з них вставляє її повну назву.

---

**Дозволи**

Пісочниця **Codex** не має доступу до мережі. Встановіть рушій у свій проєкт із власного термінала, один раз і після кожного оновлення:

```bash
npm i -D lagune@0.16.0
```

## Часті запитання

### Як встановити Lagune в Codex CLI?

Виконайте codex plugin marketplace add wellwelwel/lagune, а потім codex plugin add lagune@lagune.

### Як оновити Lagune в Codex CLI?

Виконайте codex plugin marketplace upgrade lagune.

### Як запускати команди Lagune в Codex CLI?

Введіть $ і команду з назвою плагіна, а потім свої вхідні дані, як-от $lagune:lagune-charter.

### Чи працює Lagune у пісочниці Codex?

Так, щойно ви встановите рушій у свій проєкт командою npm i -D lagune@0.16.0 із власного термінала, один раз і після кожного оновлення.

---

# Встановлення Lagune у Cursor як плагіна

> Встановіть Lagune у Cursor і Cursor CLI як плагін, підтримуйте його оновленим і заздалегідь дозвольте роботу його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/cursor
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/cursor
Останнє оновлення: 2026-11-03

**Cursor**

- Відкрийте **Customize**.
- Виберіть **From GitHub Repository** і введіть `https://github.com/wellwelwel/lagune`.
- Натисніть **Install** біля **Lagune** і виберіть область проєкту чи користувача.

**Cursor CLI**

- Додайте маркетплейс із термінала:

  ```bash
  agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor
  ```

- Введіть `/plugins` у сесії `agent`.
- Встановіть **Lagune**.

Якщо **Lagune** уже встановлено в **Claude Code**, **Cursor CLI** завантажує його звідти.

## Оновлення

**Cursor**

- Відкрийте **Customize**.
- Натисніть **Refresh** біля маркетплейсу `lagune`.

**Cursor CLI**

- Замініть маркетплейс із термінала:

  ```bash
  agent plugin marketplace remove lagune
  agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor
  ```

- Введіть `/plugins` у сесії `agent`.
- Знову встановіть **Lagune**.

## Команди

Вводьте команди за назвою, як-от `/lagune-charter`.

---

**Дозволи**

У **Cursor** команди запускають рушій через **npx**, що його режим Auto-review за замовчуванням дозволяє, не питаючи.

У **Cursor CLI** рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. Щоб дозволити їх заздалегідь, додайте ці правила до `.cursor/cli.json` для одного проєкту або до `~/.cursor/cli-config.json` для всіх:

```json
{
  "permissions": {
    "allow": [
      "Mcp(plugin-lagune-lagune:lagune_read)",
      "Mcp(plugin-lagune-lagune:lagune_write)"
    ]
  }
}
```

Коли рушій працює через **npx**, як із **skills.sh**, дозвольте `Shell(npx:--yes lagune@*)`.

## Часті запитання

### Як встановити Lagune у Cursor?

У Cursor відкрийте Customize, виберіть From GitHub Repository, введіть https://github.com/wellwelwel/lagune і встановіть Lagune. У Cursor CLI виконайте agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor, а потім встановіть Lagune через /plugins.

### Як оновити Lagune у Cursor?

У Cursor натисніть Refresh біля маркетплейсу lagune у Customize. У Cursor CLI видаліть маркетплейс lagune, додайте його знову, а потім знову встановіть Lagune через /plugins.

### Як запускати команди Lagune у Cursor?

Вводьте їх за назвою, як-от /lagune-charter.

### Чи може Cursor запускати Lagune, не питаючи дозволу?

Так. Режим Auto-review у Cursor за замовчуванням уже це дозволяє. У Cursor CLI дозвольте Mcp(plugin-lagune-lagune:lagune_read) і Mcp(plugin-lagune-lagune:lagune_write), а також Shell(npx:--yes lagune@*), коли рушій працює через npx.

---

# Встановлення Lagune в Devin CLI як плагіна

> Встановіть Lagune в Devin CLI як плагін і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/devin-cli
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/devin-cli
Останнє оновлення: 2026-11-03

Увійдіть у **Devin**, а потім встановіть плагін із термінала:

```bash
devin auth login
devin plugins install wellwelwel/lagune
```

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
devin plugins update lagune
```

## Команди

Вводьте команди з назвою плагіна, як-от `/lagune:lagune-charter` для `/lagune-charter`. Меню `/` також показує їх.

## Часті запитання

### Як встановити Lagune в Devin CLI?

Увійдіть за допомогою devin auth login, а потім виконайте devin plugins install wellwelwel/lagune.

### Як оновити Lagune в Devin CLI?

Виконайте devin plugins update lagune.

### Як запускати команди Lagune в Devin CLI?

Вводьте їх з назвою плагіна, як-от /lagune:lagune-charter. Меню / також показує їх.

---

# Встановлення Lagune у Factory Droid як плагіна

> Встановіть Lagune у Factory Droid як плагін, підтримуйте його оновленим і дозвольте інструменти його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/factory-droid
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/factory-droid
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
droid plugin marketplace add wellwelwel/lagune
droid plugin install lagune@lagune
```

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
droid plugin marketplace update lagune
droid plugin update lagune@lagune
```

## Команди

Вводьте команди за назвою, як-от `/lagune-charter`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. Коли **Factory Droid** запитає, виберіть завжди дозволяти кожен із них. Він запитає знову після синхронізації нового коміту маркетплейсу `lagune`, що може статися під час його запуску.

## Часті запитання

### Як встановити Lagune у Factory Droid?

Виконайте droid plugin marketplace add wellwelwel/lagune, а потім droid plugin install lagune@lagune.

### Як оновити Lagune у Factory Droid?

Виконайте droid plugin marketplace update lagune, а потім droid plugin update lagune@lagune.

### Як запускати команди Lagune у Factory Droid?

Вводьте їх за назвою, як-от /lagune-charter.

### Чи може Factory Droid запускати Lagune, не питаючи дозволу?

Так. Коли Factory Droid запитає, виберіть завжди дозволяти lagune_read і lagune_write. Він запитає знову після синхронізації нового коміту маркетплейсу lagune.

---

# Встановлення Lagune в Gemini CLI як розширення

> Встановіть Lagune в Gemini CLI як розширення, підтримуйте його оновленим і заздалегідь дозвольте роботу його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/gemini-cli
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/gemini-cli
Останнє оновлення: 2026-11-03

Встановіть розширення з термінала:

```bash
gemini extensions install https://github.com/wellwelwel/lagune
```

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
gemini extensions update lagune
```

Щоб оновлення відбувалися автоматично, встановіть його з `--auto-update`.

## Команди

Вводьте команди з назвою розширення, як-от `/lagune:lagune-charter` для `/lagune-charter`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. **Gemini CLI** запускає їх лише в довіреній папці. Щоб дозволити їх заздалегідь, збережіть це правило як `~/.gemini/policies/lagune.toml`:

```toml
[[rule]]
mcpName = "lagune"
toolName = ["lagune_read", "lagune_write"]
decision = "allow"
priority = 100
```

Коли рушій працює через **npx**, як із **skills.sh**, додайте до того самого файлу це правило:

```toml
[[rule]]
toolName = "run_shell_command"
commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s'
decision = "allow"
priority = 100
```

## Часті запитання

### Як встановити Lagune в Gemini CLI?

Виконайте gemini extensions install https://github.com/wellwelwel/lagune.

### Як оновити Lagune в Gemini CLI?

Виконайте gemini extensions update lagune або встановіть розширення з --auto-update.

### Як запускати команди Lagune в Gemini CLI?

Вводьте їх з назвою розширення, як-от /lagune:lagune-charter.

### Чи може Gemini CLI запускати Lagune, не питаючи дозволу?

Так. Додайте правило політики, що дозволяє інструменти lagune_read і lagune_write сервера lagune, а також правило для run_shell_command з npx --yes lagune@ і версією, коли рушій працює через npx.

---

# Встановлення Lagune у GitHub Copilot CLI як плагіна

> Встановіть Lagune у GitHub Copilot CLI як плагін і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/github-copilot-cli
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/github-copilot-cli
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
copilot plugin marketplace add wellwelwel/lagune
copilot plugin install lagune@lagune
```

У редакторі встановіть **Lagune** для **GitHub Copilot** через [**skills.sh**](https://lagune.ai/uk-UA/docs/install/universal).

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
copilot plugin marketplace update lagune
copilot plugin update lagune@lagune
```

## Команди

Вводьте команди за назвою, як-от `/lagune-charter`.

## Часті запитання

### Як встановити Lagune у GitHub Copilot CLI?

Виконайте copilot plugin marketplace add wellwelwel/lagune, а потім copilot plugin install lagune@lagune.

### Як оновити Lagune у GitHub Copilot CLI?

Виконайте copilot plugin marketplace update lagune, а потім copilot plugin update lagune@lagune.

### Як запускати команди Lagune у GitHub Copilot CLI?

Вводьте їх за назвою, як-от /lagune-charter.

### Чи можна використовувати Lagune з GitHub Copilot у VS Code?

Так. У VS Code чи іншому редакторі встановіть Lagune через skills.sh замість плагіна.

---

# Встановлення Lagune у Grok Build як плагіна

> Встановіть Lagune у Grok Build як плагін, підтримуйте його оновленим і заздалегідь дозвольте роботу його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/grok-build
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/grok-build
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
grok plugin install wellwelwel/lagune@plugin-grok --trust
```

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
grok plugin update lagune
```

## Команди

Вводьте команди за назвою, як-от `/lagune-charter`, або з назвою плагіна, як-от `/lagune:lagune-charter`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. Щоб дозволити їх заздалегідь, додайте ці правила до `~/.grok/config.toml`:

```toml
[permission]
allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"]
```

Коли рушій працює через **npx**, як із **skills.sh**, дозвольте `Bash(npx --yes lagune@*)`.

## Часті запитання

### Як встановити Lagune у Grok Build?

Виконайте grok plugin install wellwelwel/lagune@plugin-grok --trust.

### Як оновити Lagune у Grok Build?

Виконайте grok plugin update lagune.

### Як запускати команди Lagune у Grok Build?

Вводьте їх за назвою, як-от /lagune-charter, або з назвою плагіна, як-от /lagune:lagune-charter.

### Чи може Grok Build запускати Lagune, не питаючи дозволу?

Так. Дозвольте MCPTool(lagune__lagune_read) і MCPTool(lagune__lagune_write) у конфігурації Grok Build, а також Bash(npx --yes lagune@*), коли рушій працює через npx.

---

# Встановлення Lagune в Hermes Agent як плагіна

> Встановіть Lagune в Hermes Agent як плагін і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/hermes-agent
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/hermes-agent
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
hermes plugins install wellwelwel/lagune --enable
```

- Коли **Hermes Agent** попросить підтвердити плагін не з його каталогу, **підтвердьте**.
- Коли він запропонує встановити залежності **Node.js** з репозиторію, **відмовтеся**.

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
hermes plugins update lagune
```

## Команди

Вводьте команди з назвою плагіна, як-от `/lagune:lagune-charter` для `/lagune-charter` і `/lagune:lagune` для `/lagune`.

## Часті запитання

### Як встановити Lagune в Hermes Agent?

Виконайте hermes plugins install wellwelwel/lagune --enable. Підтвердьте плагін, коли попросять, і відмовтеся від встановлення залежностей Node.js з репозиторію.

### Як оновити Lagune в Hermes Agent?

Виконайте hermes plugins update lagune.

### Як запускати команди Lagune в Hermes Agent?

Вводьте їх з назвою плагіна, як-от /lagune:lagune-charter і /lagune:lagune.

---

# Встановлення Lagune у Kimi Code як плагіна

> Встановіть Lagune у Kimi Code як плагін і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/kimi-code
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/kimi-code
Останнє оновлення: 2026-11-03

Встановіть плагін із сесії **Kimi Code**, виберіть **Trust and install**, а потім почніть нову сесію, щоб завантажити його:

```text
/plugins install https://github.com/wellwelwel/lagune
/new
```

## Оновлення

Щоб оновити **Lagune**, встановіть його знову:

```text
/plugins install https://github.com/wellwelwel/lagune
/new
```

## Команди

Вводьте команди з назвою плагіна, як-от `/lagune:lagune-charter` для `/lagune-charter`. Меню `/` показує їх як `/skill:lagune:lagune-charter`, і така форма теж працює.

## Часті запитання

### Як встановити Lagune у Kimi Code?

У сесії Kimi Code виконайте /plugins install https://github.com/wellwelwel/lagune, виберіть Trust and install, а потім виконайте /new.

### Як оновити Lagune у Kimi Code?

Знову виконайте /plugins install https://github.com/wellwelwel/lagune, а потім /new.

### Як запускати команди Lagune у Kimi Code?

Вводьте їх з назвою плагіна, як-от /lagune:lagune-charter, або так, як їх показує меню /, як-от /skill:lagune:lagune-charter.

---

# Встановлення Lagune у Muse Code як плагіна

> Встановіть Lagune у Muse Code як плагін, підтримуйте його оновленим і запускайте його рушій у пісочниці.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/muse-code
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/muse-code
Останнє оновлення: 2026-11-03

Встановіть плагін із термінала:

```bash
muse plugins marketplace add lagune wellwelwel/lagune
muse plugins install lagune@lagune
```

## Оновлення

Щоб оновити **Lagune**, оновіть маркетплейс і перевстановіть плагін:

```bash
muse plugins marketplace update lagune
muse plugins remove lagune
muse plugins install lagune@lagune
```

## Команди

Вводьте команди за назвою, як-от `/lagune-charter`, або з назвою плагіна, як-от `/lagune:lagune-charter`.

---

**Дозволи**

Пісочниця **Muse Code** не може завантажити рушій. Встановіть його у свій проєкт із власного термінала, один раз і після кожного оновлення:

```bash
npm i -D lagune@0.16.0
```

## Часті запитання

### Як встановити Lagune у Muse Code?

Виконайте muse plugins marketplace add lagune wellwelwel/lagune, а потім muse plugins install lagune@lagune.

### Як оновити Lagune у Muse Code?

Виконайте muse plugins marketplace update lagune, а потім перевстановіть плагін командами muse plugins remove lagune і muse plugins install lagune@lagune.

### Як запускати команди Lagune у Muse Code?

Вводьте їх за назвою, як-от /lagune-charter, або з назвою плагіна, як-от /lagune:lagune-charter.

### Чи працює Lagune у пісочниці Muse Code?

Так, щойно ви встановите рушій у свій проєкт командою npm i -D lagune@0.16.0 із власного термінала, один раз і після кожного оновлення.

---

# Встановлення Lagune в OpenCode як плагіна

> Встановіть Lagune в OpenCode 1.x і 2.x як плагін і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/opencode
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/opencode
Останнє оновлення: 2026-11-03

**OpenCode 2.x**

Встановіть плагін із термінала:

```bash
opencode plugin add lagune
```

Або додайте його до списку `plugins` в `opencode.json`:

```json
{
  "plugins": ["lagune"]
}
```

**OpenCode 1.x**

Встановіть плагін у свій проєкт із термінала або додайте `-g`, щоб встановити його для всіх своїх проєктів:

```bash
opencode plugin lagune
```

Або додайте його до списку `plugin` в `opencode.json`:

```json
{
  "plugin": ["lagune"]
}
```

## Оновлення

**OpenCode 2.x**

Щоб оновити **Lagune**, виконайте:

```bash
opencode plugin update lagune
opencode reload
```

**OpenCode 1.x**

Щоб оновити **Lagune**, встановіть новий реліз поверх старого, додавши `-g`, якщо ви встановлювали його для всіх своїх проєктів:

```bash
opencode plugin lagune@0.16.0 --force
```

## Команди

**OpenCode 2.x**

Введіть `@` і виберіть команду, як-от `@lagune-charter`, а потім напишіть свої вхідні дані в тому самому повідомленні.

**OpenCode 1.x**

Вводьте команди за назвою, як-от `/lagune-charter`. Вони перелічені в `/skills`, а не в меню `/`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. **OpenCode** запускає їх, не питаючи.

## Часті запитання

### Як встановити Lagune в OpenCode?

В OpenCode 2.x виконайте opencode plugin add lagune. В OpenCode 1.x виконайте opencode plugin lagune, додавши -g, щоб встановити його для всіх своїх проєктів.

### Як оновити Lagune в OpenCode?

В OpenCode 2.x виконайте opencode plugin update lagune, а потім opencode reload. В OpenCode 1.x виконайте opencode plugin lagune@0.16.0 --force.

### Як запускати команди Lagune в OpenCode?

В OpenCode 2.x введіть @ і виберіть команду, як-от @lagune-charter, а потім напишіть свої вхідні дані в тому самому повідомленні. В OpenCode 1.x вводьте їх за назвою, як-от /lagune-charter, або знайдіть їх у /skills.

### Чи питає OpenCode дозволу, перш ніж запустити Lagune?

Ні. OpenCode запускає два інструменти рушія, lagune_read і lagune_write, не питаючи.

---

# Встановлення Lagune у Pi як пакета

> Встановіть Lagune у Pi як пакет з npm чи GitHub і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/pi
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/pi
Останнє оновлення: 2026-11-03

**npm**

Встановіть пакет із термінала:

```bash
pi install npm:lagune
```

**GitHub**

Встановіть останній коміт із **GitHub**, який запускає рушій через **npx**:

```bash
pi install git:github.com/wellwelwel/lagune
```

## Оновлення

**npm**

Щоб оновити **Lagune**, виконайте:

```bash
pi update npm:lagune
```

**GitHub**

Щоб оновити **Lagune**, виконайте:

```bash
pi update git:github.com/wellwelwel/lagune
```

`pi update --extensions` оновлює кожен встановлений вами пакет, а `pi update` сам по собі оновлює лише **Pi**.

## Команди

Вводьте команди з префіксом `skill:`, як-от `/skill:lagune-charter` для `/lagune-charter`.

## Часті запитання

### Як встановити Lagune у Pi?

Виконайте pi install npm:lagune або pi install git:github.com/wellwelwel/lagune, щоб отримати останній коміт із GitHub.

### Як оновити Lagune у Pi?

Виконайте pi update npm:lagune або pi update git:github.com/wellwelwel/lagune для встановлення з GitHub. pi update --extensions оновлює кожен встановлений вами пакет.

### Як запускати команди Lagune у Pi?

Вводьте їх з префіксом skill:, як-от /skill:lagune-charter.

---

# Встановлення Lagune у Qwen Code як розширення

> Встановіть Lagune у Qwen Code як розширення, підтримуйте його оновленим і заздалегідь дозвольте роботу його рушія.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/qwen-code
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/qwen-code
Останнє оновлення: 2026-11-03

Встановіть розширення з термінала:

```bash
qwen extensions install lagune
```

## Оновлення

Щоб оновити **Lagune**, виконайте:

```bash
qwen extensions update lagune
```

Щоб оновлення відбувалися автоматично, встановіть його з `--auto-update`.

## Команди

Вводьте команди з назвою розширення, як-от `/lagune:lagune-charter` для `/lagune-charter`.

---

**Дозволи**

Рушій працює через два інструменти: `lagune_read` лише читає ваш проєкт, а `lagune_write` лише записує в `.lagune/`. Щоб дозволити їх заздалегідь, додайте ці правила до `.qwen/settings.json` для одного проєкту або до `~/.qwen/settings.json` для всіх:

```json
{
  "permissions": {
    "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"]
  }
}
```

Коли рушій працює через **npx**, як із **skills.sh**, дозвольте `Shell(npx --yes lagune@*)`.

## Часті запитання

### Як встановити Lagune у Qwen Code?

Виконайте qwen extensions install lagune.

### Як оновити Lagune у Qwen Code?

Виконайте qwen extensions update lagune або встановіть розширення з --auto-update.

### Як запускати команди Lagune у Qwen Code?

Вводьте їх з назвою розширення, як-от /lagune:lagune-charter.

### Чи може Qwen Code запускати Lagune, не питаючи дозволу?

Так. Дозвольте mcp__lagune__lagune_read і mcp__lagune__lagune_write у налаштуваннях Qwen Code, а також Shell(npx --yes lagune@*), коли рушій працює через npx.

---

# Встановлення Lagune у будь-який агент через skills.sh

> Встановіть Lagune у будь-який ШІ-агент через CLI skills і підтримуйте його оновленим.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/install/universal
Мова: uk-UA
Оригінал: https://lagune.ai/docs/install/universal
Останнє оновлення: 2026-11-03

**Термінал**

Встановіть команди **Lagune** з термінала через [**skills.sh**](https://www.skills.sh/wellwelwel/lagune):

```bash
npx skills add wellwelwel/lagune
```

**Промпт**

Вставте цей промпт у свій агент:

```md
Виконай `npx --yes skills add wellwelwel/lagune` і просто зараз дотримуйся згенерованих інструкцій навички. Прочитай увесь її вивід, за потреби спершу перенаправивши його в тимчасовий файл. Розв'язуй відносні шляхи від каталогу допоміжних файлів, який вона надає.
```

## Оновлення

**Термінал**

Щоб оновити **Lagune**, виконайте:

```bash
npx skills update
```

**Промпт**

Щоб оновити **Lagune**, вставте цей промпт у свій агент:

```md
Виконай `npx --yes skills update -y` і прочитай увесь її вивід, за потреби спершу перенаправивши його в тимчасовий файл.
```

---

**Один спосіб на агента**

Встановлюйте **Lagune** або через **skills.sh**, або через його **плагін**, але ніколи обома способами.

**Дозволи**

Команди запускають рушій як `npx --yes lagune@0.16.0`, а [сторінка встановлення кожного агента](https://lagune.ai/uk-UA/docs) показує правило, що дозволяє його заздалегідь. У пісочниці без доступу до мережі встановіть рушій у свій проєкт із власного термінала, один раз і після кожного оновлення:

```bash
npm i -D lagune@0.16.0
```

## Часті запитання

### Як встановити Lagune у будь-який ШІ-агент?

Виконайте npx skills add wellwelwel/lagune у своєму проєкті або вставте промпт для встановлення у свій агент.

### Як оновити Lagune, встановлений через CLI skills?

Виконайте npx skills update або вставте промпт для оновлення у свій агент.

### Чи можна встановити Lagune і через CLI skills, і через плагін?

Ні. Якщо встановити обома способами, агент показує кожну команду двічі або використовує одну копію й приховує іншу.

---

# Навички безпеки для ШІ-агентів

> Навички, які ваш ШІ-агент отримує з Lagune: перевірка наявного проєкту або захист нової роботи під час розробки, і все це за принципами безпеки.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/get-started/commands
Мова: uk-UA
Оригінал: https://lagune.ai/docs/get-started/commands
Останнє оновлення: 2026-11-03

Щойно **Lagune** [встановлено](https://lagune.ai/uk-UA/docs), ваш **ШІ**-агент отримує набір навичок. Користуватися ними можна двома способами, і обидва підпорядковані **принципам безпеки**: захищати нову роботу під час розробки або проводити повний аудит проєкту.

**⌨️ Створення / розробка**

Не треба завершувати роботу, перш ніж її захищати. Використовуйте [**`/lagune`**](https://lagune.ai/uk-UA/docs/commands/lagune) для роботи, яку пишете **просто зараз**:

| Навичка                                       | Що вона робить для вас                                                               |
| --------------------------------------------- | ------------------------------------------------------------------------------------ |
| [**/lagune-charter**](https://lagune.ai/uk-UA/docs/commands/charter) | Встановлює правила безпеки вашого проєкту, основу, на яку спирається `/lagune`       |
| [**/lagune**](https://lagune.ai/uk-UA/docs/commands/lagune)          | Створює те, що ви просите, і посилює захист під час написання, за принципами безпеки |

**Використовуйте будь-коли**

[**`/lagune`**](https://lagune.ai/uk-UA/docs/commands/lagune) дотримується правил із ваших принципів безпеки щоразу, коли запускається. Вона приймає будь-який промпт, створює те, що ви попросили, і посилює захист безпечними налаштуваннями за замовчуванням одразу, а не пізніше.

---

#### Спеціальні навички

| Навичка                                             | Що вона робить                                                                       |
| --------------------------------------------------- | ------------------------------------------------------------------------------------ |
| [**/lagune-specialize**](https://lagune.ai/uk-UA/docs/commands/specialize) | Навчає **Lagune** нової спеціалізації з безпеки на основі статей, експлойтів або тем |

**🔬 Аудит: процес Blue Team**

Повний **процес Blue Team**: прочитати, що робить проєкт, визначити його ризики й закрити їх. Кожна фаза спирається на попередню, тож достатньо пройти список згори донизу:

| #   | Навичка                                       | Що вона робить для вас                                                                       |
| --- | --------------------------------------------- | -------------------------------------------------------------------------------------------- |
| 1   | [**/lagune-charter**](https://lagune.ai/uk-UA/docs/commands/charter) | Встановлює правила безпеки вашого проєкту, запропоновані для вас або сформовані з ваших слів |
| 2   | [**/lagune-detect**](https://lagune.ai/uk-UA/docs/commands/detect)   | Читає ваш код і визначає, що робить ваша система і де ризики                                 |
| 3   | [**/lagune-plan**](https://lagune.ai/uk-UA/docs/commands/plan)       | Перетворює те, що знайшла фаза detect, на план захисту з виправленням для кожної знахідки    |
| 4   | [**/lagune-harden**](https://lagune.ai/uk-UA/docs/commands/harden)   | Застосовує виправлення з плану до вашого коду, безпечно й по одному                          |
| 5   | [**/lagune-verify**](https://lagune.ai/uk-UA/docs/commands/verify)   | Доводить, що кожне застосоване виправлення діє, і закриває ті, що пройшли перевірку          |

---

#### Спеціальні навички

| Навичка                                             | Що вона робить                                                                                          |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| [**/lagune-specialize**](https://lagune.ai/uk-UA/docs/commands/specialize) | Навчає **Lagune** нової спеціалізації з безпеки на основі статей, експлойтів або тем                    |
| [**/lagune-prove**](https://lagune.ai/uk-UA/docs/commands/prove)           | Перетворює кожну виявлену знахідку на виконуване, суто оборонне доведення для відповідального розкриття |

---

#### Внутрішні навички

| Навичка                                     | Що вона робить                             |
| ------------------------------------------- | ------------------------------------------ |
| [**/lagune-repair**](https://lagune.ai/uk-UA/docs/commands/repair) | Відновлює внутрішнє відстеження **Lagune** |

**Порада**

Безпека не витрата, а інвестиція: те, що ви вкладаєте наперед, багаторазово окупається інцидентами, яких у вас так і не стається 🙋🏻‍♂️

## Часті запитання

### Які навички додає Lagune?

/lagune для посилення захисту роботи під час розробки і п'ятифазний процес аудиту Blue Team: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. А також /lagune-specialize і /lagune-prove.

### Що таке процес Blue Team у Lagune?

П'ятифазний аудит: charter (встановити правила), detect (визначити ризики), plan (оцінити й спланувати виправлення), harden (застосувати виправлення), verify (довести, що вони діють, і закрити їх).

### Чим відрізняється /lagune від процесу аудиту?

/lagune захищає нову роботу під час її написання, без жодного процесу, якого треба дотримуватися. Процес аудиту проходить п'ять фаз по черзі над наявним проєктом.

---

# Дашборд

> Переглядайте принципи безпеки, знахідки й каталог свого проєкту в локальному огляді наживо, що відкривається однією командою.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/get-started/dashboard
Мова: uk-UA
Оригінал: https://lagune.ai/docs/get-started/dashboard
Останнє оновлення: 2026-11-03

Запустіть **Lagune** напряму, без підкоманди, щоб отримати інтерактивний огляд `.lagune/` наживо. Він запускає дашборд і відкриває його на випадковому порту:

```bash
npx lagune
```

- [x] **Live Reload**
- [x] **Приватно** й **локально**
- [x] Показує все, що містить `.lagune/`, починаючи з перших принципів безпеки
- [x] **Керуйте** категоріями проєкту просто з браузера
- [x] Не потрібні ні `node_modules`, ні `package.json` 📦

![Принципи безпеки в дашборді Lagune](https://lagune.ai/img/dashboard/02.webp)

![Знахідки в дашборді Lagune](https://lagune.ai/img/dashboard/03.webp)

![Побічні завдання в дашборді Lagune](https://lagune.ai/img/dashboard/04.webp)

![Подробиці знахідки в дашборді Lagune](https://lagune.ai/img/dashboard/05.webp)

![Каталог у дашборді Lagune](https://lagune.ai/img/dashboard/06.webp)

**Порада**

- 🚪 Використовуйте `--port`, щоб вказати власний порт.
- ⏏️ Натисніть `Ctrl+C`, щоб зупинити.

## Часті запитання

### Як відкрити дашборд Lagune?

Виконайте npx lagune без підкоманди в корені проєкту. Він запускає огляд .lagune/ наживо на випадковому порту й відкриває його у вашому браузері.

### Чи дашборд приватний?

Так. Він працює лише на вашому комп'ютері, за локальною адресою, до якої не може дістатися жоден інший комп'ютер.

### Чи можна змінювати проєкт з дашборду?

Лише його категорії, з браузера. Усе інше, що показує дашборд, доступне лише для читання.

---

# /lagune: захищайте код, поки його пише ваш ШІ

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

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/lagune
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/lagune
Останнє оновлення: 2026-11-03

⌨️ Виконайте роботу, яку попросили, і захистіть її ще під час написання. **`/lagune`** приймає будь-який промпт на будь-якому етапі, створює те, що ви хотіли, і посилює захист безпечними налаштуваннями за замовчуванням, перш ніж повернути результат.

## Використання

Додайте **`/lagune`** до будь-якого промпту й опишіть роботу так, як завжди.

**📘 Інструкції для агентів**

```md
# Інструкції мого проєкту для агентів

<!-- ... -->

## Безпека

- Використовуй навичку `/lagune` щоразу, коли створюєш або змінюєш код, щоб вона підвищувала безпеку за замовчуванням.
```

    - Наприклад: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** тощо.

**💬 Функція**

```prompt
/lagune дай користувачам завантажувати власне фото в профіль.
```

**💬 Виправлення**

```prompt
/lagune коли користувач надсилає форму, нічого не відбувається. З'ясуй, у чому може бути причина, і виправ це.
```

**💬 Рефакторинг**

```prompt
/lagune розділи й покращ логіку обробки payload
```

**Charter необов'язкова, але з нею краще**

**`/lagune`** працює як з принципами безпеки, так і без них. Якщо вони є, кожну розробку формують власні правила вашого проєкту. Встановіть їх один раз за допомогою [`/lagune-charter`](https://lagune.ai/uk-UA/docs/commands/charter).

## Як це працює

Вона обгортає роботу в три кроки, нічого не записуючи в Lagune:

1. Завантажує ваші принципи безпеки, якщо вони є, і вони керують усією розробкою, а якщо їх ще немає, спирається на базовий рівень, безпечний за замовчуванням.
2. Переглядає [каталог](https://lagune.ai/uk-UA/docs/catalog) вашого проєкту й завантажує лише ті спеціалізації, яких торкається ваша робота, ті самі знання на вимогу, що їх використовує процес аудиту.
3. Застосовує захист під час написання коду, а потім перечитує власний результат, щоб підтвердити, що засоби захисту справді діють, перш ніж повернути роботу.

У результаті у вашому проєкті з'являється робочий код, безпечний з першого рядка.

**Використовуйте будь-коли**

Ні detect, ні plan, ні прибирання потім. **`/lagune`** однаково підходить і для нової заготовки, і для зміни у зрілій кодовій базі, і посилює захист роботи одразу, а не пізніше.

## Чого вона не робить

- Вона нічого не записує в каталог `.lagune`, ні артефактів, ні відстеження, тож єдине, що вона створює, це захищений код, про який ви просили.
- Вона не послаблює правило заради промпту: якщо те, про що ви попросили, порушило б принцип безпеки, вона зупиняється й спершу повідомляє вас, а не створює це одразу небезпечно.

## Часті запитання

### Що робить /lagune?

Вона приймає будь-який промпт на будь-якому етапі, створює те, що ви попросили, і посилює захист безпечними налаштуваннями за замовчуванням, перш ніж повернути результат. Захист застосовується під час написання коду, а не пізніше.

### Чи потрібні принципи безпеки, щоб користуватися /lagune?

Ні. Вона працює як з ними, так і без них. З принципами безпеки кожну розробку формують власні правила вашого проєкту. Без них вона спирається на базовий рівень, безпечний за замовчуванням.

### Чим відрізняється /lagune від процесу Blue Team?

/lagune захищає нову роботу під час її написання, без жодного процесу, якого треба дотримуватися. Процес Blue Team проходить п'ять фаз аудиту по черзі над наявним проєктом.

### Чи відстежує /lagune знахідки або записує артефакти?

Ні. Вона нічого не записує в каталог .lagune, ні артефактів, ні відстеження. Єдине, що вона створює, це захищений код, про який ви просили.

### Як змусити агента автоматично використовувати /lagune?

Додайте до файлу інструкцій агента (AGENTS.md, CLAUDE.md, .cursorrules тощо) вказівку використовувати навичку /lagune щоразу, коли він створює або змінює код.

---

# /lagune-charter: встановіть принципи безпеки

> Встановіть принципи безпеки свого проєкту, правила, яких дотримується кожна наступна фаза, і запишіть категорії спеціалізацій, які підтверджує аналіз проєкту.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/charter
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/charter
Останнє оновлення: 2026-11-03

🧬 Розкажіть **Lagune**, що являє собою ваш проєкт, і він перетворить це на ваші правила безпеки (а без опису виведе їх лише з самого проєкту).

Charter є керівним рівнем: набором принципів, що ставлять безпеку на перше місце і яких має дотримуватися кожна наступна фаза. Сприймайте її як перевірку під час компіляції для рівня захищеності вашого проєкту.

## Використання

**Описати**

```prompt
/lagune-charter Мій проєкт є інтернет-магазином, що продає відеоігри. Клієнти додають товари в кошик і платять кредитною карткою або банківським рахунком-фактурою. Вони бачать свої замовлення та статус кожного з них.
```

**Хай запропонує Lagune**

```prompt
/lagune-charter
```

> _Бачу платіжну бібліотеку, налаштування входу й модель замовлення, прив'язану до клієнта. Схоже на інтернет-магазин, який щось продає. Клієнти платять і відстежують власні замовлення..._ ☁️

## Що він визначає

**Lagune** бере ваш опис або **PRD** як напрям і визначає, що з нього випливає для безпеки, а потім читає проєкт, щоб піти далі за те, що ви назвали. Наприклад:

- Кошик, що зберігає замовлення, означає, що є **база даних**:
  - наприклад, `"Де зберігаються дані?"`, `"Хто має до них доступ?"`, `"Чи вони витікають?"`.
- Клієнти, які бачать власні замовлення, означають, що є якийсь **вхід або контроль доступу**:
  - наприклад, `"Чи може один клієнт дістатися до чужих замовлень?"`, `"Чи захищені сесії?"`.
- Прийом оплати карткою й банківським рахунком означає, що **задіяні гроші й чутливі дані**:
  - наприклад, `"Чи зберігаються дані карток?"`, `"Чи перевіряються платежі?"`.

Ваш опис і проєкт доповнюють одне одного: опис задає намір, а читання залежностей, README і конфігурації виявляє те, про що ви не згадали. Якщо щось важливе все ще незрозуміле, **Lagune** ставить коротке й просте запитання, а не вгадує.

Далі **Lagune** складає для проєкту набір правил безпеки, які ви можете переглянути й підлаштувати будь-коли.

**Як отримати максимум**

- Ви також можете визначити власні правила безпеки для проєкту.
- Що більше доречних подробиць ви надасте, то кращим буде підсумковий звіт:
  - Поясніть, що за проєкт, як він працює і що відбувається під капотом.
  - Хто кінцевий користувач? Що користувачі можуть робити, а чого ні?
  - Подробиці про поведінку так само цінні, як і технічні.
- Пам'ять принципів безпеки зберігається в `.lagune/memory/charter.md`.

## Які категорії вона записує

Спеціалізації, тобто знання з безпеки, які наступні фази завантажують на вимогу, потрапляють до [каталогу](https://lagune.ai/uk-UA/docs/catalog) вашого проєкту за [категоріями](https://lagune.ai/uk-UA/docs/categories). Поки в проєкті не записано жодної категорії, charter записує кожну, яку підтверджує її аналіз, як-от мову проєкту, виклики LLM чи контейнери, і називає їх у підсумку.

Коли категорії вже записано, charter залишає їх як є і лише називає категорію, якої ваш проєкт ще не використовує. Змінюйте їх самі будь-коли:

```bash
npx lagune write add --categories python
npx lagune write remove --categories python
```

## Далі

Коли правила встановлено, визначте, що насправді робить ваша система: [`/lagune-detect`](https://lagune.ai/uk-UA/docs/commands/detect).

## Часті запитання

### Що таке charter у Lagune?

Charter є керівним рівнем Lagune, набором принципів, що ставлять безпеку на перше місце і яких має дотримуватися кожна наступна фаза. Сприймайте її як перевірку під час компіляції для рівня захищеності вашого проєкту.

### Де зберігаються принципи безпеки?

У .lagune/memory/charter.md.

### Чи можна написати власні правила для charter?

Так. Lagune пропонує правила на основі вашого опису й коду, а ви можете переформулювати, прибрати, додати їх або звузити їхній обсяг.

### Чи обирає charter категорії спеціалізацій за мене?

Лише поки жодної не записано. Тоді вона записує кожну категорію, яку підтверджує її аналіз, як-от вашу мову чи виклики LLM. Коли категорії вже записано, вона їх ніколи не змінює.

---

# /lagune-detect: визначте, що робить ваша система і де ризики

> Прочитайте свій код і визначте, що робить ваша система і де ризики.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/detect
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/detect
Останнє оновлення: 2026-11-03

🔬 З'ясуйте, що насправді робить ваша система і де ризики.

Detect читає код і записує лише те, що справді знаходить, разом із доказами, потрібними наступним фазам. Її головне правило: виявляти, а не вигадувати.

## Використання

**Повна перевірка**

```prompt
/lagune-detect
```

**Вказати шляхи**

```prompt
/lagune-detect src/routes/ src/auth.ts
```

**Описати занепокоєння**

```prompt
/lagune-detect переконайся, що дані клієнтів ніколи не розкриваються
```

## Що вона визначає

**Lagune** читає код і фіксує те, що знаходить. Кожна знахідка містить, що це, чому це важливо, і доказ. Наприклад:

- **Завантаження файлів**, система приймає файли від користувачів:
  - _Чому це важливо:_ файл, замаскований під зображення, може приховувати шкідливий код.
  - _Доказ:_ обробник `POST /upload` довіряє MIME-типу, який надсилає клієнт, не перевіряючи справжній тип файлу.
- **Вхід і сесії**, користувачі входять, щоб дістатися до свого облікового запису:
  - _Чому це важливо:_ слабке керування сесіями дає змогу захопити один обліковий запис з іншого.
  - _Доказ:_ логіка видачі сесій, де сесії видаються без терміну дії.

Попутно detect виносить вердикт щодо коду для кожної спеціалізації з [каталогу](https://lagune.ai/uk-UA/docs/catalog) вашого проєкту, застосовує ті, чий контекст присутній, і записує їх у розділі **Applied specializations**, у списку, який повторно використовують harden і verify.

У результаті ви маєте чітку карту того, що робить ваша система і де ризики, готову до наступних кроків.

**Порада**

- Повторний запуск оновлює карту: розв'язані знахідки зникають, нові з'являються.
- Карта виявлення зберігається в `.lagune/memory/detect.md`.

## Далі

Перетворіть карту на план: [`/lagune-plan`](https://lagune.ai/uk-UA/docs/commands/plan).

## Часті запитання

### Що робить /lagune-detect?

Вона читає ваш код і визначає, що робить ваша система і де ризики, записуючи лише те, що справді знаходить. Її правило: виявляти, а не вигадувати.

### Що таке знахідка в Lagune?

Знахідка є одним виявленим ризиком, що містить, що це, чому це важливо, і доказ у коді. Це відстежувана одиниця, яку plan, harden і verify передають далі.

### Де зберігається карта виявлення?

У .lagune/memory/detect.md.

### Які спеціалізації використовує detect?

Кожна спеціалізація з каталогу вашого проєкту отримує вердикт щодо коду. Detect застосовує ті, чий контекст присутній, і записує їх у розділі Applied specializations.

---

# /lagune-plan: оцініть знахідки й сплануйте виправлення

> Перетворіть те, що знайшла фаза detect, на план захисту, оцінивши кожну знахідку за категорією й оцінкою CVSS v4.0 і підібравши до неї виправлення.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/plan
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/plan
Останнє оновлення: 2026-11-03

🛡️ Перетворіть те, що знайшла фаза detect, на план захисту: оцініть кожну знахідку за категорією й оцінкою CVSS v4.0, а потім підберіть до неї виправлення.

## Використання

**Спланувати все**

```prompt
/lagune-plan
```

**Вказати шляхи**

```prompt
/lagune-plan src/routes/upload.ts
```

**Зосередитися на побоюванні**

```prompt
/lagune-plan де можуть витекти чутливі дані
```

## Як це працює

Ця фаза продовжує detect. Detect уже з'ясувала, що робить ваша система і який ризик несе кожна її частина, тож план не повторює ризик, а оцінює, наскільки він серйозний, і вирішує, що з ним робити. Plan ніколи не читає код, тож кожне виправлення мусить вказувати на те, що detect справді виявила. Вона оцінює кожну знахідку методом CVSS v4.0: категорія, вектор CVSS v4.0, виведений з того, що зафіксували detect і charter, і обчислений [хуком `cvss`](https://lagune.ai/uk-UA/docs/hooks/cvss), а також рівень пріоритету, на який припадає ця оцінка. Кожне виправлення також містить принцип безпеки, який воно підтримує.

Наприклад:

- **Завантаження файлів** (Пріоритет: **Critical**)
  - _Категорія:_ необмежене завантаження файлів (CWE-434).
  - _CVSS:_ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3, Critical).
  - _Чому такий пріоритет:_ будь-хто може дістатися до завантаження через інтернет, і воно працює на сервері, що зберігає файли клієнтів.
  - _Підтримує:_ III. Усі вхідні дані недовірені, доки їх не перевірено.
  - _Виправлення:_ перевіряти справжній тип і розмір файлу, перейменовувати його під час збереження й зберігати завантаження там, де їх неможливо виконати як код.

У результаті ви маєте оцінений і впорядкований за пріоритетом список виправлень, кожне з яких прив'язане до знахідки й готове до застосування в наступній фазі. Оцінку обчислюють, а не прикидають: вектор передає відкритість і значущість проєкту як метрики Environmental, і будь-хто може вставити його в калькулятор FIRST або NVD і отримати ту саму оцінку.

**Порада**

- Фаза повністю спирається на detect. Якщо файл чи побоювання ще не досліджено, вона попросить спершу виконати для нього `/lagune-detect`.
- Повторний запуск оновлює план: виконані виправлення зникають, нові з'являються.
- План захисту зберігається в `.lagune/memory/plan.md`.

**Залежить від detect**

Plan працює лише з тим, що вже визначила [`/lagune-detect`](https://lagune.ai/uk-UA/docs/commands/detect), тож спершу виконайте detect.

## Далі

Застосуйте план: [`/lagune-harden`](https://lagune.ai/uk-UA/docs/commands/harden).

## Часті запитання

### Як Lagune визначає пріоритет вразливостей?

/lagune-plan оцінює кожну знахідку за категорією й оцінкою CVSS v4.0, яку обчислює хук cvss, а потім підбирає до неї виправлення.

### Чи використовує Lagune CVSS v4.0?

Так. Кожна знахідка отримує вектор і оцінку CVSS v4.0, які обчислює хук cvss за тією самою арифметикою, що й калькулятор FIRST, тож будь-хто може вставити туди вектор і отримати ту саму оцінку.

### Чи план читає мій код?

Ні. Plan ніколи не читає код, тож кожне виправлення мусить вказувати на те, що detect справді виявила.

---

# /lagune-harden: застосуйте виправлення безпеки до свого коду

> Застосуйте виправлення з плану до свого коду, безпечно й по одному.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/harden
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/harden
Останнє оновлення: 2026-11-03

🔧 Застосуйте виправлення з плану до свого коду, безпечно й по одному.

## Використання

**Застосувати все**

```prompt
/lagune-harden
```

**Вказати шляхи**

```prompt
/lagune-harden src/routes/upload.ts
```

**За пріоритетом**

```prompt
/lagune-harden Critical і High
```

## Як це працює

План уже визначив кожне виправлення, тож harden просто застосовує його. Оскільки це єдина фаза, що торкається вашого коду, вона діє обережно: застосовує по одному виправленню, щоб кожну зміну було легко переглянути, і ніколи не послаблює засіб захисту, щоб припасувати виправлення. Наприклад, виправлення для завантаження:

- **Завантаження файлів** (Статус: **Applied**)
  - _Що змінилося:_ перевіряє справжній тип і розмір файлу, відхиляє все неочікуване, перейменовує файл під час збереження й зберігає його там, де його неможливо виконати як код.
  - _Де:_ функція `handleUpload`, а також допоміжна функція сховища, яку вона викликає.

Якщо виправлення неможливо застосувати повністю, harden робить те, що може безпечно, а решту позначає як **Partial** або **Blocked**, залишаючи її відкритою.

**Applied не означає перевірене**

Applied ще не означає доведене. Для цього існує [verify](https://lagune.ai/uk-UA/docs/commands/verify).

**Порада**

- Фаза повністю спирається на план. Якщо виправлення чи файл ще не сплановано, вона попросить спершу виконати для нього `/lagune-plan`.
- Повторний запуск узгоджує журнал: скасовані зміни зникають, нові застосовані виправлення з'являються.
- Журнал посилення захисту зберігається в `.lagune/memory/harden.md`.

**Залежить від plan і змінює ваш код**

Harden спирається на [`/lagune-plan`](https://lagune.ai/uk-UA/docs/commands/plan). Це єдина фаза, що змінює ваш код.

## Далі

Доведіть, що кожне виправлення діє: [`/lagune-verify`](https://lagune.ai/uk-UA/docs/commands/verify).

## Часті запитання

### Чи змінює /lagune-harden мій код?

Так. Це єдина фаза, що торкається вашого коду, застосовуючи виправлення з плану по одному.

### Що означають Applied, Partial і Blocked?

Це статус, який Lagune записує для кожного виправлення. Applied означає, що виправлення внесено, Partial, що внесено лише його частину, Blocked, що його неможливо було застосувати. Applied ще не означає доведене.

### Чи застосовує Lagune виправлення, не питаючи?

Чи потребує правка вашого схвалення, вирішують ваш агент і режим дозволів, у якому ви його запускаєте, а не Lagune, який не додає власного кроку підтвердження. Проте він ніколи не послаблює засіб захисту заради виправлення, а якщо виправлення суперечило б правилу з принципів безпеки, він зупиняється й спершу повідомляє вас.

---

# /lagune-verify: доведіть, що засоби захисту діють

> Доведіть, що кожне застосоване виправлення діє, а потім закрийте ті, що пройшли перевірку.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/verify
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/verify
Останнє оновлення: 2026-11-03

⚖️ Доведіть, що кожне застосоване виправлення діє, прочитавши код і зіставивши його з тим, що записала harden, а потім закрийте ті, що пройшли перевірку.

## Використання

**Перевірити все**

```prompt
/lagune-verify
```

**Вказати шляхи**

```prompt
/lagune-verify src/routes/upload.ts
```

**За пріоритетом**

```prompt
/lagune-verify Critical і High
```

## Як це працює

Фаза читає код у кожному місці, яке записала harden, і підтверджує, що він справді відповідає заявленому. Доведенням є саме це зіставлення коду з журналом. Кожен засіб захисту отримує один із трьох вердиктів:

| Вердикт                      | Значення                                                     |
| ---------------------------- | ------------------------------------------------------------ |
| ✅ Risk closed               | Код робить саме те, що заявлено в журналі.                   |
| ❌ Risk not closed           | Засіб захисту досі відкритий. Verify повертає вас до harden. |
| ❓ Cannot tell from the code | Доказ неможливо побачити лише з коду.                        |

Ризик, закриття якого доведено, потім знімається з обліку в ланцюжку за вашим підтвердженням. Наприклад:

- **Завантаження файлів** (Вердикт: **✅ Risk closed**)
  - _Як доведено:_ прочитано обробник завантаження й підтверджено, що він визначає справжній тип файлу за вмістом, обмежує розмір і відхиляє все інше, саме як заявлено в журналі.
  - _Доказ:_ функція `handleUpload`, яка визначає справжній тип файлу за вмістом.

Якщо ризик не закрито, verify прямо про це каже й повертає вас до [`/lagune-harden`](https://lagune.ai/uk-UA/docs/commands/harden), бо виправлення досі відкрите.

**Порада**

- Фаза повністю спирається на журнал посилення захисту.
- Вона лише читає ваш код, щоб оцінити його, і ніколи не послаблює засіб захисту й не переписує код, щоб вердикт пройшов.
- Повторний запуск узгоджує вердикти: застарілі зникають, а ризик, який більше не закрито, знову позначається.
- Коли закриття ризику доведено, вона один раз питає, а потім прибирає цю знахідку з усього ланцюжка (detect, plan, harden і відстеження).
- Вона не пише власного звіту: кожен вердикт зберігається в блоці свого засобу захисту в `.lagune/memory/harden.md`, де harden прочитає його під час наступного запуску.

**Залежить від harden**

Verify спирається на [`/lagune-harden`](https://lagune.ai/uk-UA/docs/commands/harden).

## Цикл закривається

Коли все в межах обсягу знято з обліку, цикл переходить у стан спокою. Він відкривається знову, лише коли змінюється код. Безпеку можна закрити, тож процес має кінцевий стан, а не нескінченний цикл.

## Часті запитання

### Як Lagune перевіряє виправлення?

/lagune-verify читає код і зіставляє його з тим, що записала harden, повертаючи один із трьох вердиктів: Risk closed, Risk not closed або Cannot tell from the code.

### Що означає зняти з обліку?

Коли verify доводить, що ризик закрито, знахідку знімають з обліку: прибирають з усього ланцюжка за вашим підтвердженням, щоб її більше не обробляли повторно.

### Чи можна колись завершити роботу з безпеки?

Так. У SDH безпеку можна закрити: знахідку, закриття якої доведено, знімають з обліку, тож процес має кінцевий стан, а не нескінченний цикл.

---

# Категорії

> Категорії спеціалізацій, які може використовувати проєкт Lagune, від OWASP до захисту окремих мов, як-от JavaScript, Python, Go і Rust, і як їх змінювати.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/categories
Мова: uk-UA
Оригінал: https://lagune.ai/docs/categories
Останнє оновлення: 2026-11-03

**Lagune** групує свої вбудовані [**спеціалізації**](https://lagune.ai/uk-UA/docs/catalog) у **категорії (13)**. Категорії, які використовує проєкт, визначають, які вбудовані спеціалізації потрапляють до його [**каталогу**](https://lagune.ai/uk-UA/docs/catalog), і поділяються на дві групи: що робить система і якою мовою вона написана.

Поки не записано жодної категорії, проєкт використовує лише `owasp`. [`/lagune-charter`](https://lagune.ai/uk-UA/docs/commands/charter) записує кожну категорію, яку підтверджує її аналіз проєкту, а ви можете змінювати їх самі будь-коли.

## Що робить система

| Категорія      | Ключ      | Що захищає                                                                                                                                          |
| -------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| OWASP          | `owasp`   | Ризики безпеки застосунків, які відстежує OWASP: ін'єкції, порушення контролю доступу, збої автентифікації й криптографії                           |
| Інфраструктура | `infra`   | Конфігурацію контейнерів, робочих навантажень і serverless: Dockerfile, Compose, безпеку Pod, IAM і тригери FaaS                                    |
| ШІ / LLM       | `ai`      | Інтеграції зі ШІ та LLM від prompt injection і небезпечного підключення інструментів, агентів, пошуку даних і MCP                                   |
| Lovable        | `lovable` | Згенеровані ШІ застосунки на Supabase (Lovable і подібні): прогалини в RLS, витоки ключів `service_role` і небезпечні налаштування за замовчуванням |

## Якою мовою вона написана

| Категорія  | Ключ         | Що захищає                                                                                                                                 |
| ---------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
| JavaScript | `javascript` | RCE через `eval` і `child_process`, path traversal і prototype pollution у всіх середовищах виконання                                      |
| Python     | `python`     | RCE через десеріалізацію `pickle` і YAML, обхід через форматні рядки `str.format` і class pollution                                        |
| Rust       | `rust`       | Некоректні `unsafe` API, неправильне використання `transmute`, переповнення цілих чисел і невизначену поведінку на межі FFI                |
| C / C++    | `c-cpp`      | Помилки форматних рядків, переповнення буфера й записи за межі пам'яті, що дають змогу виконати код                                        |
| PHP        | `php`        | Обхід автентифікації через type juggling, ланцюжки гаджетів через object injection і небезпечні налаштування конфігурації за замовчуванням |
| Go         | `go`         | Помилки з typed nil в інтерфейсах, data races між горутинами й небезпечну конкурентність у критичних для безпеки ділянках                  |
| Java       | `java`       | Ланцюжки гаджетів при десеріалізації через `ObjectInputStream`, що закінчуються віддаленим виконанням коду                                 |
| Ruby       | `ruby`       | Ланцюжки гаджетів при десеріалізації через `Marshal.load` і YAML, що ведуть до віддаленого виконання коду                                  |
| .NET / C#  | `dotnet`     | RCE через десеріалізацію `BinaryFormatter` і обходи кодувальників, що ведуть до XSS                                                        |

**Порада**

**Lagune** не залежить від мови програмування: увесь процес читає проєкт, хоч би якою мовою його написано, а ці категорії лише додають глибини щодо пасток, специфічних для однієї мови.

## Додавайте й прибирайте будь-коли

Категорія є відправною точкою, а не зобов'язанням. Використовуйте те, що підходить проєкту зараз, і змінюйте будь-коли за ключем через `write add` і `write remove`. `--categories` без значення відкриває в терміналі інтерактивний вибір (пробіл, щоб перемкнути, enter, щоб підтвердити, порожньо, щоб пропустити). Поза терміналом передайте категорії після нього.

**Додати**

```bash
npx lagune write add --categories # interactive
npx lagune write add --categories owasp
npx lagune write add --categories owasp rust
```

**Прибрати**

```bash
npx lagune write remove --categories # interactive
npx lagune write remove --categories owasp
npx lagune write remove --categories owasp rust
```

Перший `write add` чи `write remove` починає з `owasp`, тож якщо прибрати всі категорії, залишиться порожній список, а не значення за замовчуванням. Кожна зміна потрапляє в `.lagune/configs.json`, тож уся команда працює з тим самим набором.

## Що використовує проєкт

`read list --categories` показує кожну категорію і те, чи використовує її проєкт:

```bash
npx lagune read list --categories
# Categories
#   • owasp       [used]       Harden against the application security risks OWASP tracks
#   • javascript  [available]  Harden JavaScript and its runtimes
#   • php         [available]  Harden PHP against type-juggling auth bypass
#   • go          [available]  Harden Go against typed-nil interface bugs
#   ...
#
# No category is recorded yet, so this project uses the default: owasp.
```

Які спеціалізації містить кожна категорія, дивіться в [**Каталозі**](https://lagune.ai/uk-UA/docs/catalog). Ваші власні спеціалізації, написані через [`/lagune-specialize`](https://lagune.ai/uk-UA/docs/commands/specialize), потрапляють до каталогу незалежно від категорій.

## Часті запитання

### Як додати категорію?

Передайте ключ категорії в --categories, наприклад npx lagune write add --categories javascript. Поки не записано жодної категорії, charter також записує ті, які підтверджує її аналіз проєкту.

### Чи можна використовувати більше однієї категорії?

Так. Перелічіть їх в одному рядку, одну за одною.

### Яку категорію використовувати проєкту?

Почніть з owasp, значення за замовчуванням, а потім додайте категорію для своєї мови чи стеку. Спеціалізації завантажуються лише на вимогу, тож категорія нічого не коштує, доки фазі не знадобиться одна з її спеціалізацій.

---

# Каталог: спеціалізації з безпеки на вимогу

> Як завантажуються спеціалізації з каталогу вашого проєкту, фазою на вимогу і вами напряму.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/catalog
Мова: uk-UA
Оригінал: https://lagune.ai/docs/catalog
Останнє оновлення: 2026-11-03

🧠 Спеціалізації **Lagune** є цільовими модулями знань з безпеки, незалежними від мови програмування, які завантажуються лише на вимогу, а не за замовчуванням. Це не команди. Каталог вашого проєкту є набором, який він використовує: вбудовані спеціалізації його [категорій](https://lagune.ai/uk-UA/docs/categories) плюс власні. Фази detect і verify звертаються до них під час роботи, а ви можете завантажити будь-яку напряму будь-коли.

**Огляд**

*Інтерактивний огляд каталогу є на вебсторінці. Усі вбудовані спеціалізації наведено в таблиці нижче.*

**Як це працює**

## Запуск власноруч

Щоб скористатися спеціалізацією напряму, попросіть агента завантажити її через `read catalog <name>` і напишіть завдання в тому самому промпті. Тоді знання діють на те, про що ви попросили. Це працює в будь-якому промпті, навіть не пов'язаному з процесом **Lagune**.

Наприклад, прямий довільний промпт, щоб згенерувати безпечний набір **RegExp** на **Python**:

```prompt
Завантаж спеціалізацію regex через `npx lagune read catalog regex`, а потім створи в @src/utils/regex.py набір регулярних виразів для перевірки email-адрес та імен користувачів.
```

Тут детермінований хук перевіряє кожен **RegExp** на **ReDoS**, залишає безпечні й видає щось на кшталт:

```python
import re

EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")
USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$")

def is_email(value: str) -> bool:
    return EMAIL.match(value) is not None

def is_username(value: str) -> bool:
    return USERNAME.match(value) is not None
```

**Спробуйте перевірку ReDoS**

Перевірте шаблон самі на [**devina.io/redos-checker**](https://devina.io/redos-checker).

## Вбудовані спеціалізації

Вбудовані спеціалізації згруповано в [**категорії**](https://lagune.ai/uk-UA/docs/categories). Ось набір, що постачається з **Lagune**:

| Спеціалізація         | Категорія                   | Фокус                                                                                                 |
| --------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------- |
| `regex`               | `owasp`                     | **ReDoS:** шаблони, що вибухають на підроблених вхідних даних.                                        |
| `network`             | `owasp`                     | **SSRF і перенаправлення:** адреси запитів чи перенаправлень, задані користувачем.                    |
| `interpreter`         | `owasp`, `lovable`          | **Ін'єкція коду:** `eval`, динамічне підключення, виклик за назвою.                                   |
| `sql`                 | `owasp`                     | **Реляційні бази даних:** ін'єкції, сирі виклики ORM, привілеї, досяжність рушія БД.                  |
| `path`                | `owasp`                     | **Шляхи файлової системи:** traversal, null-байт, потоки NTFS, підкидання файлів.                     |
| `upload`              | `owasp`                     | **Завантаження файлів:** тип і сигнатура, шкідливий вміст, зберігання, обмеження.                     |
| `access-control`      | `owasp`, `lovable`          | **Автентифікація, авторизація, сесії:** IDOR, mass assignment, тенанти, сесії.                        |
| `credential-endpoint` | `owasp`, `lovable`          | **Підбір і боти:** brute force, password spraying, credential stuffing, обмеження частоти.            |
| `federation`          | `owasp`                     | **Довіра до токенів:** OAuth/OIDC, SAML, перевірка JWT, вхід через QR-код.                            |
| `http-request`        | `owasp`                     | **Походження запитів:** CSRF, помилки конфігурації CORS, підроблена IP-адреса клієнта.                |
| `transport`           | `owasp`                     | **Безпека каналу:** конфігурація TLS, HTTPS проти відкритого тексту, HSTS, pinning.                   |
| `crypto`              | `owasp`, `lovable`          | **Криптографія для даних у спокої:** слабкі чи саморобні алгоритми, CSPRNG, керування ключами.        |
| `secrets`             | `owasp`, `lovable`          | **Жорстко закодовані облікові дані:** ключі, токени, паролі як літерали у вихідному коді.             |
| `api-endpoint`        | `owasp`                     | **Поверхні поза REST:** GraphQL, gRPC, авторизація WebSocket, DoS, схема.                             |
| `payment`             | `owasp`, `lovable`          | **Оформлення оплати:** перевірка шлюзу на сервері, підписані колбеки, ідемпотентність.                |
| `xml`                 | `owasp`                     | **Розбір XML:** XXE, зовнішні сутності, розростання billion laughs.                                   |
| `csv`                 | `owasp`                     | **Ін'єкція формул:** клітинки таблиць, що починаються з `=`/`+`/`-`/`@`.                              |
| `container`           | `owasp`, `infra`            | **Конфігурація контейнерів:** root, capabilities, монтування сокета, захист образу.                   |
| `infra`               | `infra`                     | **Інфраструктура як код:** Terraform, Dockerfile, GitHub Actions.                                     |
| `serverless`          | `owasp`, `infra`, `lovable` | **Функції FaaS:** IAM з мінімальними привілеями, вхідні дані подій, контекст, секрети.                |
| `llm`                 | `ai`, `lovable`             | **Ризики ШІ та LLM:** prompt injection, agency, RAG, MCP, вивід.                                      |
| `supabase`            | `lovable`                   | **Бекенд на Supabase:** RLS вимкнено за замовчуванням, політики, хибно згенеровані ШІ, модель ключів. |
| `browser`             | `javascript`, `lovable`     | **Ризики на боці клієнта:** XSS, CSP, framing, сховище тощо.                                          |
| `javascript`          | `javascript`                | **Ризики на рівні мови:** RCE, prototype pollution тощо.                                              |
| `python`              | `python`                    | **Ризики на рівні мови:** RCE через `pickle`, class pollution, `-O` тощо.                             |
| `rust`                | `rust`                      | **Коректність `unsafe`:** UB із безпечного коду, `transmute`, переповнення.                           |
| `java`                | `java`                      | **Десеріалізація й мобільний код:** ланцюжки `readObject`, перехоплення об'єктів.                     |
| `ruby`                | `ruby`                      | **Десеріалізація й `open`:** відновлення об'єктів через `Marshal` чи YAML, особливість із pipe.       |
| `php`                 | `php`                       | **Type juggling і `unserialize`:** magic hashes, POP-ланцюжки.                                        |
| `go`                  | `go`                        | **Typed nil і data races:** `nil != nil`, горутини зі спільною пам'яттю.                              |
| `c-cpp`               | `c-cpp`                     | **Форматні рядки:** `printf(user_input)`, write-what-where через `%n`.                                |
| `dotnet`              | `dotnet`                    | **Ризики на рівні платформи:** RCE через `BinaryFormatter`, `@Html.Raw`, прогалини в enum.            |

Більшість вбудованих знань стисло викладено з OWASP. Повну відповідність кожної спеціалізації її канонічним сторінкам атак і Cheat Sheet від OWASP наведено в [**Джерелах OWASP**](https://lagune.ai/uk-UA/docs/references/owasp-sources). Кілька модулів для конкретних стеків натомість спираються на настанови самого постачальника: `supabase`, наприклад, походить із документації Supabase і CVE-2025-48757.

## Ваші власні спеціалізації

Вбудовані спеціалізації розростаються додаванням одного файлу знань і одного рядка в індексі, а не нової команди. Власні ви додаєте так само, через [`/lagune-specialize`](https://lagune.ai/uk-UA/docs/commands/specialize): спрямуйте її на статтю чи тему, і вона стисло викладе нову спеціалізацію у вашому проєкті, файл у `.lagune/catalog/` і його запис у `.lagune/configs.json`. Ваші власні спеціалізації завжди є в каталозі, хоч би які в нього категорії, а ваша спеціалізація перекриває вбудовану з тією самою назвою.

**Усередині Lagune завантажує спеціалізації автоматично, на вимогу**

Коли фаза detect чи verify натрапляє на контекст, який охоплює спеціалізація, вона сама завантажує цю спеціалізацію через `read catalog <name>`. Це відбувається автоматично, як частина фази. Робити це вручну, щоб усе працювало, не потрібно.

## Що доступно

Щоб переглянути каталог вашого проєкту з термінала, по одній спеціалізації на рядок із тегами:

```bash
npx lagune read catalog
# regex: Regular Expression [required]
# network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect
# interpreter: Evaluator, Sink, Shell, Dynamic Execution
# ...
```

Спеціалізація з `[required]` застосовується завжди, хоч би якою була робота. Які вбудовані спеціалізації є в списку, залежить від [**категорій**](https://lagune.ai/uk-UA/docs/categories) вашого проєкту.

**Спеціалізації не завантажуються за замовчуванням**

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

## Часті запитання

### Що таке спеціалізація Lagune?

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

### Що таке каталог проєкту?

Спеціалізації, які використовує проєкт: вбудовані спеціалізації його категорій плюс власні. Поки не записано жодної категорії, він використовує лише OWASP.

### Чи завантажуються спеціалізації за замовчуванням?

Ні. Вони завантажуються лише на вимогу, для того, чим насправді є проєкт.

### Як завантажити спеціалізацію напряму?

У тому самому промпті, що й завдання, попросіть агента виконати npx lagune read catalog <name>.

---

# /lagune-specialize: навчіть спеціалізації з безпеки звичайним текстом

> Стисло викладіть джерело чи тему з безпеки, які ви надаєте, у нову спеціалізацію на вимогу.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/specialize
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/specialize
Останнє оновлення: 2026-11-03

🎓 Навчіть **Lagune** нової спеціалізації на основі джерела чи теми, які ви надаєте.

Вона читає матеріал і стисло викладає його в цільову, суто оборонну спеціалізацію, побудовану точно так само, як [вбудовані](https://lagune.ai/uk-UA/docs/catalog), тож фази detect і verify потім завантажують її, як і будь-яку іншу. Вона лише перевіряє й пояснює: ніколи не пише вхідних даних для атак чи експлойтів і ніколи не торкається вашого коду.

**Зі статті**

```prompt
# Посилання чи джерело: Lagune стисло викладає його у вигляді захисту
/lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection
```

**З експлойту**

```prompt
# Атака як джерело: спеціалізація все одно описує захист
/lagune-specialize "' OR 1=1 -- вклеює SQL у текст запиту"
```

**З теми**

```prompt
# Або просто назви, що треба охопити
/lagune-specialize SQL injection
```

**Атака може бути джерелом, але ніколи результатом**

Спрямувати її на атаку можна, якщо мета полягає в захисті від неї: опис експлойту є навчальним матеріалом, який вона стисло викладає у вигляді захисту. Спеціалізація, яку вона створює, завжди перевіряє й пояснює і ніколи не дає робочого експлойту, payload чи способу обходу захисту.

## Що вона записує

Результатом є два файли у вашому проєкті, закомічені й доступні для перегляду поруч із вашим кодом:

- Спеціалізація в `.lagune/catalog/<name>.md`, побудована як [вбудовані](https://lagune.ai/uk-UA/docs/catalog).
- Її запис у `.lagune/configs.json`, де ваш проєкт індексує власні спеціалізації, щоб каталог об'єднав їх із вбудованими.

Потім вона переглядає каталог, щоб підтвердити, що новий запис там є. Ваші власні спеціалізації завжди є в каталозі, хоч би які в нього категорії. Вам ніколи не треба додавати команду чи чіпати пакет: нова спеціалізація є одним файлом знань і одним записом в індексі, записаними у ваш власний проєкт.

## Уточнювати, а не перезаписувати

Спеціалізація з назвою, що вже існує, хоч вбудована, як-от `regex`, хоч та, яку ви створили раніше, **узгоджує** поточний файл, а не замінює його. Вона читає те, що там є, вплітає нові знання, зберігає те, що досі слушне, і переписує те, що змінилося. Ніщо не відкидається непереглянутим. Ваша спеціалізація перекриває вбудовану з тією самою назвою, тож ви можете вдосконалити вбудовану для свого проєкту, не втрачаючи її.

**Порада**

- Нова спеціалізація завантажується точно так само, як вбудована: фази detect і verify підхоплюють її на вимогу, або ви завантажуєте її самі командою `npx lagune read catalog <name>` і даєте їй завдання.
- Коли в матеріалу є встановлюване походження (стаття, автор, посилання, стандарт), спеціалізація його зазначає. Просто тема не має джерела.

**Примітка**

**Вона запускається лише тоді, коли ви її викликаєте:** агент ніколи не запускає її сам.

## Часті запитання

### Як додати власну спеціалізацію з безпеки?

Виконайте /lagune-specialize із джерелом чи темою. Вона стисло викладе їх у суто оборонну спеціалізацію, записану в .lagune/catalog/<name>.md, а також її запис у .lagune/configs.json.

### Чи може Lagune навчитися з опису експлойту?

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

### Чи перезаписує specialize вбудовані спеціалізації?

Ні. Вона уточнює, а не перезаписує.

---

# /lagune-prove: суто оборонний Proof of Concept

> Перетворіть кожну виявлену знахідку на виконуваний, суто оборонний Proof of Concept (PoC) і бюлетень безпеки для відповідального розкриття.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/prove
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/prove
Останнє оновлення: 2026-11-03

🧪 Перетворіть кожну виявлену знахідку на виконуваний, суто оборонний доказ для відповідального розкриття.

Для кожної знахідки з карти виявлення вона пише самодостатній бюлетень безпеки й тест, що перевіряє **безпечний шлях**, тож тест не проходить, поки проблема існує, і проходить, щойно код виправлено.

**Порада**

Тести **Lagune** зберігаються ізольовано в `.lagune/`, окремо від вашого власного набору тестів.

## Використання

**Кожна знахідка**

```prompt
/lagune-prove
```

**Знахідка за назвою**

Перегляньте знахідки, які вже відстежуються, за назвою:

```prompt
npx lagune read list --findings

# Findings
#   ...
#   • SQL injection у пошуку користувачів
#   ...
```

```prompt
# Потім доведи одну з них
/lagune-prove SQL injection у пошуку користувачів
```

## Як це працює

Вона читає вихідний код, на який вказує кожна знахідка, і для кожної доведеної знахідки створює в `.lagune/proofs/` окремий каталог, що містить рівно два файли:

| Файл                           | Що це                                                                                                                                            |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `report.test.mjs` (або `.cjs`) | Тест. Він запускається на Poku, якщо ваш проєкт уже його використовує, інакше на вбудованому раннері Node.js, тож нічого не треба встановлювати. |
| `report.md`                    | Самодостатній бюлетень безпеки: критичність, вплив, як відтворити проблему й команда запуску, зрозумілий сам по собі.                            |

Доведення завжди написані на JavaScript, тож залишаються переносними, хоч би якою мовою був написаний ваш проєкт. Індекс `README.md` містить посилання на кожне доведення й одну команду, щоб запустити їх усі.

**Порада**

- Вона **необов'язкова й автономна**: не входить до п'яти фаз і не є частиною ланцюжка відстеження.
- Вона пише лише в `.lagune/proofs/` і ніколи не торкається артефактів фаз чи вашого коду, який лише читає.
- Знахідка, тест якої не відтворює проблему, не отримує доведення, і вона попросить виконати [`/lagune-detect`](https://lagune.ai/uk-UA/docs/commands/detect) для цього місця, щоб узгодити стан.
- Повторний запуск узгоджує доведення: каталог знахідки, яка зникла чи більше не відтворюється, видаляється.

**Примітка**

**Вона запускається лише тоді, коли ви її викликаєте:** агент ніколи не запускає її сам.

**Спирається на detect**

Prove читає карту виявлення від [`/lagune-detect`](https://lagune.ai/uk-UA/docs/commands/detect), тож спершу виконайте detect.

## Лише захист і лише з дозволу

Перш ніж щось генерувати, вона підтверджує, що ви маєте дозвіл тестувати ціль, і відхиляє будь-який запит на робочий експлойт, payload атаки чи обхід виявлення. Доведення демонструє безпечну поведінку й ніколи не видає вхідних даних для атаки.

## Від доведення до розкриття

Два файли кожної доведеної знахідки разом вирушають у **приватний GitHub Gist**, щоб повідомити про вразливість. Вони є доказом чинної, ще не розкритої проблеми, тож `.gitignore` усередині `.lagune/proofs/` не пускає їх у жоден коміт: діліться ними лише через цей Gist, доки мейнтейнери не розв'яжуть проблему.

Закривати знахідку в ланцюжку **Lagune** і далі мають [`/lagune-harden`](https://lagune.ai/uk-UA/docs/commands/harden) і [`/lagune-verify`](https://lagune.ai/uk-UA/docs/commands/verify): prove створює докази, а не закриває щось.

## Часті запитання

### Чи генерує Lagune експлойти?

Ні. /lagune-prove пише суто оборонні докази: тест, що перевіряє безпечний шлях, тож він не проходить, поки проблема існує, і проходить, щойно код виправлено, а також бюлетень безпеки для відповідального розкриття.

### Що створює prove?

Два файли на кожну знахідку: тест (report.test.mjs або .cjs) і бюлетень безпеки (report.md).

### Як відповідально розкрити помилку, яку знайшов Lagune?

Prove пише самодостатній бюлетень безпеки, яким можна поділитися через приватний канал, як-от приватний GitHub Gist, дотримуючись принципів відповідального розкриття.

---

# Хук agent: виявлення необмежених циклів агентів

> Перевірте кодову базу на виклики агентів і LLM без обмеження кроків чи часу або оцініть окремий виклик просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/agent
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/agent
Останнє оновлення: 2026-11-03

Хук `agent` позначає **середовища виконання агентів, що працюють у циклі без обмеження ходів, бюджету чи часу**, тобто діру неконтрольованої автономії, через яку підроблені вхідні дані перетворюються на необмежені витрати чи ескалацію через prompt injection. Він **враховує мову** й охоплює дві екосистеми фреймворків агентів: **JavaScript** (середовище виконання `query` з агентного SDK **Claude**) і **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Це детермінований рушій [спеціалізації `llm`](https://lagune.ai/uk-UA/docs/catalog), який ви можете запускати самі в режимі **scan** або **check**.

## Запуск

**Перевірити кодову базу**

```bash
npx lagune read agent                # scans the whole project
npx lagune read agent --dir src/ai   # scans a directory
npx lagune read agent --file chat.ts # scans a single file
```

**Перевірити виклик**

```bash
npx lagune read agent --lang javascript --pattern 'query({ prompt })'                           # => uncapped
npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe
npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)'     # => uncapped
```

Кожен рядок під **Uncapped agent loops found** у файлі, що імпортує SDK агентів, є або викликом середовища виконання `query` з агентного SDK Claude без обмеження ходів, бюджету чи часу (JavaScript, без обмежень за замовчуванням), або явним зняттям обмеження фреймворку за замовчуванням, як-от `max_iterations=None` / `max_turns=None` (Python, обмежений за замовчуванням). В обох випадках код виходу ненульовий. `generateText`/`streamText` з Vercel AI SDK за замовчуванням виконують один крок (`stopWhen: stepCountIs(1)`), тож простий виклик там не може зациклитися й не позначається, а звичайний `db.query(...)` ніколи не сприймається як виклик агента. Чистий запуск виводить `no uncapped agent loops found`.

## Як читати вердикт

| Вердикт    | Значення                                                                                                       |
| ---------- | -------------------------------------------------------------------------------------------------------------- |
| `uncapped` | Виклик середовища виконання `query` без обмеження (JS) або явне зняття обмеження (`=None`, Py).                |
| `safe`     | Виклик `query`, що задає обмеження, генерація за один крок або виклик фреймворку, обмеженого за замовчуванням. |
| `invalid`  | Фрагмент коду не містить розпізнаваного виклику агента, який можна оцінити.                                    |

### Параметри CLI

| Параметр    | Значення      | Опис                                                                            |
| ----------- | ------------- | ------------------------------------------------------------------------------- |
| `--pattern` | фрагмент коду | Перевірити один виклик. Повторіть, щоб перевірити кілька, по вердикту на рядок. |
| `--lang`    | мова          | Обов'язковий із `--pattern`: `javascript` або `python`.                         |
| `--dir`     | каталог       | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.            |
| `--file`    | файл          | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`.          |

Без параметрів хук перевіряє весь проєкт. `--pattern` потребує `--lang` і не поєднується з `--dir` чи `--file`.

**Найкраще з можливого, але не вичерпно**

Власноруч написаний цикл агента будь-якою мовою не під силу статичній перевірці. Сприймайте це як надійний мінімум, а не як повний перелік.

**Порада**

Хук вирішує лише щодо обмеження: обмеження можливостей, змішування рівнів довіри й авторизацію і далі охоплює [спеціалізація `llm`](https://lagune.ai/uk-UA/docs/catalog), бо це питання судження.

## Часті запитання

### Навіщо обмежувати цикл агента?

Необмеженого агента можна довести до нескінченної рекурсії, витрат чи ескалації через prompt injection. Параметри maxTurns, maxBudgetUsd, stopWhen і signal обмежують його, а хук agent позначає виклик середовища виконання query, який не задає жодного з них.

---

# Хук cors: аудит джерел CORS

> Перевірте вихідний код на allowlist джерел CORS, який можна обійти, або оцініть окреме значення джерела на надто вільний доступ просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/cors
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/cors
Останнє оновлення: 2026-11-03

Хук `cors` є детермінованим рушієм [спеціалізації `http-request`](https://lagune.ai/uk-UA/docs/catalog), і ви можете запускати його самі. Він працює у двох режимах однієї команди: **scan**, що перевіряє вихідний код на **allowlist джерел, який можна обійти** (регулярний вираз для перевірки хоста, повз який прослизає хост зловмисника), і **score**, що оцінює окреме значення **джерела CORS** як `wildcard`, `null` або `safe`.

## Перевірка кодової бази

Без прапорців хук перевіряє весь проєкт.

**Увесь проєкт**

```bash
npx lagune read cors
```

**Каталог**

```bash
npx lagune read cors --dir src/server
```

**Один файл**

```bash
npx lagune read cors --file internal/auth/origin.go
```

Він виводить кожен allowlist, який можна обійти, під одним заголовком, згрупувавши за файлами. Валідатор хоста, у якого `.+`/`.*` стоїть у сегменті authority перед суфіксом довіреного хоста (`^https?://.+\.trusted\.com`), пропускає хост зловмисника на кшталт `your-site.com.attacker.com`.

```text
Origin-allowlist patterns with a greedy wildcard (bypassable, review):

internal/auth/origin.go
  ^https?://.+\.trusted\.com
```

Це привід для перегляду, а не закрита знахідка: чи керує регулярний вираз реальним рішенням про довіру, неможливо визначити з тексту, тож перевірка ніколи не змінює код виходу. Перегляньте кожен і переконайтеся, що allowlist порівнює за повною рівністю. Якщо нічого не знайдено, хук виводить один рядок.

```bash
npx lagune read cors --dir src/clean
# => no bypassable origin allowlist found
```

## Оцінка джерела

Передайте кожне джерело через `--origin`. Хук виводить по одному слову на джерело й завершується з ненульовим кодом за будь-якого `wildcard` чи `null`.

**Одне джерело**

```bash
npx lagune read cors --origin '*'                       # => wildcard
npx lagune read cors --origin 'null'                    # => null
npx lagune read cors --origin 'https://app.example.com' # => safe
```

**Кілька джерел**

Повторіть `--origin`, щоб оцінити весь allowlist одним викликом, по вердикту на рядок, у тому самому порядку.

```bash
npx lagune read cors \
  --origin 'https://app.example.com' \
  --origin '*' \
  --origin 'null'
# => safe
# => wildcard
# => null
```

| Вердикт    | Значення                                                                                           |
| ---------- | -------------------------------------------------------------------------------------------------- |
| `safe`     | Не `*`, не `null` і не glob із `*`. Це не гарантує, що джерело правильно сформоване.               |
| `wildcard` | `*` або glob піддомену, хоста чи порту: будь-який сайт (або широке їх коло) може читати відповідь. |
| `null`     | Джерело `null`, яке можуть підробити iframe у пісочниці й перенаправлення.                         |

Дозволом є лише `safe`, а `--origin` є оракулом значень: він оцінює значення, а не обробник, тож перевірте обробник за допомогою спеціалізації `http-request`.

### Параметри CLI

| Параметр   | Значення | Опис                                                                              |
| ---------- | -------- | --------------------------------------------------------------------------------- |
| `--origin` | джерело  | Оцінити одне значення джерела. Повторіть, щоб оцінити кілька, по одному на рядок. |
| `--dir`    | каталог  | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.              |
| `--file`   | файл     | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`.            |

Без параметрів хук перевіряє весь проєкт. `--origin` вмикає режим score і не поєднується з `--dir` чи `--file`.

**Чого він не охоплює**

Перевірка розпізнає форму **регулярного виразу, який можна обійти**, а `--origin` оцінює **значення** джерел. Два шаблони на рівні вихідного коду залишаються поза її межами: віддзеркалення `Origin` запиту (сервер повертає вхідний `Origin` назад або поєднує його з обліковими даними) і надто вільний allowlist на основі `endsWith` чи підрядка. Розпізнайте їх у коді й діяйте так, як описує [спеціалізація `http-request`](https://lagune.ai/uk-UA/docs/catalog).

## Часті запитання

### Чому джерело CORS null небезпечне?

Iframe у пісочниці й деякі перенаправлення надсилають Origin: null, тож allowlist, що довіряє null, дає цим контекстам доступ на читання. Хук cors позначає його разом із wildcard.

### Як виявити allowlist джерел CORS, який можна обійти?

Виконайте npx lagune read cors над кодовою базою. Він позначає регулярний вираз для перевірки хоста, у якого жадібний wildcard стоїть перед довіреним суфіксом, тож хост зловмисника на кшталт your-site.com.attacker.com прослизає повз нього.

---

# Хук crypto: виявлення слабкої криптографії

> Перевірте кодову базу на слабкі криптографічні примітиви або оцініть окремий фрагмент коду просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/crypto
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/crypto
Останнє оновлення: 2026-11-03

Хук `crypto` позначає **слабкі криптографічні примітиви** в місці виклику: застарілий шифр, небезпечний режим або зламаний геш. Він **враховує мову** й читає кожен файл за його власними правилами, тож конструкцію Python ніколи не буде позначено у файлі Rust. Це детермінований рушій [спеціалізації `crypto`](https://lagune.ai/uk-UA/docs/catalog), який ви можете запускати самі в режимі **scan** або **check**.

## Запуск

**Перевірити кодову базу**

```bash
npx lagune read crypto                # scans the whole project
npx lagune read crypto --dir src      # scans a directory
npx lagune read crypto --file hash.ts # scans a single file
```

**Перевірити фрагмент**

```bash
npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak
npx lagune read crypto --lang python --pattern 'hashlib.md5(data)'                  # => review
npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)'                    # => safe
```

Перевірка виводить до двох розділів. **Weak cryptography found** є набором знахідок (DES/3DES/RC4/Blowfish/RC2, режим ECB): кожна з них є зламаним шифрувальним примітивом, тож хук завершується з ненульовим кодом. **Cryptography to review manually** є набором зачіпок, які хук не може оцінити сам: геш MD5/SHA-1 (зламаний для потреб безпеки, але цілком доречний як звичайна контрольна сума, тож усе вирішує намір), некриптографічний генератор випадкових чисел у контексті безпеки або порівняння, вразливе до атак за часом. Чистий запуск виводить `no weak cryptography found`.

## Як читати вердикт

| Вердикт   | Значення                                                                                                              |
| --------- | --------------------------------------------------------------------------------------------------------------------- |
| `weak`    | Фрагмент використовує зламаний шифрувальний примітив (DES/3DES, RC4, Blowfish, RC2 або режим ECB).                    |
| `review`  | Примітив, що залежить від наміру: геш MD5/SHA-1 або некриптографічний генератор випадкових чисел у контексті безпеки. |
| `safe`    | Фрагмент використовує криптографію, і слабких примітивів не знайдено.                                                 |
| `invalid` | Фрагмент не містить розпізнаваної криптографічної конструкції, яку можна оцінити.                                     |

### Параметри CLI

| Параметр    | Значення      | Опис                                                                                                       |
| ----------- | ------------- | ---------------------------------------------------------------------------------------------------------- |
| `--pattern` | фрагмент коду | Перевірити один фрагмент. Повторіть, щоб перевірити кілька, по вердикту на рядок.                          |
| `--lang`    | мова          | Обов'язковий із `--pattern`: одна з javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. |
| `--dir`     | каталог       | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.                                       |
| `--file`    | файл          | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`.                                     |

Без параметрів хук перевіряє весь проєкт. `--pattern` потребує `--lang` і не поєднується з `--dir` чи `--file`.

### Підтримувані мови

Перевірка читає ці мови, визначаючи їх за розширенням файлу, і звіряє кожну з її власними криптографічними API.

| Мова                        | Слабкі шифри (знахідка) і геші та генератори випадкових чисел (перегляд)                                      |
| --------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` у лапках; MD5/SHA-1 `createHash`/`subtle.digest`; `Math.random()` |
| **Python**                  | pycryptodome `DES/ARC4/Blowfish.new`, `algorithms.TripleDES`, `MODE_ECB`; `hashlib.md5/sha1`; `random.*`      |
| **Go**                      | `des.NewCipher`, `rc4.NewCipher`, `blowfish.NewCipher`, `NewECBEncrypter`; `md5/sha1.Sum`; `math/rand`        |
| **Java / Kotlin**           | `Cipher.getInstance("DES"/…/ECB")`; `MessageDigest.getInstance("MD5")`, `HmacMD5`; `java.util.Random`         |
| **PHP**                     | `openssl_encrypt("des-…"/"…-ecb")`, `mcrypt_*`; `md5()`/`sha1()`, `hash("md5", …)`; `rand()`/`mt_rand()`      |
| **Ruby**                    | `OpenSSL::Cipher.new("des-…")`, `:ECB`; `Digest::MD5/SHA1`; `rand()`/`Random`                                 |
| **Rust**                    | `Rc4::`, `Blowfish::`, `des::`, `ecb::`; `Md5::`, `Sha1::`, `Hmac<Md5>`; `SmallRng`/`XorShiftRng`             |
| **C#**                      | `DES/TripleDES/RC2.Create`, `CipherMode.ECB`; `MD5/SHA1.Create`, `HMACMD5`; `new Random()`                    |
| **C / C++**                 | OpenSSL `DES_*`/`RC4`/`EVP_des_*`, `EVP_*_ecb`; `MD5()`/`SHA1()`, `EVP_md5`; `rand()`/`random()`              |

**Найкраще з можливого, але не вичерпно**

Хук читає вихідний код як текст, тож примітив, зібраний під час виконання, прихований за псевдонімом або записаний у формі, яку хук не розпізнає, може прослизнути. Сприймайте таблицю як надійну відправну точку, а не як повний перелік.

**Порада**

Хук гарантує мінімум (ці конструкції існують): керування ключами, повторне використання IV і доповнення RSA і далі охоплює [спеціалізація `crypto`](https://lagune.ai/uk-UA/docs/catalog), бо це питання судження.

## Часті запитання

### Як перевірити кодову базу на слабку криптографію?

Запустіть хук crypto без прапорців. Зламані шифри й режим ECB є знахідками, що завершуються з ненульовим кодом. Геш MD5/SHA-1 є зачіпкою для перегляду, бо він зламаний для потреб безпеки, але цілком доречний як звичайна контрольна сума.

### Чи позначає хук crypto Math.random()?

Лише як зачіпку для перегляду в контексті безпеки, а не як автоматичну знахідку, бо випадковість цілком доречна для jitter чи порядку елементів в інтерфейсі.

---

# Хук cvss: оцінка вектора CVSS v4.0

> Оцініть один чи кілька векторів CVSS v4.0 з командного рядка за тією самою арифметикою, що й калькулятор FIRST, і прочитайте кожен простими словами.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/cvss
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/cvss
Останнє оновлення: 2026-11-03

Хук `cvss` оцінює **вектор CVSS v4.0** і виводить його оцінку й рівень критичності, тобто рейтинг, який [`/lagune-plan`](https://lagune.ai/uk-UA/docs/commands/plan) записує для кожного виправлення, а [`/lagune-prove`](https://lagune.ai/uk-UA/docs/commands/prove) для кожного бюлетеня безпеки. Це детермінований рушій цих рейтингів з тією самою арифметикою, що й [калькулятор FIRST](https://www.first.org/cvss/calculator/4.0), і ви можете запускати його самі.

## Запуск

Передайте кожен вектор через `--vector`. Хук виводить по рядку на вектор: його оцінку й рівень.

**Один вектор**

```bash
npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N'
# => 9.3, Critical
```

**Кілька векторів**

Повторіть `--vector`, щоб оцінити кілька векторів одразу, по рядку на кожен, у тому самому порядку.

```bash
npx lagune read cvss \
  --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \
  --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A'
# => 9.3, Critical
# => 8.7, High
```

**Простими словами**

Додайте `--explain`, щоб прочитати кожну метрику простими словами. Коли метрики Threat чи Environmental змінюють оцінку, спершу йде оцінка лише за метриками Base.

```bash
npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A'
# => 8.7, High
# =>   Base metrics alone: 9.3, Critical
# =>   Attack Vector: Network, modified to Adjacent
# =>   Attack Complexity: Low
# =>   ...
```

## Як читати результат

| Рівень     | Оцінка          |
| ---------- | --------------- |
| `None`     | 0.0             |
| `Low`      | від 0.1 до 3.9  |
| `Medium`   | від 4.0 до 6.9  |
| `High`     | від 7.0 до 8.9  |
| `Critical` | від 9.0 до 10.0 |

Вектор лише з метриками Base оцінює саму ваду, припускаючи найгірше: кожна вимога безпеки має рівень High, а вада зазнає атак у реальному світі. Метрики Environmental (`MAV` та інші змінені метрики, а також `CR`, `IR` і `AR`) уточнюють оцінку для конкретного розгортання, а метрика Threat (`E`) для того, що відомо про експлуатацію.

Недійсний вектор виводить `invalid vector:` і що з ним не так, а хук завершується з ненульовим кодом.

### Параметри CLI

| Параметр    | Значення          | Опис                                                                                           |
| ----------- | ----------------- | ---------------------------------------------------------------------------------------------- |
| `--vector`  | вектор `CVSS:4.0` | Оцінити один вектор. Повторіть, щоб оцінити кілька, по рядку на вектор, у тому самому порядку. |
| `--explain` |                   | Додати кожну метрику простими словами під кожним рядком рейтингу.                              |

Потрібен щонайменше один `--vector`. Вектор ніколи не передається як окремий позиційний аргумент, тож його неможливо сплутати з прапорцем.

**Чому значення прапорця**

Кожен вектор передається як значення прапорця й ніколи не підставляється в команду. Значення з лапками чи зворотними апострофами залишається інертним і не може здійснити ін'єкцію в оболонку. Завжди беріть його в одинарні лапки, щоб ваша оболонка не розгорнула його першою.

**Чого він не охоплює**

Лише CVSS v4.0: вектор v2.0, v3.0 чи v3.1 відхиляється, а не оцінюється, бо **Lagune** оцінює кожну знахідку у v4.0.

**Порада**

Валідація фази plan повторює цю саму арифметику для кожного рядка CVSS, тож оцінку, що розійшлася зі своїм вектором, буде виявлено ще до того, як план приймуть.

## Часті запитання

### Як Lagune обчислює оцінку CVSS?

Хук cvss дотримується еталонного калькулятора FIRST для CVSS v4.0, тож вектор отримує точно таку саму оцінку, як на сайті FIRST.

### Чи можна оцінити ним вектор CVSS v3.1?

Ні. Lagune оцінює кожну знахідку в CVSS v4.0, а хук відхиляє будь-яку іншу версію, а не оцінює її.

### Що робить прапорець --explain?

Він читає кожну метрику простими словами й показує оцінку Base поруч із загальною, тож будь-хто бачить, що каже вектор і як контекст проєкту змінив оцінку.

---

# Хук infra: виявлення помилок конфігурації IaC

> Перевірте Terraform, Dockerfile і GitHub Actions на помилки конфігурації або оцініть окремий фрагмент просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/infra
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/infra
Останнє оновлення: 2026-11-03

Хук `infra` позначає **помилки конфігурації інфраструктури як коду**, які можна визначити з самого файлу: мережу, відкриту для всього світу, дозвіл із wildcard, секрет у маніфесті, контейнер від root, недовірене значення в shell CI. Він читає лише файли IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). Це детермінований рушій [спеціалізації `infra`](https://lagune.ai/uk-UA/docs/catalog) у режимі **scan** або **check**.

## Запуск

**Перевірити кодову базу**

```bash
npx lagune read infra                   # scans every IaC file
npx lagune read infra --dir infra       # scans a directory
npx lagune read infra --file Dockerfile # scans a single file
```

**Перевірити фрагмент**

Передайте фрагмент через `--pattern`, а його тип через `--kind` (`terraform`, `dockerfile` або `github-actions`).

```bash
npx lagune read infra --kind terraform  --pattern 'actions = ["*"]' # => iam-wildcard
npx lagune read infra --kind dockerfile --pattern 'FROM node:20'    # => mutable-tag
```

Перевірка виводить до двох розділів. **Infrastructure risks found** завершується з ненульовим кодом і містить дефекти, які можна визначити (вхідний трафік `0.0.0.0/0` на чутливий порт, інструкція IAM із wildcard, секрет у маніфесті, `encrypted = false`, незакріплений git-модуль, образ, що явно працює від root, `curl | sh`, ін'єкція в скрипт CI, `permissions: write-all`). **Infrastructure hardening advisories** не змінює код виходу (змінний базовий тег, дія, закріплена за тегом). Чистий запуск виводить `no infrastructure risks found`.

## Як читати вердикт

Режим check виводить тег найвищої критичності, який збігся (наприклад, `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), рекомендаційний тег (`mutable-tag`, `unpinned-action`) або `safe`. Ненульовий код виходу дає лише тег рівня знахідки.

### Параметри CLI

| Параметр    | Значення                                        | Опис                                                                   |
| ----------- | ----------------------------------------------- | ---------------------------------------------------------------------- |
| `--pattern` | фрагмент                                        | Перевірити один фрагмент. Потребує `--kind`. Повторіть для кількох.    |
| `--kind`    | `terraform` \| `dockerfile` \| `github-actions` | Тип, як який оцінюється фрагмент.                                      |
| `--dir`     | каталог                                         | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.   |
| `--file`    | файл                                            | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`. |

Без параметрів хук перевіряє кожен файл IaC у проєкті. `--pattern` не поєднується з `--dir` чи `--file`.

**Порада**

Хук виявляє очевидні випадки, які можна визначити: відсутність шифрування, вразливість через `pull_request_target` і правильний обсяг IAM і далі охоплює [спеціалізація `infra`](https://lagune.ai/uk-UA/docs/catalog), бо це питання судження.

## Часті запитання

### Які файли інфраструктури читає хук infra?

Terraform і HCL (.tf, .tf.json, .hcl), Dockerfile, а також YAML робочих процесів і дій GitHub Actions у .github/. Він дістається до цих файлів, хоча сканери вихідного коду їх пропускають.

---

# Хук interpreter: позначення sinks динамічного виконання коду

> Перевірте кодову базу на sinks динамічного виконання коду різними мовами або оцініть окремий фрагмент просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/interpreter
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/interpreter
Останнє оновлення: 2026-11-03

Хук `interpreter` позначає **sinks динамічного виконання коду**: конструкції, що перетворюють дані на виконуваний код або передають їх в оболонку, від `eval` до нативної десеріалізації. Він враховує мову й читає кожен файл за його власними правилами. Це детермінований рушій [спеціалізації `interpreter`](https://lagune.ai/uk-UA/docs/catalog), який ви можете запускати самі в режимі **scan** або **check**.

## Запуск

**Перевірити кодову базу**

```bash
npx lagune read interpreter               # scans the whole project
npx lagune read interpreter --dir src     # scans a directory
npx lagune read interpreter --file app.py # scans a single file
```

**Перевірити фрагмент**

```bash
npx lagune read interpreter --lang javascript --pattern 'eval(x)'   # => careful
npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe
```

Ці sinks мають подвійне призначення: чи доходять до них вхідні дані під впливом зловмисника, статична перевірка визначити не може, тож кожен збіг є **застереженням для перегляду**, а не підтвердженою знахідкою. Перевірка виводить один розділ **Dynamic-execution sinks to review**, згрупований за файлами. Чистий запуск виводить `no dynamic-execution sinks found`.

**Читайте позначений код, ніколи не запускайте його!**

Аналізуйте кожен sink **статично**, простежуючи, чи доходять до нього недовірені вхідні дані. Ніколи не виконуйте й не передавайте в `eval` позначений код чи будь-який віддалений або отриманий під час виконання код, який він підтягує, щоб "перевірити", що він робить.

## Як читати вердикт

| Вердикт   | Значення                                                                                                 |
| --------- | -------------------------------------------------------------------------------------------------------- |
| `careful` | Фрагмент містить sink динамічного виконання для своєї мови. Переглядайте його, читаючи, а не запускаючи. |
| `safe`    | Для вказаної мови sink динамічного виконання не знайдено.                                                |

### Параметри CLI

| Параметр    | Значення      | Опис                                                                                                       |
| ----------- | ------------- | ---------------------------------------------------------------------------------------------------------- |
| `--pattern` | фрагмент коду | Перевірити один фрагмент. Повторіть, щоб перевірити кілька, по вердикту на рядок.                          |
| `--lang`    | мова          | Обов'язковий із `--pattern`: одна з javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. |
| `--dir`     | каталог       | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.                                       |
| `--file`    | файл          | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`.                                     |

Без параметрів хук перевіряє весь проєкт. `--pattern` потребує `--lang` і не поєднується з `--dir` чи `--file`.

### Підтримувані мови

Перевірка читає ці мови, визначаючи їх за розширенням файлу, і звіряє кожну з її власним набором sinks динамічного виконання.

| #   | Мова                        | Розширення                                                                                                   | Що позначає                                                                                                                                                                                                                                   |
| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1   | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, конструктор Function, `setTimeout`/`setInterval` з рядковим тілом, модуль `vm`, exec з `child_process`, динамічний `require()`, динамічний `import()`                                                                               |
| 2   | **Python**                  | `.py`, `.pyi`                                                                                                | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (небезпечний)                                                                                                            |
| 3   | **Ruby**                    | `.rb`                                                                                                        | сімейство eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, зворотні апострофи або `%x`, `Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`, `Process.spawn`, `Marshal.load`                                      |
| 4   | **Go**                      | `.go`                                                                                                        | `exec.Command`/`exec.CommandContext`, `plugin.Open`                                                                                                                                                                                           |
| 5   | **PHP**                     | `.php`                                                                                                       | `eval()`, `assert()` для рядка, `create_function()`, виконання в оболонці (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` зі шляхом, визначеним під час виконання |
| 6   | **Rust**                    | `.rs`                                                                                                        | `Command::new`, `process::Command`                                                                                                                                                                                                            |
| 7   | **Java**                    | `.java`                                                                                                      | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject`                                                                                                                                                              |
| 8   | **Kotlin**                  | `.kt`, `.kts`                                                                                                | Sinks JVM: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject`                                                                                                                                                   |
| 9   | **C#**                      | `.cs`                                                                                                        | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load`                                                                                                                                                                           |
| 10  | **C**                       | `.c`, `.h`                                                                                                   | `system()`, `popen()`, сімейство `exec*` (`execl`, `execve`, `execvp`, …)                                                                                                                                                                     |
| 11  | **C++**                     | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx`                                                                 | `system()`, `popen()`, сімейство `exec*` (`execl`, `execve`, `execvp`, …)                                                                                                                                                                     |

**Найкраще з можливого, але не вичерпно**

Хук читає вихідний код як текст, тож sink, зібраний під час виконання, прихований за псевдонімом або записаний у формі, яку хук не розпізнає, може прослизнути. Сприймайте таблицю як надійну відправну точку, а не як повний перелік.

**Порада**

Хук гарантує мінімум (ці sinks існують, і відомо де): чи справді до одного з них доходить недовірене значення, вирішує судження, яке охоплює [спеціалізація `interpreter`](https://lagune.ai/uk-UA/docs/catalog).

## Часті запитання

### Чи підтверджує хук interpreter вразливість?

Ні. Він позначає sinks динамічного виконання як застереження для перегляду, а не як підтверджену знахідку, бо статична перевірка не може визначити, чи доходять до sink вхідні дані під впливом зловмисника.

### Які мови охоплює хук interpreter?

Він читає мови з таблиці "Підтримувані мови", визначаючи їх за розширенням файлу, і звіряє кожну з її власним набором sinks. Інші мови sinks не дають.

---

# Хук jwt: виявлення перевірки JWT без закріпленого алгоритму

> Перевірте кодову базу на перевірку JWT без закріпленого алгоритму або оцініть окремий виклик просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/jwt
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/jwt
Останнє оновлення: 2026-11-03

Хук `jwt` позначає **перевірку JWT без закріпленого алгоритму**, тобто діру плутанини алгоритмів, коли верифікатор довіряє заголовку `alg` самого токена, а також **повністю вимкнену перевірку**. Він **враховує мову** й читає кожен файл з огляду на його бібліотеку JWT. Це детермінований рушій [спеціалізації `federation`](https://lagune.ai/uk-UA/docs/catalog), який ви можете запускати самі в режимі **scan** або **check**.

## Запуск

**Перевірити кодову базу**

```bash
npx lagune read jwt                # scans the whole project
npx lagune read jwt --dir src      # scans a directory
npx lagune read jwt --file auth.ts # scans a single file
```

**Перевірити виклик**

```bash
npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)'                         # => unpinned
npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned
npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])'                # => safe
```

Кожен рядок під **Unpinned JWT verification found** є викликом перевірки, який не задає allowlist `algorithms` (там, де бібліотека його потребує), приймає небезпечний (`none` або асиметричний алгоритм, змішаний з HMAC) чи взагалі вимикає перевірку підпису, тож довіряє `alg` самого токена. Це підтверджена вразливість, тому хук завершується з ненульовим кодом. Чистий запуск виводить `no unpinned JWT verification found`.

## Як читати вердикт

| Вердикт    | Значення                                                                                                              |
| ---------- | --------------------------------------------------------------------------------------------------------------------- |
| `unpinned` | Виклик перевірки без allowlist алгоритмів (там, де він потрібен), з небезпечним allowlist або з вимкненою перевіркою. |
| `safe`     | Виклик перевірки, що закріплює надійний allowlist алгоритмів або чия бібліотека закріплює його неявно.                |
| `invalid`  | Фрагмент не містить розпізнаваного виклику перевірки, який можна оцінити.                                             |

### Параметри CLI

| Параметр    | Значення      | Опис                                                                                               |
| ----------- | ------------- | -------------------------------------------------------------------------------------------------- |
| `--pattern` | фрагмент коду | Перевірити один виклик. Повторіть, щоб перевірити кілька, по вердикту на рядок.                    |
| `--lang`    | мова          | Обов'язковий із `--pattern`: одна з javascript, python, go, java, kotlin, php, ruby, rust, csharp. |
| `--dir`     | каталог       | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.                               |
| `--file`    | файл          | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`.                             |

Без параметрів хук перевіряє весь проєкт. `--pattern` потребує `--lang` і не поєднується з `--dir` чи `--file`.

### Підтримувані мови

Перевірка читає ці бібліотеки, визначаючи їх за розширенням файлу. Оскільки деякі з них закріплюють алгоритм неявно (відсутність явного списку там цілком надійна), правило "немає allowlist ⇒ unpinned" діє лише там, де бібліотека очікує явний список, тож правильно налаштований виклик ніколи не позначається.

| Мова                        | Бібліотека              | Чи позначає відсутність allowlist як unpinned?                             | Позначає завжди                                   |
| --------------------------- | ----------------------- | -------------------------------------------------------------------------- | ------------------------------------------------- |
| **JavaScript / TypeScript** | jsonwebtoken, jose      | Так                                                                        | `none`, змішування асиметричного алгоритму з HMAC |
| **Python**                  | PyJWT, python-jose      | Так (PyJWT його вимагає, у python-jose за замовчуванням `algorithms=None`) | `none`, `verify_signature: False`                 |
| **Go**                      | golang-jwt              | Так (без `WithValidMethods`)                                               | `none`, `ParseUnverified`                         |
| **Ruby**                    | ruby-jwt                | Так                                                                        | `none`, `verify = false`                          |
| **Java / Kotlin**           | jjwt, nimbus            | Ні (виводиться з ключа)                                                    | `none`, непідписаний чи `unsecured` парсер        |
| **PHP**                     | firebase/php-jwt        | Ні (`Key` містить алгоритм)                                                | `none`                                            |
| **Rust**                    | jsonwebtoken            | Ні (`Validation` його вимагає)                                             | `none`, `insecure_disable_signature_validation`   |
| **C#**                      | Microsoft.IdentityModel | Ні (багаторядкові параметри)                                               | `none`, `RequireSignedTokens = false`             |

**Порада**

Хук вирішує лише щодо закріплення алгоритму: перевірки claims, ключів і потоку і далі охоплює [спеціалізація `federation`](https://lagune.ai/uk-UA/docs/catalog), бо це питання судження.

## Часті запитання

### Що таке плутанина алгоритмів JWT?

Верифікатор, що читає алгоритм із заголовка токена, дає зловмиснику змогу замінити RS256 на HS256 і підписати токен публічним ключем. Закріплення надійного allowlist алгоритмів у коді запобігає цьому, а хук jwt позначає виклик перевірки, який не задає жодного allowlist або задає небезпечний.

---

# Хук network: оцінка URL на SSRF

> Оцініть одну чи кілька адрес призначення запитів на SSRF просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/network
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/network
Останнє оновлення: 2026-11-03

Хук `network` вирішує, чи захищена адреса призначення серверного запиту від **SSRF** (запиту, який можна спрямувати на внутрішні сервіси, хмарні метадані чи приватні хости). Це детермінований рушій [спеціалізації `network`](https://lagune.ai/uk-UA/docs/catalog), і ви можете запускати його самі.

## Запуск

Передайте кожну адресу призначення через `--url`. Хук виводить по одному слову на адресу, пояснення наведено в таблиці нижче.

**Одна адреса**

```bash
npx lagune read network --url 'http://example.com/'
# => safe

npx lagune read network --url 'http://0x7f000001/'
# => private-target
```

**Кілька адрес**

Повторіть `--url`, щоб оцінити весь allowlist чи denylist одним викликом, по вердикту на рядок, у тому самому порядку.

```bash
npx lagune read network \
  --url 'http://example.com/' \
  --url 'http://[::1]/' \
  --url 'http://allowed.com@evil.example/'
# => safe
# => private-target
# => parser-divergent
```

Хук розпізнає хост так само, як мережа, тож закодовані форми внутрішньої адреси не прослизають: шістнадцяткова, вісімкова, десяткова без крапок, скорочена, IPv6 та IPv4-mapped дають `private-target`. А там, де недбалий валідатор і справжній клієнт запиту прочитали б різні хости, вердикт буде `parser-divergent`.

## Як читати вердикт

| Вердикт            | Значення                                                                                                  |
| ------------------ | --------------------------------------------------------------------------------------------------------- |
| `safe`             | Адреса з'єднується з публічним хостом, і недбалий валідатор прочитав би той самий хост.                   |
| `private-target`   | Хост розпізнається як приватна, loopback, link-local, невизначена адреса чи адреса хмарних метаданих.     |
| `parser-divergent` | Недбалий текстовий валідатор прочитав би інший справжній хост, ніж той, з яким з'єднується клієнт запиту. |
| `invalid url`      | Рядок не розбирається як URL, тож запитувати нічого.                                                      |

Дозволом є лише `safe`. Вважайте `private-target`, `parser-divergent` і `invalid url` блокуванням.

### Параметри CLI

| Параметр | Значення     | Опис                                                                            |
| -------- | ------------ | ------------------------------------------------------------------------------- |
| `--url`  | URL або хост | Перевірити одну адресу. Повторіть, щоб перевірити кілька, по вердикту на рядок. |

Потрібен щонайменше один `--url`. Адреса ніколи не передається як окремий позиційний аргумент, тож її неможливо сплутати з прапорцем.

**Чому значення прапорця**

Кожна адреса передається як значення прапорця й ніколи не підставляється в команду. Значення з лапками чи зворотними апострофами залишається інертним і не може здійснити ін'єкцію в оболонку. Завжди беріть його в одинарні лапки, щоб ваша оболонка не розгорнула його першою.

**Чого він не охоплює**

Хук є чистою функцією й ніколи не виконує DNS-запитів, тож дві прогалини часу виконання лишаються поза його межами: **DNS rebinding** (ім'я, що під час перевірки вказує на публічну адресу, а під час запиту на внутрішню) і **ланцюжки перенаправлень** (перший крок проходить перевірку, а потім перенаправляє всередину). Закрийте їх, розпізнаючи ім'я один раз і з'єднуючись із перевіреною адресою, а також відхиляючи перенаправлення. Зарезервовані loopback-імена (`localhost` і сімейство `.localhost`) хук без запиту вважає внутрішніми, але будь-яке інше DNS-ім'я дає `safe`, бо стверджувати, що воно вказує всередину, можна лише після розпізнавання: такі імена охороняє allowlist, і саме його перевіряє цей хук.

**Порада**

Це та сама перевірка, яку виконує [спеціалізація `network`](https://lagune.ai/uk-UA/docs/catalog), щоб довести, що фільтр адрес призначення діє.

## Часті запитання

### Як перевірити URL на SSRF?

Запустіть хук network. Він оцінює адресу призначення запиту й повертає safe, private-target, parser-divergent або invalid url. Дозволом є лише safe.

### Що таке URL типу parser-divergent?

Це URL, який різні парсери читають по-різному, класичний спосіб обійти захист від SSRF. Хук network позначає його, а не дозволяє.

---

# Хук regex: виявлення шаблонів ReDoS

> Перевірте кодову базу на регулярні вирази, схильні до ReDoS, або оцініть окремий шаблон просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/regex
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/regex
Останнє оновлення: 2026-11-03

Хук `regex` є детермінованим рушієм безпеки регулярних виразів, який запускає [спеціалізація `regex`](https://lagune.ai/uk-UA/docs/catalog), і ви можете запускати його самі. Він працює у двох режимах однієї команди: **scan**, що перевіряє кодову базу на шаблони, схильні до **ReDoS** або побудовані під час виконання, і **check**, що оцінює окремий шаблон, який ви йому передаєте.

## Перевірка кодової бази

Без прапорців хук перевіряє весь проєкт. `--dir` обмежує перевірку каталогом, `--file` одним файлом. Обидва можна повторювати й поєднувати в один звіт, і кожен файл з'являється в ньому один раз, навіть якщо його охоплює більше ніж одна ціль.

**Увесь проєкт**

```bash
npx lagune read regex
```

**Каталог**

```bash
npx lagune read regex --dir src/services
```

**Один файл**

```bash
npx lagune read regex --file bin/import.pl
```

**Кілька цілей**

```bash
npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift
```

**З лімітом**

`--limit` задає поріг ReDoS для перевірки (за замовчуванням 25), той самий ліміт, що приймає режим check. Нижчий ліміт суворіший.

```bash
npx lagune read regex --dir src/services --limit 15
```

Вивід є звичайним текстом, заголовки якого пояснюють, як читати кожен розділ. Розділ показується лише тоді, коли в ньому є знахідки.

```text
Vulnerable regular expressions found:

cmd/server/main.go
  ([a-z]+)+$ (exponential, search)

Dynamically built regular expressions (review manually by simulating a constructed regex):

app/payments.php
crates/parser/lexer.rs
lib/validate.py

Static regex wrapped in a constructor (use a literal instead):

config/token.rb
```

Якщо нічого не знайдено, хук виводить один рядок.

```bash
npx lagune read regex --dir src/clean
# => no unsafe patterns found
```

### Як читати розділи

| Розділ                                                                                      | Значення                                                                                                                                                                                                                    |
| ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Vulnerable regular expressions found`                                                      | Шаблони, схильні до ReDoS, згруповані за файлами, кожен шаблон з відступом під файлом, а в дужках пояснено, чому він небезпечний, і, якщо є, його область і прапорці. Кожен рядок небезпечний, тож вердикт не повторюється. |
| `Regular expressions the analysis could not settle (review manually)`                       | Шаблони, щодо яких аналіз не зміг дійти висновку в межах свого ліміту роботи, перелічені так само.                                                                                                                          |
| `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Файли, що будують регулярний вираз зі змінної, конкатенації чи інтерполяції.                                                                                                                                                |
| `Static regex wrapped in a constructor (use a literal instead)`                             | Файли, що передають звичайний рядковий літерал у конструктор регулярного виразу там, де літерал регулярного виразу простіший і не потребує компіляції під час виконання.                                                    |

Перший розділ є знахідкою безпеки. Другий і третій самі по собі не є знахідками: вони вказують на код, щодо якого статична перевірка не може дійти висновку, тож потребують, щоб його прочитала людина. Четвертий є підказкою для зрозумілості коду, а не знахідкою безпеки.

### Параметри CLI

| Параметр    | Значення                    | Опис                                                                                                    |
| ----------- | --------------------------- | ------------------------------------------------------------------------------------------------------- |
| `--pattern` | джерело регулярного виразу  | Перевірити один шаблон. Повторіть, щоб перевірити кілька, по вердикту на шаблон, у тому самому порядку. |
| `--flags`   | прапорці регулярного виразу | Перевірити кожен `--pattern` з цими прапорцями, як-от `im`. Діє лише в режимі check.                    |
| `--dir`     | каталог                     | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.                                    |
| `--file`    | файл                        | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`.                                  |
| `--limit`   | невід'ємне ціле число       | Задати ліміт повторень ReDoS (за замовчуванням 25). Діє в обох режимах. Нижчий ліміт суворіший.         |

Без параметрів хук перевіряє весь проєкт. `--pattern` вмикає режим check і не поєднується з `--dir` чи `--file`.

### Підтримувані мови

Перевірка читає ці мови, визначаючи їх за розширенням файлу, кожну за її власними правилами, тож шаблон з однієї мови ніколи не перевіряється за правилами іншої. Усе інше пропускається, а не перевіряється за хибними правилами.

| #   | Мова                        | Розширення                                                                                                   |
| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ |
| 1   | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` |
| 2   | **Python**                  | `.py`, `.pyi`                                                                                                |
| 3   | **Ruby**                    | `.rb`                                                                                                        |
| 4   | **Go**                      | `.go`                                                                                                        |
| 5   | **PHP**                     | `.php`                                                                                                       |
| 6   | **Rust**                    | `.rs`                                                                                                        |
| 7   | **Java**                    | `.java`                                                                                                      |
| 8   | **C#**                      | `.cs`                                                                                                        |
| 9   | **C**                       | `.c`, `.h`                                                                                                   |
| 10  | **C++**                     | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx`                                                                 |
| 11  | **Kotlin**                  | `.kt`, `.kts`                                                                                                |
| 12  | **Swift**                   | `.swift`                                                                                                     |
| 13  | **Scala**                   | `.scala`, `.sc`                                                                                              |
| 14  | **Dart**                    | `.dart`                                                                                                      |
| 15  | **PowerShell**              | `.ps1`, `.psm1`, `.psd1`                                                                                     |
| 16  | **Elixir**                  | `.ex`, `.exs`                                                                                                |
| 17  | **Objective-C**             | `.m`, `.mm`                                                                                                  |
| 18  | **R**                       | `.r`                                                                                                         |
| 19  | **Julia**                   | `.jl`                                                                                                        |
| 20  | **Clojure**                 | `.clj`, `.cljs`, `.cljc`, `.edn`                                                                             |
| 21  | **Crystal**                 | `.cr`                                                                                                        |
| 22  | **Nim**                     | `.nim`, `.nims`                                                                                              |
| 23  | **V**                       | `.v`                                                                                                         |
| 24  | **D**                       | `.d`                                                                                                         |
| 25  | **Perl**                    | `.pl`, `.pm`                                                                                                 |

**Найкраще з можливого, але не вичерпно**

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

## Перевірка окремого шаблону

Передайте `--pattern` із джерелом шаблону, щоб оцінити його. Хук виводить одне слово: `safe`, `unsafe`, `undetermined`, коли аналіз досягає свого ліміту роботи, не дійшовши висновку, або `invalid regex`. Повторіть `--pattern`, щоб оцінити кілька шаблонів одразу, по вердикту на шаблон, у тому самому порядку.

**Один шаблон**

```bash
npx lagune read regex --pattern '(a+)+$'
# => unsafe

npx lagune read regex --pattern '^[a-z0-9_]{3,20}$'
# => safe
```

**Кілька шаблонів**

```bash
npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$'
# => unsafe
# => safe
```

**З прапорцями**

`--flags` перевіряє кожен `--pattern` у виклику з прапорцями, з якими він виконується, бо прапорець змінює, яким символам відповідає шаблон.

```bash
npx lagune read regex --pattern '^(?:a|A)+$'
# => safe

npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i'
# => unsafe
```

**З лімітом**

`--limit` задає ліміт повторень (за замовчуванням 25) і діє для кожного `--pattern` у виклику. Нижчий ліміт суворіший.

```bash
npx lagune read regex --pattern 'a?a?a?' --limit 2
# => unsafe
```

**Чому аргумент у лапках**

Кожен шаблон передається як значення прапорця й ніколи не підставляється в команду. Значення з лапками чи зворотними апострофами залишається інертним і не може здійснити ін'єкцію в оболонку. Завжди беріть шаблон в одинарні лапки, щоб ваша оболонка не розгорнула його першою.

**Порада**

Це той самий рушій, який запускає [спеціалізація `regex`](https://lagune.ai/uk-UA/docs/catalog): перевірка scan відкриває прохід ReDoS, а check підтверджує шаблон, який вона виявляє.

## Часті запитання

### Як перевірити регулярний вираз на ReDoS з CLI?

Виконайте npx lagune read regex --pattern '<pattern>'. Хук повертає safe, unsafe, undetermined або invalid regex.

### Як перевірити весь проєкт на небезпечні регулярні вирази?

Запустіть хук regex у режимі scan над кодовою базою. Він повідомляє про шаблони, схильні до ReDoS, у 25 підтримуваних мовах.

---

# Хук secrets: виявлення жорстко закодованих секретів

> Перевірте кодову базу на жорстко закодовані облікові дані просто з командного рядка.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/hooks/secrets
Мова: uk-UA
Оригінал: https://lagune.ai/docs/hooks/secrets
Останнє оновлення: 2026-11-03

Хук `secrets` позначає **облікові дані, вкомпільовані у вихідний код**, замість того щоб читатися з оточення. Він орієнтується на **походження** (літерал проти звернення до змінної оточення), а не на вміст значення, тож не потребує вичерпного каталогу префіксів провайдерів і майже не дає хибних спрацьовувань. Це детермінований рушій [спеціалізації `secrets`](https://lagune.ai/uk-UA/docs/catalog).

Сигнатури форматів провайдерів, облікові дані в рядках підключення й літерал, прив'язаний до ідентифікатора з назвою секрету, **не залежать від мови**: той самий рядок читається однаково в будь-якому файлі. Дві евристики, що залежать від синтаксису, тобто звернення до змінної оточення з жорстко закодованим значенням за замовчуванням і секрет, що потрапляє в sink журналу, **враховують мову**, тож `console.log` з JavaScript ніколи не шукається у файлі Rust, а `os.getenv("X", "default")` з Python розпізнається окремо.

## Запуск

```bash
npx lagune read secrets                  # scans the whole project
npx lagune read secrets --dir src        # scans a directory
npx lagune read secrets --file config.ts # scans a single file
```

Перевірка виводить до двох розділів. **Hardcoded secrets found** є набором знахідок (жорстко закодоване значення за замовчуванням для змінної оточення з назвою секрету, облікові дані, вбудовані в рядок підключення, або значення, що відповідає перевіреному формату провайдера), тож хук завершується з ненульовим кодом. **Secret handling to review manually** є набором зачіпок: звичайний літерал, прив'язаний до ідентифікатора з назвою секрету (його походження можна визначити, а от чи є значення справжнім секретом, ні), і значення з назвою секрету, що потрапляє в sink журналу чи відповіді. Чистий запуск виводить `no hardcoded secrets found`.

### Параметри CLI

| Параметр | Значення | Опис                                                                   |
| -------- | -------- | ---------------------------------------------------------------------- |
| `--dir`  | каталог  | Обмежити перевірку каталогом. Повторюється й поєднується з `--file`.   |
| `--file` | файл     | Обмежити перевірку одним файлом. Повторюється й поєднується з `--dir`. |

Без параметрів хук перевіряє весь проєкт.

### Охоплення мов

Знахідка про значення оточення за замовчуванням і зачіпка про sink журналу читають набір форм для кожної мови, тож охоплюють мови нижче й мовчать в інших. Решта три сигнали працюють для **кожного** файлу.

| Сигнал                             | Мови                                                                            |
| ---------------------------------- | ------------------------------------------------------------------------------- |
| Значення оточення за замовчуванням | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# |
| Sink журналу чи відповіді          | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C#    |

**Чи це проблема з політикою використання?**

Ні. Розпізнавання формату секрету, щоб попередити, що його закомічено, є стандартним оборонним інструментом, тією самою операцією, яку виконують gitleaks, trufflehog і push protection від GitHub. Хук постачає сигнатури виявлення (публічні **формати** токенів), а не справжні секрети, і перевіряє та пояснює, а не викрадає дані.

## Часті запитання

### Як хук secrets уникає хибних спрацьовувань?

Він орієнтується на походження, а не на вміст значення. Формати з високою достовірністю (токени провайдерів, значення оточення за замовчуванням, рядки підключення) є знахідками, що завершуються з ненульовим кодом. Звичайний літерал, прив'язаний до ідентифікатора з назвою секрету, є зачіпкою для перегляду, яку треба підтвердити, а той самий ідентифікатор, прочитаний із process.env, узагалі не позначається.

---

# Приклади промптів Lagune: автоматизуйте процес Blue Team

> Готові до копіювання промпти Lagune: перевірка лише для читання, повний процес Blue Team і аудит Zero Trust, а також виявлення в межах коміту, diff гілки чи PR або реального інциденту.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/examples/prompts
Мова: uk-UA
Оригінал: https://lagune.ai/docs/examples/prompts
Останнє оновлення: 2026-11-03

Готові до копіювання промпти Lagune, які можна вставити просто у ваш ШІ-агент.

## 💧 Поверхнева перевірка

Перевірка лише для читання, яка самостійно читає код і повідомляє про кожну ваду з виправленням, не запускаючи процес Blue Team і нічого не записуючи у відстеження Lagune.

**Порада**

Краще працює в режимі планування і з визначеними принципами безпеки (`/lagune-charter`).

**🪼 Стандартно**

| Аспект                   | Компроміс                                                       | Рівень              |
| ------------------------ | --------------------------------------------------------------- | ------------------- |
| **Зусилля**              | Один агент перевіряє й звітує, без субагентів.                  | 1/5 |
| **Час**                  | Швидко. Один прохід лише для читання, нічого не застосовується. | 2/5 |
| **Використання токенів** | Помірне, спільне. Уся перевірка йде в одному контексті.         | 2/5 |

```md
/lagune Ти дослідник кібербезпеки з глибокою експертизою в оборонній безпеці, який використовує Lagune, щоб поглибити свої знання й точність.

Самостійно перевір робочий простір і до кожної знайденої вади підбери конкретне виправлення. Це окрема перевірка, а не процес Blue Team: не запускай detect, plan, harden чи verify і нічого не записуй у відстеження Lagune.

Наприкінці перелічи всі знайдені вади, кожну з її критичністю й конкретним виправленням.
```

**🐬 Кілька агентів**

| Аспект                   | Компроміс                                                                                    | Рівень              |
| ------------------------ | -------------------------------------------------------------------------------------------- | ------------------- |
| **Зусилля**              | Один субагент на файл, кількість залежить від розміру кодової бази.                          | 2/5 |
| **Час**                  | Паралельно для кожного файлу, потім усе об'єднується в один звіт. Як і раніше, лише читання. | 3/5 |
| **Використання токенів** | Вище, але ізольоване. Кожен субагент перевіряє у власному контексті.                         | 3/5 |

````md
/lagune Ти оркестратор кібербезпеки, який використовує Lagune, щоб перелічити шляхи, запустити по субагенту на кожен шлях і об'єднати їхні звіти (увесь вміст читають субагенти).

Ти маєш делегувати завдання субагентам залежно від розміру поточного проєкту: що більша кодова база, то більше субагентів треба запустити, усіх паралельно, давши кожному промпт нижче:

```prompt
/lagune Ти дослідник кібербезпеки з глибокою експертизою в оборонній безпеці, який використовує Lagune, щоб поглибити свої знання й точність.

Самостійно перевір <path> і до кожної знайденої вади підбери конкретне виправлення. Це окрема перевірка, а не процес Blue Team: не запускай detect, plan, harden чи verify і нічого не записуй у відстеження Lagune.

Наприкінці перелічи всі вади в <path>, кожну з її критичністю й конкретним виправленням.
```

Наприкінці об'єднай звіти всіх субагентів в один упорядкований за пріоритетом список вад і виправлень.
````

**Попередження**

Швидка перевірка є одним широким промптом без обмеження обсягу, тож деякі агенти з більшою ймовірністю відмовляться від неї чи перервуть її. Якщо ваш агент опирається, натомість запустіть повний **процес Blue Team** нижче: його обмежені за обсягом покрокові фази блокують значно рідше.

---

## 🌊 Автоматичний аудит Blue Team

Запускає [повний процес команд](https://lagune.ai/uk-UA/docs/get-started/commands) від початку до кінця без пауз на введення.

**🪼 Стандартно**

| Аспект                   | Компроміс                                                                                               | Рівень              |
| ------------------------ | ------------------------------------------------------------------------------------------------------- | ------------------- |
| **Зусилля**              | Один агент, без субагентів, незалежно від розміру кодової бази.                                         | 3/5 |
| **Час**                  | Середній, але менш ретельно у великих кодових базах. Кожна команда виконується один раз, одна за одною. | 4/5 |
| **Використання токенів** | Нижче, але менш ізольоване. Усі команди ділять той самий контекст.                                      | 4/5 |

```md
Виконай такі команди по черзі: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` і `/lagune-verify`.

## Цикл

Коли `/lagune-verify` відхиляє одне чи кілька виправлень, повторюй `/lagune-harden`, а потім `/lagune-verify`, доки всі знахідки не буде належно розв'язано.

## Важливо

- Не зупиняйся й не питай: у разі сумнівів роби все в режимі "full".
```

**🐋 Кілька агентів (глибока перевірка)**

| Аспект                   | Компроміс                                                                                                    | Рівень              |
| ------------------------ | ------------------------------------------------------------------------------------------------------------ | ------------------- |
| **Зусилля**              | Кількість субагентів залежить від розміру кодової бази.                                                      | 5/5 |
| **Час**                  | Довше, але ретельніше. Запускає кілька субагентів, щоб паралельно виявляти, планувати й виправляти знахідки. | 5/5 |
| **Використання токенів** | Вище, але безпечніше. Кожен субагент має власний ізольований контекст без упередженості.                     | 5/5 |

````md
Виконай кожну з таких команд в окремому субагенті, по одній (без зворотних апострофів, лише саму команду):

Промпт субагента 1: `/lagune-charter`
Промпт субагента 2: `/lagune-detect`
Промпт субагента 3: `/lagune-plan`
Промпт субагента 4: `/lagune-harden`
Промпт субагента 5: `/lagune-verify`

У командах `/lagune-detect`, `/lagune-plan`, `/lagune-harden` і `/lagune-verify` ти маєш делегувати завдання субагентам залежно від розміру поточного проєкту: що більша кодова база, то більше субагентів треба запустити. Наприклад:

```prompt
/lagune-detect <path>
```

```prompt
/lagune-plan <finding>
```

```prompt
/lagune-harden <finding>
```

```prompt
/lagune-verify <finding>
```

- Кілька агентів для тієї самої команди треба запускати паралельно.
- Коли всі субагенти `/lagune-detect` завершать роботу, виконай:

```prompt
/lagune-detect об'єднай рівнозначні знахідки. Не шукай нових знахідок і не перевіряй кодову базу знову.
```

## Цикл

Коли `/lagune-verify` відхиляє одне чи кілька виправлень, повторюй `/lagune-harden`, а потім `/lagune-verify`, доки всі знахідки не буде належно розв'язано.

## Важливо

- Не зупиняйся й не питай: у разі сумнівів роби все в режимі "full".
````

---

## 🪄 Виявлення в обмеженому обсязі

Спрямуйте [`/lagune-detect`](https://lagune.ai/uk-UA/docs/commands/detect) на частину проєкту замість усього проєкту. Опишіть обсяг простою мовою (коміт, pull request чи реальну ситуацію), і вона визначить лише знахідки, важливі для безпеки в цих межах.

**Порада**

Усе, що вона тут виявляє, є звичайними знахідками, тож їх можна одразу передати в `/lagune-plan`, `/lagune-harden` і `/lagune-verify`, обмеживши лише цими елементами.

**📌 Від коміту**

Проведіть окрему перевірку безпеки для свіжої порції комітів, обмежену лише тим, що вони змінили, наприклад:

```prompt
/lagune-detect Обмеж виявлення всім, що змінилося після коміту `a1b2c3d`.
```

**🔀 Diff гілки чи PR**

Перевірте pull request на безпеку до злиття, обмежившись лише його diff, наприклад:

```prompt
/lagune-detect Обмеж виявлення змінами, які ця гілка вносить порівняно з `main`.
```

**⛑️ Після інциденту**

Опишіть, що сталося, власними словами. Lagune читає ситуацію, а не прапорець, і перетворює її на цільовий пошук, наприклад:

```prompt
/lagune-detect Кілька тижнів тому на нашому сайті стався витік даних. Я не знаю точно, як це сталося, і боюся, що щось досі відкрите й може знову злити дані. Уважно пройдися кодом, зосередься на всіх місцях, де чутливі дані читаються, зберігаються чи розкриваються, і визнач усе, що досі може бути шляхом назовні. Стався до цього як до реального інциденту, а не навчань.
```

---

## 🚨 Аудит Zero Trust

Вважає весь робочий простір і кожну залежність ворожими: шукає інтерпретатори, мережеві виклики, закодовані payload і код, захований у несподіваних місцях, щоб прослизнути повз сканери, а наприкінці виносить вердикт go/no-go щодо того, чи безпечно використовувати проєкт.

Промпти напряму завантажують спеціалізації, на які спирається цей аудит, незалежно від категорій вашого проєкту. Для решти каталогу, яку підбирає `/lagune`, переконайтеся, що проєкт використовує **OWASP**, **ШІ / LLM** і категорію свого стеку (наприклад, **JavaScript**, **Python** тощо):

```bash
npx lagune write add --categories owasp ai javascript
```

**Небезпека**

Будьте обережні, запускаючи проєкти з недовірених джерел у своєму локальному середовищі. Використовуйте ізольоване середовище, як-от **пісочницю** (рекомендовано), **VM** чи щось подібне, щоб шкідливий код не вплинув на вашу систему.

**🪼 Стандартно**

| Аспект                   | Компроміс                                                                             | Рівень              |
| ------------------------ | ------------------------------------------------------------------------------------- | ------------------- |
| **Зусилля**              | Один агент перевіряє весь робочий простір, без субагентів.                            | 2/5 |
| **Час**                  | Середній. Один агент послідовно опрацьовує код і його залежності.                     | 3/5 |
| **Використання токенів** | Помірне, але спільне. Спеціалізації, код і залежності завантажуються в один контекст. | 3/5 |

```md
/lagune Ти дослідник кібербезпеки з глибокою експертизою в оборонній безпеці за принципом zero trust, який використовує Lagune, щоб поглибити свої знання й точність.

Досліди весь робочий простір як недовірене джерело й потенційно шкідливу область. Кожен інтерпретатор, fetch, base64 тощо треба вважати потенційною загрозою.

Пошир аналіз на залежності й транзитивні залежності: проєкт може спробувати сховати шкідливий код у несподіваному місці, щоб прослизнути повз сканери.

Обов'язкові спеціалізації (завантажуй їх по одній через `npx lagune read catalog <name>`):

- interpreter
- secrets
- llm
- path

Щоб було ясно: кожну знайдену вразливість треба вважати потенційною загрозою, без винятків.

Наприкінці винеси вердикт, чи безпечний і надійний проєкт для мого використання.
```

**🐋 Кілька агентів (глибока перевірка)**

| Аспект                   | Компроміс                                                                                         | Рівень              |
| ------------------------ | ------------------------------------------------------------------------------------------------- | ------------------- |
| **Зусилля**              | Один субагент на файл, кількість залежить від розміру кодової бази.                               | 5/5 |
| **Час**                  | Довше, але ретельніше. Файли перевіряються паралельно, потім усе об'єднується в один вердикт.     | 4/5 |
| **Використання токенів** | Найвище, але найбезпечніше. Кожен субагент читає спеціалізації у власному ізольованому контексті. | 5/5 |

````md
/lagune Ти оркестратор кібербезпеки, який використовує Lagune, щоб перелічити файли, запустити по субагенту на кожен файл і згенерувати звіти (увесь вміст читають субагенти).

Запусти по одному субагенту на файл, усіх паралельно, давши кожному промпт нижче, обмежений його файлом:

```prompt
/lagune Ти дослідник кібербезпеки з глибокою експертизою в оборонній безпеці за принципом zero trust, який використовує Lagune, щоб поглибити свої знання й точність.

Вважай <file> недовіреним джерелом і потенційно шкідливою областю. Кожен інтерпретатор, fetch, base64 тощо треба вважати потенційною загрозою.

Пошир аналіз на все, що імпортує <file>, зокрема залежності й транзитивні залежності, де може ховатися шкідливий код, щоб прослизнути повз сканери.

Обов'язкові спеціалізації для кожного субагента (завантажуй їх по одній через `npx lagune read catalog <name>`):

- interpreter
- secrets
- llm
- path

Щоб було ясно: кожну знайдену вразливість треба вважати потенційною загрозою, без винятків.

Наприкінці винеси вердикт, чи безпечний і надійний проєкт для мого використання.
```

Наприкінці об'єднай звіти всіх субагентів в один остаточний вердикт.
````

---

# Security-Driven Hardening: конвенція для епохи розробки з допомогою ШІ

> Методологія Security-Driven Hardening (SDH): конвенція Blue Team з урахуванням контексту для аудиту й посилення захисту програм, створених з допомогою ШІ та у стилі vibe coding.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/references/paper
Мова: uk-UA
Оригінал: https://lagune.ai/docs/references/paper
Останнє оновлення: 2026-11-03

- **Weslley Araújo**
- **Стаття про методологію, 2026.**

---

## Анотація

Security-Driven Hardening (SDH) є структурованою, керованою ШІ, суто оборонною методологією безпеки для епохи, у якій програмне забезпечення дедалі частіше пишуть ШІ-агенти й люди, що не є фахівцями з безпеки. Замість загального чек-листа SDH спершу визначає, що насправді робить система (вхід, завантаження файлів, платежі, розкриття даних тощо), а потім спрямовує роботу з безпеки, специфічну саме для цього контексту. Нею керують принципи безпеки за замовчуванням, вона повністю зосереджена на захисті й викладена простою мовою, щоб будь-який користувач міг діяти на її основі.

Цей документ стверджує, що SDH є відсутньою конвенцією, а не окремим інструментом. Знання з безпеки містяться в методології та її спеціалізаціях на вимогу, базовому рівні, на який може спиратися кожен користувач, і це дає їй змогу обслуговувати новачка й експерта тим самим процесом. Дві властивості вирізняють її серед попередніх підходів, що ставлять специфікацію на перше місце `[1]`. SDH **не залежить від стану**: вона пристосовується до порожнього каталогу, проєкту в роботі, окремого pull request чи великої застарілої кодової бази в будь-якому стеку. І в SDH **безпеку можна закрити**: ризик, закриття якого перевірено, знімається з обліку в усьому процесі, тож знахідка досягає усталеного стану й відкривається знову лише тоді, коли змінюється код. SDH не замінює фахівців з безпеки чи спеціалізовані інструменти Blue Team. Вона розширює власні знання розробника, і що краще розробник розуміє безпеку, то більше він може нею керувати.

**Lagune** є еталонною реалізацією, і він доводить, що методологію можна побудувати й перенести. SDH пропонується як конвенція, яку можуть прийняти інші.

> **Ключові терміни**
>
> розробка з допомогою ШІ, безпека програмного забезпечення, оборонна безпека, spec-driven development, посилення захисту, робочі процеси під керуванням агентів, закриваність, безпека з урахуванням контексту, знання на вимогу, інструменти, незалежні від агента.

---

## I. Вступ: прогалина в безпеці, яку відкрила розробка з допомогою ШІ

Програмне забезпечення дедалі частіше випускають люди й ШІ-агенти, які не можуть надійно розпізнати небезпечний шаблон: витік секрету, відсутню перевірку авторизації, запит, уразливий до ін'єкції. Це не екзотичні ризики. Вони належать до класів ризиків, що домінують у реальних інцидентах і роками описуються в публічних джерелах `[6]`, `[7]`, а нещодавні дослідження повідомляють, що помітна частка коду, згенерованого ШІ, виходить саме з такими дефектами `[8]`. ШІ-асистенти для програмування загострили проблему, давши нерозробникам змогу випускати реальне програмне забезпечення, але прогалина ширша за будь-яку окрему аудиторію. Більшість проєктів ніколи не проходять перевірку безпеки, специфічну для того, що вони насправді роблять. Екосистема стає крихкішою з кожним передчасним рішенням "працює, випускаємо".

Загальні поради з безпеки не закривають цю прогалину. Статичний чек-лист не враховує, що робить система, тож засипає невеликий проєкт нерелевантними пунктами й усе одно пропускає ризик, важливий саме для цього проєкту. Проблема не в нестачі знань з безпеки у світі. Проблема в тому, щоб підібрати правильні знання до системи, яка справді перед користувачем, і зробити це для людини, яка може не знати, про що просити.

SDH відповідає на це однією інверсією: **знання з безпеки містяться в специфікації та її спеціалізаціях на вимогу, базовому рівні, на який може спиратися кожен користувач**. Методологія визначає контекст, сортує за пріоритетом ризики, які несе цей контекст, і спрямовує виправлення, тож розробник і нерозробник обслуговуються тим самим процесом. Знахідки й рекомендації залишаються викладеними простою мовою, тож на їхній основі можна діяти незалежно від технічної глибини читача. Експерта це не обмежує, а підсилює, і цю двоїстість ми розвиваємо в `§VI`.

> **Ключова думка**
>
> **Основна інверсія:** знання з безпеки містяться в специфікації та її спеціалізаціях на вимогу, базовому рівні, на який може спиратися кожен користувач. Методологія дізнається, що робить система, підбирає до неї роботу з безпеки й розширює те, що користувач уже знає.

Уявіть розробника, який каже ШІ-асистенту: "мій застосунок дає користувачам завантажити фото профілю". Без перевірки безпеки асистент видає робочий код, який непомітно довіряє всьому, що надсилає клієнт: заявленому типу файлу, імені файлу, розміру. Завантаження йде в реліз, і файл, замаскований під зображення, може нести код, підроблене ім'я може вирватися за межі шляху сховища, а завеликий файл може вичерпати ресурси сервера. Нічого з цього не видно на демо, тож воно йде в реліз.

Той самий код, пропущений через SDH, поводиться інакше. Методологія визначає, що система приймає файли ззовні (виявлення), сортує це в ризики, які несе завантаження (сортування), пропонує перевіряти справжній тип і розмір файлу, перейменовувати його під час збереження й зберігати там, де код не може виконатися (усунення), а потім читає результат і підтверджує, що кожен засіб захисту справді діє (перевірка). Розробнику ніколи не довелося знати фразу "unrestricted file upload". Методологія підставила її за нього.

Цей документ робить такі внески:

- Точне визначення SDH як методології, незалежної від будь-якої окремої реалізації, з її принципами проєктування (`§III`).
- П'ятифазний оборонний життєвий цикл, у якому розподіл обов'язків сам є внеском: виявлення ніколи не вигадує, планування ніколи не читає код, лише одна фаза змінює код, а перевірка ніколи не пом'якшує свого судження (`§IV`).
- **Закриваність** як методологічна позиція: окрема знахідка має кінцевий стан, а не нескінченний цикл (`§V`).
- Двоїстість **розширювача знань розробника**: один процес, що захищає новачка й підсилює експерта (`§VI`).
- **Спеціалізації, які не викликаються напряму, і промпт на вимогу**: цільові знання з безпеки, які агент завантажує, коли цього вимагає контекст проєкту, а не за замовчуванням (`§VII`).
- **Незалежність від стану** й **неавторитарна адаптивність**: SDH підходить до будь-якого стану розробки й пристосовується до сценарію, а не нав'язує фіксований обсяг (`§VIII`).
- **Превентивний режим**: той самий захист працює під час створення звичайної роботи, тож код з'являється безпечним за замовчуванням, а фазам залишається менше виправляти (`§IX`).
- Окреме порівняння зі Spec-Driven Development, лінією, з якої виросла SDH і від якої потім відійшла (`§X`).
- Інженерні дисципліни, що дають методології пережити рефакторинги й залишатися незалежною від будь-якого агента: відстеження з ідентичністю за назвою (`§XI`) і носій, незалежний від агента (`§XII`).

---

## II. Передумови й пов'язані роботи

SDH спирається на попередні роботи. Вона успадковує перевірену структуру розробки, що ставить специфікацію на перше місце й керується агентом `[1]`, `[2]`, `[3]`: шаблони, slash-команди, які споживає агент, керівний документ і агента, що виконує фази. Вона заново реалізує цю структуру з оборонною метою. Ця спадкоємність свідома, і один із робочих принципів SDH прямо її називає: будуй робочий процес на перевіреній структурі, а потім спрямовуй його на безпеку.

SDH не є статичним чек-листом загальних рекомендацій. Чек-лист знає багато про безпеку загалом і нічого про проєкт перед ним. SDH змінює цей акцент на протилежний. Свої перші зусилля вона витрачає на виявлення, на те, щоб дізнатися, що робить система, і лише потім звертається до знань, які виявлення робить доречними.

SDH також не замінює фахівців з безпеки чи спеціалізовані інструменти Blue Team. Вона розширює знання розробника (`§VI`). Команді з окремою функцією безпеки варто її зберегти. SDH дає такій команді структурований носій, а команді без неї дає обґрунтований базовий рівень.

SDH також стоїть поруч із детермінованими сканерами безпеки (статичний аналіз, лінтери) `[4]`, `[5]`. Ці інструменти цінні саме тому, що вони детерміновані й відтворювані. SDH здебільшого спирається на міркування агента, тобто обмінює сувору детермінованість на врахування контексту. Методологія не вдає, що це не так. Там, де детермінованість важлива, вона вбудовує детермінований рушій у міркування (`§VII`): агент вирішує, чи варто перевіряти вхідні дані, а детермінована програма вирішує, чи вони небезпечні.

Найближчим попереднім підходом є Spec-Driven Development (SDD), сімейство методологій, що ставлять специфікацію на перше місце й ведуть розробку від виконуваної специфікації. Ми розглядаємо SDD як клас. Найчіткіше як практичну методологію її сформульовано у звіті Piskala `[1]`, а її найпомітнішим інструментарієм під керуванням агента є Spec Kit від GitHub `[2]`, тоді як OpenSpec `[3]` є другим інструментом із того самого сімейства. Вони є канонічними джерелами для порівняння в `§X`.

---

## III. SDH: визначення й принципи проєктування

**Security-Driven Hardening** є структурованою, керованою ШІ методологією безпеки, що робить кодову базу безпечнішою, спрямовуючи роботу від специфікації, яку виконує агент, а не від ситуативних виправлень. Назву натхнено **Blue Teams**, захисниками в безпеці. SDH стосується захисту, посилення захисту й перевірки, а ніколи не нападу.

> **Визначення**
>
> **Security-Driven Hardening (SDH):** структурована, керована ШІ, суто оборонна методологія безпеки, що спершу визначає, що насправді робить система, а потім спрямовує роботу з безпеки, специфічну для контексту, під керуванням принципів безпеки за замовчуванням і простою мовою.

SDH визначається набором обов'язкових принципів. Кожен із них є правилом, і кожен дає користувачу певну гарантію.

| Принцип                                                                  | Правило                                                                                                                                                                     | Що він гарантує користувачу                                                                                                                                                   |
| ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Безпечно за замовчуванням, простою мовою, для всіх однаково              | Кожне значення за замовчуванням, повідомлення й виправлення безпечне одразу й зрозуміле будь-якому читачу, розробнику чи ні. Жоден рівень користувачів не має переваг.      | Новачок отримує безпечний базовий рівень, не просячи про нього, і читає результат своїми словами.                                                                             |
| Контекст понад загальність                                               | Кожна фаза починає з контексту, виявленого в detect, і діє відповідно до того, що насправді робить система.                                                                 | Рекомендації відповідають проєкту, а не чек-листу. Знання з безпеки містяться в специфікації та її спеціалізаціях на вимогу й розширюють усе, що приносить користувач.        |
| Гнучкість понад жорсткість                                               | Принципи, вимоги й рекомендації є відправними точками. Користувач може переформулювати, прибрати, додати будь-що або звузити його обсяг.                                    | Методологія підлаштовується під проєкт і користувача й ніколи не буває суворішою, ніж хоче користувач. Гнучкість ніколи не послаблює базовий рівень безпеки за замовчуванням. |
| Узгоджувати, а не лише дописувати                                        | Артефакти є живими документами, а не журналами. Кожен запуск перевіряє кожен запис: зберігає те, що досі слушне, переписує змінене, прибирає те, що вже не стосується.      | Запис завжди відображає теперішнє, тож ніколи не перетворюється на застарілий беклог.                                                                                         |
| Лише захист                                                              | SDH перевіряє, посилює захист і верифікує. Вона ніколи не створює наступальних інструментів, експлойтів для зловмисного використання чи способів обійти виявлення на шкоду. | Методологію неможливо перетворити на зброю. Вміст подвійного призначення з'являється лише в чітко оборонному контексті.                                                       |
| Специфікація на першому місці, керування агентом, спрямування на безпеку | Робочий процес побудовано з шаблонів, команд, керівних принципів безпеки й агента, що виконує фази.                                                                         | Перевірена структура розробки, перепрофільована так, щоб агент виконував суттєву роботу з безпеки.                                                                            |

**Таблиця 1.** Принципи проєктування SDH і гарантія, яку кожен із них дає користувачу.

Ці принципи не декоративні. Це обмеження, яких має дотримуватися кожна фаза нижче, і обговорення в `§XV` повертається до них, щоб окреслити межі методології.

Решта документа розвиває дев'ять іменованих стовпів. Це частини, які читач має тримати в голові, і частини, які інша команда реалізувала б заново, щоб стверджувати, що вона практикує SDH.

| Стовп                                                 | Що він дає                                                                                                         | Розділ      |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------- |
| Інверсія з урахуванням контексту                      | Знання з безпеки містяться в специфікації та її спеціалізаціях на вимогу, тож новачок і експерт мають один процес. | `§I`, `§VI` |
| П'ятифазний оборонний життєвий цикл                   | Розподіл обов'язків: політика, виявлення, сортування, усунення, перевірка, і в кожної одне завдання.               | `§IV`       |
| Закриваність                                          | Знахідка має кінцевий стан, а не нескінченний цикл. Закриту роботу знімають з обліку.                              | `§V`        |
| Двоїстість розширювача знань розробника               | Один процес, що захищає новачка й підсилює експерта, не замінюючи жодного з них.                                   | `§VI`       |
| Промпт на вимогу, знання, які не викликаються напряму | Доречні знання з безпеки завантажуються для того, чим є проєкт, а не за замовчуванням.                             | `§VII`      |
| Незалежність від стану й неавторитарна адаптивність   | Підходить до будь-якого стану розробки в будь-якому стеку й пристосовується до сценарію, а не нав'язує обсяг.      | `§VIII`     |
| Превентивний режим                                    | Той самий захист працює під час створення нової роботи, тож код з'являється безпечним за замовчуванням.            | `§IX`       |
| Відстеження з ідентичністю за назвою                  | Знахідка залишається одним елементом між фазами, а перейменування розриває зв'язок в одному місці.                 | `§XI`       |
| Носій, незалежний від агента                          | Цінність для безпеки записано один раз, і вона не залежить від жодного агента чи стеку.                            | `§XII`      |

**Таблиця 2.** Дев'ять іменованих стовпів SDH і де кожен із них розвивається.

---

## IV. П'ятифазний процес Blue Team

SDH структурує роботу як п'ятифазний оборонний життєвий цикл (рисунок 1). Кожна фаза зосереджена на захисті, кожна спирається на попередню, а фази відтворюють реальну діяльність Blue Team: встановити політику, виявити, відсортувати, усунути, перевірити.

```mermaid
flowchart TB
    charter["1 · charter (політика)<br/>читає: проєкт і, якщо є, опис від користувача<br/>записує: принципи безпеки<br/>кожен принцип простою мовою називає ризик, якому запобігає"]
    detect["2 · detect (виявлення)<br/>читає: код користувача<br/>записує: карту виявлення<br/>виявляти, а не вигадувати: записувати лише те, що підтверджує код"]
    plan["3 · plan (сортування)<br/>читає: карту виявлення, ніколи код<br/>записує: план захисту<br/>кожне виправлення вказує на те, що detect справді визначила"]
    harden["4 · harden (усунення)<br/>читає: план захисту й код, якого він стосується<br/>записує: код і журнал посилення захисту<br/>єдина фаза, що змінює код, по одному виправленню, найменша зміна, яка діє"]
    verify["5 · verify (перевірка)<br/>читає: код і журнал посилення захисту<br/>записує: кожен відкритий вердикт у журнал посилення захисту<br/>зіставлення коду з журналом, статично, без пом'якшення"]
    charter --> detect --> plan --> harden --> verify
    verify -.->|"відхилено: знову відкрита робота для harden,<br/>повторно застосована з огляду на записану причину"| harden
    verify -.->|"закриття: те, що доведено закритим,<br/>знімається з обліку в усьому ланцюжку,<br/>один рядок в історії"| detect
```

**Рисунок 1.** П'ятифазний процес: що читає кожна фаза, що вона записує і її ключовий інваріант. Verify керує обома поверненнями: відхилений засіб захисту знову відкриває harden, а знахідку, закриття якої доведено, знімають з обліку в усьому ланцюжку, залишаючи один рядок в історії.

Розподіл обов'язків і є внеском. Оскільки кожна фаза має одне завдання, збій залишається в одному місці, а читач може довіряти тому, що стверджує кожен артефакт.

> **Ключова думка**
>
> **Applied не означає перевірене:** harden записує, що виправлення застосовано. Verify перевіряє це, зіставляючи код із цим записом, і вердикт ніколи не пом'якшується, щоб відповідати запису. Засіб захисту може бути в коді й при цьому залишати ризик досяжним, і тоді чесний вердикт: "risk not closed".

### charter (політика)

Charter встановлює принципи безпеки проєкту, правила, яких має дотримуватися кожна наступна фаза. Це керівний рівень, своєрідна перевірка під час компіляції для рівня захищеності проєкту. Кожен принцип має чітку назву, непорушне правило, яке можна перевірити за кодом, і рядок `Why:`, що називає ризик, якому принцип запобігає, а не лише виправлення. Charter завжди читає сам проєкт (його маніфести, структуру й залежності), а опис користувача, якщо він є, задає напрям, який аналіз потім розширює за межі названого користувачем. Без опису проєкт є єдиним джерелом. Ці джерела доповнюють, а не заперечують одне одного, і charter записує політику, якої має дотримуватися проєкт, а не стан його коду. Нерозробник має змогу прочитати її й зрозуміти і правило, і ризик.

### detect (виявлення)

Detect читає код і визначає, що насправді робить система з того, що має вагу для безпеки. Головна настанова: "виявляти, а не вигадувати", тобто записувати лише те, що підтверджує код, разом із доказами, потрібними наступним фазам. Detect нейтральна. Вона не підганяє свої знахідки під принципи безпеки, бо зіставляти ризики з правилами принципів безпеки є завданням фази plan. Кожна знахідка має три частини: що це (опис простою мовою), чому це важливо (ризик, а не лише факт) і доказ (функція чи маршрут, де вона міститься). Доказ не містить шляху до файлу. Шлях зберігається лише в карті відстеження (`§XI`), тож текст ніколи не містить шляху, який може застаріти.

### plan (сортування)

Plan перетворює кожну знахідку на виправлення, назване за класом ризику (з посиланням на усталені джерела, CWE та OWASP, там, де вони його обґрунтовують) і прив'язане до принципу безпеки, який підтримує виправлення. Пріоритет (Critical, High, Medium, Low) не є вільним вибором: plan оцінює кожну знахідку методом CVSS v4.0 з метриками Base і Environmental, тож рівень є оцінкою, переказаною простими словами й обґрунтованою одним рядком простою мовою про відкритість і значущість, і два запуски дають той самий порядок. Вектор є точною опорою для експерта, а рівень і його обґрунтування є тим самим рейтингом, зрозумілим будь-кому. Plan працює лише з картою виявлення й ніколи не читає код. Це свідоме обмеження, а не недолік: воно змушує кожне виправлення вказувати на те, що detect справді виявила. Якщо якусь область ще не досліджено, plan зупиняється й повертає користувача до detect, а не вгадує.

### harden (усунення)

Harden є єдиною фазою, що змінює код, тож вона діє обережно. Чи потребує правка схвалення користувача, вирішують агент і режим дозволів, у якому він працює, тож harden не додає власного кроку підтвердження. Вона застосовує по одному виправленню, спершу залежності, потім найвищий пріоритет, тож кожна зміна залишається невеликою, зручною для перегляду й легкою для скасування. Вона ніколи не послаблює наявний засіб захисту, щоб припасувати нове виправлення, і ніколи не порушує принцип безпеки. Якщо виправлення суперечило б принципу, harden зупиняється й показує конфлікт замість того, щоб застосувати виправлення. Кожен блок записується як Applied, Partial чи Blocked. "Applied ще не означає перевірене", і саме цим займається наступна фаза.

### verify (перевірка)

Verify перевіряє кожен застосований засіб захисту, читаючи код і зіставляючи його з тим, що записала harden. Перевіркою є саме це зіставлення коду з журналом, і воно статичне: воно підтверджує, що засіб захисту наявний і коректний у коді, а не що він витримує атаку на працюючу систему. Така перевірка під час виконання, що проводить реальні чи змодельовані атаки на робочу систему, свідомо лишається поза обсягом. Verify повертає один із трьох вердиктів: risk closed, risk not closed або cannot tell from the code. Вона не створює власного артефакту: harden і verify ділять журнал посилення захисту, при цьому harden володіє тим, що зроблено, а verify вердиктом і його причиною, і жодна з них ніколи не пише в поля іншої. Відхилений засіб захисту є знову відкритою роботою для harden, яка під час наступного запуску ставить вердикт вище за власне прочитання коду й повторно застосовує виправлення саме до тієї прогалини, яку називає причина. Verify довіряє коду більше, ніж журналу, бо журнал може заявляти більше, ніж дає код. Код користувача вона лише читає й ніколи не пом'якшує вердикт, щоб він відповідав журналу. Засіб захисту може бути наявним і все одно залишати ризик досяжним іншим шляхом, і в такому разі чесний вердикт: "risk not closed". Якщо під час читання verify помічає проблему безпеки, якої карта виявлення ніколи не охоплювала, вона не вигадує для неї вердикт, бо виявлення є завданням detect: вона показує проблему й повертає користувача до detect, тож знахідка входить тим самим процесом, а не в обхід нього.

> **Наскрізний приклад: завантаження файлів.** Одна знахідка показує весь хребет від початку до кінця.
>
> - **detect** знаходить її: система приймає файли від користувачів, а обробник завантаження довіряє MIME-типу, який надсилає клієнт, не перевіряючи справжній тип файлу. _Чому це важливо:_ файл, замаскований під зображення, може приховувати шкідливий код.
> - **plan** визначає виправлення з пріоритетом **Critical**, що підтримує принцип "Усі вхідні дані недовірені, доки їх не перевірено": перевіряти справжній тип і розмір файлу, перейменовувати його під час збереження й зберігати завантаження там, де їх неможливо виконати як код.
> - **harden** застосовує його зі статусом **Applied**: обробник тепер визначає справжній тип за вмістом, обмежує розмір, відхиляє все неочікуване, перейменовує файл під час збереження й зберігає його там, де код не може виконатися.
> - **verify** читає обробник, зіставляє його з журналом і повертає **risk closed**: код робить саме те, що заявлено в журналі.
>
> Та сама назва знахідки проходить через карту виявлення, план і журнал посилення захисту, а verify діє з цим журналом під тією самою назвою: відкритий вердикт записується в блок знахідки, а знахідку, закриття якої доведено, знімають з обліку (`§V`). Ця спільна назва є її ідентичністю (`§XI`).

---

## V. Закриваність: знахідка має кінцевий стан

Більшість інструментів безпеки залишає користувачу беклог, який лише росте. SDH займає іншу позицію: **знахідку можна закрити, тож вона має кінцевий стан, а не живе в нескінченному беклозі** (рисунок 2). Це прямо випливає з принципу узгодження.

> **Визначення**
>
> **Закриваність:** ризик, закриття якого перевірено, знімається з обліку в усьому процесі, тож знахідка досягає усталеного стану й відкривається знову лише тоді, коли змінюється код. Знахідка має кінцевий стан, хоча сама програма безпеки залишається безперервною.

Артефакти SDH є живими документами, а не журналами подій. Щоразу, коли фаза запускається повторно, вона звіряє кожен наявний запис із поточною правдою й робить одне з трьох: зберігає те, що досі слушне, переписує змінене або прибирає те, що вже не стосується. Знахідку, яку, як показує код, уже розв'язано, просто прибирають. Робочий запис відображає теперішнє, а не минуле.

Закриття є тим самим узгодженням, доведеним до завершення. Коли verify підтверджує, що ризик закрито, вона знімає знахідку з обліку в усьому процесі: у карті виявлення, плані, журналі посилення захисту й карті відстеження. Саме тому verify є єдиною фазою, що пише в артефакти інших фаз: це фаза, що замикає цикл. Коли знахідка залишає ланцюжок, зняття з обліку стисло переносить її в короткий запис в історії, яка зберігається поза робочим ланцюжком і ніколи не обробляється повторно. У цьому й полягає межа між зникненням і закриттям: знахідка, яку узгодження прибрало, бо вона перестала бути правдою, нічого по собі не залишає, тоді як знахідка, закриття якої доведено, заслуговує на свій рядок в історії. Знахідки, знятої з обліку, після цього немає в жодному робочому артефакті, і ця відсутність очікувана, а не ознака розірваного ланцюжка.

```mermaid
stateDiagram-v2
    direction TB
    [*] --> OPEN: detect виявляє
    OPEN --> Plan: plan
    Plan --> Harden: harden
    Harden --> Verify: verify
    Verify --> StoodDown: risk closed
    StoodDown --> SETTLED
    SETTLED --> OPEN: зміни коду знову відкривають знахідку
    Plan: plan
    Harden: harden
    Verify: verify
    StoodDown: ЗНЯТО З ОБЛІКУ · один рядок в історії
```

**Рисунок 2.** Машина станів закриваності. Знахідка переходить OPEN → ЗНЯТО З ОБЛІКУ → SETTLED і відкривається знову лише тоді, коли змінюється код.

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

---

## VI. Двоїстість розширювача знань розробника

SDH не замінює людей і не замінює спеціалізовані інструменти Blue Team. Вона **розширює власні знання розробника**. Що краще розробник розуміє безпеку, то точніше він може керувати процесом і то більше має автономії. Розробник, який розуміє мало, все одно отримує безпечний результат, бо автоматичний режим його захищає.

Інверсія з `§I`, за якою знання з безпеки містяться в специфікації, діє в обох напрямках. Для новачка це захист: йому не треба знати, про що просити, бо специфікація пропонує сама. Для експерта це підсилення: та сама специфікація дає йому змогу точно спрямовувати процес, а не боротися з фіксованим чек-листом.

Кожна фаза несе цю двоїстість у власній роботі (рисунок 3). Запущена без вхідних даних, вона діє на весь обсяг від імені користувача. Отримавши вказівки, та сама фаза звужується саме до того, на що її спрямував користувач.

```mermaid
flowchart TB
    inversion["одна інверсія, два напрямки:<br/>знання з безпеки містяться в специфікації"]
    inversion --> auto["автоматичний режим (без вхідних даних)<br/>фаза пропонує й діє<br/>на весь обсяг"]
    inversion --> directed["спрямований режим (є вхідні дані)<br/>фаза звужується саме до того,<br/>на що її спрямував користувач"]
    auto --> novice["новачок під захистом:<br/>безпечний результат без<br/>знання, про що просити"]
    directed --> expert["експерт підсилений:<br/>процес спрямовано точно,<br/>а не фіксованим чек-листом"]
    novice -.-> phases["ті самі п'ять фаз служать обом:<br/>charter · detect · plan · harden · verify"]
    expert -.-> phases
```

**Рисунок 3.** Двоїстість розширювача знань розробника. Одна інверсія служить двом аудиторіям: автоматичний режим захищає новачка, а спрямований режим підсилює експерта, через ті самі п'ять фаз.

Спеціалізації на вимогу (`§VII`) роблять цю двоїстість явною у власному тексті. Кожна з них каже агенту, що її знання "розширюють твоє судження", і просить міркувати далі за межі того, що дає спеціалізація. Знання є мінімумом, а не стелею. Саме це служить обом аудиторіям у тому балансі, який задумав документ: спільнота розробників отримує вагомий інструмент, а практик Blue Team отримує структурований носій, який не вдає, що виконує його роботу за нього.

---

## VII. Спеціалізації, які не викликаються напряму, і промпт на вимогу

Це найновіший шаблон методології. SDH несе цільові знання з безпеки у вигляді спеціалізацій, що завантажуються **лише на вимогу**, і агент сам вирішує, які завантажити, зіставляючи їх із контекстом проєкту. Ми називаємо це **промптом на вимогу**: способом для агента вибирати, які знання активувати, залежно від обсягу проєкту, у якому він працює, а не запускати всі перевірки за замовчуванням. Спеціалізації еволюціонують, і будь-яку з них можна будь-коли змінити чи замінити. Внеском є шаблон, а не самі спеціалізації.

> **Визначення**
>
> **Промпт на вимогу:** агент вибирає, які знання з безпеки активувати, зіставляючи їх з обсягом проєкту перед ним, тож потрібні знання підтягуються для того, чим насправді є проєкт, замість того щоб за замовчуванням запускалися всі перевірки.

> **Визначення**
>
> **Спеціалізація, яка не викликається напряму:** цільова, незалежна від мови програмування одиниця знань з безпеки для одного контексту, як-от завантаження файлів чи код, що виконується в браузері. Вона перевіряє й пояснює, ніколи не переписує код і ніколи не створює вхідних даних для атаки. Це не команда: вона завантажується, коли контекст, який вона охоплює, потрапляє в обсяг, або коли промпт просить її за назвою.

Кожна спеціалізація називає безпечніші форми для ризиків, які вона охоплює, і пояснює агенту, як діяти зі знахідкою в кожній фазі, що її використовує: як оцінити її під час виявлення, як безпечно застосувати її виправлення під час усунення і як довести його під час перевірки.

Визначальна риса полягає в тому, що спеціалізація **сама по собі не викликається**: це не команда, і всередині процесу її завантажує збіг. Фаза виявлення один раз переглядає каталог, зіставляє контекст проєкту з тим, що охоплює кожен запис, і завантажує лише ті спеціалізації, чий контекст присутній в обсязі. Наступні фази повторно використовують цей список збігів, а не переглядають каталог знову, тож один збіг служить усьому ланцюжку, а превентивний режим (`§IX`) виконує те саме зіставлення для роботи, яку ось-ось буде створено. Спеціалізацію, чийого контексту немає, пропускають, і за пропуск звітують так само, як за завантаження: кожен запис у каталозі отримує явний вердикт, застосовано чи пропущено, з причиною, прочитаною з коду, тож розмите відчуття нерелевантності ніколи не підміняє відсутність. Не знайти жодної доречної спеціалізації є цілком прийнятним результатом.

Каталог є даними, і його зростання означає один файл знань плюс один рядок у каталозі, а ніколи не нову команду. Вбудовані спеціалізації згруповано в категорії, як-от OWASP, мова програмування чи інтеграції зі ШІ, а каталог, який використовує проєкт, містить вбудовані спеціалізації обраних ним категорій плюс його власні спеціалізації. Проєкт записує цей вибір разом з рештою свого стану, тож уся команда зіставляє код з тим самим каталогом. Це той самий принцип урахування контексту, що й у фазах, застосований до знань: потрібні знання підтягуються для того, чим насправді є проєкт, замість того щоб за замовчуванням запускалися всі перевірки. Та сама властивість дає змогу розширювати каталог не лише мейнтейнеру, а й користувачу: джерело чи тема з безпеки, які надає користувач, стисло викладаються в нову спеціалізацію, що належить проєкту, потрапляє до його каталогу незалежно від категорій і завантажується точно так само, як вбудована, замінюючи вбудовану з тією самою назвою. Створення спеціалізації саме по собі суто оборонне й підпорядковане тій самій межі, яку забезпечують спеціалізації: опис атаки може бути джерелом, але спеціалізація, яку з нього отримано, перевіряє й пояснює і ніколи не видає робочого експлойту. Тож інверсія з `§I`, за якою інтелект міститься в специфікації, поширюється й на сам каталог, який користувач може поглиблювати для власного контексту, не пишучи коду.

Короткий приклад ілюструє промпт на вимогу. Detect читає папку з кодом, що виконується в браузері. Вона знаходить цей контекст у каталозі, завантажує спеціалізацію, яка його охоплює, і виявляє знахідку на боці клієнта звичайними кроками detect. Спеціалізації, чийого контексту немає в цьому обсязі, не збігаються, тож ніколи не завантажуються, і кожну з них записано як пропущену. Які знання доречні, вирішив проєкт, а не фіксована конфігурація.

Детермінованість з'являється саме там, де вона важлива. Спеціалізація може містити детермінований перевіряльник, а не лише текст: там, де клас ризику має чітку процедуру вирішення, невелика програма повертає фіксований вердикт для заданих вхідних даних, наприклад коротке слово на кшталт `safe`, `unsafe` чи `invalid input`. Деякі класи ризиків детерміновано розв'язні саме так, і за процедурою вирішення стоїть масив попередніх робіт `[9]`, `[10]`, `[11]`. Перевіряльник або оцінює кандидатів, яких надає агент, або сам перевіряє обсяг, щоб їх знайти, і в обох випадках вердикт повертає перевіряльник, а не агент. Достатньо універсальну спеціалізацію можна позначити в каталозі як обов'язкову, і тоді вона застосовується завжди, а її перевіряльник запускається на весь обсяг. Це єдиний випадок, коли знання завантажуються без збігу з контекстом, і він задекларований у даних каталогу, а не вирішується агентом у моменті. Саме тут SDH підкріплює міркування агента чимось відтворюваним, не вдаючи, що весь процес детермінований.

Нарешті, спеціалізації **від'єднувані**. Оскільки знання самодостатні, користувач може запустити одну з них напряму в промпті, який не має нічого спільного з повним процесом SDH, і тримати безпеку поруч зі звичайною розробкою. Спеціалізація з детермінованим перевіряльником може, наприклад, перевіряти кожного кандидата, створеного під час звичайного програмування, і залишати лише безпечні. Ця від'єднуваність є однією з причин, чому SDH пристосовується до такої кількості ситуацій, про що йдеться в `§VIII`, а її повний вияв є превентивним режимом (`§IX`), у якому ті самі знання захищають звичайну розробку від початку до кінця.

---

## VIII. Незалежність від стану й неавторитарна адаптивність

Дві властивості відрізняють SDH від жорстких методологій на основі специфікацій.

### Незалежність від стану

> **Визначення**
>
> **Незалежність від стану:** методологія не залежить від стану розробки. Вона підходить до порожнього каталогу, проєкту в роботі, окремого pull request чи великої застарілої кодової бази в будь-якому стеку, бо дізнається вихідну точку, читаючи її.

Кожна фаза працює однаково, хоч проєкт зовсім новий, хоч він уже існує. Charter виводить принципи з будь-якого наявного коду. Detect визначає будь-який код, що є, навіть якщо його зовсім мало. Жодної припущеної вихідної точки немає.

### Неавторитарна адаптивність

> **Визначення**
>
> **Неавторитарна адаптивність:** методологія пристосовується до сценарію, а не нав'язує фіксований обсяг, якого має дотримуватися користувач. Коли користувач не знає, що сказати, вона читає середовище, у якому її викликано, генерує контекст і ставить запитання, що визначають її подальші дії.

Режим пропозиції в charter є найчіткішим прикладом: SDH виводить безпечні за замовчуванням принципи безпеки, аналізуючи проєкт, і питає користувача лише тоді, коли прогалина справді змінює результат, а потім записує їх і подає кожен принцип простою мовою разом із ризиком, якому він запобігає. Принципи безпеки є живим документом, який користувач переробляє повторним запуском, а не контрактом, захованим за запитом на схвалення, тож вони ніколи не вимагають від користувача знати, про що просити.

Ця адаптивність проявляється як чутливість до форми вхідних даних: та сама фаза читає те, що їй дали, і вибирає режим (рисунок 4). Файл у промпті, знахідка зі списку, побоювання, цільова місія проти відомого слабкого місця чи запит на повну перевірку перебором: кожен варіант відповідає потребі користувача, бо процес неавторитарний за задумом. Ніщо з цього не послаблює базовий рівень безпеки за замовчуванням. Гнучкість визначає, як застосовується базовий рівень, і ніколи його не знижує.

```mermaid
flowchart TB
    shape["фаза читає форму<br/>того, що їй дали"]
    shape --> none["без вхідних даних"]
    shape --> paths["один чи кілька шляхів"]
    shape --> concern["описане занепокоєння"]
    shape --> finding["знахідка за назвою"]
    shape --> band["рівень пріоритету"]
    none --> auto["автоматичний режим:<br/>запропонувати або перевірити<br/>весь обсяг"]
    paths --> focus["зосередитися лише на цих<br/>файлах чи каталогах"]
    concern --> scoped["обмежитися цим<br/>одним занепокоєнням"]
    finding --> item["діяти з цим одним<br/>відстежуваним елементом"]
    band --> priority["діяти лише з Critical,<br/>High, Medium чи Low"]
```

**Рисунок 4.** Неавторитарна адаптивність. Та сама фаза читає форму своїх вхідних даних і вибирає режим, тож обсяг завжди належить користувачу, а не нав'язується.

---

## IX. Універсальний превентивний режим: той самий захист під час створення роботи

SDH має один доповнювальний режим: звичайну розробку з тим самим захистом, активним під час написання коду. Користувач просить саму роботу, сторінку входу, завантаження, ендпоінт, а методологія захищає розробку в процесі, тож результат безпечний за замовчуванням із моменту появи, а не після пізнішого проходу посилення захисту.

> **Визначення**
>
> **Превентивний режим:** звичайна розробка під керівним рівнем і знаннями SDH. Принципи безпеки зобов'язують розробку, спеціалізації, доречні для того, що ось-ось буде створено, завантажуються на вимогу, а результат зіставляється саме з тим захистом, який використовувався, перш ніж роботу визнають завершеною.

Режим повторно використовує кожну частину, яку вже несуть фази, спрямовуючи її на код, якого ще не існує. Визначення контексту переходить від коду до наміру: агент міркує над тим, що ось-ось створить, і над межами, які перетинає ця робота (вхід передбачає облікові дані, сесію й вхідні дані ззовні), і саме з цим міркуванням зіставляється каталог знань. Промпт на вимогу (`§VII`) тут узагальнюється: контекст можна виявити в плані коду, а не лише в коді, що вже існує. Принципи безпеки керують, як завжди, а запит, що порушив би принцип, показується як конфлікт і ніколи не виконується. Захист застосовується одразу, у момент написання кожної частини: перевірка на межі й безпечна конструкція з першого разу, тож робочої, але небезпечної версії, яку довелося б виправляти, ніколи не існує.

Режим завершується так, як починається verify. Перш ніж роботу визнають завершеною, той, хто її створює, зіставляє власний результат із захистом, який використав: засіб захисту має стояти на шляху ризику, а не поруч, він має бути повним, а там, де спеціалізація містить детермінований перевіряльник, вердикт перевіряльника стоїть вище за власне прочитання агента. Прогалину, знайдену тут, закривають у межах тієї самої роботи, бо завершити роботу означає завершити її безпечно.

Те, від чого режим відмовляється, так само свідоме, як і те, що він робить. Він створює лише те, про що просили, і нічого не перевіряє навколо: аудит наявного належить фазам. Він не пише артефактів і не відстежує знахідок, бо знахідка є ризиком, виявленим у тому, що вже існує, а мета цього режиму в тому, щоб небезпечна версія взагалі ніколи не з'явилася. Два напрямки доповнюють один одного: фази закривають те, що вже є (`§V`), а превентивний режим не дає новій роботі знову це відкрити. Ланцюжок у стані спокою залишається в ньому не тому, що розробка зупинилася, а тому, що все створене, поки він спочиває, створюється під захистом.

---

## X. Security-Driven Hardening проти Spec-Driven Development

Security-Driven Hardening (SDH) виросла з основи Spec-Driven Development (SDD), а потім різко відійшла від неї. Структурна спадковість реальна й визнана: специфікація на першому місці, керування агентом, керівний документ і набір поетапних команд, які виконує агент. SDH свідомо повторно використовує цю структуру. Відрізняються мета, модель повноважень, припущений стан і умова завершення. Ми розглядаємо SDD як клас, беручи звіт Piskala `[1]` за канонічне формулювання методології, Spec Kit від GitHub `[2]` за канонічний інструментарій для агентів, а OpenSpec `[3]` за другий інструмент із того самого сімейства.

SDD перевертає традиційну розробку, роблячи специфікації виконуваними: специфікація напряму генерує робочу реалізацію, а не лише спрямовує її `[1]`. Її набір фаз веде розробку вперед `[2]` (встановити керівні принципи, описати, що створювати, спланувати технологічний стек, розбити план на завдання, а потім реалізувати). Її керівний документ, конституція принципів, є основою, якої агент має дотримуватися весь час. У цьому суть відмінності. Повноваження SDD течуть від специфікації в розробку, і від реалізації очікують, що вона їй слідуватиме.

SDH перевертає майже кожну вісь цього контракту (таблиця 3).

> **Ключова думка**
>
> **Основна відмінність:** повноваження SDD течуть від специфікації в розробку, і від реалізації очікують, що вона їй слідуватиме. SDH неавторитарна й тече в протилежному напрямку, всередину від виявленого контексту системи, посилюючи захист того, що вже є.

| Вісь                  | SDD                                                                                               | SDH                                                                                                                                          |
| --------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Мета                  | Постачати функції. Специфікація стає робочою реалізацією.                                         | Посилювати захист того, що існує чи створюється. Кожна фаза спрямована на захист.                                                            |
| Модель повноважень    | Авторитарна. Специфікація й конституція обмежують розробку обсягом, якого вона має дотримуватися. | Неавторитарна. SDH пристосовується до сценарію, а користувач може переформулювати, прибрати чи звузити обсяг.                                |
| Припущення щодо стану | Розробка вперед від специфікації.                                                                 | Незалежність від стану: порожній каталог, проєкт у роботі, окремий PR чи застарілий код.                                                     |
| Умова завершення      | Завершується, коли функцію створено.                                                              | Безпеку можна закрити. Знахідка досягає усталеного стану й відкривається знову лише тоді, коли змінюється код.                               |
| Керівний документ     | Конституція принципів, якої має дотримуватися агент.                                              | Принципи безпеки, сформульовані через ризики (кожен має рядок `Why:`), які явно не є фіксованим контрактом.                                  |
| Як ростуть знання     | Додати команду (або розширити набір фаз).                                                         | Додати спеціалізацію, яка не викликається напряму й яку агент завантажує на вимогу: один файл плюс один рядок у каталозі, без нової команди. |
| Кому служить          | Тому, хто веде створення функції вперед.                                                          | Будь-якому користувачу, розробнику чи ні, через той самий процес.                                                                            |
| Що змінює код         | Фаза реалізації генерує розробку.                                                                 | Код змінює лише фаза harden, по одному виправленню.                                                                                          |

**Таблиця 3.** SDD проти SDH за вісьмома осями. Запозичена структура, перевернутий контракт.

Щодо справедливості до попередників: SDD є перевіреним попереднім підходом, і SDH завдячує йому структурою, на якій працює. Розбіжність не є критикою SDD, яка добре розв'язує іншу проблему (розробку вперед). SDH бере той самий перевірений механізм і спрямовує його на захист, адаптивність і закриття. OpenSpec `[3]`, організований довкола пропозицій змін, списків завдань і специфікацій для кожної зміни, підтверджує шаблон: це сімейство веде розробку вперед від специфікації, тоді як SDH посилює захист системи всередину від її виявленого контексту. Навіть превентивний режим SDH (`§IX`), єдине місце, де вона супроводжує розробку вперед, зберігає перевернутий контракт: він визначає, як створюється робота, і ніколи не вирішує, що створювати.

---

## XI. Інженерна ретельність: дисципліна відстеження

Дисципліна "узгоджувати, а не дописувати" (`§V`) потребує основи, що переживає рефакторинги. Знахідка має залишатися одним елементом у кожній фазі, що її торкається, а перейменований чи переміщений файл не має розривати ланцюжок. SDH розв'язує це за допомогою **ідентичності за назвою** і **шляхів, що зберігаються лише у відстеженні**.

> **Визначення**
>
> **Ідентичність за назвою:** ідентичністю знахідки є її назва, записана однаково в кожному артефакті. Текст містить назву, а не шлях. Шляхи до файлів зберігаються лише в карті відстеження, тож перейменування чи переміщений файл розриває зв'язок рівно в одному місці.

Кожна знахідка detect є одним відстежуваним елементом. Її ідентичністю є **назва**, тобто заголовок розділу, записаний однаково в карті виявлення, плані й журналі посилення захисту. Наступні фази дослівно повторно використовують цю назву, діючи з тим самим елементом, а verify записує свій вердикт у журнал посилення захисту під тією самою назвою. Карта відстеження містить відстеження й нічого більше, по одному запису на елемент:

```json
{ "name": "File uploads", "paths": ["src/routes/upload.ts"] }
```

Карта не записує ні тексту, ні анотацій, ні окремого ідентифікатора, ні фази. Текстові артефакти містять формулювання, а карта містить лише ідентичність і шляхи. Шляхи до файлів є єдиним мінливим елементом, і вони зберігаються лише тут. Перейменування чи переміщений файл може розірвати зв'язок рівно в одному місці, а не у двох копіях, що розійшлися.

```mermaid
flowchart TB
    detect["карта виявлення"] --> name
    plan["план захисту"] --> name
    harden["журнал посилення захисту<br/>verify записує сюди свій вердикт"] --> name
    name["name = &quot;File uploads&quot;<br/>текст містить назву, а не шлях"]
    name -.-> tracking
    tracking["карта відстеження<br/>{ name: &quot;File uploads&quot;,<br/>paths: [&quot;src/routes/upload.ts&quot;] }<br/>шлях зберігається лише тут, тож перейменування виправляє лише цей запис"]
```

**Рисунок 5.** Конвеєр ідентичності. Одна назва знахідки проходить через кожен артефакт, а її шлях зберігається лише в карті відстеження, тож перейменування виправляють в одному місці.

Два акти підтримують карту у звичайному процесі, а третій стоїть окремо як обслуговування. **Track** є адитивною реєстрацією: фаза повідомляє про знахідки, які записала, а рушій записує нові й стежить за перейменованим шляхом для решти, класифікуючи кожну як нову, переміщену чи незмінну. Він ніколи не прибирає нічого, про що фаза не повідомила. **Untrack** знімає з обліку знахідки, які закрила verify: за один детермінований прохід він стисло переносить кожну в її запис в історії, прибирає весь її розділ з артефактів, видаляє артефакт, остання знахідка якого зникла, і прибирає її запис у відстеженні, тож агент нічого з цього не робить вручну. Там, де детермінований прохід не може безпечно діяти, наприклад коли назву знятої з обліку знахідки досі цитує текст іншої знахідки, він позначає це місце для агента, а не вгадує правку. Ці два акти фази викликають під час роботи. **Repair** є актом обслуговування: фаза автоматично делегує йому роботу, коли її власне узгодження виявляє, що відстеження неузгоджене (записаний шлях більше не існує), а в інших випадках його запускають на вимогу. Він вирівнює всю карту одразу, читаючи кожен артефакт і поточний код, виправляючи шляхи кожного елемента й показуючи те, чого не може вирішити сам: сироту (відстежуваний елемент, який більше не називає жоден артефакт) чи кандидата на перейменування (елемент, чиї шляхи збігаються з іншою повідомленою назвою).

Repair є обслуговуванням, а не шостою фазою. Він не торкається ні коду користувача, ні текстових артефактів, лише відстеження. Він читає вихідний код користувача лише з однією метою, щоб дізнатися новий шлях перейменованого файлу, і ніколи не пише вміст про безпеку. Людина є остаточним арбітром у тому єдиному питанні, яке рушій відмовляється вгадувати: чи зниклий елемент розв'язано, чи лише перейменовано. Краще спитати, ніж вгадувати, бо помилково прибраний елемент розриває ланцюжок.

Методологія застосовує власну дисципліну захисту до самої себе. Детерміновані рушії викликаються як програми командного рядка, і кожне вхідне значення передається як окремий аргумент процесу, що залишає його інертним, тож значення з лапками чи зворотними апострофами ніколи не може здійснити ін'єкцію в команду. Невідома перевірка завершується помилкою, а не відповіддю, тож перевірка з помилкою в назві ніколи не виглядає як чистий результат. SDH не звільняє власну інфраструктуру від принципу безпеки за замовчуванням.

---

## XII. Носій: архітектура, незалежна від агента, як доказ переносимості

Щоб SDH стала конвенцією, яку приймають інші, вона не має бути прив'язаною до одного агента чи одного стеку, тож її носій розділяє три аспекти (рисунок 6). Lagune доводить, що це досяжно.

**Цінність для безпеки** записано один раз, і вона нічого не знає про те, який агент її виконує: інструкції фаз і шаблони, які вони заповнюють, каталог знань і детерміновані рушії. **Доставка** тонка: її єдине завдання полягає в тому, щоб донести цю цінність до конкретного агента у формі й місці, яких він очікує, і вона не несе власної логіки безпеки. **Стан проєкту** належить проєкту: принципи безпеки, артефакти фаз, карта відстеження, обрані ним категорії й власні спеціалізації, закомічені й доступні для перегляду, як і будь-яка інша частина його коду.

```mermaid
flowchart TB
    value["цінність для безпеки, записана один раз<br/>інструкції фаз · шаблони · каталог знань · детерміновані рушії<br/>нічого не знає про те, який агент її виконує"]
    delivery["доставка<br/>доносить цю цінність до кожного агента в очікуваній формі<br/>не несе логіки безпеки"]
    agent["агент<br/>виконує фази"]
    project["стан проєкту<br/>закомічений разом із кодом<br/>принципи безпеки · артефакти фаз · відстеження · категорії · власні спеціалізації"]
    value --> delivery --> agent
    agent -->|"читає й записує"| project
```

**Рисунок 6.** Носій, незалежний від агента. Цінність для безпеки записано один раз, тонка доставка доносить її до кожного агента, а стан залишається за проєктом.

Оскільки доставка не несе логіки безпеки, те, як її побудовано, нічого не змінює в SDH. Носій може побудувати доставку сам або передати її екосистемі, яка вже поширює навички агентів, як це робить еталонна реалізація, і фази, їхні артефакти та їхні гарантії залишаються тими самими. Ніщо з цього не специфічне й для мови чи середовища виконання. Еталонну реалізацію написано в одному стеку, але методологія є межею між цими аспектами, а не інструментарієм, що їх будує. Той самий дизайн можна було б заново реалізувати зовсім іншою мовою, не змінюючи того, чим є SDH.

---

## XIII. Наскрізний випадок: SDH від початку до кінця

> **Наскрізний випадок**
>
> **Оборонне посилення захисту поверхні завантаження й адміністрування.**
> **Контекст:** невеликий застосунок, що приймає завантаження файлів від користувачів і показує їх на сторінці адміністратора.
> **Шаблон:** charter → detect (зі знаннями на вимогу, активованими контекстом) → plan → harden → verify, з одним закриттям і одним справжнім провалом.
> **Результат (можливості):** один ризик, закриття якого перевірено й знято з обліку в усьому ланцюжку, і один засіб захисту, щодо якого перевірено, що ризик _не_ закрито, і який повернуто до harden. Вердикт відображає код, а не журнал.

_Це ілюстративний наскрізний приклад механіки методології, а не дослідження з польовими вимірюваннями, і він не наводить метрик ефективності._

Один безперервний розбір показує методологію в дії, а не лише її частини. Ми розширюємо приклад із завантаженням файлів з `§IV` активацією знань на вимогу й закриттям і додаємо один справжній провал.

1. **charter** пропонує принцип "Усі вхідні дані недовірені, доки їх не перевірено" з ризиком, викладеним простою мовою: неперевірені вхідні дані є найпоширенішим способом зламати систему.
2. **detect** перевіряє маршрут завантаження й невелику сторінку адміністратора, що показує завантажені файли. Вона виявляє знахідку щодо завантаження (обробник довіряє MIME-типу від клієнта). Сторінка адміністратора виконується в браузері, і цей контекст розпізнає промпт на вимогу (`§VII`), тож detect завантажує спеціалізацію для цього контексту й виявляє другу знахідку: місце, де ім'я файлу записується на сторінку як розмітка, а не як текст, тож підроблене ім'я може виконатися як скрипт у браузері відвідувача. Спеціалізації, чийого контексту немає в цьому обсязі, ніколи не завантажуються, і кожен пропуск записується разом із відсутністю, прочитаною з коду.
3. **plan** призначає виправленню завантаження пріоритет Critical, прив'язаний до принципу: перевіряти справжній тип і розмір файлу, перейменовувати під час збереження, зберігати там, де код не може виконатися. Другому виправленню вона призначає пріоритет High: відображати ім'я файлу як текст, а не розмітку.
4. **harden** спершу застосовує виправлення завантаження (найвищий пріоритет) і записує його як Applied, а потім друге, теж Applied.
5. **verify** читає кожне місце й зіставляє код із журналом. Засіб захисту завантаження діє: обробник визначає справжній тип за вмістом, обмежує розмір і відхиляє решту. Вердикт: risk closed. Verify знімає знахідку щодо завантаження з обліку в усьому ланцюжку, а її стислий підсумок потрапляє в історію.

Далі йде справжній провал. Припустімо, друге виправлення harden додало безпечну допоміжну функцію для відображення тексту, але старий виклик, що записує розмітку, залишився досяжним іншим шляхом у коді. Verify читає сторінку, бачить безпечну допоміжну функцію, а також бачить, що небезпечний шлях досі активний. Засіб захисту наявний, але ризик не закрито. Verify відмовляється пом'якшувати вердикт, щоб він відповідав журналу. Вона повертає "risk not closed", записує прогалину й повертає до harden. Засіб захисту, який не повністю усуває ризик, не вважається пройденим.

У цьому прикладі видно характер методології: виявлення з урахуванням контексту, упорядковані за пріоритетом виправлення, прив'язані до принципів, обережне застосування й перевірка, яка повідомляє фактичний стан коду незалежно від журналу.

---

## XIV. Коли використовувати SDH і її межі

SDH рідко буває надмірною, як це буває з важким процесом, бо вона не залежить від стану й безпеку в ній можна закрити: вона масштабується аж до одного файлу й одного занепокоєння й досягає усталеного стану, а не залишає постійного тягаря. Її межею є не розмір проєкту, а **глибина гарантій**.

```mermaid
flowchart TB
    q1{"Чи робить код щось важливе для безпеки?<br/>(вхідні дані, автентифікація, дані, секрети, зовнішні виклики)"}
    q1 -->|ні| little["Тут SDH дає мало."]
    q1 -->|так| q2{"Запустіть SDH. Чи є вимоги відповідності<br/>або окрема функція безпеки?"}
    q2 -->|ні| baseline["SDH є обґрунтованим базовим рівнем."]
    q2 -->|так| carrier["SDH є структурованим носієм:<br/>вона підтримує експертну перевірку й аудит,<br/>а не замінює їх."]
```

**Рисунок 7.** Коли використовувати SDH. Розгалуження спершу йде за важливістю для безпеки, потім за глибиною гарантій, але ніколи не за розміром проєкту.

Де SDH досягає своєї межі: поведінка, що проявляється лише під час роботи системи (verify читає код, а не виконує систему), ризик, що залежить від конфігурації чи середовища, яких агент не може прочитати, і контексти з високими ставками, де експертна перевірка потрібна за будь-яких умов. У кожному з цих випадків SDH все одно додає цінності як структурований перший прохід, але вона є мінімумом, а не стелею.

> **Ключова думка**
>
> **Межа:** межею SDH є глибина гарантій, а не розмір проєкту. Вона може слугувати обґрунтованим базовим рівнем майже будь-де й підтримує експертну перевірку там, де цього вимагають ставки, але не замінює тестування працюючої системи чи судження фахівця з безпеки.

---

## XV. Обговорення: позиціонування, межі й те, чого SDH не стверджує

SDH точно окреслює свої межі.

### Вона розширює, а не замінює

SDH не замінює фахівців з безпеки чи спеціалізовані інструменти Blue Team. Вона розширює знання розробника (`§VI`). Виважене твердження тут є правильним: за належного застосування SDH **може** ефективно закривати реальні ризики, особливо для проєктів, які інакше взагалі не пройшли б перевірки безпеки. Це не гарантія і не заміна експертної перевірки там, де її вимагають ставки.

### Лише захист, за побудовою

SDH перевіряє, посилює захист і верифікує. Вона ніколи не створює наступальних інструментів, експлойтів чи способів обійти виявлення на шкоду. Вміст подвійного призначення з безпеки прийнятний лише в чітко оборонному, авторизованому контексті. Це жорстка межа, а не вподобання.

### Перевірка суттєва, а не показова

Verify перевіряє, читаючи код і зіставляючи його з журналом, а не запускаючи систему. Це статична перевірка: вона підтверджує, що засіб захисту наявний і коректний у коді, і не доводить, що він витримує атаку під час виконання. Тож "cannot tell from the code" є законним вердиктом, а не провалом, прихованим за успішним результатом. Коли доказу немає в коді (він залежить від конфігурації чи шляху, який агент не може прочитати), SDH так і каже, а не вгадує.

### Детермінованість обмежена й названа

Більша частина SDH спирається на міркування агента, і саме це дає їй змогу враховувати контекст. Детермінованість зарезервована за детермінованими рушіями: перевіряльниками, які може містити спеціалізація (`§VII`), і рушієм відстеження (`§XI`). Документ не розмиває цю межу. Там, де результат детермінований, це результат програми. Там, де він виведений міркуванням, це прочитання коду агентом, а остаточним арбітром є користувач.

### Вартість і масштаб

Повна перевірка витрачає багато токенів. Ручні режими (`§VI`, `§VIII`) існують почасти для того, щоб вартість залишалася пропорційною занепокоєнню.

### Остаточний арбітр: користувач

SDH просить людину вирішити, чи елемент перейменовано, чи розв'язано, а схвалення правок коду залишається там, де користувач уже керує своїм агентом, у режимі дозволів, у якому він його запускає. Методологія пропонує й перевіряє. Вона не переважує рішення людини.

### Заперечення й відповіді

Сумлінний скептик висуне кілька заперечень. Суттєві з них варто навести його власними словами.

**"Хіба це не просто статичний аналізатор із прикрученою LLM?"** Ні. Статичний аналізатор за замовчуванням запускає всі свої правила. SDH спершу визначає, чим є система, а потім звертається до доречних знань (`§II`, `§VII`) і _вбудовує_ детермінований перевіряльник лише там, де клас ризику має чітку процедуру вирішення. Міркування спираються насамперед на контекст, а детермінованість цільова.

**"Хіба це не просто чек-лист безпеки?"** Ні. SDH перевертає чек-лист: першим іде виявлення, а знання підтягуються для того, що насправді робить проєкт (`§II`, `§VII`).

**"Хіба це не просто SDD під новою назвою для безпеки?"** Ні. SDH запозичує структуру SDD і перевертає її контракт: повноваження, припущення щодо стану, умова завершення й те, кому вона служить, різняться (`§X`). Той самий механізм, протилежний напрямок.

**"Хіба метод на основі міркувань ШІ не вигадує знахідки?"** Дизайн обмежує вигадування, а не покладається на те, що модель поводитиметься належно. Detect записує лише те, що підтверджує код ("виявляти, а не вигадувати", `§IV`), verify зіставляє код із журналом і може відповісти "cannot tell from the code" (`§XV`), детерміновані перевіряльники обґрунтовують розв'язні випадки (`§VII`), а остаточним арбітром є користувач. Це не робить агента непогрішним, але робить його твердження перевірюваними.

Примітка щодо позиціонування. SDH визначено тут незалежно від її еталонної реалізації. П'ять фаз, принципи безпеки, сформульовані через ризики, дисципліна "узгоджувати, а не дописувати" та її закриваність, знання з промпту на вимогу, превентивний режим, відстеження з ідентичністю за назвою й межа "лише захист" і є методологією. Інша команда могла б реалізувати їх в іншому стеку й іншій екосистемі агентів, і результат усе одно був би SDH. Lagune є її доведенням, а не визначенням.

---

## XVI. Пастки й те, як SDH структурно їх уникає

Методології цього сімейства мають спільний відомий набір збоїв. Відповідь SDH на більшість із них структурна, закладена в процес, а не покладена на дисципліну.

| Пастка                                 | Збій                                                       | Структурна відповідь SDH                                                                                                              |
| -------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Гниття специфікації, застарілий беклог | Артефакти накопичують мертві записи, яким ніхто не довіряє | Узгоджувати, а не дописувати (`§V`): кожен запуск перевіряє кожен запис і прибирає розв'язане                                         |
| Хибна впевненість, успішний результат  | Вважається, що наявний засіб захисту закриває ризик        | Verify зіставляє код із журналом, тож "risk not closed" і "cannot tell" є повноцінними вердиктами (`§IV`, `§XV`)                      |
| Потоп чек-листів                       | Загальні пункти затуляють один ризик, що має значення      | Контекст понад загальність, а промпт на вимогу завантажує лише те, чого вимагає обсяг (`§VII`)                                        |
| Прив'язка до інструментів              | Метод приварено до одного постачальника чи агента          | Носій, незалежний від агента: цінність для безпеки записано один раз, а її доставка до кожного агента не несе логіки безпеки (`§XII`) |
| Нескінченний цикл                      | Беклог ніколи не закривається, робота ніколи не спочиває   | Закриваність і стан спокою (`§V`)                                                                                                     |

**Таблиця 4.** Відомі пастки цього сімейства методологій і структурна відповідь SDH на кожну з них.

Суть у тому, щоб назвати пастку й вказати на механізм: це не застереження бути обережним, а властивості процесу.

---

## XVII. Подальша робота

Методологія та її еталонна реалізація мають чіткі наступні кроки.

- **Розширювати каталог знань:**
  Кожне доповнення зберігає форму з `§VII`: файл знань і рядок у каталозі, без нової команди. Шлях з боку користувача там уже існує: користувач на вимогу стисло викладає власні спеціалізації. Більше вбудованих мов, середовищ виконання й класів ризиків, кожен у своїй категорії, є напрямом з боку мейнтейнера, а спеціалізації, як очікується, еволюціонуватимуть.
- **Більше детермінованих перевіряльників:**
  Там, де клас ризику має чітку процедуру вирішення, спеціалізація може містити детермінований перевіряльник, що підкріплює міркування агента відтворюваним вердиктом. Поширення цього на більше класів ризиків є природним напрямом.
- **Емпірична оцінка:**
  Найважливіше відкрите питання стосується виміряної ефективності: якості закриття й частоти хибних вердиктів на реальних кодових базах. Дослідження результатів SDH для безпеки є подальшою роботою, і твердження тут відповідно обмежено.

---

## XVIII. Висновок

Розробка з допомогою ШІ відкрила прогалину в безпеці, яку не можуть заповнити загальні чек-листи, бо важливий ризик специфічний для того, що насправді робить система, а людина, яка її випускає, може не знати, про що просити. SDH закриває цю прогалину процесом з урахуванням контексту, суто оборонним і таким, що його можна закрити, у якому знання з безпеки містяться в методології та її спеціалізаціях на вимогу, базовому рівні, на який може спиратися кожен користувач. Вона визначає справжній контекст системи, сортує за пріоритетом ризики, які несе цей контекст, обережно застосовує виправлення й перевіряє кожне, а потім знімає з обліку те, що закрила, тож кожна знахідка досягає кінцевого стану. Той самий захист також працює превентивно під час створення нової роботи, тож те, що закрив процес, залишається закритим. Вона пристосовується до будь-якого стану розробки в будь-якому стеку й розширює знання розробника, а не замінює людей та інструменти, які вже виконують цю роботу.

Lagune є доведенням, але внеском є конвенція. SDH пропонується як базовий процес безпеки для епохи розробки з ШІ, щоб інші могли прийняти її, удосконалити й реалізувати у власних стеках.

---

## Джерела

**[1]** D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (Submitted to AIWare 2026.) [Online]. Available: https://arxiv.org/abs/2602.00180

**[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Available: https://github.com/github/spec-kit. Accessed: 2026.

**[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Available: https://github.com/Fission-AI/OpenSpec. Accessed: 2026.

**[4]** B. Chess and G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111.

**[5]** OWASP Foundation, "Source Code Analysis Tools." [Online]. Available: https://owasp.org/www-community/Source_Code_Analysis_Tools. Accessed: 2026.

**[6]** OWASP Foundation, "OWASP Top 10:2021." [Online]. Available: https://owasp.org/Top10/. Accessed: 2026.

**[7]** MITRE, "Common Weakness Enumeration (CWE)." [Online]. Available: https://cwe.mitre.org/. Accessed: 2026.

**[8]** N. Perry, M. Srivastava, D. Kumar, and D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622

**[9]** J. Davis and contributors, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Available: https://github.com/davisjam/safe-regex. Accessed: 2026.

**[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Available: https://github.com/DmitrySoshnikov/regexp-tree. Accessed: 2026.

**[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Available: https://github.com/tjenkinson/redos-detector. Accessed: 2026.

---

## Додаток A: принципи дослівно

1. **Безпечно за замовчуванням, простою мовою, для всіх однаково:**
   Кожне значення за замовчуванням, повідомлення й виправлення має бути безпечним одразу й зрозумілим будь-якому користувачу, розробнику чи ні. Жоден рівень користувачів не має переваг над іншим.
2. **Контекст понад загальність:**
   Кожна фаза має починати з контексту, виявленого в detect, і діяти відповідно до того, що насправді робить система. Віддавайте перевагу рекомендаціям, специфічним для цього контексту, а не загальним чек-листам. Знання з безпеки містяться в специфікації та її спеціалізаціях на вимогу й розширюють усе, що приносить користувач.
3. **Гнучкість понад жорсткість:**
   SDH підлаштовується під проєкт і користувача. Принципи, вимоги й рекомендації є відправними точками, а не фіксованим контрактом. Дозвольте користувачу переформулювати, прибрати, додати будь-що або звузити його обсяг. Гнучкість ніколи не послаблює базовий рівень безпеки за замовчуванням, вона лише дає користувачу змогу визначити, як його застосовувати.
4. **Узгоджувати, а не лише дописувати:**
   Артефакти є живими документами, а не журналами. Коли фаза запускається повторно, звіряйте кожен наявний запис із поточною правдою: зберігайте те, що досі слушне, переписуйте змінене й прибирайте те, що вже не стосується. Закриття є тим самим узгодженням, доведеним до завершення.
5. **Лише захист:**
   SDH перевіряє, посилює захист і верифікує. Вона ніколи не створює наступальних інструментів, експлойтів для зловмисного використання чи способів обійти виявлення на шкоду. Вміст подвійного призначення з безпеки прийнятний лише в чітко оборонному, авторизованому контексті.
6. **Специфікація на першому місці, керування агентом, спрямування на безпеку:**
   Будуйте робочий процес на перевіреній структурі: шаблони, команди, керівні принципи безпеки й агент, що виконує фази. Реалізуйте цю структуру заново з оборонною метою.

---

# Глосарій Lagune: SDH, принципи безпеки, знахідки й засоби захисту

> Визначення простою мовою для кожного терміна Lagune і Security-Driven Hardening: SDH, charter, detect, знахідка, засіб захисту, harden, verify, зняття з обліку, закриваність, спеціалізації, категорії й каталог.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/references/glossary
Мова: uk-UA
Оригінал: https://lagune.ai/docs/references/glossary
Останнє оновлення: 2026-11-03

Кожен ключовий термін Lagune і методології Security-Driven Hardening, визначений один раз і простою мовою.

### Security-Driven Hardening (SDH)

Методологія, яку реалізує Lagune: конвенція Blue Team з урахуванням контексту, що визначає контекст системи, сортує за пріоритетом ризики, які несе цей контекст, і спрямовує виправлення. Знання з безпеки містяться в специфікації та її спеціалізаціях на вимогу, тож розробник і нерозробник обслуговуються тим самим процесом.

### Lagune

Еталонна реалізація SDH: дев'ять команд агента, кожна з шаблоном, який вона заповнює, що їх ШІ-агент виконує, щоб посилити захист кодової бази. Кожен агент встановлює їх через власний інсталятор плагінів або через [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), як показано на [сторінці встановлення](https://lagune.ai/uk-UA/docs), а вони запускають рушій Lagune для кожного детермінованого кроку.

### Charter

Керівний рівень Lagune: набір принципів, що ставлять безпеку на перше місце і яких має дотримуватися кожна наступна фаза. Сприймайте її як перевірку під час компіляції для рівня захищеності проєкту. Вона зберігається в `.lagune/memory/charter.md`.

### Процес розробки

Універсальна команда `/lagune`, що посилює захист роботи під час написання коду. Вона приймає будь-який промпт на будь-якому етапі, створює те, що ви попросили, і посилює захист безпечними налаштуваннями за замовчуванням, перш ніж повернути результат, керуючись принципами безпеки, якщо вони є. Вона нічого не записує у відстеження Lagune, тож її єдиним продуктом є захищений код. Разом із принципами безпеки (до) і процесом Blue Team (після) саме так Lagune захищає під час розробки.

### Процес Blue Team

П'ятифазний аудит, що лежить в основі Lagune: charter, detect, plan, harden, verify. Кожна фаза спирається на попередню. "Blue Team" є традицією захисників у безпеці, на противагу наступальній Red Team.

### Знахідка

Один виявлений ризик. Кожна знахідка містить, що це, чому це важливо, і доказ у коді. Знахідка є єдиною відстежуваною одиницею, яку plan, harden і verify передають далі, ідентифікованою за назвою в кожному артефакті.

### Засіб захисту

Захід безпеки, застосований, щоб закрити ризик. Harden застосовує засоби захисту, verify доводить, що вони діють. Lagune ніколи не послаблює засіб захисту заради промпту.

### Detect

Фаза, що читає код і визначає, що робить система і де ризики. Її головне правило: виявляти, а не вигадувати. Вона записує лише те, що підтверджує код.

### Harden

Єдина фаза, що торкається вашого коду. Вона застосовує виправлення з плану по одному й записує кожне як Applied, Partial чи Blocked. Applied ще не означає доведене.

### Verify

Фаза, що доводить, що кожне застосоване виправлення діє, читаючи код і зіставляючи його з тим, що записала harden. Вона повертає один із трьох вердиктів: Risk closed, Risk not closed або Cannot tell from the code.

### Зняття з обліку

Коли verify доводить, що ризик закрито, знахідку знімають з обліку: прибирають з усього ланцюжка за вашим підтвердженням, щоб її більше не обробляли повторно.

### Закриваність

Властивість, завдяки якій робота з безпеки має кінцевий стан. Оскільки знахідку, закриття якої доведено, знімають з обліку, процес може перейти в стан спокою й відкривається знову лише тоді, коли змінюється код. Безпеку в SDH можна закрити, це не нескінченний цикл.

### Рушій

Пакет `lagune` в **npm**, через який команди виконують кожен детермінований крок за допомогою `npx`: хуки, каталог і категорії.

### Спеціалізація

Цільовий модуль знань з безпеки, незалежний від мови програмування, який завантажується лише на вимогу, а не за замовчуванням. Спеціалізація не є командою. Завантажте її в будь-який промпт через `read catalog <name>` рушія, наприклад `npx lagune read catalog regex`.

### Категорія

Іменована група вбудованих спеціалізацій, від `owasp` до спеціалізацій для окремих мов, як-от `javascript`, `python`, `go` і `rust`. Категорії, які використовує проєкт, записані в `.lagune/configs.json`, визначають, які вбудовані спеціалізації потрапляють до його каталогу. Поки жодної не записано, проєкт використовує лише `owasp`.

### Каталог

Набір спеціалізацій, які використовує проєкт: вбудовані спеціалізації його категорій плюс власні, написані через `/lagune-specialize`. `read catalog` рушія виводить його, а фази зіставляють його з кодом.

### Промпт на вимогу

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

### Ідентичність за назвою

Модель відстеження Lagune: назва кожної знахідки, записана однаково як заголовок розділу в кожному артефакті, є її ідентичністю в усьому ланцюжку. Карта відстеження (`.lagune/tracking.json`) містить лише відстеження, а не текст.

## Часті запитання

### Що таке Security-Driven Hardening (SDH)?

SDH є методологією безпеки Blue Team з урахуванням контексту. Вона визначає контекст системи, сортує за пріоритетом ризики, які несе цей контекст, і спрямовує виправлення, викладаючи кожну знахідку простою мовою. Lagune є її еталонною реалізацією.

### Що таке charter у Lagune?

Charter є керівним рівнем Lagune, набором принципів, що ставлять безпеку на перше місце і яких має дотримуватися кожна наступна фаза. Вона зберігається в .lagune/memory/charter.md.

### Що означає зняти знахідку з обліку?

Коли verify доводить, що ризик закрито, знахідку знімають з обліку: прибирають з усього ланцюжка за вашим підтвердженням, щоб її більше не обробляли повторно.

---

# Схема конфігурації

> JSON Schema для конфігурації проєкту Lagune, що дає автодоповнення й валідацію у вашому редакторі, за поточною версією Lagune чи із закріпленою версією.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/references/configs-schema
Мова: uk-UA
Оригінал: https://lagune.ai/docs/references/configs-schema
Останнє оновлення: 2026-11-03

`.lagune/configs.json` записує [**категорії**](https://lagune.ai/uk-UA/docs/categories), які використовує проєкт, і індексує його власні [**спеціалізації**](https://lagune.ai/uk-UA/docs/catalog). Його JSON Schema дає вашому редактору змогу автодоповнювати кожне поле й позначати друкарську помилку чи невідому категорію ще під час редагування файлу.

## Поточна схема

Щоразу, коли **Lagune** записує файл і не знаходить у ньому `$schema`, він спрямовує файл на поточну схему:

```json
{
  "$schema": "https://lagune.ai/schemas/configs.json",
  "categories": ["owasp", "javascript"]
}
```

Ця адреса завжди відповідає поточній версії **Lagune**. Файл, записаний до **Lagune** 0.16.0, отримує її під час наступної зміни, а доти кожна фаза нагадує про це.

## Закріплення версії

Кожен реліз **Lagune**, починаючи з 0.16.0, містить схему в тому вигляді, якою вона була в цій версії, опубліковану в **npm** і доступну через **jsDelivr**. Щоб закріпити версію, вкажіть потрібну версію після `lagune@` в адресі `$schema`:

```json
{
  "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json"
}
```

Версія приймає будь-який діапазон semver:

| Версія              | Схема                          |
| ------------------- | ------------------------------ |
| `0.16.0`            | Схема з 0.16.0                 |
| `0.16.x` або `0.16` | Схема з останнього релізу 0.16 |
| `0.x` або `0`       | Схема з останнього релізу 0.x  |
| `latest`            | Схема з останнього релізу      |

## Часті запитання

### Чи потрібна Lagune схема?

Ні. Схема лише допомагає вашому редактору, а Lagune читає файл однаково з $schema і без нього.

### Чи перезапише Lagune закріплену схему?

Ні. Lagune записує $schema лише тоді, коли у файлі її немає, і зберігає будь-яку задану вами адресу.

### Коли варто закріплювати версію?

Коли проєкт працює з конкретною версією Lagune, щоб ваш редактор перевіряв файл за тим, що приймає ця версія.

---

# Lagune vs. Deepsec: два підходи до безпеки на основі ШІ пліч-о-пліч

> Довідка, що порівнює Lagune і Deepsec від Vercel за принципом роботи, життєвим циклом, виявленням, вартістю, знахідками й закриттям.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/references/deepsec
Мова: uk-UA
Оригінал: https://lagune.ai/docs/references/deepsec
Останнє оновлення: 2026-11-03

[Lagune](https://github.com/wellwelwel/lagune) і [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) є двома оборонними відповідями на ту саму проблему: безпеку в епоху розробки з допомогою ШІ. Їхня вихідна ідея, їхні початок, середина й кінець, а також те, як кожен подає себе користувачу, свідомо розходяться, навіть там, де їхні механізми перетинаються.

**Порада**

Чи натхненний Lagune проєктом Deepsec? Ні, Lagune написано з нуля, і його натхненням є Spec-Driven Development і Security Hardening. Обидва проєкти розроблялися незалежно, а це порівняння має допомогти користувачам зрозуміти їхні відмінності.

## Коротко

| Аспект               | Lagune                                                                                                                | Deepsec                                                                            |
| -------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Тип                  | Методологія (SDH) з еталонною реалізацією                                                                             | Продукт: сканер вразливостей на основі агентів                                     |
| Центр ваги           | Принципи безпеки й знання на вимогу керують агентом, спираючись на детерміновані хуки                                 | Широка сітка регулярних виразів живить обов'язкове розслідування ШІ                |
| Що створює           | Захищений код, доведення й відстежуваний ланцюжок знахідок                                                            | Звіт зі знахідками, відсортованими за критичністю й пріоритетом                    |
| Чи торкається коду   | Так: `harden` редагує ваш код                                                                                         | Ні: лише статичний аналіз, видає знахідки й текст рекомендацій                     |
| Середовище виконання | Працює на агенті й моделі, які ви вже використовуєте, будь-якого рівня                                                | Запускає власний конвеєр моделей, за замовчуванням передового рівня                |
| Початок роботи       | Одне встановлення плагіна чи `npx skills add`, а далі керування простою мовою, без нового інструмента для розгортання | Розгорнути робочий простір `.deepsec/`, встановити залежності й додати ключ моделі |

## Як це працює

Lagune ставить агента на перше місце: агент керує процесом, на вимогу підтягує знання про те, чим є код, і делегує частину, яку можна визначити, детермінованим хукам.

Deepsec ставить на перше місце детермінованість: широка перевірка позначає кандидатів, які вказують обов'язковій моделі, що розслідувати й оцінювати.

| Аспект             | Lagune                                                                                            | Deepsec                                                           |
| ------------------ | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Порядок            | Принципи безпеки й відповідні знання спрямовують агента, який делегує хукам і оцінює решту        | Матчери позначають кандидатів, модель розслідує й оцінює кожного  |
| Детермінована роль | Багатомовні хуки, що повертають вердикт або спрямовують агента, у поєднанні зі знаннями категорій | Матчери, що позначають кандидатів для оцінки обов'язковою моделлю |
| Процес розробки    | `/lagune` створює безпечний код просто під час програмування                                      | Переглядає код, а не пише його                                    |
| Процес аудиту      | `charter` → `detect` → `plan` → `harden` → `verify`                                               | `scan` → `process` → `triage` → `revalidate` → `report`           |
| Завдання ШІ        | Міркувати на основі знань, застосовувати виправлення й доводити, що воно діє                      | Розслідувати кожного кандидата й звітувати про знахідки           |

## Життєвий цикл

Lagune працює до, під час і після написання коду. Deepsec перевіряє репозиторій, коли код уже існує.

| Момент                | Lagune                                                                           | Deepsec                                                               |
| --------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| До появи коду         | `charter` формує політику безпеки із заявленого наміру                           | Починає з наявного коду: `init` потребує каталогу                     |
| Під час розробки      | `/lagune` створює безпечний за замовчуванням код одразу, не залишаючи артефактів | Перевіряє після розробки, а не під час неї                            |
| Для наявного коду     | `detect` → `plan` → `harden` → `verify`                                          | `scan` → `process`, основний процес                                   |
| Безперервна перевірка | Повторний запуск фаз для потрібного обсягу, без готового шлюзу CI                | Інкрементальна повторна перевірка, `process --diff` як шлюз виходу CI |

## Рівень виявлення

Два детерміновані рівні протилежні за своєю природою: один вирішує, інший позначає.

| Аспект               | Lagune                                                                           | Deepsec                                                               |
| -------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| Групування           | Хуки й спеціалізації, згруповані в категорії                                     | Матчери для кожного шаблону чи фреймворку                             |
| Вивід                | Буквальний вердикт (знахідка / перегляд / рекомендація) плюс мітка класифікації  | Кандидат без вердикту (slug, рядки, фрагмент коду, шаблон, що збігся) |
| Налаштування         | Точність: врахування коментарів, захист від заповнювачів і вікон                 | Повнота: широкі сітки, а хибні спрацьовування потім відсіює ШІ        |
| Глибина              | Глибше в спільних класах                                                         | Ширше, але менш глибоко в спільних класах                             |
| Хибні спрацьовування | Утримуються на низькому рівні від самого джерела, а потім оцінюються в контексті | Навмисно генеруються з надлишком і скорочуються проходом `revalidate` |

## Знання й судження

Обидва несуть знання з безпеки, недоступні регулярним виразам. Вони відрізняються тим, де ці знання зберігаються і хто може їх формувати.

| Аспект                | Lagune                                                                        | Deepsec                                                                                 |
| --------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Форма                 | Редаговані модулі в markdown, кілька з яких підкріплені детермінованим хуком  | Короткий промпт і підказки для кожної технології, що спираються на власні знання моделі |
| Вибір                 | Підбираються до коду, завантажуються лише тоді, коли присутній їхній контекст | Вставляються в кожну партію ШІ, плюс підказки для виявленої технології                  |
| Хто їх пише           | Користувач редагує модулі й додає нові через `specialize`                     | Промптом володіє мейнтейнер, а користувач заповнює `INFO.md`                            |
| Де місце судження     | Хуки вирішують свій мінімум, а агент оцінює решту на основі знань             | Централізовано: один процесор ШІ оцінює кожного кандидата                               |
| Повторне використання | Один модуль спрямовує і `detect`, і `verify`                                  | Один промпт керує єдиним етапом `process`                                               |

## Знахідки й закриття

Найбільше вони розходяться в тому, чим стає знахідка після розв'язання.

| Аспект              | Lagune                                                                                          | Deepsec                                                                              |
| ------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Критичність         | Оцінка CVSS v4.0, скоригована з урахуванням відкритості й значущості                            | Критичність від ШІ плюс сортування P0 / P1 / P2 за можливістю експлуатації й впливом |
| Вердикти            | Risk closed, not closed або cannot tell from the code                                           | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate            |
| Зберігання          | Робочий ланцюжок узгоджується, закриті знахідки стисло переходять в історію                     | Записи для кожного файлу лише з дописуванням, нічого не видаляється                  |
| Кінцевий стан       | Безпеку можна закрити: доведену знахідку знімають з обліку, ланцюжок може перейти в стан спокою | Кожна знахідка зберігається назавжди й ховається з переглядів після розв'язання      |
| Деталізація історії | Стислий підсумок того, яким був ризик                                                           | Повний слід вердиктів, зокрема те, як ризик виправили                                |

## Вартість

| Аспект                 | Lagune                                                                                                                                                               | Deepsec                                                                                                                                                                                                                       |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Детермінований мінімум | Безкоштовно: хуки працюють без ШІ й без ключа і вже видають вердикти                                                                                                 | Безкоштовно: `scan` працює без ШІ, але сам по собі не видає вердиктів                                                                                                                                                         |
| Типовий рахунок        | Входить в агента, якого ви вже використовуєте: аж до $0 на локальній моделі, ціна плану, яким ви вже користуєтеся, або оплата за ітерацію при використанні через API | [Приблизно від $25 до $1200 за запуск, якщо файлів від 100 до 2000, більше в масштабі](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) |
| Найдешевший шлях       | Будь-яка модель, зокрема безкоштовна локальна, закриває цикл                                                                                                         | Є дешевші платні рівні, але знахідки потребують платного етапу ШІ                                                                                                                                                             |

## Розширюваність і керування

Кожен відкриває той рівень, який інший тримає закритим.

| Аспект                   | Lagune                                               | Deepsec                                                  |
| ------------------------ | ---------------------------------------------------- | -------------------------------------------------------- |
| Що ви розширюєте         | Редагуєте модулі або додаєте нові через `specialize` | Додаєте матчери, агентів, сповіщувачі й відповідальність |
| Рівень політик           | Принципи безпеки керують кожною фазою й мають версії | Конфігурація операційна (матчери, моделі, шляхи)         |
| Перевизначення за назвою | Уточнений модуль перекриває вбудований               | При збігу slug матчера перемагає ваш матчер              |

## Інтерфейси

Deepsec видає результати для організації з безпеки. Lagune показує огляд наживо для того, хто його запускає.

| Аспект                 | Lagune                                                  | Deepsec                                                                     |
| ---------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------- |
| Інтерфейс для людини   | Локальний дашборд усього ланцюжка наживо, простою мовою | Файли звіту, експорту, метрик і коментарів до PR, а також сайт документації |
| Відповідальність       | Показує файли й спеціалізації, які застосувалися        | Пропонує відповідального: чергового, менеджера чи автора коміту             |
| Відтворюване доведення | `prove` пише виконувані тести й бюлетень для розкриття  | Свідомо залишається статичним і ніколи не виконує ціль                      |
| Самозахист інструмента | Захищає локальний API запису в дашборді                 | Захищає власне виконання ШІ від недовіреного коду цілі                      |

## Масштаб і розгортання

| Аспект               | Lagune                                                                                   | Deepsec                                                      |
| -------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Встановлення         | Дев'ять команд із плагіна вашого агента чи CLI skills, без жодних згенерованих заготовок | Робочий простір `.deepsec/` з власним пакетом і залежностями |
| Напрям масштабування | Обмежується будь-якою частиною: контекстом, одним файлом чи всім проєктом                | Перевіряє цілі репозиторії, аж до великих монорепозиторіїв   |
| Розподіл             | Лише локально, єдиний сервер прив'язаний до loopback                                     | Необов'язковий розподіл між робочими VM у Vercel Sandbox     |

## Досвід користувача

Як кожен зустрічає людину, що його запускає: чого потребує перший запуск і як оператор його спрямовує.

### Початок роботи

Lagune працює через уже відкритого агента. Deepsec спершу готує власний робочий простір і доступ до моделі.

| Аспект                    | Lagune                                                                                   | Deepsec                                                                               |
| ------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Перша команда             | Встановлення плагіна чи `npx skills add wellwelwel/lagune`, а потім `/lagune-*` в агенті | `npx deepsec init`, потім `cd .deepsec`, `pnpm install`, `scan`, `process`            |
| Облікові дані для запуску | Окремий ключ не потрібен, використовується ваш поточний агент                            | Ключ моделі (наприклад, AI Gateway, 12-годинний токен Vercel OIDC чи токен Anthropic) |

### Керування

Обидва приймають вказівки. Lagune у кожній фазі читає форму вхідних даних. Deepsec звужує набір файлів, над яким виконується те саме розслідування.

| Аспект            | Lagune                                                                 | Deepsec                                                |
| ----------------- | ---------------------------------------------------------------------- | ------------------------------------------------------ |
| Увесь проєкт      | Фаза без вхідних даних перевіряє весь обсяг                            | `scan` і `process` перевіряють репозиторій             |
| Частина           | Будь-яка фаза обмежується заданими файлами чи каталогами               | `--files`, `--files-from` або `--diff` звужують запуск |
| Занепокоєння      | Фаза обмежується описаним побоюванням                                  | Промпт розслідування незмінний                         |
| Рівень пріоритету | `harden` і `verify` обмежуються рівнями Critical, High, Medium чи Low  | Знахідкам призначають мітки після запуску              |
| Окреме значення   | Хук напряму оцінює один фрагмент, шаблон чи URL (`--pattern`, `--url`) | Одиницею роботи є файл                                 |

## Часті запитання

### Чим Lagune відрізняється від Deepsec?

Lagune ставить агента на перше місце й працює до, під час і після написання коду: встановлює політику ще до коду, посилює захист одразу під час розробки, а також перевіряє, захищає й верифікує вже написаний код. Deepsec ставить на перше місце детермінованість: широка перевірка регулярними виразами живить обов'язкове розслідування моделлю передового рівня, яке переглядає наявний код і звітує про знахідки, не змінюючи його.

### Чи можна запускати будь-який із них безкоштовно?

Увесь процес Lagune може працювати за $0 на безкоштовній локальній моделі, а його детерміновані хуки видають вердикти взагалі без ШІ. Перевірка Deepsec безкоштовна, але не видає вердиктів, тож будь-яка знахідка потребує платного етапу ШІ.

### Чи змінює хтось із них мій код?

Lagune змінює: harden застосовує виправлення до вашого коду. Deepsec не змінює: це лише статичний аналіз, що видає знахідки й текст рекомендацій, які людина чи агент застосовує окремо.

---

# Джерела OWASP

> Звідки походять знання вбудованих спеціалізацій OWASP, зіставлені з канонічними сторінками атак і Cheat Sheet від OWASP.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/references/owasp-sources
Мова: uk-UA
Оригінал: https://lagune.ai/docs/references/owasp-sources
Останнє оновлення: 2026-11-03

Цей документ зіставляє кожну **атаку** (`www-community`) і кожен **Cheat Sheet** (`CheatSheetSeries`) від OWASP з категорією безпеки, і кожен пункт містить посилання на свою канонічну публічну сторінку. У межах категорії рівнозначні пункти ділять один рядок чек-листа: атаки й cheat sheet, що стосуються того самого ризику, перелічено разом через кому. Пункти без прямого відповідника стоять в окремому рядку.

- Авторство належить OWASP. Атаки розміщено за адресою `https://owasp.org/www-community/attacks/<attack>`, а cheat sheet за адресою `https://cheatsheetseries.owasp.org/cheatsheets/<cheat>.html`.

---

## 1. Ін'єкції (загальні)

- [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter)
- [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter)
- [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter)
- [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network)
- [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter)
- [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter)
- [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter)
- [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter)
- [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter)
- [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter)

---

## 2. Ін'єкції SQL і в бази даних

- [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql)
- [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql)
- [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql)
- [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter)
- [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql)
- [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter)

---

## 3. Ін'єкції команд ОС

- [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter)

---

## 4. Ін'єкції LDAP, XPath і XML

- [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter)
- [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter)
- [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter)
- [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml)

---

## 5. Cross-Site Scripting (XSS)

- [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser)
- [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser)
- [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser)
- [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser)
- [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser)
- [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser)
- [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser)
- [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser)

---

## 6. Cross-Site Request Forgery (CSRF) і clickjacking

- [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request)
- [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser)
- [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser)
- [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network)
- [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser)

---

## 7. Перенаправлення й переспрямування

- [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network)
- [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser)

---

## 8. Контроль доступу й авторизація

- [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control)
- [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control)
- [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control)
- [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control)
- [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control)
- [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control)
- [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control)
- [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control)

---

## 9. Автентифікація й облікові дані

- [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint)
- [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint)
- [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation)
- [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control)
- [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control)
- [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control)
- [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control)

---

## 10. Керування сесіями

- [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control)
- [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control)

---

## 11. Федерація ідентичності (OAuth / SAML / JWT)

- [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation)
- [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation)
- [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation)

---

## 12. Криптографія й безпека передавання даних

- [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto)
- [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport)
- [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport)
- [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport)

---

## 13. Server-Side Request Forgery (SSRF)

- [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network)

---

## 14. Path traversal і робота з файлами

- [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path)
- [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path)
- [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path)
- [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path)
- [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload)

---

## 15. Зловживання протоколом HTTP (заголовки, кешування, розщеплення)

- [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter)
- [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (розподілено: browser, transport, http-request, access-control)
- [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter)
- [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request)

---

## 16. Кодування й підміна вмісту

- [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter)
- [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter)
- [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser)

---

## 17. Ін'єкції в CSV і таблиці

- [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv)

---

## 18. CORS (Cross-Origin Resource Sharing)

- [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request)
- [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request)

---

## 19. Відмова в обслуговуванні

- [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex)

---

## 20. Безпека пам'яті й нативний код

- [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp)
- [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp)

---

## 21. Мобільний код і виконання недовіреного коду

- [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter)
- [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java)
- [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java)

---

## 22. Десеріалізація

- [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (розподілено: python, ruby, php, java, dotnet)

---

## 23. Шкідливе ПЗ і загрози на боці клієнта

- [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser)
- [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser)

---

## 24. Журналювання, відмова від авторства й обробка помилок

- [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter)
- [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter)

---

## 25. Бізнес-логіка й зловживання функціональністю

Бізнес-логіка й зловживання функціональністю не мають єдиної поверхні в коді, яку захищала б спеціалізація для окремої поверхні: захист полягає в специфічному для застосунку дизайні, за тією самою логікою, якою керується моделювання загроз проєкту. Перенесено до "Поза обсягом".

---

## 26. Безпека ШІ, LLM і агентів

- [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm)
- [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm)
- [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm)
- [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm)
- [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm)
- [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm)
- [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm)

---

## 27. Prototype pollution і міжсайтові витоки

- [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript)
- [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser)

---

## 28. Фреймворки й мовні платформи

- [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python)
- [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby)
- [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php)
- [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php)
- [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java)
- [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet)
- [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript)
- [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php)

---

## 29. Вебфронтенд і браузер

- [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser)
- [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser)
- [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (розподілено: access-control, browser)

---

## 30. API й сервіси

- [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint)
- [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint)
- [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint)

---

## 31. Хмара, контейнери й інфраструктура

Конфігурація контейнерів і робочих навантажень є конфігурацією як кодом, яку розробник постачає разом із застосунком (`Dockerfile`, Compose, `securityContext` у Pod), реальною поверхнею, яку `harden` виправляє, а `verify` доводить, тож вона в межах обсягу. Адміністрування кластера (RBAC, etcd, API-сервер, admission, сегментація мережі) належить до сфери оператора й лишається поза обсягом.

- [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container)
- [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (container: частина про робочі навантаження й Pod. Адміністрування кластера лишається поза обсягом)
- [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless)

---

## 32. Ланцюжок постачання й CI/CD

- [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter)
- [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter)

---

## 33. Секрети й конфігурація

Керування секретами є операційним питанням: сховища секретів, CI/CD, хмарна конфігурація, ротація. Єдиний аспект на рівні коду (секрет, жорстко закодований у вихідному коді) є детермінованою перевіркою, а не спеціалізацією з ризику. Перенесено до "Поза обсягом".

---

## 34. Процеси, дизайн і керування

Захист приватності користувачів є питанням політики й дизайну (мінімізація даних, прозорість, зберігання), а не поверхнею в коді, яку захищає спеціалізація. Перенесено до "Поза обсягом".

---

## 35. Платежі й відповідність вимогам

- [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment)

---

## 36. Вбудовані системи, IoT і спеціалізовані галузі

Безпека автомобілів і дронів належить до галузі вбудованих систем (шина CAN, OTA-прошивки, цілісність сенсорів і радіо, фізичний доступ), а не до вихідного коду вебзастосунків і API, який перевіряє Lagune. Перенесено до "Поза обсягом".

---

## Поза обсягом (немає поверхні в коді)

Ці пункти не є територією для спеціалізацій і не мають прапорця: це керування, процеси, операційне посилення захисту чи використання фреймворків без єдиної поверхні в коді, яку захищала б спеціалізація для окремої поверхні. Їхня цінність для безпеки реальна, але вона полягає в процесах і архітектурі (або, для фреймворку, у власній навичці відповідної мови), а не в захисті, який постачає цей каталог. Їх наведено для довідки, а не як роботу.

- [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html)
- [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html)
- [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html)
- [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack)
- [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood)
- [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton) (посилення через SOAP/WS-Addressing, операційний різновид DoS без поверхні в коді)
- [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow)
- [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (шкідливе ПЗ на пристроях кінцевих користувачів, а не поверхня в коді проєкту, що перевіряється. Аспект доставки в браузері охоплює `browser`)
- [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html)
- [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html)
- [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (дизайн і компроміси: IAM проти підписаних URL, публічні й приватні VPC, межі довіри, спільна відповідальність. На відміну від `container`, тут немає конкретної конфігурації, яку перевіряє спеціалізація)
- [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (попри назву, це процес SDLC та інструменти для _керування_ IaC: плагіни IDE, статичний аналіз, сканування образів, CI/CD, підписування. Він не показує шлях від небезпечного шаблону до безпечної форми у файлі Terraform чи CloudFormation)
- [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_лише частина про адміністрування кластера_: RBAC, etcd, API-сервер, admission. Частина про робочі навантаження й Pod входить в обсяг у межах `container`)
- [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (архітектура мережі й політики брандмауера)
- [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (життєвий цикл DNS і моніторинг, а не код)
- [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (сховища секретів, CI/CD, ротація. Аспект жорстко закодованих секретів є детермінованою перевіркою, а не спеціалізацією з ризику)
- [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (прапорці компілятора, лінкера й збирання, без sink у вихідному коді)
- [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html)
- [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html)
- [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html)
- [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html)
- [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure) (глобальна конфігурація обробника помилок для кожного стеку. Витік є тим самим розкриттям, яке вже охоплює обробка помилок)
- [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case _(historical)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (специфічний для застосунку дизайн, без єдиного sink у коді)
- [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (мінімізація даних, прозорість, політика зберігання)
- [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (галузі вбудованих систем: шина CAN, OTA-прошивки, цілісність сенсорів і радіо, а не вихідний код вебзастосунків і API)
- [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (посилення захисту платформ Android та iOS: сховище, біометрія, pinning, PII. Немає єдиної поверхні в коді, а аспект завантаження недовіреного коду перейшов до `interpreter`)
- [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(community page)_](https://owasp.org/www-community/Threat_Modeling)
- [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)
- [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)
- [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)
- [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html)
- [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)
- [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html)
- [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html)

---

# /lagune-repair: відновіть відстеження знахідок

> Відновіть ланцюжок, коли перейменування чи переміщений файл заплутує відстеження Lagune.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/repair
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/repair
Останнє оновлення: 2026-11-03

🧰 Відновіть ланцюжок, коли перейменування чи переміщений файл його заплутує.

**Внутрішнє обслуговування, а не фаза безпеки**

Repair не є шостою фазою в лінійному процесі. Її завдання полягає в тому, щоб відстеження залишалося узгодженим.

```prompt
# Вона не приймає вхідних даних: завжди відновлює весь ланцюжок
/lagune-repair
```

## Як це працює

Кожна знахідка detect є одним відстежуваним елементом, який plan, harden і verify передають далі, кожна діє з ним і повторно звітує про нього за назвою. Ця назва, записана однаково як заголовок розділу в кожному артефакті, є його ідентичністю на всьому шляху.

Єдине мінливе, що зберігає відстеження, це шляхи до файлів, на які вказує елемент. Ці шляхи більше ніде не зберігаються, тож перейменування чи переміщений файл може розірвати зв'язок лише там, а не у двох копіях, що розійшлися. Коли це стається, repair виправляє карту (`.lagune/tracking.json`), щоб ідентичність пережила перейменування. Вона читає артефакти й карту відстеження, читає ваш вихідний код лише для того, щоб дізнатися новий шлях перейменованого файлу, і ніколи не пише вміст про безпеку.

У тому самому проході вона звіряє кожен артефакт пам'яті з його шаблоном і повідомляє, що відхилилося, вказуючи для кожної розбіжності фазу, яка її виправляє.

**Порада**

- Вона не торкається ні вашого коду, ні текстових артефактів, лише відстеження.
- Вам рідко доведеться запускати її вручну. Коли фаза помічає, що ланцюжок неузгоджений, вона сама запускає repair і продовжує.
- Відстеження, яке вона підтримує, зберігається в `.lagune/tracking.json`, внутрішньому стані, який ви ніколи не редагуєте вручну.

---

# Migrate: перенесіть проєкт Lagune на маніфесті на навички й плагіни

> Перенесіть проєкт Lagune на основі маніфесту на Lagune на основі навичок, зберігши принципи безпеки, артефакти, відстеження й власні спеціалізації.

Канонічна URL-адреса: https://lagune.ai/uk-UA/docs/commands/migrate
Мова: uk-UA
Оригінал: https://lagune.ai/docs/commands/migrate
Останнє оновлення: 2026-11-03

🔀 Перенесіть проєкт **Lagune** на основі маніфесту на **Lagune** на основі навичок, зберігши все, що ви написали.

**Повідомлення про застарілість**

Проєкт із маніфестом працюватиме як є до `v1.x`: `npx lagune` передає `init`, `pull`, `update`, `add`, `remove`, `list` і дашборд версії `lagune@0.15.0`, останній на основі маніфесту.

## Перенесення

1. Переконайтеся, що поточну роботу закомічено, а потім виконайте migrate з кореня проєкту:

   ```bash
   npx lagune migrate
   ```

2. Закомітьте зміни, які вона внесла, окремим комітом, щоб перенесення залишилося однією зміною, яку легко переглянути.
3. Встановіть команди для свого агента, як показано на [сторінці встановлення](https://lagune.ai/uk-UA/docs).
4. Якщо в проєкті вже є артефакт detect, plan чи harden, попросіть [`/lagune-repair`](https://lagune.ai/uk-UA/docs/commands/repair) узгодити старі посилання в них і у ваших власних спеціалізаціях:

   ```prompt
   /lagune-repair Узгодь застосовані спеціалізації (раніше sub-skills) в артефактах у `.lagune/memory/` (`detect.md`, `plan.md` і `harden.md`) з назвами, які наводить новий каталог, і перепиши кожен виклик, який мої власні спеціалізації в `.lagune/catalog/` роблять до старих хуків у `.lagune/hooks/`, як виклик інструмента `lagune_read` або `lagune_write`.
   ```

## Що змінюється

| До                                                                    | Після                                                                             |
| --------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| `.lagune/templates/`, `.lagune/hooks/` і `.lagune/specializations.md` | Видалено: кожна навичка містить свій шаблон, а хуки виконує рушій                 |
| Копії вбудованих спеціалізацій у `.lagune/skills/`                    | Видалено: вбудовані спеціалізації надає рушій                                     |
| Ваші власні спеціалізації в `.lagune/skills/`                         | Переміщено в `.lagune/catalog/`                                                   |
| `.lagune/skills.json`, індекс ваших власних спеціалізацій             | Об'єднано з `.lagune/configs.json`                                                |
| Категорії маніфесту                                                   | Записано в `.lagune/configs.json`                                                 |
| Старі команди агента, як-от `/lagune.detect`                          | Видалено: [встановлення **Lagune**](https://lagune.ai/uk-UA/docs) приносить нові, як-от `/lagune-detect` |
| Блок **Lagune** у `.gitignore`                                        | Видалено разом із файлом, якщо в ньому більше нічого не було                      |
| `.lagune/proofs/`, який ігнорував цей блок                            | Не потрапляє в коміти завдяки власному `.gitignore`                               |
| `.lagune/manifest.json`                                               | Видалено останнім                                                                 |

Ваша робота з безпеки залишається як є: принципи безпеки, артефакт, створений кожною фазою, і карта відстеження зі шляхами, на які вказує кожна знахідка.

## Часті запитання

### Чи обов'язково мігрувати?

Так. Проєкти на основі маніфесту застаріли й працюватимуть лише до v1.x, тож виконайте npx lagune migrate, щоб перенести свій.

### Що зберігає migrate?

Ваші принципи безпеки, кожен артефакт фаз, карту відстеження, ваші категорії й власні спеціалізації. Спеціалізації переміщуються в .lagune/catalog/, а їхній індекс об'єднується з вашими категоріями в .lagune/configs.json.

### Коли встановлювати нові команди?

Після migrate, як показує сторінка встановлення для вашого агента. Встановити їх спершу теж можна, бо migrate зберігає нову /lagune.

### Колега вже мігрував. Що мені запустити?

Отримайте зміни з перенесенням, а потім один раз виконайте npx lagune migrate. Вона видаляє те, що Lagune на основі маніфесту залишив у вашому клоні і чого система контролю версій ніколи не переносила, а також не пускає ваші доведення в коміти.