Объясним цепь поставок на примере. Если Боб хочет смастерить кукольный домик для своих внуков, он может купить изготовленный на фабрике набор. Фабрике требуются древесина, бумага, краска, клей, машины для резки, люди для управления и обслуживания техники, а также энергия для ее питания. Древесину фабрика заказывает у лесозаготовительной компании, вырубающей деревья в лесу. Компания владеет этим лесом либо имеет лицензионный доступ на вырубку в нем. Бумага, краска и клей, скорее всего, производятся на разных заводах. Возможно, люди работают непосредственно на фабрике или являются временными подрядчиками. Энергия, скорее всего, поступает от энергетической компании, но нельзя исключать использование альтернативных источников (солнце или ветер) или генератора в случае чрезвычайной ситуации. На рис. 1.6 показана (гипотетическая) цепь поставок для приобретенного Бобом набора, из которого он сделает кукольный домик для внуков на Рождество.

Рис. 1.6. Вероятная цепь поставок для кукольного домика Боба

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

При разработке программного обеспечения мы также используем цепь поставок: платформу – для написания кода, библиотеки – для записи на экране, выполнения сложных математических вычислений или отрисовки кнопки, интерфейсы программирования приложений (API) – для выполнения действий от имени приложений и т. д. Более того, каждый из этих фрагментов программного обеспечения обычно зависит от других фрагментов, и все они чаще всего поддерживаются различными группами, компаниями или людьми. Как правило, современные приложения на 20–40 % состоят из оригинального кода[3] (того, что написали вы и ваши коллеги), в остальном – из сторонних компонентов, часто называемых зависимостями. При подключении зависимостей к приложению вы принимаете на себя риски кода, который они содержат. Например, если вы добавите в приложение модуль для обработки изображений, вместо того чтобы самому написать часть соответствующего кода, и в этом модуле будет серьезный недостаток безопасности, то уязвимость приложения тоже значительно повысится.

Однако нельзя утверждать, что необходимо писать каждую строчку кода самостоятельно: такое решение крайне неэффективно, а вероятность допущения ошибок, приводящих к проблемам безопасности, все равно высока. Один из способов снизить риск – использовать меньше зависимостей и тщательно проверять те, которые вы решили включить в свое программное обеспечение. Многие инструменты (некоторые из них даже бесплатные) могут проверить наличие каких-либо известных проблем безопасности в используемых вами зависимостях. Их следует применять не только при каждом запуске нового кода, но и для регулярной проверки вашего репозитория кода.

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

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

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

Другим примером «безопасности через неясность» является использование беспроводного маршрутизатора, скрывающего имя SSID/Wi-Fi (то есть при подключении к сети необходимо вручную указать ее имя), или размещение веб-сервера без доменного имени в надежде, что никто его не найдет. Существуют инструменты для обхода данных мер, но риск атаки на беспроводной маршрутизатор или веб-сервер снижается.

Существует обратная концепция – «безопасность через открытость», которая подразумевает, что за программным обеспечением с открытым исходным кодом наблюдает больше глаз, а значит, эти глаза найдут уязвимости в безопасности и сообщат о них. На практике исследователи безопасности редко просматривают открытый код и сообщают об ошибках бесплатно. В проектах с открытым исходным кодом разработчики не всегда устраняют выявленные недостатки безопасности, а если уязвимости найдены, нашедший может решить продать их на черном рынке (преступникам, собственному либо иностранному правительству и т. д.), вместо того чтобы сообщить о них владельцу репозитория кода надежным способом.

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

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