Словник для SBOM і безпеки ланцюга постачання програмного забезпечення
Вивчіть основний англійський словник для обговорення програмних списків матеріалів, походження і залежностей уразливостей у роботі з безпекою ланцюга постачання.
Безпека ланцюга постачання програмного забезпечення стала головною проблемою інженерії, і вона має словник, який охоплює відповідність, безпеку і інженерію систем збирання. Такі терміни, як «SBOM» і «провідність» тепер регулярно з’ являються в анкетах постачальників, оглядах безпеки і регуляторних розмовах, і їх точне використання допомагає вам чітко повідомляти про ризики як командам безпеки, так і менш технічним зацікавленим сторонам, таким як закупівлі або юридичні.
Ключовий словник
** SBOM (Програмний матеріальний опис) ** Структурований, машинно- зчитуваний перелік кожного компонента — прямих і транзитивних залежностей, бібліотек і їх версій — що складають програму. Приклад: “Ми генеруємо SBOM як частину кожної версії, тому ми можемо швидко перевірити, які версії містять щойно розкриту вразливу бібліотеку.”
Происхождение Перевіряються метадані, що описують, як був побудований артефакт програмного забезпечення, включаючи джерело, затвердження, систему збирання і виконані кроки, використовуються для встановлення довіри до походження та цілісності артефакту. Приклад: «Без підтвердження походження, ми не можемо криптографічно перевірити, що цей бінарний файл був дійсно збудований з початкового коду, який ми переглянули, а не з потім змінений.»
** Перехідна залежність ** Залежність, яку ваш проект не оголосив безпосередньо, але яку було прив’ язано опосередковано, оскільки від неї залежить одна з ваших безпосередніх залежностей.
- Приклад: « Вразлива бібліотека не є чимось, що ми імпортували безпосередньо — це транзитивна залежність трьох рівнів, затягнута бібліотекою журналювання, яку ми використовуємо безпосередньо. » *
** Розкриття вразливості (CVE) ** Публічно задокументована вразливість безпеки, зазвичай, з присвоєним стандартизованим ідентифікатором (CVE- номером), що описує програмне забезпечення, яке зазнало шкоди, і природу помилки. Приклад: “Ця CVE впливає на версії до 4.2.1 бібліотеки, і наша SBOM показує, що ми зараз на 4.1.0, тому нам потрібно латка.”
Зависимость путаница Метод атаки, за якого шкідливий пакунок опубліковано під тією ж назвою, що і внутрішній, приватний пакунок, обманюючи систему збирання, щоб вона завантажила шкідливу публічну версію замість цього. Приклад: «Ми зменшили ризик плутанини залежностей, зареєструвавши наші внутрішні назви пакунків у публічному реєстрі, навіть якщо ми ніколи не плануємо публікувати під ними справжній код.»
** Типографська гра ** Опублікування шкідливого пакунка під назвою, яка навмисно схожа на популярний законний пакунок, з надією, що розробники зроблять помилку при введенні назви і встановлять замість неї шкідливий пакунок. Приклад: «Заражений пакунок був типографським помилковим копіюванням широко використовуваної бібліотеки, що відрізняється лише однією транспонованою літерою в назві.»
** Підписання / підписання артефакту ** Криптографічний підпис артефакту програмного забезпечення (пакунку, контейнерного зображення або бінарного файлу), щоб споживачі могли перевірити, що з ним не було зловживання і що він справді походить з заявленого джерела.
- Приклад: « Тепер ми вимагаємо, щоб кожен опублікований штамп контейнера був підписаний, а наш конвеєр розгортання відмовляється розгортати щось з невірним або відсутнім підписом. » *
Сертифікат Підписане твердження, часто машинно перевіряємое, що певне твердження про програмний артефакт є істинним — наприклад, що воно було побудовано певним CI- конвеєром з певного джерела.
- Приклад: « Підтвердження підтверджує, що цей артефакт було створено за допомогою нашого офіційного конвеєра CI, а не завантажено вручну кимось, хто має доступ до запису в реєстрі. » *
Звичайні фрази
** В обзорах коду: **
- «Ця конвеєрна побудова не генерує SBOM як частину випуску — ми повинні додати, що це перед тим, як це піде до будь-якого клієнта, який вимагає відповідності ланцюга постачання»
- «Ми витягуємо цю залежність з реєстру загального призначення без прикріплення точної версії або перевірки контрольної суми — це залишає нас уразливими до компрометованого оновлення»
- «Цей новий пакунок майже не має історії завантаження і був опублікований минулого тижня — давайте затримаємося, поки ми не переглянемо його уважно, перш ніж додати його як залежність»
В стоячих позах:
- «Вчора я налаштував автоматичне створення SBOM в конвеєрі випуску; сьогодні я підключаю сканер, щоб позначати будь-які нові розкриті CVE проти нашого поточного дерева залежностей»
- «Я заблокований через транзитивну залежність — пряма залежність, яку ми використовуємо, ще не випустила латовану версію, тому ми не можемо просто заблокувати номер версії»
- «Я закінчив додавання підписування артефактів до нашої контейнерної збірки; конвеєр розгортання тепер перевіряє підпис перед тим, як дозволити розгортання»
** У перегляді безпеки виробника або розмовах про відповідність: **
- «Ми можемо надати SBOM для цього випуску на запит, разом з атестаціями походження, що показують, що він був побудований через наш офіційний CI-конвейер»
- «Ця транзитивна залежність має відкритий CVE, але наше використання не викликає вразливий шлях коду — ось наша документована оцінка ризику»
- «Ми вимагаємо підписаних артефактів по всьому нашому конвеєру розгортання, тому атакуючий з доступом до реєстру не міг отримати непідписаний образ розгортання»
Фрази, яких слід уникати
**Сказати « ми перевірили наші залежності » без пояснення як. ** Замість цього скажіть: « ми перевіряємо наш SBOM на відповідність базі даних CVE під час кожної збірки » або « ми вручну перевірили залежності верхнього рівня, але ще не автоматизували перевірку транзитивних залежностей ». Неясні запевнення не підходять для перевірки безпеки.
Сказав, що це просто невелика бібліотека, щоб відкинути ризики ланцюга постачання. Розмір не корелює з ризиком - деякі з найбільш впливових компромісів ланцюга постачання включали невеликі, широко використовувані пакети послуг. Оцінювати за допомогою сигналів використання та обслуговування, а не сприйняття важливості.
Скажите “уязвимость не влияет на нас” без оправдания. Для цього потрібно вказати документовану причину — наприклад, « ми не викликаємо вразливу функцію » або « шлях до вразливого коду недоступний у нашому налаштуванні ». Необґрунтоване відхилення є червоним прапорцем у будь- якій перевірці безпеки.
Краткий справочник
| Term | How to use it |
|---|---|
| SBOM | ”We generate an SBOM for every release to track our full dependency tree.” |
| provenance | ”Provenance attestation confirms the artifact came from our official build.” |
| transitive dependency | ”The vulnerable library is a transitive dependency, three levels deep.” |
| dependency confusion | ”We reserved our internal package names to prevent dependency confusion.” |
| typosquatting | ”The compromised package was a typosquat of a popular library.” |
| artifact signing | ”Our pipeline rejects any artifact without a valid signature.” |
Ключеві моменти
- SBOM є основою для розмов про безпеку ланцюга постачання - знаєте, як описати, що він захоплює і як часто він відновлюється.
- Розрізняйте прямі і перехідні залежності під час обговорення часу виявлення вразливості і часу виправлення.
- Провідність і підписання артефактів встановлюють довіру до того, звідки прийшов артефакт — описують їх як перевіряються, а не просто як заяву про політику.
- Ніколи не відкидайте вразливість як «не впливає на нас» без конкретного, документованого технічного обґрунтування.
- Плутанина залежностей і типоскваттинг називаються, добре зрозумілі шаблони атаки - використовуйте точний термін, а не нечіткий опис «зловмисного пакунку»
Науковий ступінь: кандидат філософських наук (спеціальність: «Практичне застосування та фрази»)
Добре, давайте перейдемо від простого розуміння чого означають ці терміни. Справжній виклик полягає в ефективному їх обміні - особливо при співпраці з міжнародними командами або документуванні складних питань. Часто, тонка різниця між «впливом» і «вплином», наприклад, може драматично змінити розуміння потенційних наслідків вразливості. Аналогічно, такі фрази як «залежність від попереднього рівня» проти просто «залежності» мають різні конотації щодо зусиль по усуненню. Ключова концепція, яку потрібно зрозуміти, полягає в тому, що точна мова мінімізує неоднозначність в обговореннях безпеки ланцюга постачання.
Розглянемо сценарій: під час перегляду коду для критичного компонента, розробник повідомляє про потенційну проблему зі старішою бібліотекою. Замість того, щоб сказати «ця бібліотека може бути вразливою», більш ефективним підходом - відображаючи словник, який ми обговорювали - було б: «Ця висхідна залежність має відому вразливість (CVE-2023-1234) і вимагає негайної уваги. Його присутність значно впливає на нашу загальну безпеку, можливо, піддаючи нас [згадайте конкретний ризик - наприклад, ескалацію привілеїв]. Нам потрібно оцінити ступінь його використання в коді і визначити пріоритетність усунення». Зауважте навмисне використання «вгору», «вплинути», і явне згадування CVE - це ключові фрази, які демонструють чітке розуміння проблеми і її тяжкості. Уникайте неясних термінів, таких як «це погано» або «ми повинні виправити це»
Іншою поширеною ситуацією є опис походження компонентів програмного забезпечення: «провідність» не просто про те, щоб знати * де * щось прийшло; це про встановлення перевіряного ланцюга опіки, документуючи кожен крок в його життєвому циклі. Такі фрази, як «відстежуваність» і «ланцюг контролю» часто використовуються для опису цього процесу. При повідомленні про вразливості, чітке вказання «SBOM запису», пов’язаного з враженим компонентом, є критичним - забезпечення контексту для усунення. Ви часто почуєте дискусії про «аналіз кореневої причини» - визначення того, де вразливість почалася в ланцюжку постачання.
Нарешті, пам’ятайте, що ефективне спілкування вимагає адаптації вашої мови до аудиторії. Для технічних користувачів ви можете скористатися більш докладною термінологією. Але при поясненні концепцій нетехнічним аудиторіям (наприклад, керівникам), спрощення мови при передачі критичного повідомлення є найважливішим.
Ось приклад того, як cargo audit можна використовувати для виявлення вразливостей у проекті Rust:
cargo audit --depth=2За допомогою цієї команди буде виконано сканування залежностей вашого проекту на предмет відомих вразливостей, буде надано докладні відомості щодо кожної з вразливостей і її можливого впливу. Результат підкреслює критичну природу результатів, безпосередньо відповідаючи нашим обговоренням щодо тяжкості і усунення.