DevSecOps English: Security Shift-Left and Threat Vocabulary (англійською)

Introduction

DevSecOps інтегрує практику безпеки в цілий життєвий цикл розробки програмного забезпечення, а не розглядає безпеку як ворота в кінці процесу. Якщо ваша команда приймає практику DevSecOps, ви зіткнетеся з певним набором англійських термінів у переглядах безпеки, обговореннях конвеєрів і розмовах про архітектуру. Знання цього словника допоможе вам у вирішенні питань безпеки, допоможе вам у сеансах моделювання загроз і допоможе вам у написанні документації з безпеки.

Пересунути ліворуч

Центральною концепцією DevSecOps є пересування ліворуч — пересування дій з безпеки на початку процесу розробки, у бік лівої частини хронології розробки програмного забезпечення:

• «Ми переміщуємо безпеку вліво, запускаючи SAST в CI» — ловля вразливостей до того, як код буде розгорнутий
• «Безпека — це відповідальність кожного, а не тільки команди безпеки» — культурне твердження філософії Shift-Left
• «Ми знаходимо проблеми в розробці, а не в виробництві» — мета зсуву вліво
• ** ворота безпеки ** — контрольна точка у конвеєрі, яка запобігає продовженню роботи, якщо перевірки безпеки зазнають невдачі; « ми додали ворота безпеки, які блокують злиття, якщо виявлено критичні вразливості »
• «Змінити безпеку ліворуч без створення тертя» — виклик зробити безпеку достатньо швидко, щоб розробники прийняли її

Фраза «пересунути ліворуч» походить від читання хронології розробки зліва (планування) направо (виробництво). Безпека традиційно відбувається в крайньому правому куті — після розробки. Змінити його наліво означає зробити це раніше, коли ремонт дешевше і швидше.

САС, ДАС, СКА

Зазвичай обговорюється три типи автоматичного сканування безпеки:

• ** SAST (Static Application Security Testing) ** — аналізує код на вразливості без запуску програми; « ми запускаємо SAST на кожному запиті на витягування за допомогою Semgrep »
• ** DAST (Dynamic Application Security Testing) ** — перевірка запущеної програми за допомогою імітації атак; « ми запускаємо DAST проти середовища тестування перед кожним випуском »
• SCA (Software Composition Analysis) — сканує залежності на відомі вразливості; «SCA виявив, що наша бібліотека журналювання має критичний CVE — нам потрібно оновити її»
• CVE (Common Vulnerabilities and Exposures) — стандартизований ідентифікатор для відомої вразливості; «CVE-2021-44228 є вразливістю Log4Shell»
• ** fake positive ** — попередження про вразливість, яку неможливо використати у вашому контексті; « ми розглянули 30 результатів SAST, з яких 18 були хибно позитивними »

У обговореннях перегляду коду: «Це SAST виявлення є справжнім позитивним — SQL запит дійсно вразливий до втручання. Нам потрібно використовувати параметризовані запити»

Моделювання загроз

** Моделювання загроз ** — це структурований процес для визначення ризиків безпеки у проекті. Словник:

• ** модель загрози ** — документ або діаграма, що визначає активи, загрози і заходи зменшення ризику; « ми провели модель загрози для нового API »
• ** STRIDE ** — система категорізації загроз (спуфінг, маніпуляції, відмова, розголошення інформації, відмова у службі, підвищення привілеїв)
• ** поверхня атаки ** — набір точок, де атакуючий може спробувати ввести або витягнути дані; « додавання нової загальнодоступної кінцевої точки збільшує поверхню атаки »
• ** актор загрози ** — людина або система, яка може атакувати вас; « наші основні акторі загрози — це опортуністичні нападники і незадоволені колишні працівники »
• ** mitigate ** — зменшує ризик загрози; « ми зменшуємо цю загрозу за допомогою обмеження швидкості і блокування облікового запису »
• ** залишковий ризик ** — ризик, що залишається після застосування засобів контролю; « залишковий ризик приймається власником бізнесу »

Секрети і ланцюги постачання

Дві швидко розвиваються області словника DevSecOps:

Управління секретами:

• «Ми скануємо на тверді секрети» — перевіряємо, що API ключі, паролі і токени не знаходяться в коді
• ** розкидання секретів ** — секрети зберігаються у багатьох небезпечних місцях; « у нас розкидання секретів — унікальні дані знаходяться у змінних середовища CI, Slack і локальних файлах .env »
• «Ми змінюємо секрети за розкладом» — періодично замінюємо улікові дані, щоб обмежити доступ

Безпека ланцюга постачання:

• ** SBOM (Software Bill of Materials) ** — список всіх компонентів вашого програмного забезпечення; « ми створюємо SBOM для кожного випуску, щоб підтримувати вимоги до відповідності »
• ** атака з плутанню залежностей ** — атака ланцюга постачання, коли замість цього встановлюється шкідливий публічний пакунок з такою ж назвою, як і внутрішній пакунок; « ми використовуємо назви пакунків з обсягом, щоб зменшити плутанину залежностей »
• «Ми прикріплюємо версії залежностей» — використовуючи точні номери версій, щоб уникнути несподіваних оновлень

Ключовий словник

Term	Definition
shift left	Moving security activities earlier in the development process
SAST	Static Application Security Testing — scanning source code for vulnerabilities
DAST	Dynamic Application Security Testing — attacking a running application
SCA	Software Composition Analysis — scanning dependencies for known vulnerabilities
CVE	A standardised identifier for a publicly known vulnerability
threat model	A structured analysis of potential attacks on a system
attack surface	All the points where an attacker could enter or extract data
mitigate	Reduce the likelihood or impact of a security threat
SBOM	Software Bill of Materials — an inventory of all software components
secrets sprawl	Credentials stored in many insecure, unmanaged locations

Практичні поради

1. ** Запустіть інструмент SAST на вашій базі коду і сортуйте результати англійською мовою. ** Для кожного результату напишіть коротку записку: « Це справді позитивний результат — вхідні дані контролюються користувачем і їх слід очистити. Зменшення: використовувати параметризований запит.” або “Це хибний позитивний результат — дані надходять з внутрішньої системи і не контролюються користувачем.”

2. ** Практикуйте пояснення « пересунути ліворуч » розробнику, який не любить завдання з безпеки. ** Ключовий аргумент: « Знайти вразливість у запиті на збирання займає 10 хвилин. Знаходження його у виробництві після порушення займає місяці і коштує репутації компанії»

3. Знайомтеся з різницею між SAST і DAST. Це питання, яке часто задають під час інтерв’ ю для ролей DevSecOps. «SAST аналізує код без його запуску — це як редагування. DAST тестує запущену програму — це як тестування проникнення в автоматизований спосіб»

4. ** Використовуйте « mitigate » обережно. ** У сфері безпеки, « mitigate » означає зменшення ризику, а не його усунення. « Ми зменшуємо ризик крадіжки унікальних даних, щоквартально змінюючи секрети » є правильним. Уникаючи слова “захист”, коли ризик все ще існує, показує точність.

Conclusion

DevSecOps лексика — зсув ліворуч, SAST, DAST, SCA, модель загрози, поверхня атаки, SBOM — описує філософію безпеки, яка розглядає безпеку як інтегровану інженерну проблему, а не кінцеву контрольну точку. Знання і використання цих термінів допоможе вам брати участь у перегляді безпеки, робити внесок у сеанси моделювання загроз і підтримувати практику безпеки у вашій команді. Оскільки організації стикаються зі зростаючим регуляторним і клієнтським тиском навколо безпеки, цей словник стане тільки більш центральним для інженерних дискусій.

Національний парк «Східний берег» — ландшафтний заказник місцевого значення

DevSecOps - це не тільки інструменти; це фундаментально зміна в менталітеті - той, який приоритизує інтеграцію безпеки протягом всього життєвого циклу розробки програмного забезпечення. Зрозуміти специфічний англійський словник, пов’язаний з цим підходом, є критичним, особливо для розробників, які мають різне походження або працюють на міжнародному рівні. Розглянемо деякі ключові терміни і те, як вони зазвичай використовуються в професійних дискусіях, зосередившись на ясності і точності, а не тільки на буквальних перекладах. Основна концепція тут * shift-left *, що означає вирішення проблем безпеки на ранньому етапі - під час проектування і розробки - замість того, щоб чекати до кінця. Цей проактивний підхід значно зменшує ризики і витрати, пов’язані з відновленням пізніше. Крім того, розуміння * моделювання загроз * - систематично визначаючи потенційні загрози для системи - має вирішальне значення для прийняття рішень.

Однією з найпоширеніших проблем є точний переклад концепцій між мовами. Наприклад, просто сказати « безпека на ранньому етапі » не передає нюансований сенс « shift-left ». Це про вбудування практики безпеки на кожному етапі, від початкових вимог до збору, тестування і розгортання. Іншою ключовою областю є SAST (Статичное тестування безпеки застосунків) і DAST (Динамічне тестування безпеки застосунків). Хоча «статичний» може здатися чисто математичним, в цьому контексті він відноситься до аналізу початкового коду без запуску програми, в той час як «динамічний» включає активне тестування запущеної програми - критичне відмінність. Аналогічно, коли ми обговорюємо * управління секретами *, ми говоримо не тільки про збереження паролів; це про контроль доступу до конфіденційної інформації, наприклад, API-ключів і реєстраційних даних бази даних протягом усього їхнього життєвого циклу, реалізацію надійних засобів контролю і механізмів аудиту. Нарешті, з підвищенням акценту на * безпеку ланцюга постачання *, розробники повинні розуміти ризики, пов’язані з компонентами сторонніх виробників і як перевірити їх цілісність - складна область, що вимагає ретельної ретельності.

Метою є не просто використовувати модні слова; це про ефективне спілкування і співпрацю в команді DevSecOps. Фрази на кшталт «Давайте включимо вимоги безпеки в початковий етап проектування» або «Ми повинні виконати модель загрози перед тим, як продовжити розробку» є набагато яснішими, ніж нечіткі заявки. Пам’ятайте, чітке спілкування є найважливішим, коли виявляються вразливості на ранньому етапі і розвивається культура спільної відповідальності за безпеку. Це про будівництво спільного розуміння того, що безпека не є пізньою думкою; вона вплетена в тканину кожного рішення, яке ми приймаємо.

# Example: Using `npm audit` to identify vulnerabilities in Node.js dependencies
npm audit --production

Ця команда, використовуючи npm, є простим прикладом того, як розробники активно використовують інструменти для shift-left - ідентифікації проблем безпеки в залежностях проекту перед розгортанням. Вивід надає відомості про потенційні вразливості і пропонує кроки по усуненню, демонструючи практичне застосування захисту програмного забезпечення на початку його життєвого циклу. Ключовим моментом тут є те, що словник перекладається безпосередньо в дії процесів і практик.