По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
NoSQL СУБД, или нереляционные базы данных, обладают уникальными возможностями, которые компенсируют ограничения моделей реляционных баз. Нереляционные СУБД – это общее название для 4 основных подгрупп:
базы данных типа «ключ-значение»
колоночные базы данных
графовые базы данных
документные базы данных
В этой статье мы расскажем о том, что такое документная база данных, опишем ее плюсы и минусы, а также рассмотрим примеры.
Документная база данных
Документная (или документоориентированная) база данных – это тип нереляционных СУБД, который хранит данные не в столбцах и строках, а в виде документов JSON. JSON является нативным языком, используемым для хранения и запросов данных. Такие документы можно сгруппировать в коллекции, которые образуют системы баз данных.
Каждый документ состоит из нескольких пар «ключ-значение». Ниже приведен пример документа из 4 пар «ключ-значение»:
{
"ID" : "001",
"Book" : "Java: The Complete Reference",
"Genre" : "Reference work",
"Author" : "Herbert Schildt",
}
JSON позволяет разработчикам приложений хранить и запрашивать данные в том же формате документной модели, который используется ими для структурирования кода приложений. Объектную модель можно преобразовать в такие форматы, как JSON, BSON и XML.
Сравнение реляционной и документной базы данных
Реляционная система управления базами данных (РСУБД) основана на языке структурированных запросов (SQL). Для нереляционных баз они не нужны.
РСУБД занимается созданием связей между файлами для хранения и считывания данных. Документные базы данных ориентированы на сами данные, а связи между ними представлены в виде вложенных данных.
Ключевое сравнение реляционных и документных баз данных:
РСУБД
Система документных баз данных
Выстроена вокруг концепции о связях
Сосредоточена на данных, а не связях
Структурирует данные в кортежи (или строки)
Вместо строк в документах имеются свойства без теоретических определений.
Определяет данные (образует связи) через ограничения и внешние ключи (например, дочерняя таблица ссылается на основную таблицу через ее идентификатор).
Для определения схем не нужен язык DDL.
Для создания связей использует язык DDL (язык описания данных).
Вместо внешних ключей связи реализованы через вложенные данные (в одном документе могут содержаться другие, вложенные в него, документы, из-за чего между двумя сущностями документов формируется связь 1 ко многим (или многие к одному)).
Обеспечивает исключительную согласованность. В некоторых случаях она просто необходима (например, ежедневные банковские операции).
Обеспечивает согласованность в конечном счете (с периодом несогласованности).
Особенности документной базы данных
Документные базы данных обеспечивают быстрые запросы, структуру, которая отлично подходит для обработки больших данных, гибкое индексирование и упрощенный принцип поддержания баз данных. Такая СУБД эффективна для веб-приложений и была полностью интегрирована крупными ИТ-компаниями уровня Amazon.
Несмотря на то, что базы данных SQL могут похвастаться отличной стабильность и вертикальной структурой, им свойственна «тяжеловесность» данных. В сценариях использования, когда требуется моментальный доступ к данным (например, медицинские приложения), лучше выбирать документные базы данных. Так вы сможете легко запрашивать данные в той же модели документа, в которой писался код приложения.
Примеры использования документной базы данных
База данных «Книга»
Для создания баз данных «Книга» используются как реляционные, так и нереляционные СУБД, хотя и по-разному.
В реляционных СУБД связи между книгами и авторами выражаются через таблицы с идентификаторами ID: таблица Author (Автор) и таблица Books (Книги). Данная модель не допускает пустых значений, поэтому за каждым «Автором» должна быть закреплена как минимум одна запись в таблице «Книги».
В документной модели вы можете вкладывать данные. Такая модель показывает взаимосвязи проще и естественнее: в каждом документе с авторами есть свойство Books с массивом связанных документов «Книги». При поиске по автору отображается вся коллекция книг.
Управление содержимым
Разработчики пользуются документными базами данных для создания блогов, платформ с потоковыми видео и аналогичных сервисов. Каждый файл сохраняется в виде отдельного документа, и со временем, по мере разрастания сервиса, такую базу легче поддерживать. На значимые изменения в данных (как, например, изменения модели данных) не требуется простоя, поскольку им не нужно обновление схемы.
Каталоги
Когда дело касается хранения и чтения файлов каталога, документные базы данных оказываются в разы эффективнее реляционных СУБД. В каталогах могут храниться тысячи атрибутов, а документная база данных обеспечивает их быстрое считывание. В документных базах данных атрибуты, связанные с одним продуктом, хранятся в одном документе. Изменение атрибутов в одном из продуктов не влияет на другие документы.
Плюсы и минусы документной базы данных
Ниже представлены главные плюсы и минусы документной базы данных:
Плюсы документной БД
Минусы документной БД
Отсутствие схемы
Ограничения по проверке на согласованность
Быстрое создание и обслуживание
Проблемы с атомарностью
Отсутствие внешних ключей
Безопасность
Открытые форматы
Встроенное управление версиями
Плюсы
Отсутствие схемы. Нет ограничений по формату и структуре хранилищ данных. Это хорошо для сохранения существующих данных в больших объемах и разных структурных состояниях, особенно в непрерывно преобразующихся системах.
Быстрое создание и обслуживание. Как только вы создали документ, ему требуется лишь минимальная поддержка – она может оказаться не сложнее разового добавления вашего сложного объекта.
Отсутствие внешних ключей. Когда эта динамика связей отсутствует, документы становятся независимыми друг от друга.
Открытые форматы. Чистый процесс сборки, в котором для описания документов используется XML, JSON и другие производные.
Встроенное управление версиями. По мере того, как увеличивает размер ваших документов, повышается и их сложность. Управление версиями уменьшает количество конфликтов.
Минусы
Ограничения по проверке на согласованность. В примере с базой данных «Книга» можно искать книги по несуществующему автору. При поиске по коллекциям книг вы можете находить документы, не связанные с коллекцией авторов. Кроме того, в каждом списке для каждой книги может дублироваться информация об авторе. В некоторых случаях такая несогласованность не особо важна. Но при более высоких стандартах непротиворечивости РСУБД несогласованность серьезно снижает производительность баз данных.
Проблемы с атомарностью. Реляционные системы позволяют изменять данные из одного места без использования JOIN. Все новые запросы на чтение унаследуют изменения, внесенные в данные по одной команде (например, обновление или удаление строки). Для документных баз данных изменение, затрагивающее 2 коллекции, выполняется через 2 отдельных запроса (по одному на коллекцию). Это нарушает требования к атомарности.
Безопасность. Почти в половине современных веб-приложений отмечается активная утечка конфиденциальных данных. Поэтому владельцам нереляционных баз данных следует быть крайне внимательными к уязвимостям веб-приложения.
Лучшие документные базы данных
Amazon DocumentDB
Особенности:
совместимость с MongoDB;
полная управляемость;
высокая производительность с низкой задержкой запросов;
строгое соответствие требованиям и безопасность;
высокая доступность.
Как используется:
Вся команда разработки Amazon пользуется Amazon DocumentDB для повышения оперативности и продуктивности. Им нужны были вложенные индексы, агрегирование, ad-hoc запросы (запросы узкой специализации), а также полностью управляемый процесс.
BBC использует документные БД для запросов и хранения данных из нескольких потоков данных с компиляцией их в единый канал для клиентов. Они перешли на Amazon DocumentDB, чтобы получить полностью управляемы сервис с высокой доступностью, прочностью и резервным копированием по умолчанию.
Rappi выбрали Amazon DocumentDB для сокращения времени на написание кода, Dow Jones – для упрощения операций, а Samsung – для более гибкой обработки больших журналов.
MongoDB
Особенности:
ad-hoc запросы;
оптимизированное индексирование для запросов;
сегментирование;
балансировка нагрузки.
Как используется:
Forbes сократил время компоновки на 58%, получив прирост в 28% по количеству подписок, за счет более быстрого создания новых функций, более простого объединения и более качественной обработки разнообразных типов данных.
Toyota заметила, что разработчикам было проще работать с документными БД на больших скоростях за счет использования нативных JSON-документов. Больше времени тратилось на создание ценности бизнеса, а не на моделирование данных.
Cosmos DB
Особенности:
быстрое чтение в любом масштабе;
99,999% доступность;
полная управляемость;
NoSQL/Native Core API;
бессерверное, экономичное/мгновенное масштабирование.
Как используется:
Coca-Cola получает информацию за минуты, что способствует глобальному масштабированию. До перехода на Cosmos DB на это уходили часы.
ASOS искали распределенную базу данных, которая легко и гибко масштабируется для обслуживания 100+ миллионов розничных клиентов по всему миру.
ArangoDB
Особенности:
валидации схем;
разноплановое индексирование;
быстрые распределенные кластеры;
эффективность с большими наборами данных;
поддержка многих нереляционных моделей данных;
объединение моделей в единые запросы.
Как используется:
Оксфордский университет разработал онлайн-тестирование на сердечно-легочные заболевания, благодаря чему снизил посещаемость больниц и усовершенствовал результаты анализов.
FlightStats привел к единому стандарту разрозненную информацию о полетах (статус рейса, погодные условия, задержки в аэропорту, справочные данные), что позволило получить точные, прогнозирующие и аналитические результаты.
Couchbase Server
Особенность:
возможность управления глобальными развертываниями;
крайняя гибкость и адаптивность;
быстрота в крупных масштабах;
простые облачные интеграции.
Как используется:
BT использовал гибкую модель данных Couchbase для ускорения собственных возможностей по высокопроизводительной поставке контента, а также легкого масштабирования в моменты резкого повышения спроса.
eBay перешел от Oracle к более экономичному и функциональному решению (их документной системы/хранилища типа «ключ-значение»). Возросла доступность и производительность приложения, а разработчики могли пользоваться своим опытом в SQL для ускорения пайплайна CI/CD (конвейера сборки) через более гибкую схему.
CouchDB
Особенности:
графический интерфейс на базе браузера;
простейшие репликации;
аутентификация пользователя;
свойства ACID (Атомарность – Согласованность – Изолированность – Прочность).
Как используется:
Meebo (соцсеть) пользуется CouchDB для веб-интерфейса и его приложений.
The BBC выбрал CouchDB за платформы динамического контента
Как выбрать?
Структуру данных определяют важнейшие требования, предъявляемые к приложению. Вот несколько ключевых вопросов:
Вы будете больше читать или записывать? В случае, если вы чаще записываете данные, лучше подойдут реляционные системы, поскольку они позволяют избегать задвоений при обновлениях.
Насколько важна синхронизация? Благодаря стандартам ACID, реляционные системы справляются с этой задачей лучше.
Насколько сильно потребуется изменять вашу схему базы данных в будущем? Документные БД – это беспроигрышный вариант, если вы работаете с разнообразными данными в масштабе и ищете минимальной поддержки.
Нельзя сказать, что документная СУБД или SQL база лучше во всем. Правильный выбор зависит от вашего сценария использования. Принимая решение, подумайте, какие типы операций будут выполняться чаще всего.
Заключение
В данной статье мы объяснили особенности документной базы данных, поговорили о плюсах и минусах системы, а также рассмотрели сценарии использования. Кроме того, был приведен список лучших документных СУБД и рассказано, как компании из рейтинга Forbes 500 пользуются этими системами для повышения эффективности своей деятельности и процессов разработки.
На сегодняшний день проблемы информационной безопасности в мире приобретают всё большую актуальность. В СМИ часто можно наткнуться на новость об очередной успешной хакерской атаке, крупной утечке критичных данных или очередном вирусе-вымогателе, который срывает работу целых компаний. Даже если Вы человек далёкий от информационной безопасности и мира информационных технологий, то Вы всё равно наверняка слышали о вирусе “WannaCry”, уязвимостях “Spectre” и “Meltdown” и может быть даже о недавней атаке на устройства компании Cisco, которая ударила по крупным провайдерам и парализовала много сервисов и сетевых сегментов.
Однако, широкой огласке обычно подвергаются новости об атаках и уязвимостях, носящие массовый характер, направленных на наиболее распространенные инфраструктурные системы. Мы же хотим рассказать о том, как обстоит ситуация с информационной безопасностью в отдельной в отдельно взятой сфере - IP телефонии и решений VoIP. Разберём наиболее важные проблемы и тренды развития данного направления.
Проблемы информационной безопасности в VoIP
Если раньше, выбирая на чём строить офисную телефонию, заказчиков больше всего волновали вопросы стоимости и надёжности, то в связи с нынешним положением, вопросы защиты и безопасности всё чаще начинают преобладать. Хотя IP телефония имеет массу преимуществ по сравнению с системами традиционной телефонии, её намного легче взломать. В случае с традиционной системой PSTN злоумышленник должен получить физический доступ к среде передачи или системам, которые задействованы в обмене голосовой информацией. IP телефония – это прежде всего сеть с коммутацией пакетов, которые передаются на ряду с другими корпоративными сервисами – Интернетом, почтой и другими. Если эта сеть недостаточно защищена, то злоумышленнику даже не обязательно находиться в одной стране с системой IP телефонии, чтобы получить доступ к критичным данным, украсть их или модифицировать.
Вот почему необходимо обеспечивать многоуровневую защиту систем корпоративной IP телефонии. Недостаточно просто поставить стойкий пароль к интерфейсу управления. Это должен быть чёткий набор определённых мер, применяемых в комплексе – межсетевое экранирование, антивирусная защита, регулярные обновления программного обеспечения, шифрование передаваемых данных и другое.
Отдельно следует уделить внимание повышению осведомлённости своих сотрудников об атаках из разряда социальной инженерии. Одним из наиболее распространённых векторов атаки данного типа на сегодняшний день является “фишинг”. Суть его заключается в том, что злоумышленник рассылает “письма счастья” с вредоносными вложениями, в надежде на то, что человек откроет это вложение и тем самым, загрузит на свой компьютер вредонос. Защититься от таких атак можно сразу на нескольких уровнях:
Межсетевой экран, на котором адрес отправителя фишинговых писем должен быть заблокирован. Автоматизировать процесс получения актуального списка адресов активных отправителей для блокировки на МСЭ, можно с помощью решений Threat Intelligence. Существуют как платные решения от таких компаний как Anomali, ThreatConnect или EclecticIQ, так и OpenSource, например, YETI и MISP.
Решение для защиты почтового сервера, которое проверяет все письма на предмет подозрительных вложений, адреса отправителя, блокирует спам. Примерами таких решений является Kaspersky Security для почтовых серверов, AVG Email Server Edition для ME, McAfee Security for Email Servers. Кстати, в этом случае также можно автоматизировать процесс блокировки с помощью решений TI.
Антивирусное ПО для защиты оконечных устройств, которое заблокирует опасное вложение, если всё-таки вредонос сможет пролезть через МСЭ и почтовый сервер. Для этого подойдёт Kaspersky Endpoint Security, Norton, Trend Micro и другие.
Но если от фишинга можно защититься с помощью специализированных программ и аппаратных решений, то от следующих видов атак, основанной на социальной инженерии, защититься гораздо труднее. Возможно, Вы не знали, но помимо традиционного email “фишинга”, существует также и телефонный. Например, сотруднику Вашей компании на голосовую почту может прийти сообщение от “банка” о том, что кто-то пытался получить доступ к его счёту и что ему необходимо срочно перезвонить по оставленному номеру. Не трудно догадаться, что на другом конце провода, его будет ждать злоумышленник, который постарается сделать всё, чтобы втереться в доверие, украсть данные его счёта, чтобы в итоге похитить денежные средства.
Существует также телефонный “вишинг”. Этот тип атаки направлен на первую линию сотрудников, которые принимают все входящие звонки в Вашей компании. На общий номер поступает звонок от какой-нибудь известной организации или персоны, а дальше с помощью методов психологического давления, доверчивого сотрудника заставляют что-либо сделать. В самом лучшем случае, позвонивший будет агрессивно требовать соединить его с руководством компании, чтобы предложить какие-нибудь услуги, в самом худшем - выдать конфиденциальную или критически важную информацию. А что, если злоумышленник узнает каким банком обслуживается Ваша компания и позвонит бухгалтеру от лица “Вашего банка”? К такому тоже нужно быть готовым.
Защититься от подобного типа атак можно было бы с помощью некоего аналога Threat Intelligence для VoIP – списка телефонных номеров, с которых поступают “фишинговые” и “вишинговые” звонки, чтобы заблокировать их на АТС. Однако, такого решения пока нет, поэтому придётся просвещать сотрудников на тему безопасности.
Безопасность облачных систем
Сейчас уже сложно обозначить чёткие границы офисной сети. С распространением облачных решений, распределённых сетей VPN и всеобщей виртуализации, корпоративная сеть уже перестала иметь чёткую географическую привязку.
Аналогично обстоят дела и в сфере VoIP. Каждый крупный провайдер IP телефонии имеет в своем наборе услуг облачную АТС, которая настраивается в считанные минуты и способна обеспечить телефонией компанию любого размера и неважно где территориально она расположена. Облачная или виртуальная АТС – это очень удобное решение, которое привлекает заказчиков тем, что не надо держать лишние сервера в здании и обслуживать их. Вместо этого, можно просто арендовать необходимые серверные мощности или сервис телефонии. Однако, с точки зрения информационной безопасности, облачные АТС – это идеальная цель для хакерских атак. Потому что, как правило, аккаунты для доступа к настройкам АТС, находятся в открытом доступе. Если владелец аккаунта не озаботится созданием стойкого пароля, то он рискует оплатить немаленький счёт за телефонные разговоры злоумышленника или предоставить доступ к записям разговоров своих сотрудников. В этой связи при выборе провайдера следует также проверить обеспечивает ли он дополнительные мероприятия по защите целостности и конфиденциальности данных. Используется шифрование при подключении к аккаунту с настройками облачной АТС, шифруются ли данные при их транспортировке.
Тренды развития направления ИБ в VoIP
Наиболее распространённым методом защиты корпоративной инфраструктуры является организация защищённой сети VPN, когда подключение извне осуществляется по зашифрованному каналу, а данные внутри сети передаются в незашифрованном виде. Это относится и к голосовому трафику. Однако, тенденции развития информационных технологий указывают на то, что в недалёком будущем голосовая информация также будет подвергаться шифрованию. Большинство VoIP вендоров уже давно имплементируют в своих решениях поддержку таких протоколов как SIP/TLS, SRTP, ZRTP и д.р, стимулируя пользователей применять внедрять ещё один уровень защиты. Например, большинство IP-телефонов и решений видеоконференцсвязи от компании Cisco, а также системы CUCM, CUBE, Cisco SBC, UCCS и д.р поддерживают TLS 1.2 и SRTP. Самое распространённое Open Source решение IP-АТС Asterisk имеет поддержку защищённых протоколов передачи медиа трафика начиная с версии 1.8. В программной Windows-based АТС 3CX версии V15, поддержка SRTP включена по умолчанию.
VoIP решения зачастую очень тесно интегрируются с другими корпоративными системами, такими как CRM, ERP, CMS, не говоря уже о таких каналах бизнес коммуникаций как email, обмен мгновенными сообщениями (чат) и социальные сети, формируя в совокупности концепцию UC (Unified Communications). Потенциальные преимущества, которые несёт данная концепция очень привлекательны, но вместе с тем, создаётся множество точек уязвимых к возможному взлому. Недостаточный уровень защиты одной из них может быть угрозой всей корпоративной сети. Поэтому разработчики, несомненно, будут усиливать безопасность каналов интеграции данных систем.
Можно также ожидать интеграцию систем корпоративной телефонии в такие средства защиты как DLP (средства защиты от утечек), адаптации метрик VoIP в SIEM системах (система управления информацией и событиями безопасности), а также появление унифицированных репутационных баз (Threat Intelligence) со списками потенциально опасных номеров или других индикаторов компрометации, относящихся к VoIP, которые будут автоматически блокироваться имеющимися средствами защиты.
Недавно я просматривал некоторые общедоступные репозитории Google на их GitHub. И я заметил, что у них есть репозиторий для непрерывного фаззинга. Я понятия не имел, что такое фаззинг, не говоря уже о непрерывном.
Что же такое фаззинг?
Фаззинг (иногда его называют нечетким тестированием) – это способ автоматического тестирования программного обеспечения. Обычно фаззер вводит в программу большое количество неправильных или случайных входных данных. Таким образом пытаются вызвать сбои, ошибки, утечки памяти и т.д.
Обычно фаззинг лучше всего работает с программами, которые принимают входные данные, такие как веб-сайты, которые могут запрашивать ваше имя или возраст.
Можно попробовать вводить самые различные строки, чтобы попытаться вызвать какие-то проблемы, например, что-нибудь вроде такого: «Power?????????????????? ? ?h ? ??» (это когда-то вызвало аварийный сбой iOS), «??????h??e???????? ???????N??e??z?????p??????e????r????????d??????i??????a?????n?? ?????h??i??v?????-?????m???i????n???? ????????????f ????????c?????????a?????????s?.?? ?Z????????a?????l?????g????????o??.?», «?» или «undefined».
В целом идея фаззинга заключается в том, чтобы попытаться найти пограничные случаи в кодовой базе. Его используют для того, чтобы убедиться, что синтаксический анализ данных, их прием, сохранение и чтение не вызывают ошибок.
Это довольно полноценный тест, поскольку вы можете протестировать весь процесс хранения, например, пробела нулевой длины (U+200B в Юникоде) на своем сайте, чтобы проверить, возникнут ли какие-то проблемы.
Некоторые пытаются внедрить код в поля ввода (это часть фаззинга, которая называется «внедрение кода»), например, в качестве имени.
Злоумышленники не заинтересованы в том, чтобы вы тестировали нестандартный ввод, так как вы можете обнаружить ошибки, которые нарушают работу приложения, а они могли бы использовать их для кражи данных или повторного сбоя в вашем приложении/сервере.
На GitHub есть список под названием «Big List of Naughty Strings» («Большой список сомнительных строк»). Это список строк, которые с большей долей вероятности вызовут проблемы.
Вы можете взглянуть на некоторые в файлах .json и .txt и почитать некоторые комментарии, чтобы понять, почему именно эти строки вызывают проблемы.
Например, некоторые строки написаны вверх ногами «u?op?p?sd?». Есть строки, которые могут быть помечены как ненормативная лексика или как неприемлемые, но на самом деле они к этому не имеют никакого отношения (это называется проблемой Скантропа). И даже есть такие строки, которые могут раскрыть системные файлы, если они вдруг будут проанализированы плохо настроенным синтаксическим анализатором XML.
Кто использует фаззинг?
Как я уже говорил, фаззинг используется в процессе тестирования программного обеспечения для поиска ошибок в ваших программах. Но он также применяется в кибербезопасности и при взломах.
Что касается применения в кибербезопасности, то здесь хакеры пытаются пересечь границу доверия. Граница доверия – это место в компьютерных системах, где данные из доверенного источника передаются из одной области в другую.
В качестве примера давайте представим, что вы получаете имя пользователя в клиентской части, убеждаетесь, что оно является допустимым, а затем передаете его на серверную часть. Ваша граница доверия – это воображаемая линия, по которой данные передаются от клиента к серверу.
Если ваша серверная часть просто «доверяет» данным и не проверяет их (поскольку клиент уже проверил их!), то это может стать проблемой. В случае, если хакеры смогут пройти проверку клиента, они станут поставщиками доверенных входных данных и смогут попытаться вставить туда вредоносные строки.
Именно в этой ситуации фаззинг может посодействовать выборочной проверке, чтобы убедиться, что вы можете выявлять эти проблемы.
Допустим, кто-то должен был фаззить Google Chrome. Один из способов это сделать – запустить браузер в инструменте отладки для того, чтобы отслеживать команды, которые выполняет Chrome, и профилировать его управление памятью.
Позже хакеры направляют программу Chrome, за которой они наблюдают, на один из своих серверов. Их серверы создают миллионы различных веб-страниц, которые Chrome будет загружать. Все эти веб-страницы немного отличаются с точки зрения JS, CSS и HTML. Это нужно для того, чтобы попытаться сломать Chrome, который профилируют хакеры.
Эти хакеры могут осмысленно запускать эти автоматические тесты в течение нескольких месяцев, собирать огромный список журналов Chrome (сбои, любые переполнения памяти и т.д.) и пытаться выяснить, что вызвало сбой.
Просто заставить Chrome «рухнуть» не является их конечной целью. Как только эти хакеры узнают, какие входные данные вызывают сбои, они также могут выяснить, почему эти данные вызывают сбои, и проанализировать, могут ли они использовать эти эксплойты, чтобы исполнить свой зловещий план, или получить доступ к чему-то, к чему доступа у них не должно быть.
На сегодняшний день Google фаззит свои приложения на 30 000 виртуальных машинах! Таким образом, вы вряд ли добьетесь какого-либо успеха, поскольку они очень сильно постарались.
OSS-Fuzz от Google обнаружил более 25 000 ошибок в коде Google Chrome и примерно 22 000 ошибок в других общедоступных кодовых базах, которые используют OSS-Fuzz.
Итак, вернемся к основному заголовку. Кто использует фаззинг? Держу пари, что почти все компании, которые должны защищать свои цифровые активы или информацию, либо наймут тестировщиков для фаззинга своих продуктов, либо будут делать это самостоятельно.
Заключение
Я надеюсь, что эта статья помогла вам понять, что такое фаззинг и для чего он применяется.