AI trust boundary
Дозволена межа даних, providers і controls для AI workflow, визначена governance, privacy, security та contractual requirements організації.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Authentication Cheat Sheet
Додає security boundary для MFA, authentication logging і test-only seams.
Юзер менеджмент та костилі з якими ви стикнетесь в житті → Першоджерело ↗Database Authorization
Фіксує поточний contract між JWT, PostgreSQL roles, grants і Row-Level Security.
Прихована складність бекенд-тестування → Першоджерело ↗Database authorization у PostgREST
PostgREST автентифікує request, перемикається на PostgreSQL role і залишає authorization базі даних. JWT claims, grants і Row-Level Security стають перевірюваними частинами API access control.
Прихована складність бекенд-тестування →Playwright Authentication
Фіксує security boundary для auth state і parallel account strategy.
Практика курсу на YOY, домашні завдання та формат ПМП → Першоджерело ↗Shift Left review requirements
До початку реалізації знайдіть у вибраному requirement contradictions, missing states, duplicated rules і неявні security або data contracts. Для кожного ризику визначте найдешевший ранній evidence, який його підтвердить або спростує.
Таблиця requirement risk → рання перевірка → очікуваний evidence → відповідальна роль.
OTP, rate limits і production smoke
Для OTP можна зарезервувати test identity і детермінований code; для rate limits — окреме правило для CI traffic. Автор допускає такий bypass навіть на production, хоча прямо зазначає, що цього бажано не робити. Редакційне security-застереження: на production безпечніше виконувати smoke через звичайний захист або спеціально спроєктований найменш привілейований test path. Будь-який production bypass header чи hardcoded OTP стає критичним секретом: його витік фактично вимикає захист, тому потрібні ротація, журналювання, вузький scope і окремий security review.
Інфраструктура і рекомендований маршрут
Security scanner може запускатися всередині private infrastructure, щоб бачити internal services і network paths, недоступні зовні. Це вимагає розуміння Docker, Kubernetes, cloud networking, permissions та безпечного поводження з collected traffic і reports. Практичний маршрут із відео: обрати цільову security-спеціалізацію, пройти hands-on курс, підготуватися до ринково визнаної сертифікації, посилити scripting та infrastructure basics і шукати перші security задачі у поточному продукті. Перехід простіший, коли можна показати відтворювані лабораторні результати, а не лише заявлений інтерес.
Можливість, технічний борг і безпека
[Дивитися з 31:22](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1882s). Малий бізнес зможе дозволити собі одного-двох інженерів для власної CRM, аналітики чи інтеграцій, але слабка інженерна база збільшить кількість data-loss, authentication і maintenance incidents. Enterprise adoption стримують privacy та заборона передавати proprietary code стороннім моделям. Паралельно AI і генерує security vulnerabilities, і допомагає знаходити давні дефекти. Єдиної відповіді для ринку немає: AI дає величезну можливість швидко реалізувати ідею, але deployment, domain, observability, security та подальша підтримка все ще потребують людей і бюджету.
Ринок, consulting і практичне навчання
Внутрішня pentest-команда потрібна не кожному продукту постійно. Багато компаній залучають зовнішній security assessment перед важливим запуском, аудитом або після інцидентів; навіть зрілі внутрішні команди можуть замовляти незалежну перевірку. Як навчальний старт рекомендуються практичні курси, де учень підіймає vulnerable environment, працює з Docker, читає API specification і пробує реальні tools. Так формується зв’язок між знахідкою scanner-а, її відтворенням та поясненням impact.
SAST, DAST і спеціалізовані scanners
SAST аналізує codebase, configuration та infrastructure definitions без запуску повного user flow. До scope можуть входити source code, dependencies, YAML, Docker та Terraform files. DAST працює проти запущеного застосунку: генерує requests, змінює parameters, headers, authentication data й шукає небезпечну runtime behavior. OpenAPI specification може бути input для API security scanner-а. Окремі tools аналізують network traffic або вразливості, характерні для конкретної мови, cloud platform, protocol чи IoT stack. Тому pentesting швидко розгалужується на спеціалізації, а не зводиться до ручного перебору requests у Postman.
Класи еквівалентності, boundary values та IDs
Таблиця розширюється через equivalence partitioning і boundary value analysis: валідний формат незареєстрованого email, відсутня локальна або domain-частина, пробіли, порожній пароль, занадто короткі чи довгі значення. Окремо LLM пропонує рядки, схожі на XSS і SQL injection payloads. Ці payloads є лише вхідними прикладами, а не доказом захищеності: security check повинен мати конкретний expected result і виконуватися в безпечному тестовому середовищі. Для кожної параметризованої ітерації задається `id`, щоб у pytest output і CI report було видно не номер набору, а зміст failed case. Запуск виявляє як помилки з Faker/API, так і server-side rate limit. Це корисний сигнал: параметризація збільшує кількість однотипних запитів, тому test data й темп запуску мають враховувати обмеження системи.
Security та нефункціональні релізи
Оновлення framework, runtime, бази даних або Kafka може майже не змінити бізнес-код, але все одно є повноцінним релізом. Такі зміни повинні регулярно проходити перевірки, бо бібліотеки накопичують відомі вразливості. Статичні dependency scanners знаходять відомі проблеми за назвою й версією прямої або транзитивної залежності. Реакція може полягати в upgrade, заміні пакета або, як останній варіант, відмові від нього.
Як переходити з automation у pentesting
Pentesting значною мірою спирається на automation tools, network sniffers, static analysis і спеціалізовані scanners. Попередній досвід написання тестів і scripts тому корисний, але його потрібно доповнити security-моделлю: вразливостями, протоколами, trust boundaries і способами підтвердження ризику. Автор наголошує, що для цього напряму професійні сертифікації мають більшу ринкову вагу, ніж загальні QA certificates: у конкретних вакансіях, тендерах або client engagements вони можуть бути формальною вимогою. Найбезпечніший шлях — поєднати підготовку до визнаної сертифікації з лабораторною практикою, а не обмежуватися теорією.
Домовленість із командою замість маскування бота
Cloudflare, gateway або load balancer можуть блокувати automation за browser signals, JavaScript execution і частотою запитів. Надійний шлях — узгодити з developers та DevOps контрольований header, cookie, test account або environment flag, який переводить конкретний тестовий traffic у спеціальний режим. Редакційне security-застереження: це має бути вузький контракт із секретом, allowlist, аудитом і мінімальними правами, а не загальний спосіб вимкнути захист.
Як працює SSH-доступ до GitHub
SSH використовує пару ключів. Приватний ключ залишається лише на довіреному комп’ютері й не публікується. Публічний ключ призначений для передавання сервісу на кшталт GitHub: сервер пов’язує його з акаунтом і перевіряє, що клієнт володіє відповідним приватним ключем. Якщо локальний проєкт уже ініціалізовано як Git-репозиторій, PyCharm/IntelliJ може опублікувати його через Share Project on GitHub. Перед цим варто налаштувати автентифікацію та перевірити, під яким акаунтом працює IDE.