Англійська для розробників Semgrep

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

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

** Правило ** — окрема перевірка Semgrep, визначена шаблоном і метаданими (серйозність, повідомлення, мова), базовим об’ єктом, який або збігається з кодом, або не збігається. “Це правило занадто широке — воно відповідає кожному виклику exec, навіть тим, що мають твердо закодований, безпечний аргумент. Давайте звузимо шаблон.»

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

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

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

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

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

• Чи є це справжнім хибним позитивним, чи це справжній результат, який ми вирішили придушити?»
• Чи можемо ми звузити цей шаблон з метазмінною замість написання трьох майже дублікатних правил?
• Чи варто нам настроїти правило, щоб зменшити шум, або пригнічувати окремі результати один за одним?»
• «Скільки знахідок генерує це правило, і чи вони в основному мають той самий підґрунтовий шаблон?»
• Чи це придушення десь відстежується, чи це просто мовчки коментар, який ніхто не перегляне?»

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

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

Пояснення рішення про проектування: “Ми написали нетипове правило з метазмінною для внутрішнього методу запиту ORM, оскільки загальне правило введення SQL не відповідало нашій специфічній функції обгортки.”

Опис події:

• “Шаблон вразливості було відправлено, тому що відповідне правило було перенастроєно для виключення цілого каталогу, який також включав файл, де була введена справжня проблема.” *

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

• При обговоренні виводу Semgrep скажіть “finding” замість “error” або “bug” — виявлення потребує сортування, і передчасне називання його вадами пропускає цей крок.
• Розрізняти “фальшивий позитивний” від “придушення” явно в кожній розмові триажу - об’єднання їх або приховує реальні проблеми або заливає команду непотрібним шумом.
• Використовуйте ** « metavariable » ** коректно під час обговорення шаблонів правил — це означає, що ви розумієте, як узагальнити правило, замість написання майже дублікатів для кожного варіанту.
• Запропонуйте “налаштування правила” як альтернативу масовому придушення результатів — це виправляє шум у джерелі, а не розсіює винятки по всій кодовій базі.

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

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

Наприклад, мова йде про мовлення: мовлення немовляти

Ядро ефективного спілкування в команді розробників, особливо при роботі з такими інструментами, як Semgrep, сильно залежить від точної англійської мови. Це не просто передавання * того, що * ви спостерігаєте - це про вираження * чому * і пропозиції * як * виправити це. Для розробників, чия перша мова не є англійською, це може здатися неймовірно пригнічуючим. Незначні відмінності у формулюванні, неявні припущення, випікаються в спільних запитах, і навіть очікуваний рівень деталей можуть створити значні бар’єри. Не відчайдуйся; освоєння професійної англійської мови — це подорож, і зосередження уваги на практичному застосуванні у вашому робочому процесі дасть набагато кращі результати, ніж просто запам’ ятовування списків слів. Одним з ключових елементів, який часто ігнорується, є розуміння * тону * спілкування - пропозиція, оформлена як запит, дуже відрізняється від тієї, що представлена як імператив.

Розглянемо звичайний сценарій: ви виявили потенційну вразливість, яку Semgrep позначила у запиті на витяг. Спочатку ви можете написати коментар на зразок « Це правило відповідає цьому коду ». Хоча це технічно правильно, у цьому коментарі бракує контексту, і його можна легко неправильно інтерпретувати. Ефективнішим підходом було б: «Я виявив можливу проблему, пов’язану з [спеціфічна назва функції], яка збігається з правилом no-eval. Це тому, що у коді використовується вбудований вираз JavaScript, який зазвичай не рекомендується з причин безпеки. Чи могли б ви переглянути цей розділ і розглянути можливість його переробки, щоб використовувати безпечнішу альтернативу?» Зауважте додане пояснення, посилання на певне правило і ввічливу фразу (« Чи могли б ви переглянути…»). Це демонструє не тільки те, що ви щось ідентифікували, але і те, що ви пропонуєте допомогу і пояснюєте * чому * знайдення важливе. Аналогічно, під час написання описів PR, уникайте нечітких тверджень на зразок « Виправлено помилку ». Замість цього, докладно описуйте проблему, її вирішення і обґрунтування: « Виправлено потенційну уразливість XSS у логіці обробки вводу користувача шляхом очищення всіх даних перед відтворенням у DOM. »

Інша часта проблема виникає під час перегляду коду - особливо при роботі з результатами, які можуть здатися надто чутливими або вимагають подальшого дослідження. Розробник може відповісти у захисному дусі: « Це цілком нормально; Semgrep просто шумить ». Ця відповідь припиняє обговорення і не вирішує проблеми, яка лежить у його основі. Кращий підхід буде таким: «Я розумію ваші вагання, але правило no-eval викликається тут через потенціал довільного виконання коду, якщо ненадійний вхід обробляється безпосередньо в JavaScript. Хоча цей конкретний випадок виглядає доброякісним, він підкреслює ширші роздуми щодо безпеки, які заслуговують уваги. ” Пам’ ятайте, мета полягає не в тому, щоб довести Semgrep неправильним, а в тому, щоб спільно оцінити і зменшити ризик.

І, нарешті, не бійтеся прохання про пояснення. Якщо ви не розумієте коментар або запит, ввічливо попросіть пояснення: « Чи можете ви розібратися, що ви маєте на увазі під « зменшити кількість хибних позитивних результатів »? Я хочу переконатися, що я ефективно вирішую основну причину. Більшість розробників цінують вашу працю і з радістю нададуть вам контекст. Будівництво впевненості виникає з активного залучення до дискусій і демонстрації готовності навчатися.

# Example Semgrep rule for detecting inline JavaScript
rule inline_javascript {
  patterns = [
    "eval\\((.+?)\\)",
    "new Function\\((.+?)\\)"
  ]
  severity = "High"
  description = "Detects potentially dangerous inline JavaScript execution."
}