claude-howto/uk/SECURITY.md

<!-- i18n-source: SECURITY.md -->
<!-- i18n-source-sha: 63a1416 -->
<!-- i18n-date: 2026-04-09 -->

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

## Огляд

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

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

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

| Версія | Статус | Підтримка до |
|--------|--------|--------------|
| Остання (main) | ✅ Активна | Поточна + 6 місяців |
| Релізи 1.x | ✅ Активна | До наступної мажорної версії |

**Примітка**: Як освітній проєкт-довідник, ми зосереджуємося на підтримці актуальних найкращих практик та безпеки документації, а не на традиційній підтримці версій. Оновлення застосовуються безпосередньо до гілки 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](https://www.first.org/cvss/v3.1/specification-document)
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**: Призначені рецензенти для ключових файлів
- **Підписані коміти**: Рекомендовано для контриб'юторів

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

```bash
# 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/
```

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

```bash
# Check for known vulnerabilities
pip install safety
safety check

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

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

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

1. **Ніколи не захардкоджуйте секрети**
   ```python
   # ❌ Bad
   api_key = "sk-1234567890"

   # ✅ Good
   api_key = os.getenv("API_KEY")
   ```

2. **Попереджайте про наслідки безпеки**
   ```markdown
   ⚠️ **Security Note**: Never commit `.env` files to git.
   Add to `.gitignore` immediately.
   ```

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

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

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

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

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

3. **Тестуйте наслідки безпеки**
   - Чи можна це зловживати?
   - Який найгірший сценарій?
   - Чи є граничні випадки?

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

### Офіційні стандарти
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [CWE Top 25](https://cwe.mitre.org/top25/)
- [CVSS Calculator](https://www.first.org/cvss/calculator/3.1)

### Безпека Python
- [Python Security Advisories](https://www.python.org/dev/security/)
- [PyPI Security](https://pypi.org/help/#security)
- [Bandit Documentation](https://bandit.readthedocs.io/)

### Управління залежностями
- [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/)
- [GitHub Security Alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)

### Загальна безпека
- [Anthropic Security](https://www.anthropic.com/)
- [GitHub Security Best Practices](https://docs.github.com/en/code-security)

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

Минулі рекомендації безпеки доступні на вкладці [GitHub Security Advisories](https://github.com/luongnv89/claude-howto/security/advisories).

## Контакти

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

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

## Подяки

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

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

Ця політика безпеки переглядається та оновлюється:
- При виявленні нових вразливостей
- При розвитку найкращих практик безпеки
- При зміні обсягу проєкту
- Щорічно як мінімум

**Останнє оновлення**: Квітень 2026
**Наступний перегляд**: Квітень 2027

---

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