Files
claude-howto/uk/SECURITY.md
T
Luong NGUYEN 28149a85fc docs: sync to Claude Code v2.1.245 (#177)
* docs: sync to Claude Code v2.1.245

Sync the tutorial, its four translations, and both learner-facing skills
against Claude Code v2.1.245 (was anchored at v2.1.235).

The graded material turned out to be staler than the tutorials it grades.
The lesson READMEs already said "31 hook events", "six rewind options" and
"six permission modes"; the quiz and self-assessment still said 25, 5 and 5,
so learners were scored against a wrong answer and then sent to a lesson
that contradicted it. Seven such claims are fixed here.

Two long-standing doc defects were also verified against official docs:

- Hook default timeout was documented as 60 seconds. It is 600 for
  command/http/mcp_tool (30 for prompt, 60 for agent), with per-event
  overrides. Wrong in five places.
- Skill precedence was documented as enterprise > project > personal. The
  official order is enterprise > personal > project. question-bank.md
  Lesson 03 Q9 already graded the correct order, so the lesson had been
  contradicting its own quiz.

Fixed
- Hook default timeout 60s -> 600s, with per-event overrides
- Skill precedence: project and personal were swapped
- Memory "overrides root CLAUDE.md" -> concatenation model (last holdouts
  after the quiz was aligned in #164)
- permissionMode frontmatter omitted `auto` (English + vi/ja/uk); the quiz
  was right and the docs were wrong
- Built-in subagent `Bash` no longer exists upstream -> renamed to `claude`
- `/undo` is absent from the official commands reference -> marked deprecated
- `backgroundTasks` settings block was fabricated -> replaced with
  CLAUDE_CODE_DISABLE_BACKGROUND_TASKS and the concurrency env var
- Plugin manifest field is `lspServers`, not inline `lsp`
- vi/05-mcp documented `claude mcp add --transport ws`, which upstream
  explicitly does not support
- Self-assessment could never reach its own maximum score: rounds cap at
  4+4+4+3+4 = 19, not 20
- 13 dangling quiz `Review:` pointers, two of which named another lesson
- Skill description cap: 1024 chars -> 1,536 combined with `when_to_use`

Added
- WebSocket (`ws`) MCP transport, undocumented until now
- Concise output style (v2.1.237), a fifth built-in
- modelPicker, promptCacheTtl, subagentPromptCacheTtl, modelPricing,
  keybindingFlavor settings
- ANTHROPIC_DEFAULT_MODEL env var
- Hook `async`, `asyncRewake`, `shell`, `statusMessage`, `retry` keys;
  `agent` type marked experimental
- /design canvas, Remote Control out of research preview, notify_when_idle,
  plugin manifest fields (workflows, channels, dependencies, outputStyles)

Deferred deliberately: the reserved `synced` skills folder, and a bulk
footer stamp across the translations. zh/ carries none of the P0 claims
(it is abridged upstream of this run), so it has no P0 sub-tasks rather
than fabricated English.

Mermaid validation did not run in this environment (mmdc absent); CI covers it.

* fix(docs): propagate v2.1.245 corrections to CATALOG, translations, and stale enumerations

* fix(docs): propagate built-in subagent rename to uk/vi/zh CATALOG and zh lesson
2026-08-26 07:20:04 +02:00

17 KiB
Raw Blame History

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

Огляд

Безпека проєкту Claude How To є важливою для нас. Цей документ описує наші практики безпеки та пояснює, як відповідально повідомляти про вразливості.

Підтримувані версії

Ми надаємо оновлення безпеки для наступних версій:

Версія Статус Підтримка до
Остання (main) Активна Поточна + 6 місяців

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

Практики безпеки

Безпека коду

  1. Управління залежностями

    • Усі Python-залежності зафіксовані в requirements.txt
    • Регулярні оновлення через dependabot та ручний перегляд
    • Сканування безпеки за допомогою Bandit при кожному коміті
    • Pre-commit хуки для перевірок безпеки
  2. Якість коду

    • Лінтинг за допомогою Ruff виявляє поширені проблеми
    • Перевірка типів за допомогою mypy запобігає вразливостям, пов'язаним з типами
    • Pre-commit хуки забезпечують дотримання стандартів
    • Усі зміни переглядаються перед злиттям
  3. Контроль доступу

    • Захист гілки main
    • Обов'язковий рев'ю перед мерджем
    • Статусні перевірки повинні пройти перед мерджем
    • Обмежений доступ на запис до репозиторію

Безпека документації

  1. Ніяких секретів у прикладах

    • Усі API-ключі в прикладах є заповнювачами
    • Облікові дані ніколи не захардкоджені
    • Файли .env.example показують необхідні змінні
    • Чіткі попередження щодо управління секретами
  2. Найкращі практики безпеки

    • Приклади демонструють безпечні патерни
    • Попередження безпеки виділені в документації
    • Посилання на офіційні гайди безпеки
    • Обробка облікових даних обговорюється у відповідних розділах
  3. Перегляд контенту

    • Вся документація перевіряється на проблеми безпеки
    • Міркування безпеки в настановах для контриб'юторів
    • Валідація зовнішніх посилань та посилань

Безпека залежностей

  1. Сканування

    • Bandit сканує весь Python-код на вразливості
    • Перевірка вразливостей залежностей через GitHub security alerts
    • Регулярні ручні аудити безпеки
  2. Оновлення

    • Патчі безпеки застосовуються оперативно
    • Мажорні версії оцінюються ретельно
    • Changelog включає оновлення, пов'язані з безпекою
  3. Прозорість

    • Оновлення безпеки задокументовані в комітах
    • Розкриття вразливостей обробляється відповідально
    • Публічні рекомендації безпеки за потреби

Повідомлення про вразливість

Проблеми безпеки, які нас цікавлять

Ми цінуємо повідомлення про:

  • Вразливості коду в скриптах або прикладах
  • Вразливості залежностей у Python-пакетах
  • Проблеми криптографії в будь-яких прикладах коду
  • Недоліки автентифікації/авторизації в документації
  • Ризики витоку даних у прикладах конфігурації
  • Вразливості ін'єкцій (SQL, команди тощо)
  • Проблеми SSRF/XXE/обхід шляхів

Проблеми безпеки поза межами

Це виходить за рамки цього проєкту:

  • Вразливості в самому Claude Code (повідомляйте Anthropic)
  • Проблеми із зовнішніми сервісами або бібліотеками (повідомляйте upstream)
  • Соціальна інженерія або навчання користувачів (не стосується цього довідника)
  • Теоретичні вразливості без підтвердження концепції
  • Вразливості в залежностях, повідомлені через офіційні канали

Як повідомити

Приватне повідомлення (рекомендовано)

Для чутливих проблем безпеки використовуйте приватне повідомлення про вразливості GitHub:

  1. Перейдіть: https://github.com/luongnv89/claude-howto/security/advisories
  2. Натисніть "Report a vulnerability"
  3. Заповніть деталі вразливості
  4. Вкажіть:
    • Чіткий опис вразливості
    • Уражений компонент (файл, розділ, приклад)
    • Потенційний вплив
    • Кроки для відтворення (якщо можливо)
    • Запропоноване виправлення (якщо є)

Що відбувається далі:

  • Ми підтвердимо отримання протягом 48 годин
  • Ми дослідимо та оцінимо серйозність
  • Ми працюватимемо з вами над розробкою виправлення
  • Ми узгодимо графік розкриття
  • Ми вкажемо вас у рекомендації безпеки (якщо ви не бажаєте анонімності)

Публічне повідомлення

Для нечутливих проблем або тих, що вже є публічними:

  1. Створіть GitHub Issue з міткою security
  2. Вкажіть:
    • Назва: [SECURITY] з коротким описом
    • Детальний опис
    • Уражений файл або розділ
    • Потенційний вплив
    • Запропоноване виправлення

Процес реагування на вразливості

Оцінка (24 години)

  1. Ми підтверджуємо отримання повідомлення
  2. Ми оцінюємо серйозність за CVSS v3.1
  3. Ми визначаємо, чи входить це в область застосування
  4. Ми зв'язуємося з вами з початковою оцінкою

Розробка (1-7 днів)

  1. Ми розробляємо виправлення
  2. Ми переглядаємо та тестуємо виправлення
  3. Ми створюємо рекомендацію безпеки
  4. Ми готуємо нотатки до випуску

Розкриття (залежно від серйозності)

Критична (CVSS 9.0-10.0)

  • Виправлення випускається негайно
  • Публічна рекомендація видається
  • 24-годинне попереднє повідомлення репортерам

Висока (CVSS 7.0-8.9)

  • Виправлення випускається протягом 48-72 годин
  • 5-денне попереднє повідомлення репортерам
  • Публічна рекомендація при випуску

Середня (CVSS 4.0-6.9)

  • Виправлення випускається в наступному регулярному оновленні
  • Публічна рекомендація при випуску

Низька (CVSS 0.1-3.9)

  • Виправлення включається в наступне регулярне оновлення
  • Рекомендація при випуску

Публікація

Ми публікуємо рекомендації безпеки, що включають:

  • Опис вразливості
  • Уражені компоненти
  • Оцінку серйозності (CVSS-бал)
  • Версію виправлення
  • Обхідні рішення (якщо є)
  • Подяку репортеру (з дозволу)

Найкращі практики для репортерів

Перед повідомленням

  • Перевірте проблему: Чи можете ви відтворити її стабільно?
  • Шукайте існуючі issues: Чи вже повідомлено про це?
  • Перевірте документацію: Чи є настанови щодо безпечного використання?
  • Тестуйте виправлення: Чи працює ваше запропоноване виправлення?

При повідомленні

  • Будьте конкретними: Вказуйте точні шляхи файлів та номери рядків
  • Додавайте контекст: Чому це проблема безпеки?
  • Покажіть вплив: Що міг би зробити зловмисник?
  • Надайте кроки: Як ми можемо відтворити?
  • Запропонуйте виправлення: Як би ви це виправили?

Після повідомлення

  • Будьте терплячими: Ми маємо обмежені ресурси
  • Будьте на зв'язку: Відповідайте на подальші запитання швидко
  • Зберігайте конфіденційність: Не розголошуйте публічно до виправлення
  • Дотримуйтесь координації: Слідуйте нашому графіку розкриття

Заголовки безпеки та конфігурація

Безпека репозиторію

  • Захист гілок: Основна гілка потребує 2 схвалень для змін
  • Статусні перевірки: Усі CI/CD перевірки повинні пройти
  • CODEOWNERS: Призначені рецензенти для ключових файлів
  • Підписані коміти: Рекомендовано для контриб'юторів

Безпека розробки

# Install pre-commit hooks
pre-commit install

# Run security scans locally
bandit -c pyproject.toml -r scripts/
mypy scripts/ --ignore-missing-imports
ruff check scripts/

Безпека залежностей

# Check for known vulnerabilities
pip install safety
safety check

# Or use pip-audit
pip install pip-audit
pip-audit

Настанови безпеки для контриб'юторів

При написанні прикладів

  1. Ніколи не захардкоджуйте секрети

    # ❌ Bad
    api_key = "sk-1234567890"
    
    # ✅ Good
    api_key = os.getenv("API_KEY")
    
  2. Попереджайте про наслідки безпеки

    ⚠️ **Security Note**: Never commit `.env` files to git.
    Add to `.gitignore` immediately.
    
  3. Використовуйте безпечні значення за замовчуванням

    • Увімкнення автентифікації за замовчуванням
    • Використання HTTPS де можливо
    • Валідація та санітизація введення
    • Використання параметризованих запитів
  4. Документуйте міркування безпеки

    • Пояснюйте, чому безпека важлива
    • Показуйте безпечні vs. небезпечні патерни
    • Посилайтесь на авторитетні джерела
    • Розміщуйте попередження на видному місці

При перегляді внесків

  1. Перевіряйте на відкриті секрети

    • Сканування на поширені патерни (api_key=, password=)
    • Перегляд конфігураційних файлів
    • Перевірка змінних оточення
  2. Перевіряйте безпечні практики кодування

    • Відсутність захардкоджених облікових даних
    • Правильна валідація введення
    • Безпечна автентифікація/авторизація
    • Безпечна робота з файлами
  3. Тестуйте наслідки безпеки

    • Чи можна це зловживати?
    • Який найгірший сценарій?
    • Чи є граничні випадки?

Ресурси безпеки

Офіційні стандарти

Безпека Python

Управління залежностями

Загальна безпека

Архів рекомендацій безпеки

Минулі рекомендації безпеки доступні на вкладці GitHub Security Advisories.

Контакти

Для запитань, пов'язаних з безпекою, або для обговорення практик безпеки:

  1. Приватне повідомлення про безпеку: Використовуйте приватне повідомлення про вразливості GitHub
  2. Загальні питання безпеки: Відкрийте обговорення з тегом [SECURITY]
  3. Відгуки про політику безпеки: Створіть issue з міткою security

Подяки

Ми цінуємо дослідників безпеки та учасників спільноти, які допомагають підтримувати безпеку цього проєкту. Контриб'юторів, які відповідально повідомляють про вразливості, буде відзначено в наших рекомендаціях безпеки (якщо вони не бажають анонімності).

Оновлення політики

Ця політика безпеки переглядається та оновлюється:

  • При виявленні нових вразливостей
  • При розвитку найкращих практик безпеки
  • При зміні обсягу проєкту
  • Щорічно як мінімум

Останнє оновлення: 25 серпня 2026 Версія Claude Code: 2.1.245 Джерела:


Дякуємо за допомогу в забезпеченні безпеки Claude How To! 🔒