А в общем как ваши тесты выглядят - просто набор мини тестов, которые нацеливаются на конкретные функции или вы целиком приложения скармиливаете? Сколько времени оно фаззит одну исполняемую единицу?
Да, набор тестов для конкретных функций. Предварительно выбираем наиболее уязвимые места, там где внешний ввод, близость к сети, большой импакт и т.д. По времени от 2-х до 24 часов.
Запускаем на ферме по необходимости. Критерии ФСТЭК используем, но они достаточно общие, например там не указывается целевое покрытие. Критерии останова фазинга это вообще сложный вопрос, одно время у нас был критерий по целевому покрытию, сейчас от этого уходим.
А есть что-нибудь про формальную верифицированные программы, которые были сформированы из пруфов на каком-нибудь Coq/Lean/Idris?
При это я немного знаю, слышал что у нас делалась формальная верификация на основе TLA+ модели.
Спасибо за комментарий. Касаемо мониторинга в реальном времени - это один из возможных подходов к разработке софта, он предусматривает быстрое обнаружение уязвимостей и главное быстрый фикс. Не всегда это подходит предметной области, например к критической инфраструктуре это не применимо.
Что касается безопасных языков, Rust и прочих, то как Вы правильно сказали их безопасность ограничивается работой с памятью. Т.е. они фиксят жирный пласт различных переполнений, UAF, невалидный итераторов и т.д., но этим списком уязвимости не ограничиваются - есть еще целочисленные переполнения, гонки, работа с файлами, сетью и т.д. Безопасные языки не закрывают все проблемы.
Все познается в сравнении и иногда, чтобы понять ценность паттерна нужно оценить вред соответствующего ему анти-паттерна. Вот некоторые примеры комбинаций паттерн/анти-паттерн.
Паттерн «Сделать наспех и сбежать — преступление» («Commit-and-run is a crime», Niclas Nilsson) — внесение изменений в код с учетом всех возможных последствий. Анти-паттерн «Ползущий улучшизм» («Creeping featurism») — добавление новых улучшений в ущерб качеству системы.
Паттерн «Одна строчка рабочего кода стоит 500 строк спецификации» («One line of working code is worth 500 of specification», Allison Randal) — ни один дизайн не бывает идеальным с самого начала, любой дизайн подвержен изменениям по мере реализации. Анти-паттерн «Аналитический паралич» («Analysis paralysis») — выделение непропорционально больших усилий в фазе анализа проекта.
Паттерн «У каждого есть свои слепые пятна» (Dave Quick) — «слепые пятна» — слабости и проблемы, которые трудно принять. Люди, готовые сообщить неприятную правду — драгоценный ресурс. Анти-паттерн «Я тебе это говорил» («I told you so») — когда игнорируется предупреждение эксперта, являющееся оправданным.
Паттерн «Предоставьте разработчикам независимость» (Phillip Nelson) — независимость позволит разработчикам продемонстрировать свои навыки и проявить творческие способности. Анти-паттерн «Драконовские меры» («Management by perkele») — военный стиль управления без толерантности к диссидентству.
Паттерн «Остерегайтесь хороших идей» (Greg Nyberg) — хорошие идеи раздувают масштаб проекта, повышают сложность и требуют лишних усилий на включение в приложение того, что не нужно для достижения бизнес-цели. Анти-паттерн «Рыцарь на белом коне» («Knight in shining armor») — проявляется, когда личность появляется на сцене и пытается починить всё, без сообщений о том, какие изменения он/она сделал(а)/сделает и почему.
Да, набор тестов для конкретных функций. Предварительно выбираем наиболее уязвимые места, там где внешний ввод, близость к сети, большой импакт и т.д. По времени от 2-х до 24 часов.
AFL++. Оригинальный уже не поддерживается.
Запускаем на ферме по необходимости. Критерии ФСТЭК используем, но они достаточно общие, например там не указывается целевое покрытие. Критерии останова фазинга это вообще сложный вопрос, одно время у нас был критерий по целевому покрытию, сейчас от этого уходим.
При это я немного знаю, слышал что у нас делалась формальная верификация на основе TLA+ модели.
Спасибо за комментарий. Касаемо мониторинга в реальном времени - это один из возможных подходов к разработке софта, он предусматривает быстрое обнаружение уязвимостей и главное быстрый фикс. Не всегда это подходит предметной области, например к критической инфраструктуре это не применимо.
Что касается безопасных языков, Rust и прочих, то как Вы правильно сказали их безопасность ограничивается работой с памятью. Т.е. они фиксят жирный пласт различных переполнений, UAF, невалидный итераторов и т.д., но этим списком уязвимости не ограничиваются - есть еще целочисленные переполнения, гонки, работа с файлами, сетью и т.д. Безопасные языки не закрывают все проблемы.
Паттерн «Сделать наспех и сбежать — преступление» («Commit-and-run is a crime», Niclas Nilsson) — внесение изменений в код с учетом всех возможных последствий.
Анти-паттерн «Ползущий улучшизм» («Creeping featurism») — добавление новых улучшений в ущерб качеству системы.
Паттерн «Одна строчка рабочего кода стоит 500 строк спецификации» («One line of working code is worth 500 of specification», Allison Randal) — ни один дизайн не бывает идеальным с самого начала, любой дизайн подвержен изменениям по мере реализации.
Анти-паттерн «Аналитический паралич» («Analysis paralysis») — выделение непропорционально больших усилий в фазе анализа проекта.
Паттерн «У каждого есть свои слепые пятна» (Dave Quick) — «слепые пятна» — слабости и проблемы, которые трудно принять. Люди, готовые сообщить неприятную правду — драгоценный ресурс.
Анти-паттерн «Я тебе это говорил» («I told you so») — когда игнорируется предупреждение эксперта, являющееся оправданным.
Паттерн «Предоставьте разработчикам независимость» (Phillip Nelson) — независимость позволит разработчикам продемонстрировать свои навыки и проявить творческие способности.
Анти-паттерн «Драконовские меры» («Management by perkele») — военный стиль управления без толерантности к диссидентству.
Паттерн «Остерегайтесь хороших идей» (Greg Nyberg) — хорошие идеи раздувают масштаб проекта, повышают сложность и требуют лишних усилий на включение в приложение того, что не нужно для достижения бизнес-цели.
Анти-паттерн «Рыцарь на белом коне» («Knight in shining armor») — проявляется, когда личность появляется на сцене и пытается починить всё, без сообщений о том, какие изменения он/она сделал(а)/сделает и почему.