Анализ на уязвимостите и SBOM
CRA превръща Вашата софтуерна спецификация на материалите в живо задължение: знайте какво има в продукта Ви, следете тези компоненти за нови уязвимости и ги отстранявайте и докладвайте в сроковете по член 14. Тази страница преминава през цикъла и безплатния инструмент, който го изпълнява.
Генерирайте SBOM
Изгответе машинночетима софтуерна спецификация на материалите, обхващаща поне Вашите зависимости от най-високо ниво. Това е твърдо изискване, а не най-добра практика.
Как да го генерирате ↓Наблюдавайте за уязвимости
Непрекъснато сверявайте кръстосано всеки компонент спрямо актуални данни за уязвимости (NVD, EUVD). Групираните обобщения на уведомления не отговарят на 24-часовия срок.
Защо обобщенията са недостатъчни ↓Оценете, отстранете и докладвайте
Документирайте възможността за експлоатиране, осигурете поправка и докладвайте активно експлоатираните уязвимости на ENISA и CSIRT в срок от 24 ч. / 72 ч. / 14 дни.
Инструментът, който прави това ↓CRA Vulnerability Analyzer
Качете Вашия SBOM и списък с активни уязвимости. Analyzer сверява кръстосано всеки компонент спрямо Националната база данни за уязвимости (NVD) и базата данни на ЕС за уязвимости (EUVD), маркира компонентите с изтекъл жизнен цикъл и генерира доклад за съответствие, който можете да приложите към техническото си досие.
Практически ръководства
Генерирайте съответстващ SBOM
Софтуерната спецификация на материалите (SBOM) е твърдо правно изискване съгласно приложение I, част II, точка 1. Това ръководство обхваща задължителния обхват и формат, как да я генерирате и как тя захранва цикъла на наблюдение.
1 · Правно основание
Приложение I, част II („Изисквания за обработване на уязвимостите“), точка 1 изисква производителите да „идентифициране и документиране на уязвимостите и компонентите … включително чрез изготвяне на софтуерна спецификация на материалите (SBOM) в широко използван и машинночетим формат, обхващаща поне зависимостите от най-високо ниво на продукта.“
За разлика от някои разпоредби на CRA, които позволяват гъвкавост при тълкуването, задължението за изготвяне на машинночетим SBOM, обхващащ поне зависимостите от най-високо ниво, не допуска алтернативни подходи.
2 · Задължителен обхват и формат
Покритие на компонентите. SBOM трябва да документира всички зависимости от най-високо ниво, което е законовият минимум, а не препоръчителната цел. Картографирайте преходните (непреките) зависимости, където е осъществимо; повърхностният SBOM удовлетворява буквата на закона, но често е недостатъчен за ефективно управление на уязвимостите.
Формат. CRA изисква „широко използван, машинночетим формат“. Приетите формати включват:
- SPDX (ISO/IEC 5962:2021): широко възприет, насочен към лицензиране, подходящ за документация за съответствие.
- CycloneDX: ориентиран към сигурността, добре подходящ за работни процеси по управление на уязвимостите.
- Други структурирани формати (JSON, XML) от признат инструментариум по принцип са приемливи съгласно базовото изискване.
Не съхранявайте SBOM като PDF. PDF може да бъде оспорен като немашинночетим от органите за надзор на пазара. Съхранявайте оригиналния изход във формат JSON, XML или tag-value от Вашия инструментариум.
Задължителни полета с метаданни
| Поле | Описание |
|---|---|
| Наименование на компонента | Уникален идентификатор за библиотеката, пакета или модула |
| Версия | Точен низ на версията; диапазоните от версии са недостатъчни |
| Доставчик / произход | Издател, доставчик или наименование на проект с отворен код |
| Връзки между зависимостите | Преки спрямо преходни; граф на зависимостите, когато е осъществимо |
| Криптографски хеш | Проверка на интегритета SHA-256 или по-силна за всеки компонент |
| Идентификатор на лиценза | SPDX лицензионен израз (напр. Apache-2.0, MIT) |
3 · Генериране на Вашия SBOM
Повечето съвременни платформи могат да генерират SBOM автоматично по време на компилиране, без допълнителни разходи:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Извежда SPDX JSON.
- GitLab: Докладите в CycloneDX се генерират по естествен начин от заданието за CI/CD за сканиране на зависимостите.
- Syft (Anchore): CLI инструмент с отворен код, който генерира SPDX и CycloneDX за контейнерни образи, файлови системи и пакетни манифести.
- cdxgen: SBOM в CycloneDX за npm, Maven, pip, Go, Rust и други.
Проверка за уязвимости. Преди да финализирате който и да е SBOM, проверете всеки компонент спрямо бази данни с известни уязвимости. Както скенерът на GitHub, така и Syft се интегрират с Grype за това. Включването на компонент с известна, вече поправена уязвимост е пряко нарушение на приложение I и не носи гъвкавост при тълкуването.
Ако съществува поправена версия на компонент, трябва да я използвате. Съгласно CRA няма категория „приет риск“ за разрешени уязвимости. Действайте по всяка находка, преди да пуснете продукта на пазара.
4 · Поддръжка и съхранение през жизнения цикъл
SBOM е жив артефакт, който се актуализира непрекъснато през поддържания жизнен цикъл на продукта, за да отразява поправени компоненти, нови зависимости, премахнати компоненти с изтекъл жизнен цикъл и промени във веригата на доставки. Всички версии на техническата документация, включително SBOM, трябва да се съхраняват поне 10 години от първото пускане на пазара…
Раздели 4—9: жизнен цикъл, санкции, BSI TR-03183-2 и контролния списък за готовност
Останалата част от ръководството обхваща 10-годишното задължение за съхранение, поверителността и оповестяването по веригата на доставки, интеграцията с докладването на уязвимости по член 14, честотата на наблюдение, по-строгите правила на германския BSI, глобите (до 15 млн. евро или 2,5% от оборота) и готов за използване контролен списък за готовност.
Свързани инструменти и анализи
Матрица на съответствието
Всяко задължение през жизнения цикъл с препратката към съответния член; проследявайте напредъка си и изтеглете пълния контролен списък.
Актуално състояние на нещата
Къде се намира CRA днес: актове за изпълнение, хармонизирани стандарти и пътят към декември 2027 г.
Калкулатор на разходите
Ориентировъчна оценка на това колко вероятно ще струва постигането и поддържането на съответствие.