UCCSAL
Центр адаптації та локалізації стандартів кібербезпеки
Глосарій та каталог, що оновлюється

MITRE CWE

MITRE CWE Glossary

CWE пояснює типи слабкостей програмного й апаратного забезпечення та допомагає знаходити спільні причини вразливостей. Глосарій дає поняття для читання каталогу й точного опису дефектів.

Огляд CWE

Common Weakness Enumeration (CWE) — відкритий каталог типів помилок у програмному та апаратному забезпеченні, які за певних умов можуть спричинити вразливості. Він дає командам спільні назви й ідентифікатори для пояснення причин дефектів та їх запобігання.

Обране джерело цієї сторінки — CWE Glossary: словник понять, потрібних для читання каталогу. Повні записи CWE містять додаткові приклади, наслідки та способи запобігання; словник не замінює ці записи.

Тип матеріалуГлосарій та каталог типів слабкостей
ОрганізаціяMITRE
Джерело сторінкиMITRE CWE Glossary
Випущена версія каталогуCWE 4.20 · 2026-04-30
ПризначенняНазвати причину помилки й запобігти її повторенню
Офіційний сайтMITRE CWE Glossary

Для кого призначено

Основні користувачі — розробники, архітектори, проєктувальники обладнання, тестувальники та фахівці з безпеки продуктів. Вони можуть пов’язати знайдену проблему з відомим типом слабкості й обговорити виправлення однією мовою.

Викладачам CWE допомагає пояснювати типові помилки, а замовникам — формулювати вимоги до перевірки продукту. Керівникам корисні узагальнення повторюваних причин; повсякденним користувачам достатньо розуміти зміст повідомлень про вразливості.

Для яких галузей

CWE застосовують у розробленні вебсервісів, корпоративного ПЗ, вбудованих систем і цифрового обладнання. Ті самі типи помилок можуть траплятися у фінансових сервісах, державних системах, медицині, транспорті та промисловості.

Для програмного продукту доречне подання Software Development, для обладнання — Hardware Design. Команда обирає слабкості за технологіями та функціями свого продукту; загальний список не визначає галузевих юридичних вимог.

CWE, CVE та CAPEC: різні завдання

CWE описує тип слабкості: що саме пішло не так у конструкції або реалізації. CVE ідентифікує конкретну оприлюднену вразливість продукту. CAPEC описує патерн атаки — повторюваний спосіб, яким зловмисник може використати слабкості.

Наприклад, CWE-89 описує помилку побудови SQL-команди з даними, що можуть змінити її зміст. Уразливі версії конкретного застосунку можуть бути описані в записі CVE, а спосіб атаки — у CAPEC. Ідентифікатор CWE сам по собі не означає, що ваш продукт уразливий.

Як організовано каталог

Weakness — запис про тип слабкості. Category об’єднує записи за спільною ознакою; View подає вибрану частину каталогу для певного завдання або аудиторії. Категорія й подання не є окремими помилками, які можна знайти в коді.

Зв’язки показують, який запис загальніший, який конкретніший і до якої групи він належить. Їх треба читати в контексті подання. Цей опис використовує термінологію випущеної версії CWE 4.20; анонсовані зміни майбутньої моделі наведено в історії.

Рівні деталізації слабкостей

Pillar — найзагальніша тема помилок; Class описує ширший тип без прив’язки до конкретної технології; Base додає достатньо деталей для вибору способів виявлення та запобігання; Variant уточнює слабкість для певної технології чи ресурсу.

Це рівні абстракції, а не шкала небезпеки. Детальніший запис не обов’язково небезпечніший; він точніше пояснює причину. Для зіставлення з реальною вразливістю обирають найбільш конкретний дозволений запис, який підтверджують наявні факти.

Як читати запис CWE

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

Для CWE-89 ключова ідея запобігання — відокремити дані від SQL-команди, зокрема через параметризовані запити. Сам напис «перевіряти введення» занадто нечіткий: у завданні на виправлення треба назвати конкретний механізм і спосіб перевірки.

Як зіставляти знахідки зі слабкостями

Спочатку з’ясуйте першопричину: відсутня перевірка доступу, неправильна робота з пам’яттю чи інша конкретна помилка. Не обирайте запис лише за наслідком на кшталт витоку даних. Прочитайте Vulnerability Mapping Notes і перевірте, чи дозволено використовувати цей ідентифікатор для зіставлення.

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

Практичне використання та межі

Команда може згрупувати підтверджені дефекти за CWE, виявити повторювані причини та додати відповідні перевірки до розроблення. Для конкретного продукту перелік доповнюють аналізом архітектури, тестами та оцінкою наслідків для користувачів.

CWE не надає сертифікації організації та не доводить відсутність уразливостей. Покриття інструментом певних CWE означає заявлені типи перевірок; його реальну здатність знаходити помилки потрібно перевіряти на відповідних прикладах.