Англійська для Snyk Vulnerability Scanning

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

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

** Серйозність вразливості ** — оцінка Snyk (зазвичай, низька, середня, висока, критична), яка відображає потенційний вплив вразливості, заснований на таких факторах, як оцінка CVSS, чи можна її віддалено використати, і чи є працюючий експлойт загальнодоступним. “Це оцінюються як Висока, а не Критична, тому що хоча вразливість є реальною, вона вимагає локального доступу для експлуатації — це змінює те, наскільки терміново нам потрібно її лагодити.”

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

** Зріст експлойту ** — показник того, наскільки відомі вразливості використовуються на практиці, у діапазоні від « немає відомих експлойтів » до « доведення концепції » до « зрілих », що впливає на те, наскільки терміново виправлення має бути пріоритетним, окрім сирого рейтингу тяжкості. “Один лише бал CVSS зробив це невідкладним, але зрілість експлойту вказана як “невідомий експлойт”, тому ми спочатку віддали пріоритет двом іншим виявленням з активним кодом доказу концепції.”

** Fix PR ** — запит на звантаження, який Snyk генерує автоматично, щоб оновити вразливу залежність до версії з латами, призначений для зменшення кількості роботи, яку слід виконати вручну для розв’ язання відомої проблеми. “Замість того, щоб вручну перевіряти версію і перевіряти на зміни, ми просто переглянули PR Snyk, запустили тестовий набір проти нього і об’єднали його, як тільки CI був зеленим.”

** Правило ігнорування ** — правило, яке пригнічує виявлення певної вразливості під час майбутніх сканувань, використовується, коли вразливість не застосовується у вашому контексті (недоступний шлях коду, зменшено у іншому місці), а не виправлено її справді. “Ми додали правила ігнорування для цього виявлення з датою закінчення дії та документованою причиною — вразлива функція ніколи не викликається в нашому шляху коду — замість того, щоб залишати її нерозв’язаною і пере- сортувати кожне сканування.”

Звичайні фрази

• Чи це пряма залежність, чи це приходить транзитивно через щось інше в нашому манифесті?»
• «Яка тут зрілість експлойту — чи є фактичне доведення концепції, чи це теоретично наразі?»
• Чи можемо ми просто об’єднати Snyk’s fix PR, або це оновлення включає в себе зміну, яку нам потрібно перевірити вручну?
• Чи варто нам це виправити, чи це підходить для політики ігнорування з документованим виправданням?»
• Чи є ця оцінка тяжкості керована лише балом CVSS, або ж зрілість експлуатації змінює, наскільки це насправді критичне?»

Приклади висловлювань

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

Пояснення рішення про пріоритетність: “Ми латуємо Критичне виявлення з відомою зрілістю експлойту сьогодні, і відкладаємо Середнє виявлення без відомого експлойту до наступного спринту — одна тільки тяжкість не визначає порядок тут.”

Документування придушення: “Ми додали правила ігнорування цього виявлення, тому що шлях вразливого коду захищений прапорцем функції, який назавжди виключений у виробництві — але він встановлений на строк дії через 90 днів, тому ми переглянемо його, якщо це зміниться.”

Професійні поради

• Відрізняти ** тяжкість ** від ** зрілості експлойту ** явно під час визначення пріоритету виправлень — висока тяжкість без відомого експлойту є іншим видом ризику, ніж нижча тяжкість з активним доказом концепції.
• Назва transitive dependency точно, коли вразливість не може бути виправлена за допомогою простого прямого оновлення — це пояснює, чому виправлення вимагає очікування або перевищення пакунка, що походить від попередника.
• Переглянути fix PR для розбиття змін, а не об’ єднання їх на сліпо — Snyk автоматизує порівняння, а не судження про те, чи безпечно приймати нову версію.
• Документуйте кожну ** політику ігнорування ** з причиною і терміном дії — недокументоване, постійне ігнорування — це те, як справді використовувані вразливості забуваються.

Практичні вправи

1. Поясніть різницю між тяжкістю і зрілістю експлойту.
2. Описати, чому уразливість транзитивної залежності іноді не можна виправити за допомогою прямого перенесення версії.
3. Напишіть речення, у якому пояснюється, коли застосування правила ігнорування є належною відповіддю на виявлення.

Навігація по сторінках: професійна комунікація навколо уразливостей

Будьмо чесними - технічний жаргон вже достатньо складний. Коли ви обговорюєте вразливості з колегами, особливо з тими, хто розмовляє англійською як другою мовою, тонкі нюанси професійного вимови можуть створити значні трення. Це не просто розуміння самих слів; це передавання намірів, визнання ризику і запропонування рішень таким чином, що сприяє співпраці, а не обороні. Просте “Це погано” не впорається з переглядом коду або поясненням критичних виявлень безпеки. Замість цього, розробникам потрібно чітко сформулювати вплив вразливості, продемонструвати розуміння більш широкого контексту і чітко сформулювати свої рекомендації.

Розглянемо цей сценарій: Сара, молодший розробник, надсилає запит на оновлення залежностей проекту. Під час перегляду коду Марк, старший інженер, залишає коментар до одного з оновлених файлів, в якому говорить: « Ця версія має вразливість високої важкості — вам потрібно її виправити ». Хоча технічно це правильний коментар, він може здатися обвинувальним і негайно поставити Сару в оборону. Він не пояснює * чому * це критично, як це може вплинути на програму, або які кроки потрібні для усунення. Більш конструктивний підхід буде виглядати приблизно так: «Я помітив високу вразливість у залежності lodash. Це може потенційно піддати наших користувачів XSS- атакам, якщо не вжити негайних заходів. Чи можемо ми дослідити вплив і дослідити стратегії зменшення ризику – можливо, перейти на латовану версію?” Зауважте зміну; тепер вона зосереджена на ризику, впливі і розв’ язанні.

Іншою поширеною ситуацією є пояснення вразливостей у самому описі запиту на завантаження. Замість простого повідомлення « Виправити вразливість », вам потрібно надати контекст. « Цей PR розв’ язує критичну вразливість (CVE- 2023- 1234), виявлену в бібліотеці axios. Ця вразливість дозволяє віддалене виконання коду, що може призвести до значних порушень безпеки. Виправлення включає в себе оновлення axios до версії 1.6.0, яка включає необхідний патч. Я також оновив файл керування залежностями, щоб відобразити цю зміну, і додав коментар до відповідних файлів, що документують оновлення. » Знову ж таки, деталі є ключовими — тяжкість, CVE ID (для відстеження), потенційний вплив, конкретні виправлення і документація — це всі важливі елементи чіткого спілкування.

Нарешті, пам’ятайте, що «ігнорування» вразливості не є варіантом. Навіть з ігноруванням правил на місці, розробники повинні обґрунтувати, чому певна вразливість повинна бути трактована по-іншому. Це часто вимагає детального аналізу і документації. Повідомлення Slack, що вимагає затримки, може виглядати так: «Команда, ми в даний час оцінюємо вплив уразливості vulnerability-id в react-dom. Хоча це позначено як дуже серйозну проблему, наша поточна архітектура мінімізує безпосереднє взаємодія користувача з цим компонентом. Ми проводимо глибший аудит безпеки, щоб підтвердити це припущення і надамо оновлення протягом 24 годин»

# Example Snyk command to list vulnerabilities:
snyk monitor --severity critical

Цей результат буде використаний як основа для подальшого обговорення і дій, завжди з акцентом на ясність і спільне вирішення проблем.