Криптоалгоритмы. классификация с точки зрения количества ключей

Особенности использования Open Source

Главное преимущество открытого кода с позиции бизнеса – это возможность использовать готовые элементы кода для решения типовых задач. Это существенно снижает временные и финансовые затраты на создание нового программного продукта или доработку функций уже существующего.

Однако, это не значит что Open Source – это просто и бесплатно. Процесс кастомизации и адаптации кода под конкретные задачи и особенности инфраструктуры компании может быть довольно затратным.

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

С другой стороны, никакого единого регламента к безопасности open-source, который соблюдался бы всеми интерессантами, в данный момент не существует. В актуальных условиях за безопасность продукта, фактически, отвечают все участники, от авторов до контрибьюторов и конечных пользователей. Из-за этого нередки ситуации, когда за безопасность открытого кода не отвечает вообще никто.

С позиции ИБ, наиболее оптимальна политика «нулевого доверия» к компонентам Open Source. Она подразумевает проведение аудита безопасности кода еще до того, как он будет развернут в инфраструктуре компании.

Open Source для бизнеса. Что мы рекомендуем.

Выше мы сравнили коммерческое и Open Source ПО. Кому-то может показаться, что корпоративному заказчику нужно либо выбрать один из двух подходов, либо использовать единственно доступный для него.

Даже для крупной компании уровень инвестиций в ИТ, требуемый для организации полноценного и безопасного использования Open Source ПО, может быть слишком высоким. А для компаний, которые производят продукцию, создают сервисы, предлагают услуги и не являются ИТ-гигантами, такие затраты просто не оправданы.

• Как в такой ситуации одновременно использовать преимущества обоих подходов?

• Как использовать инновации из мира Open Source, но делать это безопасно и не «раздувать» штат своего ИТ-подразделения?

• Как не остаться «один на один» с проблемами в вопросах технической поддержки?

Можно продолжать использовать иностранное ПО, игнорируя риски. В этом подходе есть очевидные плюсы – не нужно повторно инвестировать в то, что пока работает. Минусы тоже очевидны – не понятно сколько это «пока» продлится. Можно внедрять российское ПО, но не во всех сферах есть готовые решения. Во многие направления, например, СУБД, российские ИТ-компании не инвестировали, потому что рынок был прочно занят иностранными гигантами.

Но есть и более интересная перспектива. Некоторые крупные корпорации, которые вкладывали в развитие собственной Open Source-экспертизы, выводят на рынок собственные сборки продуктов и начинают предлагать услуги технической поддержки. Например, мы уже несколько лет предлагаем на рынке «Платформу управления данными». Для многих компаний это может быть экономически выгодным решением, которое совмещает высокую технологичность Open Source, надежность поставщика и гарантированную техническую поддержку на территории России. Предполагаем, что в ближайшее время на рынке будет появляться больше таких решений и от других компаний.

Как наказывают провинившихся программистов

Согласно российскому законодательству, есть два вида имущественной ответственности за нарушение авторских прав: полное возмещение убытков или компенсация в размере от 10 тысяч до 5 миллионов рублей.

Возмещение убытков — сложная для истца процедура, ведь ему нужно будет обосновывать указанный им размер убытков.

Компенсация, с одной стороны, удобнее: можно затребовать твёрдую сумму, двукратную стоимость контрафактных экземпляров или двукратную стоимость лицензионного договора на использование произведения. Однако не стоит забывать про верхний предел в пять миллионов; при нарушении прав на софт это будет довольно скромным утешением.

Кроме того, в некоторых случаях возможна и компенсация морального ущерба — например, если пострадала репутация автора. Конкретную сумму определяет суд исходя из обстоятельств дела.

Ответчиком в подобных делах рискует стать любой, кто пользуется ПО с открытым кодом. Например:

• перед правообладателями, если вы нарушили условия свободной лицензии;
• перед действительными авторами, если вы не проверили авторство программы и нарушили их права;
• перед иными правообладателями: продукт с открытым кодом может включать в себя другие объекты интеллектуальной собственности — например, запатентованные. Не любая свободная лицензия предоставляет на них права, необходимые для использования программы. И даже если такие права предоставлены, как, например, в Apache 2.0, это не исключает возможного возникновения патентных исков.

У всех тяжб, связанных с имущественной ответственностью, есть не самый радостный нюанс: даже если вам удастся в конце концов доказать свою невиновность, это не спасёт вас от побочных неприятностей. Допустим, правообладатель может запретить вам использовать спорное ПО на всё время судебного разбирательства.

Напомню один из самых известных имущественных процессов. В 2017 году компания Artifex, создавшая Ghostscript, подала в суд на Hancom, включившую эту разработку в свой офисный пакет.

Суть спора заключалась в следующем: у Artifex было две лицензии на Ghostscript — свободная (GPL) и коммерческая. В Hancom решили схитрить: воспользоваться открытой версией Ghostscript, но свой продукт в качестве свободного ПО не выпускать. Истец счёл это нарушением условий лицензии.

Для чего нужен каждый вид тестирования

Прежде всего это зависит от того, какая инфраструктура тестируется — внутренняя или внешняя.

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

Допустим, у компании Example Ltd. есть сайт example.com. Она обращается к службе тестирования на проникновение с просьбой проверить внешний периметр. Для этого предоставляют конкретный перечень ресурсов — например, IP-адреса и доменные адреса — или просят составить его самостоятельно.

Внутренняя инфраструктура — ресурсы, доступные только внутри корпоративной сети: принтеры, сетевые диски, доменный контроллер Active Directory, панели администрирования АСУТП, базы данных, рабочие станции сотрудников и так далее.

Для неё чаще проводят анализ защищённости. Это удобно для Blue Team: они могут захватывать сетевой трафик, примеры запросов, собирать данные для систем обнаружения и реагирования на киберинциденты.

Прочие виды тестирования проводят компании с довольно зрелым уровнем информационной безопасности — например, крупные заводы или телеком-провайдеры. Иначе там быть не может — слишком много рисков, связанных с утечкой данных. Это довольно длительные процессы, длящиеся от трёх месяцев до нескольких лет.

Независимо от вида тестирования и принадлежности к той или иной команде, специалистам отдела информационной безопасности лучше всегда быть на связи — например, создавать общий чат и обмениваться знаниями. Хотя часто он становится чатом для претензий одной команды к другой.

Безопасность как эргономика

Этот уровень безопасности — самый новый, и его я считаю самым интересным. Я говорю об опасных ситуациях, которые могут возникнуть при подключении компьютеров к сложным процессам, основанным на человеческом восприятии. Как и в вышеописанном случае, проблемы и методы третьего уровня не являются какими-то новыми открытиями. Но современные технологии, в частности искусственный интеллект, сделали их актуальными как никогда.

Программное обеспечение изначально придумывали для того, чтобы помогать человеку в работе, — но есть разница между присутствием в системе и участием в ней. Когда вы используете базу данных для отслеживания изменений в реестре, ПО присутствует в системе. Когда вы создаёте ПО, которое само переупорядочивает элементы этой базы, оно становится участником.

Ключевое различие — в том, как ведёт себя программа: записывает или изменяет данные. Поскольку автоматизация ПО становится всё более распространённой, на первый план выходит вопрос о том, как инициируемые им изменения могут влиять на людей, участвующих в процессе.

Многие называют эту проблему этической, но для меня это проблема безопасности. Этика предполагает, что небезопасные состояния можно предвидеть. Когда проектное решение вызывает крушение самолёта, мы не обсуждаем этику — если, конечно, не выяснится, что люди, принявшие это решение, могли знать о возможности такого исхода. В противном случае это просто случайность.

Безопасность ПО начинается с разработчиков

До DevOps команды разработчиков часто обеспечивали безопасную работу на последних этапах процесса выпуска приложения, обычно как необходимый шаг Cовета по Изменениям (CAB). По причине того, что команды безопасности появлялись в процессе слишком поздно, у них было мало времени для ознакомления с бизнес-требованиями, понимания технических изменений, оценки рисков и запуска тестов безопасности. Если они подтверждали проблемы, было слишком мало времени для их решения без нарушения сроков выпуска, а проблемы, требующие существенных правок кода, ставили команду разработчиков перед трудным выбором (знакомая тема, как-то раз уже попадал в такую ситуацию, прим. переводчика).

Позднее тестирование безопасности в процессе выпуска может стать критическим риском для команд DevOps, увеличивающих частоту выпусков или желающих перейти на микросервисы. Согласно отчету State Of DevOps 2019 года (перевод на русском), публикуемому DORA и Google Cloud, о 43% опрашиваемых можно сказать, что они исполнители с высокими или элитными показателями, выпускающие приложения ежедневно или еженедельно. Это значительное увеличение производственных развертываний, частота которых требует внедрения передовых методов обеспечения безопасности на раннем этапе процесса разработки.

Совместная работа гибких команд разработчиков и infosec нужна в следующих областях:

• Ознакомление с требованиями безопасности, архитектурой и принципами разработки;
• Обеспечение автоматических тестов безопасности в конвейерах CI/CD;
• Мониторинг угроз для приложений, решение проблем безопасности.

Я предлагаю почитать некоторые руководства, чтобы получить представление о каждой области в разделах ниже. Первая, вторая, третья ссылки.

Критерий выбора

Для понимания смысла использования Common Criteria важно знать как уровень
оценки EAL, так и проверявшиеся профили безопасности. К сожалению, пока выбор
систем государственного уровня основывается либо на утопических идеях (Поднимем
Россию с колен, построим «Русскую ось»!), либо на маркетинговых заявлениях

В госаппарте есть эксперты соответствующего уровня. В Америке давно решили,
что стоимость переобучения персонала на новую систему обойдётся дороже, чем
многомиллиардный контракт с Microsoft. В конечном счете, неужели сумма ущерба от
всех хакерских атак не перекрывает стоимость внедрения новых, более безопасных
информационных систем? Верится с трудом.

Кто и как борется за безопасность свободного ПО

В зарубежной практике есть система договоров-стратегий SLA (Service Level Agreement, соглашение об уровне обслуживания). Его заключают заказчик и поставщик Open Source для уменьшения рисков отсутствия обратной связи и решения проблем информационной безопасности.

Хорошо известны инструменты по повышению безопасности открытого ПО:

• статические анализаторы исходного кода (SAST);
• динамические анализаторы безопасности приложений (DAST);
• автоматизированные сценарии тестирования в процессе проверки качества (QA);
• анализаторы многоуровневых взаимозависимостей между своими и сторонними компонентами (SCA);
• анализаторы безопасности скриптов, используемых для построения «инфраструктуры как кода»;
• анализаторы безопасности образов и конфигураций контейнеров и средств для их оркестрации.

В 2020 году Linux Foundation совместно с GitHub, Google, IBM, JPMorgan Chase, Microsoft, NCC Group, OWASP Foundation и Red Hat учредила новый совместный проект OpenSSF (Open Source Security Foundation), целью которого стало повышение безопасности ПО с открытым кодом. К инициативе также присоединились GitLab, HackerOne, Intel, Uber, VMware, ElevenPaths, Okta, Purdue, SAFECode, StackHawk и Trail of Bits.

В числе задач проекта названы:

• раскрытие информации об уязвимостях и распространение исправлений;
• разработка инструментов для обеспечения безопасности;
• разработка и публикация лучших практик по ИБ при организации разработки;
• выявление угроз в открытом ПО, аудит и усиление ИБ критически важных открытых проектов;
• организация идентификации и подтверждения личности разработчиков для исключения внесения нелегитимных изменений в код.

Среди других проектов, исследующих защищённость открытого ПО, — Coverity, созданный в сотрудничестве со Стэнфордским университетом; PVS-Studio; сообщество Open Web Application Security Project (OWASP).

В последнее время повышенное внимание безопасности открытого кода уделяется и в отечественной IT-индустрии. Например, по инициативе Федеральной службы по техническому и экспортному контролю (ФСТЭК) создан Технологический центр исследования безопасности ядра Linux

В октябре 2021 года представители ФСТЭК, научного сообщества и IT-рынка раскрыли концепцию центра и рассказали, как он будет работать

Например, по инициативе Федеральной службы по техническому и экспортному контролю (ФСТЭК) создан Технологический центр исследования безопасности ядра Linux. В октябре 2021 года представители ФСТЭК, научного сообщества и IT-рынка раскрыли концепцию центра и рассказали, как он будет работать.

Центр будет исследовать и совершенствовать защиту отечественных дистрибутивов Linux и всего, что на них создано. А также «обеспечивать технологическую независимость российских компаний-разработчиков дистрибутивов и программно-аппаратных средств от внешних игроков».

В апреле 2022 года начала работать . Её директором стала Любовь Орлова, в 2014–2015 годах возглавлявшая Российскую ассоциацию свободного программного обеспечения (РАСПО). В состав учредителей входят Ростелеком, Т1, VK, Россельхозбанк, «АДС Групп», Фонд информационной демократии и другие. В планах организации — создать среду для разработчиков национальных проектов с открытым кодом.

Следи за ПО, будь осторожен

Проекты Open Source задействуют большое количество участников. Не все из них разбираются в вопросах безопасности ПО. Если централизованная проверка созданного кода не проводится, возникает опасность включения вредоносных фрагментов вроде backdoor и spyware.

Кроме того, не всегда есть общий алгоритм устранения неполадок в случае обнаружения уязвимостей (system vulnerabilities), а обновления, которые помогают с ними бороться, выходят нерегулярно. Это может привести к серьёзным угрозам информационной безопасности по всему миру.

Например, уязвимость в Apache Log4j — библиотеке, которая используется миллионами корпоративных приложений и Java-серверами, — позволяла преступникам выполнять произвольный код на сервере или устройстве, чтобы похитить данные или внедрить вредоносную программу.

Точно так же в 2014 году большой резонанс вызвала уязвимость Heartbleed, обнаруженная в компоненте с открытым исходным кодом OpenSSL.

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

Владимир Садовский, руководитель группы мониторинга и реагирования на инциденты информационной безопасности «М.Видео-Эльдорадо», — о том, как построить процесс безопасного программирования

Угрозы безопасности в ритейле

• Реализация автотестов безопасности при тестировании приложений.
• Создание костюмных правил для статического анализатора с привязкой к критичным бизнес-процессам и интеграциям.
• Ручной анализ частей измененного кода, в разрезе функционала, который имеет высокую критичность на основании рисков.
• Процесс поиска закладок в коде, периодический аудит внешних библиотек.

Работа с Big Data и построение моделей аномального поведения и отклонения от нормы.
Процесс мониторинга и аудита JS-скриптов. Современные сайты не работают без JS-скриптов. Зачастую они загружаются с внешних ресурсов

Поэтому важно понимать их функционал, и какую угрозу JS-скрипты несут для сайта. Поиск уязвимостей на основании аналитики сервисов и метрик Google и Яндекс.
Регулярное проведение тестирования защищенности проекта в целом.
Использование программы Bug Bounty для выявления новых уязвимостей.
Интеграция WAF для защиты приложений и эффективного реагирования на проблемы

На страже государства

На сайте
Microsoft, в прессе и по телевидению всё чаще можно слышать заверения о
возросшем уровне безопасности операционных систем семейства Windows. Подобные
высказывания не голословны, а основываются на результатах тестирования
сторонними компаниями, чья деятельность сертифицирована по всем правилам Общих
Стандартов. Что ж, после такого становится понятно, почему такой важный с точки
зрения безопасности проект как «Электронная
Россия» базируется на
решениях компании Microsoft. Или почему военные США и России массово
устанавливают «Висту» на базах по всему миру.

Об уязвимостях операционных систем семейства Windows говорить излишне. Однако
Windows соответствуют высокому стандарту безопасности, позволяющему свободно
использовать ось в государственных целях. В этом, на первый взгляд, чувствуется
какая-то патология. Но лишь до тех пор, пока мы не начнём вчитываться в
многотомную документацию сертификатов безопасности. Там чётко указано
позиционирование Windows на тех профилях безопасности, которые не предназначены
для использования в условиях, когда действует систематическая продуманная атака
со стороны хакеров. Становится понятно, почему из года в год военные сети
остаются уязвимыми. Недавнийпереполох в министерстве
обороны США привёл к временному запрету на использование всех типов сменных
носителей – от флешек до винчестеров. Такова оказалась цена за сертифицированную
безопасность.

Плагиаторы поневоле

По закону, пока не будет доказано иное, автором считается тот, кто указан в этом качестве на оригинале или копии произведения. Отсюда и риски, возникающие в ситуации, когда вы выкладываете свою программу с открытым кодом под одной из свободных лицензий. Любой недобросовестный разработчик может использовать ваш код в своём продукте и даже выдавать его за собственный. И выяснится это, скорее всего, не сразу.

Точно так же опасность возникает, если вы используете чей-то открытый код в своих разработках. Никто не может гарантировать, что его автор законопослушен, что именно он обладает правами на код и может распространять его под указанной им лицензией. Сами того не подозревая, вы рискуете нарушить чьи-то авторские права или лицензионные условия — со всеми вытекающими из этого судебными последствиями.

Ситуации могут быть самые разные. Например, вы использовали в своём проекте код, распространяемый под разрешительной лицензией, а потом выяснилось, что он включает в себя части проприетарного кода, который скопировали нелегально. Или кто-то не особо щепетильный в юридических вопросах объединил в одну библиотеку фрагменты кода из источников, выпущенных под разными лицензиями. Либо же, не заморачиваясь, изменил вид лицензии — скажем, с GPL на MIT.

Во всех случаях вы будете нести ответственность за юридическую чистоту использованного вами открытого кода, причём вне зависимости от того, знали ли вы о нарушении чужих авторских прав или нет.

Занятный казус из судебной практики. Один российский программист предложил бывшему работодателю заключить лицензионное соглашение, которое позволяло бы использовать созданную им программу на условиях простой неисключительной лицензии с сохранением за ним авторских прав и ограничением коммерческого использования.

Через некоторое время он обнаружил, что из строки кода исчез знак охраны авторского права. Айтишник подал в суд, потребовав восстановления своих прав и компенсации за их нарушения. Причём не только от бывшего работодателя, но и от администратора домена, разместившего спорную программу.

Суд первой инстанции вынес решение в его пользу. Однако после апелляции его отменили: выяснилось, что и сам автор нарушил условия использования программных библиотек по GPL-лицензии, так что разработанная им программа — по сути, производная и никаких особых прав на неё он не имеет.

Уровни безопасности

В настоящий момент выделяют семь уровней безопасности. EAL1-EAL4 уровни
являются общими, для всех стран поддерживающих стандарт.  Высшие уровни
EAL5-EAL7 индивидуально принимаются каждой страной для учёта национальных
особенностей защиты государственных секретов. Каждый уровень может получить
приставку «+» (например, EAL4+), что означает постоянный выпуск обновлений для
сертифицированного продукта.

EAL1 – требования к безопасности существуют, но уровень подразумевает
почти полное отсутствие угроз со стороны внешней среды. Проверка осуществляется
«формально», никакие «тестовые лаборанты» в код не заглядывают.

EAL2 – уровень безопасности предоставляет пользователям полную
информацию об архитектуре ПО. Однако и в этом случае проверка касается лишь
огромного количества документации, описывающей процесс работы программного
обеспечения.

Пример достижения:
JBoss Enterprise Application Platform – интегрированная платформа для
разработки Java-приложений,
Symantec Endpoint Protection 11.0 – базовая система защиты

EAL3 – софт проходит проверку на наличие типичных уязвимостей в
тестовой лаборатории, соответствующей стандарту Common Criteria.

Пример достижения:SuSE Linux
Enterprise Server.

EAL4 – наиболее полно описанный и стандартизированный уровень
«де-факто» для операционных систем. Поиск всех возможных уязвимостей с
дальнейшей процедурой их устранения. Пример достижения: Windows (2000-2008
Server, все версии),
Hewlett-Packard HP-UX, IBM
AIX и
Trusted Solaris – основанная на Solaris операционная система с
гарантированной безопасностью (используется модель принудительного контроля
доступа) компании Sun Microsystems.

EAL5-EAL7 – система проверена всеми возможными математическими
методами; узкоспециализированные стандарты, основанные на критериях безопасности
конкретных стран-участников.

Пример достижения:Integrity-178B
уровня EAL6+ — военная операционная система (использовалась в ВВС для управления
автоматикой новейших истребителей, а также в космических челноках NASA), первая
в мире получившая столь высокий рейтинг.

Совместная работа над требованиями безопасности, архитектурой и принципами разработки

Команды разработки и infosec должны работать вместе над безопасностью в гибком процессе разработки, даже ранее, чем начнется непосредственно написание кода. В отчете State of DevOps, публикуемом Puppet, CircleCI и Splunk, авторы определили несколько передовых методов для совместной работы команд разработки и infosec:

• Эти команды должны работать над моделями угроз.
• Функциональные и нефункциональные требования безопасности должны быть включены в список задач с высоким приоритетом.
• Требования безопасности надо рассматривать как архитектурные ограничения.

Гибкие команды разработки могут применить эти методы, выставляя более высокие требования к рискам и реализациям безопасности при анализе уязвимостей. Разработчики должны сотрудничать с infosec при работе над требованиями, архитектурой, дизайном и реализацией частей приложения, обрабатывающих пользовательские данные, управление авторизацией, другие чувствительные данные.

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

Гибкие разработчики должны также учитывать принципы основ безопасности от OWASP, включающих несколько передовых методов:

• Установка по умолчанию политик, основанных на безопасности, в различных областях, например, срок действия пароля.
• Реализация принципа минимальных привилегий при определении ролей и предоставлении доступа к бизнес-процессам.
• Понимание принципов безопасности, например, разделение задач, «недоверенные» сервисы, минимизация поверхности атаки, недопущение безопасности через неясность.
• Быстрое исправление проблем безопасности после понимания ключевых причин, реализация целостных исправлений.

Ну и наконец, команды разработки и infosec должны совместно установить описание передовых методов при написании кода. Здесь можно использовать передовые методы используемых языков программирования и платформ, включая методы Университета Карнеги Меллон, Университета Мичигана.

Если вы производите развертывание в публичные облака, потребуется также изучить передовые методы, к примеру, от AWS, Azure, Google Cloud

Собираем все вместе —- «DevSecOps»

На основе вышеизложенного должно быть очевидно, что напрашивается объединение подходов «инфраструктура как код» и «безопасность как код». Как показано на рисунке ниже, эти практики естественным образом сливаются для гармоничного взаимодействия между различными ролями и используемыми системами.

Можно выделить несколько фундаментальных принципов DevSecOps:

• Обеспечьте гибкость и скорость, инвестируя в hardened-инструменты, охватывающие весь жизненный цикл приложений и ресурсов: разработка-тестирование-развертывание-мониторинг.

• Подвергайте все сомнению, обеспечивая прозрачность на каждом этапе CI / CD-конвейера.

• Сделайте безопасность фундаментальным и безусловным критерием приемки на раннем этапе процесса разработки. Другими словами, «сдвиньте безопасность влево».

  

  

  

  

  

  

  

  

  

• Относитесь ко всему с подозрением, включая код, конфигурацию, артефакты, инфраструктуру, и установите оценку безопасности в качестве требования для продвижения по конвейеру.

• Как можно чаще прогоняйте приложение через Dev, QA, Staging и Production.

• И, наконец, автоматизируйте, автоматизируйте и автоматизируйте.

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

Кто должен отвечать за безопасность open-source

Это один из вопросов, который отличает открытое ПО от проприетарного. Фактически, ответственность не закреплена ни за кем. Формально, если говорить о популярных продуктах, вокруг которых уже сформировалось достаточно развитое комьюнити, можно говорить о коллективной ответственности. Для такой модели характерен высокий уровень доверия как одного пользователя к другому, так и пользователей к авторам.

Однако, на данном этапе развития Open Source такой концепт работает на практике далеко не везде. Учитывая тот факт, что открытый код, по данным Red Hat, используется в бизнесе все чаще, вопрос его проверки и анализа становится еще более актуальным.

Важную роль играет зрелость Open Source как концепции. Согласно исследованию Linux Foundation, разработчики ОПО уделяют безопасности своего продукта примерно 3% от времени, которое тратится на разработку. В таких условиях безопасность продукта становится вопросом, который пользователю предстоит решать самостоятельно.

Поскольку далеко не у каждой компании есть достаточное количество свободных и компетентных в вопросах безопасности сотрудников, набирает обороты тренд на делегирование аудита безопасности open-source сторонним, экспертным компаниям.

Это позволяет обеспечить высокий уровень проведения аудита, в рамках которого могут применяться и автоматизированные системы поиска уязвимостей. Весомый плюс работы с профильной компанией – это появление контрагента, который ответственен за результат.

Андрей Рыжкин и Алексей Клинов из AGIMA — о том, как и зачем контролировать безопасность приложений в заказной разработке

• Персональные данные сотрудников и клиентов.
• Данные доступа в банк-клиент.
• Данные о клиентах компании.
• Производственные чертежи.
• Проектная документация.
• И др.

Как организовать процесс тестирования на уязвимости?

• Полная интеграция в процессе разработки CI/CD.
• Ревизия безопасности на контрольных точках.
• Ситуационная или разовая ревизия безопасности.

• Сокращение репутационных рисков как для разработчика, так и для заказчика.
• Снижение стоимости устранения уязвимостей в процессе эксплуатации приложения.
• Уменьшение количества независимых проверок приложения на безопасность.

В заключение

Ричард Столлман:

Евангелист свободного программного обеспечения и основатель проекта GNU

Фундаментальный принцип Open Source ПО – свобода доступа, свобода использования. И этот фундаментальный принцип сегодня подвергается серьезным испытаниям. Популярные репозитории, на которых размещается исходный код – Github и Gitlab – находятся в правовом поле США.

Масштабных изменений пока не последовало, а российский сегмент Интернета пока не изолировали, мы все еще имеем доступ к Open Source репозиториям. Но аккаунты некоторых пользователей из России уже заблокировали. А в код на публичных репозиториях внедряли некоторые адресные закладки. Это увеличивает риски использования «импортных» Open Source-продуктов для бизнес-критичных решений и промышленных процессов.