Салюты, неплохое начало дня 😆

#lol

Вдохновляйся 🙃

#lol

А ведь не поспоришь

#lol

Ой эй 😟

приятные мелочи, но все же мило ;)

🏆 Управление Findings: реальность метрик

Когда toolchain начинает лить сотни срабатываний — команда быстро перестаёт им доверять и ценность AppSec резко падает. Думаю, что все таки стоит разобраться с тем, как это полечить, поэтому возьмем кейсы на базе моей практики.

На конфе я рассказал кулуарно как это считается, почему именно такой подход выбрал и что же важно для него. Давай смотреть на метрики:

• False Positive Rate = (закрыто как FP / всего срабатываний) × 100% - на ruleset пороги инструмента (SQL Injection, XSS, SSRF и т.д.)

Реко:
— ≤ 15% — инструмент адекватно считает (если вы делали качественно и не все в исключение отправляли)
— 15–30% — жёлтая зона, нужна донастройка правил
— > 30% — красная зона, следовательно немедленный аудит правил инструмента
— < 5% — проверьте False Negative или что-то повалилось

• FPR по CWE: FPR(CWE XXX) = FP / все сработки × 100% - отдельные критичные моменты, которые подходят чисто под вашу специфику и стек. Если FPR по CWE > 30%, то добавляйте sink/ source whitelist, context-aware фильтры, исключения по аннотациям для правила сработки.

Пример:
— CWE-89 (SQL Injection) — низкий FPR при правильном парсинге AST, но высокий при regex
— CWE-79 (XSS) — FPR зависит от контекста вывода HTML/ JS/ attr
— CWE-22 (Path Traversal) — высокий FPR из-за ложных taint-цепочек в ORM
— CWE-611 (XXE) — низкий FPR и частый FN из-за кастомных XML
— CWE-502 (Insecure Deserialization) — один из самых назойливых FPR

• Risk-based приоритизация срабатываний: Priority Score = CVSS × EPSS × Reachability × Business Impact

Коэффициенты:
— EPSS — вероятность эксплуатации в 30 дней (0.0–1.0)
— Reachability: 1.0  — endpoint достижим снаружи/ из смежного контура;  0.2  — изолирован, нет маршрута
— Business Impact:  2.0  — external API, user data;  1.0  — internal сервис;  0.5  — dev/ test среда

Пример:
— Score = 7.5 × 0.65 × 1.0 × 2.0 = 9.75 → CRITICAL и акцент на приоритете, который эксплуатируем

• Где нет CVSS/ EPSS, то используем: AppSec Priority = Severity × Confidence (подтверждение сработки по уровню) × Reachability × Business Impact

Итого: минимальный процесс внедрения будет следующий

• Считать FPR отдельно по каждому критическому CWE — раз в спринт, общий раз в крватал или H (полугодие)
• CWE с FPR > 30% на аудит правила, не отключение
• Для каждого срабатывания считать AppSec Priority Score
• Порог для сути, где берём в работу немедленно: Priority Score > 10
• Пересматривать Confidence-коэффициенты под свой инструмент по типу 1.0  — High,  0.5  — Medium,  0.1  — Low

#appsec #reco #devsecops #specialty #paper #research #toolchain

Салюты,
Сегодня «сияем»

#lol

Ууу, родной(ая), делюсь приятностями уже от МФТИ со Сколково, оч хорошо, что после двух полноценных потоков получилась такая ОС, доволен 🫶

🤔 Метрики оценки: тащим STLC в AppSec правильно

Салют.
Часто показываю слайд с восемью метриками оценки из STLC — это классика QA-мира. На конфе, которая была, словил инсайд: необходимость доносить годность для AppSec, когда мы приравниваем баги к уязвимостям кодовой базы. Поэтому поделюсь с тобой своими мыслями. В целом эти метрики и нужны, но не прямо в лоб, потому что скопировать их нельзя, нужно переопределять.

Сначала договоримся с тобой так — тут зарыта главная подмена, где в STLC дефект — это баг, тест — тест-кейс, требование — функциональное требование. А теперь прикол в том, что:

• Дефект - это подтверждённая уязвимость True Positive
• Тест - правило/ политика анализатора ruleset
• Требование - класс угроз CWE, контроль ASVS, пункт безопасной разработки ГОСТ 56939-2024

А теперь чекай слайд:

• «Убойность» правил = подтверждённые уязвимости (TP) / число активных правил ruleset

— Низкая по ruleset, где правила сбоят или мертвы
— Аномально высокая на одном правиле, тут либо системный дефект кода, либо правило сбоит

• Доля покрытия классов угроз (широта) = CWE-классы и контроли, реально проверяемые toolchain / все релевантные для стека × 100%

— < 60% — токсично
— 60–85% — рабочая зона
— > 85% — зрелое покрытие

• Доля отклонённых срабатываний = (FP + accepted / risk accept) / все срабатывания × 100%

— высокая из-за FP, то инструмент сбоит, следовательно делаем аудит правил
— высокая из-за accepted risk, то есть то, что валит процесс, делай эскалацию

• Плотность покрытия (глубина) = число правил / число контролей (CWE / ASVS)

— < 1, показывает, что контроль покрыт формально
— несколько правил с разной логикой (AST + taint analys+ semantic ruleset)

• Плотность уязвимостей = подтверждённые уязвимости (TP) / покрытие кодовой базы (кандидаты на Secure Code Review)

• Доля регрессий уязвимостей (reopen rate) = уязвимости, вернувшиеся после «устранения» / все устранённые × 100%

— > 15% — фиксят не то и не там
— на каждую устранённую Critical/ High следует правило в Quality Gate

• Эффективность AppSec = уязвимости, взвешенные по критичности / трудозатраты AppSec (часы скан + триаж). Веса обычно: Critical 10, High 5, Medium 2, Low 0.5, а лучше перевернуть в «стоимость одной Critical-находки» = часы / число Critical.

• Плотность уязвимостей после поставки = уязвимости, найденные в PROD / обьем кодовой базы (про результат). Если плотностьне падает от релиза к релизу, лезем в проектное управление команды и собираем evidence к ним. Считай Defect Removal Efficiency для ИБ = найдено до релиза / (до релиза + после) × 100%.

Итого:

• Широту покрытия и глубину (плотность правил) считать в паре — раз в спринт детально по критичным CWE, общий срез раз в квартал или H
• Долю отклонённых всегда расщеплять на FP и accepted risk
• Плотность уязвимостей и долю регрессий смотреть каждый релиз
• Эффективность считать через стоимость Critical-находки
• Главный KPI зрелости — Defect Removal Efficiency для ИБ > 90%

#appsec #devsecops #reco #toolchain #paper #specialty

Салюты, интересное подьехало - почекай

Всем привет!

Open source по выходным: я выпустил новый релиз моей карты средств защиты ядра Linux.

Теперь она соответствует относительно свежему ядру v6.17.

Я добавил в нее новые средства защиты, устранил несколько ошибок и сделал связи еще более красивыми 🖼

Радуюсь, что все-таки находятся силы развивать этот проект!

https://github.com/a13xp0p0v/linux-kernel-defence-map