БЕ @programming_tales
Showing posts older than #410 · Back to latest
Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
Есть две школы мысли.
Первая — это директора, HR-ы и "эффективные менеджеры", которые уже планируют сокращения IT-отделов. Они искренне верят, что ChatGPT скоро будет писать весь код, а программисты станут не нужны. Максимум оставят пару "промт-инженеров" и всё. Зачем платить разработчику, если можно просто попросить ИИ "сделать мне интернет-магазин"?
Вторая школа мысли сложна для понимания, потому что senior-программисты ржут так сильно, что не могут нормально объяснить.
(c) Мем с просторов интернета
Warning реализовать методы сравнения".public class Warning
{
public string ErrorCode { get; set; }
public string Message { get; set; }
public uint Level { get; set; }
public List<Position> Trace { get; set; }
}
public class Position
{
public int Line { get; set; }
public string FilePath { get; set; }
}
public bool Equals(Warning other)
{
if (other is null) return false;
if (ReferenceEquals(this, other)) return true;
return ErrorCode == other.ErrorCode &&
Message == other.Message &&
Level == other.Level &&
(Trace == other.Trace ||
(Trace != null && other.Trace != null &&
Trace.SequenceEqual(other.Trace)));
}
public override int GetHashCode()
{
unchecked
{
int hash = 17;
hash = hash * 23 + (ErrorCode?.GetHashCode() ?? 0);
hash = hash * 23 + (Message?.GetHashCode() ?? 0);
hash = hash * 23 + Level.GetHashCode();
hash = hash * 23 + (Trace?.GetHashCode() ?? 0);
return hash;
}
}
GetHashCode в строке:hash = hash * 23 + (Trace?.GetHashCode() ?? 0);
Trace — список (ссылочный тип), поэтому хэш-код считается от ссылки на память, а она у всех объектов разная. Следовательно объекты никогда не будут равны, даже если у них одинаковые значения. В итоге ни один из стандартных алгоритмов (сортировки, фильтры, дубликаты и т.п.) не работал правильно.Forwarded from Конференция ВСРВ-2027
Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, об условленных небезопасными преобразованиями кода.
Настоящий стандарт устанавливает общие требования к безопасному компилятору программ на языках С и C++. Целью работы безопасного компилятора является не вносить в бинарный код программы ошибки, которых не было в исходном коде программы и которые могут появиться в ходе компиляции, в том числе в ходе выполнения оптимизаций кода программы. Настоящий стандарт задает требования к динамической компоновке и загрузке программ, выполнение которых необходимо для поддержки ряда возможностей безопасного компилятора. Настоящий стандарт уточняет требования к мерам по разработке безопасного программного обеспечения, реализуемые при выполнении конструирования и комплексирования программного обеспечения, в части требований к используемым инструментальным средствам (безопасному компилятору). Настоящий стандарт определяет требования к функциям безопасного компилятора и задает нефункциональные требования к безопасному компилятору, задает требования к методике проверки требований к безопасному компилятору.
Настоящий стандарт предназначен для разработчиков компиляторов, а также для разработки безопасного программного обеспечения при выборе и оценке средств компиляции.
Безопасный компилятор предотвращает появление уязвимостей в программе при выполнении агрессивных оптимизаций кода (например, в результате использования конструкций, проявляющих неопределённое поведение). Минимально ограничивает выполняемые оптимизации, что позволяет избежать значительного падения производительности по сравнению с полным отключением оптимизаций.
5.12. — Использование безопасной системы сборки программного обеспечения.
Мы используем свой проверенный компилятор для сборки JDK. Мы создали свои доверенные Gradle и Maven, которые собрали своим компилятором Java. Эти сборки позволяют гарантировать чистоту сборочного конвейера. Дополнительно они вносят в JAR-файлы библиотек подписи с информацией, что сборка библиотеки произведена компанией Axiom JDK.
Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.
Определить инструменты динамического анализа и фаззинг-тестирования, порядок их применения.
п.3.2 динамический анализ кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода.
п.3.22 фаззинг-тестирование программы: Вид работ по исследованию программы, основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.
Тип недостатка: Применение средств фаззинг-тестирования, не реализующих генетические алгоритмы фаззинг-тестирования (в том числе за счет инструментирования тестируемого кода).
Завершился этап «Домашнее задание» в рамках испытаний статических анализаторов ФСТЭК России. Эксперты подготовили набор синтетических тестов для проверки выявления критических ошибок по ГОСТ Р 71207-2024. Однако на практике возникло много технических вопросов. На вебинаре эксперты PVS-Studio, Positive Technologies и АО «НПО «Эшелон» обсудили эти нюансы и поделились полученным опытом.
п.5.10.3.3 Конфигурации и параметры настройки инструментов статического анализа должны обеспечивать выполнение требований регламента проведения статического анализа в части выявления типов и критичности ошибок (уязвимостей), периодичности проведения статического анализа или событий, при наступлении которых необходимо выполнять повторный статический анализ.
п.5.10.3.4 Отчеты по результатам проведения статического анализа должны включать:
- срабатывания инструментов статического анализа;
- результаты анализа (разметки) выявленных ошибок (срабатываний статического анализатора).
п.5.10.3.5 Конфигурации и параметры настройки инструментов статического анализа, уточненные по результатам выполнения требований 5.10.2.5, должны обеспечивать выполнение требований регламента проведения статического анализа в части выполнения критериев их пересмотра.
5.10.3.1 Регламент проведения статического анализа исходного кода ПО должен содержать следующие сведения:
- обязанности сотрудников и их роли при проведении статического анализа;
- критерии выбора инструментов статического анализа; [рассмотрим подробнее ниже]
- критерии выбора ПО (модулей ПО, компонентов ПО, функциональных подсистем ПО), подлежащих проведению статического анализа;
- правила обработки срабатываний средств статического анализа;
- типы и критичность ошибок (уязвимостей), выявляемых статическим анализатором, подлежащих устранению, и приоритеты устранения ошибок (уязвимостей);
- периодичность проведения статического анализа или события, при наступлении которых необходимо выполнять повторный статический анализ;
- критерии пересмотра конфигурации и параметров настройки инструментов статического анализа.
Перечень инструментов статического анализа должен включать наименования инструментов статического анализа, их версии и информацию о соответствии используемым языкам программирования.
Наступил тот самый момент, когда нашим дорогим подписчикам можно узнать детали ещё одной тайны мироздания – как получить сертификат ФСТЭК на свою разработку.
Вместе с Никитой Молчаном из лаборатории Атомзащитаинформ, Даниилом Скалацким из Angie Software и Андреем Карповым из PVS-Studio выясняли, в чём разница между лицензированием, аттестацией и сертификацией, зачем, кому и для чего оно надо, как проводится экспертиза и, самое главное, что ждёт рискнувшего и как заполучить вожделенный сертификат.
Предотвращение внесения потенциально опасных конструкций и ошибок в ПО, а также использования опасных конструкций и уязвимостей из заимствованного кода.
