Політика безпеки
Огляд
Безпека проєкту Claude How To є важливою для нас. Цей документ описує наші практики безпеки та пояснює, як відповідально повідомляти про вразливості.
Підтримувані версії
Ми надаємо оновлення безпеки для наступних версій:
| Версія | Статус | Підтримка до |
|---|---|---|
| Остання (main) | ✅ Активна | Поточна + 6 місяців |
| Релізи 1.x | ✅ Активна | До наступної мажорної версії |
Примітка: Як освітній проєкт-довідник, ми зосереджуємося на підтримці актуальних найкращих практик та безпеки документації, а не на традиційній підтримці версій. Оновлення застосовуються безпосередньо до гілки main.
Практики безпеки
Безпека коду
Управління залежностями
- Усі Python-залежності зафіксовані в
requirements.txt - Регулярні оновлення через dependabot та ручний перегляд
- Сканування безпеки за допомогою Bandit при кожному коміті
- Pre-commit хуки для перевірок безпеки
- Усі Python-залежності зафіксовані в
Якість коду
- Лінтинг за допомогою Ruff виявляє поширені проблеми
- Перевірка типів за допомогою mypy запобігає вразливостям, пов'язаним з типами
- Pre-commit хуки забезпечують дотримання стандартів
- Усі зміни переглядаються перед злиттям
Контроль доступу
- Захист гілки
main - Обов'язковий рев'ю перед мерджем
- Статусні перевірки повинні пройти перед мерджем
- Обмежений доступ на запис до репозиторію
- Захист гілки
Безпека документації
Ніяких секретів у прикладах
- Усі API-ключі в прикладах є заповнювачами
- Облікові дані ніколи не захардкоджені
- Файли
.env.exampleпоказують необхідні змінні - Чіткі попередження щодо управління секретами
Найкращі практики безпеки
- Приклади демонструють безпечні патерни
- Попередження безпеки виділені в документації
- Посилання на офіційні гайди безпеки
- Обробка облікових даних обговорюється у відповідних розділах
Перегляд контенту
- Вся документація перевіряється на проблеми безпеки
- Міркування безпеки в настановах для контриб'юторів
- Валідація зовнішніх посилань та посилань
Безпека залежностей
Сканування
- Bandit сканує весь Python-код на вразливості
- Перевірка вразливостей залежностей через GitHub security alerts
- Регулярні ручні аудити безпеки
Оновлення
- Патчі безпеки застосовуються оперативно
- Мажорні версії оцінюються ретельно
- Changelog включає оновлення, пов'язані з безпекою
Прозорість
- Оновлення безпеки задокументовані в комітах
- Розкриття вразливостей обробляється відповідально
- Публічні рекомендації безпеки за потреби
Повідомлення про вразливість
Проблеми безпеки, які нас цікавлять
Ми цінуємо повідомлення про:
- Вразливості коду в скриптах або прикладах
- Вразливості залежностей у Python-пакетах
- Проблеми криптографії в будь-яких прикладах коду
- Недоліки автентифікації/авторизації в документації
- Ризики витоку даних у прикладах конфігурації
- Вразливості ін'єкцій (SQL, команди тощо)
- Проблеми SSRF/XXE/обхід шляхів
Проблеми безпеки поза межами
Це виходить за рамки цього проєкту:
- Вразливості в самому Claude Code (повідомляйте Anthropic)
- Проблеми із зовнішніми сервісами або бібліотеками (повідомляйте upstream)
- Соціальна інженерія або навчання користувачів (не стосується цього довідника)
- Теоретичні вразливості без підтвердження концепції
- Вразливості в залежностях, повідомлені через офіційні канали
Як повідомити
Приватне повідомлення (рекомендовано)
Для чутливих проблем безпеки використовуйте приватне повідомлення про вразливості GitHub:
- Перейдіть: https://github.com/luongnv89/claude-howto/security/advisories
- Натисніть "Report a vulnerability"
- Заповніть деталі вразливості
- Вкажіть:
- Чіткий опис вразливості
- Уражений компонент (файл, розділ, приклад)
- Потенційний вплив
- Кроки для відтворення (якщо можливо)
- Запропоноване виправлення (якщо є)
Що відбувається далі:
- Ми підтвердимо отримання протягом 48 годин
- Ми дослідимо та оцінимо серйозність
- Ми працюватимемо з вами над розробкою виправлення
- Ми узгодимо графік розкриття
- Ми вкажемо вас у рекомендації безпеки (якщо ви не бажаєте анонімності)
Публічне повідомлення
Для нечутливих проблем або тих, що вже є публічними:
- Створіть GitHub Issue з міткою
security - Вкажіть:
- Назва:
[SECURITY]з коротким описом - Детальний опис
- Уражений файл або розділ
- Потенційний вплив
- Запропоноване виправлення
- Назва:
Процес реагування на вразливості
Оцінка (24 години)
- Ми підтверджуємо отримання повідомлення
- Ми оцінюємо серйозність за CVSS v3.1
- Ми визначаємо, чи входить це в область застосування
- Ми зв'язуємося з вами з початковою оцінкою
Розробка (1-7 днів)
- Ми розробляємо виправлення
- Ми переглядаємо та тестуємо виправлення
- Ми створюємо рекомендацію безпеки
- Ми готуємо нотатки до випуску
Розкриття (залежно від серйозності)
Критична (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Настанови безпеки для контриб'юторів
При написанні прикладів
Ніколи не захардкоджуйте секрети
python# ❌ Bad api_key = "sk-1234567890" # ✅ Good api_key = os.getenv("API_KEY")Попереджайте про наслідки безпеки
markdown⚠️ **Security Note**: Never commit `.env` files to git. Add to `.gitignore` immediately.Використовуйте безпечні значення за замовчуванням
- Увімкнення автентифікації за замовчуванням
- Використання HTTPS де можливо
- Валідація та санітизація введення
- Використання параметризованих запитів
Документуйте міркування безпеки
- Пояснюйте, чому безпека важлива
- Показуйте безпечні vs. небезпечні патерни
- Посилайтесь на авторитетні джерела
- Розміщуйте попередження на видному місці
При перегляді внесків
Перевіряйте на відкриті секрети
- Сканування на поширені патерни (api_key=, password=)
- Перегляд конфігураційних файлів
- Перевірка змінних оточення
Перевіряйте безпечні практики кодування
- Відсутність захардкоджених облікових даних
- Правильна валідація введення
- Безпечна автентифікація/авторизація
- Безпечна робота з файлами
Тестуйте наслідки безпеки
- Чи можна це зловживати?
- Який найгірший сценарій?
- Чи є граничні випадки?
Ресурси безпеки
Офіційні стандарти
Безпека Python
Управління залежностями
Загальна безпека
Архів рекомендацій безпеки
Минулі рекомендації безпеки доступні на вкладці GitHub Security Advisories.
Контакти
Для запитань, пов'язаних з безпекою, або для обговорення практик безпеки:
- Приватне повідомлення про безпеку: Використовуйте приватне повідомлення про вразливості GitHub
- Загальні питання безпеки: Відкрийте обговорення з тегом
[SECURITY] - Відгуки про політику безпеки: Створіть issue з міткою
security
Подяки
Ми цінуємо дослідників безпеки та учасників спільноти, які допомагають підтримувати безпеку цього проєкту. Контриб'юторів, які відповідально повідомляють про вразливості, буде відзначено в наших рекомендаціях безпеки (якщо вони не бажають анонімності).
Оновлення політики
Ця політика безпеки переглядається та оновлюється:
- При виявленні нових вразливостей
- При розвитку найкращих практик безпеки
- При зміні обсягу проєкту
- Щорічно як мінімум
Останнє оновлення: Квітень 2026 Наступний перегляд: Квітень 2027
Дякуємо за допомогу в забезпеченні безпеки Claude How To! 🔒