Салюты,
Немного интересного, сейчас готовлю материалы для выступления, о котором говорил тут, на пока поделюсь с тобой частичным контентом.
#appsec #devsecops #meetup #reco #specialty
Немного интересного, сейчас готовлю материалы для выступления, о котором говорил тут, на пока поделюсь с тобой частичным контентом.
#appsec #devsecops #meetup #reco #specialty
🔥5
Forwarded from СофтТех
ФАС раскрыла картель при закупках ПО
Антимонопольная служба выявила картельный сговор при проведении торгов ПО для государственных нужд. Общая сумма начальных максимальных цен контрактов в результате сговора составила 236 млн руб.
В качестве нарушивших антимонопольное законодательство называются три компании:
▶️ ООО «Бизнес Стандарт»
▶️ ООО АКБ «Барьер»
▶️ ООО «Сэйвит Эдьюкейшн»
Особый интерес вызывают последние две: АКБ «Барьер» и «Сэйвит Эдьюкейшн» — обе находятся в списке активов группы «Софтлайн».
Конкретно компании обвиняются в отказе от конкуренции при участии в торгах: компании выбирали единую модель поведения, что выражалось в минимальном снижении от начальной максимальной цены контракта.
В ходе расследования ФАС выяснилось, что компании использовали единую цифровую инфраструктуру, синхронизировали поведение на торгах. Также влияние оказала аффилированность учредителей и устойчивые финансово-хозяйственные взаимоотношения между ответчиками.
Коллеги из TAdviser взяли комментарий у «Софтлайна» и те отметили, что речь идет о самостоятельных юридических лицах с разными направлениями деятельности и историей владения. На момент процедур, к которым существуют претензии, компании находились вне структуры владения группой «Софтлайн»:
В перспективе за картельный сговор компаниям грозит оборотный штраф от 10% до 50% от начальной цены торгов, а также в случае, если ущерб признают крупным, вплоть до 7 лет лишения свободы для руководителя📌
💻 СофтТех в Telegram | в MAX
Антимонопольная служба выявила картельный сговор при проведении торгов ПО для государственных нужд. Общая сумма начальных максимальных цен контрактов в результате сговора составила 236 млн руб.
В качестве нарушивших антимонопольное законодательство называются три компании:
Особый интерес вызывают последние две: АКБ «Барьер» и «Сэйвит Эдьюкейшн» — обе находятся в списке активов группы «Софтлайн».
Конкретно компании обвиняются в отказе от конкуренции при участии в торгах: компании выбирали единую модель поведения, что выражалось в минимальном снижении от начальной максимальной цены контракта.
В ходе расследования ФАС выяснилось, что компании использовали единую цифровую инфраструктуру, синхронизировали поведение на торгах. Также влияние оказала аффилированность учредителей и устойчивые финансово-хозяйственные взаимоотношения между ответчиками.
Коллеги из TAdviser взяли комментарий у «Софтлайна» и те отметили, что речь идет о самостоятельных юридических лицах с разными направлениями деятельности и историей владения. На момент процедур, к которым существуют претензии, компании находились вне структуры владения группой «Софтлайн»:
ГК «Софтлайн» не имеет никакого отношения к тендерным процедурам и заключению контрактов во время принадлежности указанных активов предыдущим владельцам. Совершенно справедливо, что никакие должностные лица ГК «Софтлайн» не подвергнуты ответственности за эти, состоявшиеся до приобретения указанных предприятий, правонарушения.
В перспективе за картельный сговор компаниям грозит оборотный штраф от 10% до 50% от начальной цены торгов, а также в случае, если ущерб признают крупным, вплоть до 7 лет лишения свободы для руководителя
Please open Telegram to view this post
VIEW IN TELEGRAM
😱3
🏆 Управление Findings: реальность метрик
Когда toolchain начинает лить сотни срабатываний — команда быстро перестаёт им доверять и ценность AppSec резко падает. Думаю, что все таки стоит разобраться с тем, как это полечить, поэтому возьмем кейсы на базе моей практики.
На конфе я рассказал кулуарно как это считается, почему именно такой подход выбрал и что же важно для него. Давай смотреть на метрики:
• False Positive Rate = (закрыто как FP / всего срабатываний) × 100% - на ruleset пороги инструмента (SQL Injection, XSS, SSRF и т.д.)
• FPR по CWE: FPR(CWE XXX) = FP / все сработки × 100% - отдельные критичные моменты, которые подходят чисто под вашу специфику и стек. Если FPR по CWE > 30%, то добавляйте sink/ source whitelist, context-aware фильтры, исключения по аннотациям для правила сработки.
• Risk-based приоритизация срабатываний: Priority Score = CVSS × EPSS × Reachability × Business Impact
• Где нет CVSS/ EPSS, то используем: AppSec Priority = Severity × Confidence (подтверждение сработки по уровню) × Reachability × Business Impact
Итого: минимальный процесс внедрения будет следующий
#appsec #reco #devsecops #specialty #paper #research #toolchain
Когда 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
🔥6
Forwarded from Партизанский Маркетинг
Увольнения из-за ИИ дошли до того, что разработчики уже готовятся к худшему заранее.
Айтишник сделал кнопку «I GOT FIRED» — после её нажатия система автоматически публикует код компании, сливает все ключи и пароли, удаляет тестовую базу и отправляет уведомление юристу. Сам разработчик уверяет, что нажимать её не планирует, а собрал её чисто на всякий случай.
Пока одни обновляют резюме, другие готовят кнопку на чёрный день.
Айтишник сделал кнопку «I GOT FIRED» — после её нажатия система автоматически публикует код компании, сливает все ключи и пароли, удаляет тестовую базу и отправляет уведомление юристу. Сам разработчик уверяет, что нажимать её не планирует, а собрал её чисто на всякий случай.
Пока одни обновляют резюме, другие готовят кнопку на чёрный день.
😱5
🤔 Метрики оценки: тащим STLC в AppSec правильно
Салют.
Часто показываю слайд с восемью метриками оценки из STLC — это классика QA-мира. На конфе, которая была, словил инсайд: необходимость доносить годность для AppSec, когда мы приравниваем баги к уязвимостям кодовой базы. Поэтому поделюсь с тобой своими мыслями. В целом эти метрики и нужны, но не прямо в лоб, потому что скопировать их нельзя, нужно переопределять.
А теперь чекай слайд:
• «Убойность» правил = подтверждённые уязвимости (TP) / число активных правил ruleset
• Доля покрытия классов угроз (широта) = CWE-классы и контроли, реально проверяемые toolchain / все релевантные для стека × 100%
• Доля отклонённых срабатываний = (FP + accepted / risk accept) / все срабатывания × 100%
• Плотность покрытия (глубина) = число правил / число контролей (CWE / ASVS)
• Плотность уязвимостей = подтверждённые уязвимости (TP) / покрытие кодовой базы (кандидаты на Secure Code Review)
• Доля регрессий уязвимостей (reopen rate) = уязвимости, вернувшиеся после «устранения» / все устранённые × 100%
• Эффективность AppSec = уязвимости, взвешенные по критичности / трудозатраты AppSec (часы скан + триаж). Веса обычно: Critical 10, High 5, Medium 2, Low 0.5, а лучше перевернуть в «стоимость одной Critical-находки» = часы / число Critical.
• Плотность уязвимостей после поставки = уязвимости, найденные в PROD / обьем кодовой базы (про результат). Если плотностьне падает от релиза к релизу, лезем в проектное управление команды и собираем evidence к ним. Считай Defect Removal Efficiency для ИБ = найдено до релиза / (до релиза + после) × 100%.
Итого:
#appsec #devsecops #reco #toolchain #paper #specialty
Салют.
Часто показываю слайд с восемью метриками оценки из 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
🔥6