DevSecOps Pipeline Vocabulary: SAST, DAST, and Shift-Left Security Language (англійською)
Вивчіть основний англійський словник для конвеєрів DevSecOps — SAST, DAST, SCA, безпека з переходом ліворуч, SBOM, безпека ланцюга постачання і термінологія воріт безпеки.
В енциклопедії «Вільне слово»: Зростання цінності слова
DevSecOps — інтеграція практики безпеки в DevOps конвеєр — створив багатий набір словників, які інженери безпеки, розробники і команди операцій повинні розуміти. Сканування безпеки, управління вразливістю і безпека ланцюга постачання більше не є єдиною сферою діяльності команди безпеки; вони вбудовані в кожен запит на витяг і конвеєр розгортання. Цей підручник містить основні терміни.
Статичний і динамічний аналіз
SAST (Статичний тест безпеки застосунків)
** SAST ** аналізує початковий код або зкомпільовані двійкові файли без виконання програми. Він вивчає структуру коду, потоки даних і відомі шаблони вразливості, щоб визначити потенційні проблеми безпеки.
«SAST запускає на кожному запиті pull і флагів потенційних SQL введення шаблони в новий конструктор запитів, перш ніж код досягає перегляду.»
Інструменти SAST ** специфічні для мови ** — інструмент для Java не буде аналізувати Python. Поширені інструменти SAST включають Semgrep, SonarQube, CodeQL, і Checkmarx.
** Істинно позитивний ** — результат SAST, що відповідає реальній вразливості. ** Фальшиво позитивний ** — виявлення SAST, яке позначає безпечний код як уразливий. « Ми налаштували набір правил Semgrep, щоб зменшити кількість випадків фальшиво позитивних результатів у наших тестових файлах, де імітовані шаблони атаки неправильно запускали правила безпеки. »
DAST (Dynamic Application Security Testing) — тестування динамічної безпеки застосунків
** DAST ** перевіряє запущену програму, надсилаючи вхідні дані і спостерігаючи за її відповідями, шукаючи уразливості, які виявляються під час виконання, наприклад, помилки введення, обхід розпізнавання або небезпечні заголовки.
«Ми запускаємо OWASP ZAP DAST сканування проти стадіонного середовища на кожному кандидатові на випуск перед продвиженням до виробництва»
DAST не вимагає доступу до початкового коду, що робить його корисним для тестування сторонніх компонентів або систем чорного ящика.
IAST (Інтерактивне тестування безпеки застосунків)
** IAST ** використовує агенти або інструменти всередині запущеної програми для спостереження за її поведінкою під час виконання тестів. Він поєднує аспекти SAST (код обізнаності) і DAST (спостереження за часом виконання).
Безпека та захист інформаційних систем
Система аналізу програмного забезпечення (англ. Software Analysis System)
SCA аналізує залежності проекту від сторонніх розробників, щоб визначити відомі вразливості, проблеми з ліцензіями та застарілими пакунками. Це основний інструмент для управління ризиками відкритого коду.
«SCA виявила, що бібліотека журналювання, яку ми успадкували від старої кодової бази, мала відому критичну вразливість — її було залатано три місяці тому, але ми не оновили залежність»
** CVE (Common Vulnerabilities and Exposures) ** — стандартизований ідентифікатор для загальнодоступних вразливостей безпеки. « Сканування SCA виявило CVE- 2024- XXXXX у клієнтській бібліотеці HTTP — нам потрібно оновити до версії 4. 2. 1 або вище. »
** Оцінка CVSS** — числова оцінка (0- 10), що вказує на ступінь тяжкості вразливості. « Знаходження має оцінку CVSS 9. 8, що відповідає категорії Критична — перед наступним розгортанням слід виконати заходи по усуненню порушень »
Система програмного забезпечення (Software)
SBOM є всеохопним, машинно-читливим переліком всіх програмних компонентів в системі — прямих залежностей, транзитивних залежностей, їх версій і ліцензій.
«Ми генеруємо SBOM як частину конвеєра випуску і зберігаємо його разом з артефактом збирання. У разі інциденту в ланцюжку постачання, ми можемо негайно запитати, які з наших продуктів були вражені»
Безпека ланцюга постачання
** Безпека ланцюга постачання програмного забезпечення ** включає практику та інструменти, що використовуються для перевірки цілісності та надійності коду, інструментів та інфраструктури, що використовуються для створення програмного забезпечення.
** SLSA (Supply- chain Levels for Software Artefacts) ** — система рівнів безпеки для цілісності ланцюга постачання програмного забезпечення, з чотирма прогресивними рівнями. « Наша поточна конфігурація CI досягає рівня SLSA 2, що означає, що збірки є скриптовими, а артефакти містять метадані походження »
** Провідність ** — метадані, які можна перевірити, що описують, як було збудовано артефакт програмного забезпечення — який початковий код, інструменти і середовище було використано. « Підписані сертифікати провідності дозволяють споживачам перевірити, що наші артефакти релізів були збудовані у надійному середовищі CI. »
Shift-Left Безпека
** Shift- left security ** це принцип перенесення тестування безпеки і перегляду раніше в життєвому циклі розробки — до робочої станції розробника і стадії запитів на витягування, а не очікування на спеціальний перегляд безпеки перед випуском.
«Змінюючи безпеку з автоматизованим SAST і SCA в IDE і CI конвеєрі, ми ловимо більшість проблем під час розробки, а не в огляді безпеки — де виправлення є набагато дорожчими»
** Чемпіон з безпеки ** — розробник у складі інженерної команди, який має додаткові знання з безпеки і підтримує безпечні методи розробки у своїй команді.
** Моделювання загроз ** — структурований процес для визначення потенційних загроз, векторів атаки і заходів зменшення ризику для системи під час фази проектування. Зміна моделювання загроз ліворуч означає, що це робити під час проектування архітектури, а не після реалізації.
Мова воріт безпеки
** Шлюз безпеки ** — це точка в конвеєрі CI/ CD, де збирання зупиняється або блокується, якщо не задовольняються критерії безпеки.
«Врата безпеки в нашому трубопровіді блокує проходження до стадії, якщо будь-які критичні або високі результати CVSS присутні в результатах SCA або SAST»
** Policy as code ** — вираз правил безпеки і відповідності у вигляді машинно- зчитуваного коду, який можна автоматично контролювати і застосовувати. « Ми використовуємо правила OPA (Open Policy Agent) у вигляді коду для послідовного застосування критеріїв ворота безпеки у всіх конвеєрах. »
** Відмова / виняток ** — документоване, схвалене рішення продовжити роботу, незважаючи на виявлення помилки безпеки, зазвичай, на визначений період часу. « Команда надіслала заяву про відмову від виконання завдань, пов’ язаних з виявленням помилки середньої важкості у застарілому модулі, оскільки ця помилка не піддається впливу вводу даних користувача — ця заява про відмову закінчується через 90 днів і вимагає компенсаційного контролю. »
П’ять прикладів речення
- «Сканування SAST на запиті pull позначило потенційну вразливість у перетині шляху в обробнику завантаження файлів — ми додали перевірку вводу перед об’єднанням коду»
- «Наш SCA конвеєр виявив транзитивну залежність з критичним CVE результатом 9.1; ми негайно ескалаційну команду і залагодили залежність протягом чотирьох годин»
- «Зміна безпеки вліво означає, що наш квартальний тест проникнення тепер знаходить значно менше проблем, тому що легкі перемоги автоматично ловляться в CI-конвейері»
- «Ми генеруємо і підписуємо SBOM для кожного випуску артефакту, що дозволяє нам реагувати на інциденти в ланцюзі постачання, такі як Log4Shell, протягом декількох годин, а не днів»
- «Політика ворота безпеки блокує виробниче розгортання будь-якого зображення, що містить Критичну вразливість, якщо схвалене звільнення не зареєстровано в реєстрі винятків»
Слово про комунікацію
Вивчення безпеки може створити напруження між інженерами безпеки і командами розробників. Під час написання або обговорення результатів англійською, будьте точними і об’єктивними. Не використовуйте паніки. Визначте виявлення, докази, ризик і засоби усунення. « Ця кінцева точка приймає несанкціонований вхід користувача, який передається безпосередньо до запиту SQL, що уможливлює атаки за допомогою введення SQL у базу даних » є більш корисним і менш загрозливим, ніж « цей код є небезпечно небезпечним. »
На практиці: Навігація розмов навколо інструментів безпеки
Будьмо чесними - коли ви вперше вивчаєте нову технічну область, наприклад DevSecOps, обсяг спеціалізованого словника може здатися приголомшливим. Це не просто про те, щоб знати * що * щось є; це розуміння того, як ефективно обговорювати це з вашою командою. Часто, не рідні носії англійської мови стикаються з труднощами перекладу своїх технічних знань на точні і природні фрази англійською мовою. Це не просто питання знайти правильне слово - це про передачу намірів, невідкладності і контексту в рамках спільного потоку роботи.
Розглянемо цей сценарій: Alex, розробник з Польщі, переглядає запит на збір нової можливості у веб- програмі. Опис PR включає коментар від Сари, інженера з безпеки. У коментарі написано: « Спроба сканування SAST зазнала невдачі — можлива вразливість для введення SQL у функції user_login ». Алекс може спочатку перекласти це безпосередньо польською, а потім спробувати перекласти це назад англійською, що призведе до написання щось на зразок: « Інструмент SAST повідомив про можливу проблему з введенням SQL у функцію, відповідальну за входження користувача ». Хоча це технічно коректно, це надто формально і не має терміну дії і тону співпраці, яких очікується у середовищі DevSecOps. Природнішою формулюванням було б: «Схоже, що сканування SAST виявило потенційний ризик втручання SQL в user_login. Давайте переглянемо, як це обробляється.” Ключова відмінність полягає в тому, що використовується активний голос, безпосередньо приписуючи відповідальність (“Давайте переглянемо”), і визнаючи роль інструменту (“сканування SAST”).
Інша поширена ситуація виникає під час планування спринту. Марк з Німеччини пропонує інтегрувати сканування DAST у їх автоматизований конвеєр. Він повинен чітко сформулювати цінність цього процесу для більшої команди. Хороший початковий пункт може бути: «Ми повинні реалізувати Динамічне тестування безпеки застосунків (DAST) як частину нашого CI / CD конвеєра. Це допоможе нам проактивно визначати вразливості * перед * розгортанням, зменшуючи ризик інцидентів з безпекою. ” Зауважте, як формулювання « проактивно визначати » змінює фокус з реактивної проблеми — знаходження вразливостей * після * розгортання — на профілактичну заходу. Аналогічно, при обговоренні SBOM (Software Bill of Materials), підкреслювати, що вони надають «повний список всіх програмних компонентів» є яснішим, ніж просто зазначати їхню мету. Зрозуміти ці тонкі відмінності у фразування значно покращує комунікацію і співпрацю.
Нарешті, пам’ятайте, що термінологія не статична; вона постійно розвивається. З’являються нові інструменти і методи, і мова, використана для їх опису, відповідно пристосовується. Для вільної мови важливо бути в курсі останніх досягнень та активно слухати, як спілкуються ваші колеги.
Ось простий приклад запуску npm audit для перевірки залежностей вашого проекту на вразливості:
npm auditЦя команда використовує менеджер пакунків npm для виконання вбудованого інструмента аудиту безпеки, який аналізує дерево залежностей вашого проекту і повідомляє про всі відомі вразливості разом з рекомендаціями щодо їх усунення. Це швидкий спосіб отримати початкову оцінку потенційних ризиків у вашій кодовій базі.