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

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

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

Что такое цепочка поставок программного обеспечения?

Цепочка поставок программного обеспечения — это дисциплина, охватывающая команды (как внутренние, так и внешние), методологии, инструменты и лучшие практики для реализации программных артефактов от проектирования до развертывания.

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

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

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

Неадекватно разработанный код с жестко закодированными секретами и слабо спроектированной инфраструктурой подвержен частым атакам.

Самые популярные уязвимости

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

В какой-то момент последние новости об атаке на SolarWinds потрясли мир технологий. Мероприятие стало прекрасным примером опасностей неадекватных методов обеспечения безопасности.

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

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

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

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

В качестве еще одного примера того, как уязвимости могут повредить систему, давайте посмотрим на биткойны. Биткойны могут быть легко раскрыты и украдены, если поставщик услуг не соблюдает правила безопасности.

Copay, биткойн-кошелек, подвергся атаке на цепочку поставок, когда в мобильном приложении, в котором размещается биткойн-кошелек, была ошибка. Ошибка в архитектуре возникла из-за уязвимости пакета в диспетчере пакетов узлов инструментов Javascript с открытым исходным кодом (NPM). Эта версия с ошибками была обнародована и позволила хакеру изменить приложения, чтобы загрузить рефакторинговый код и получить доступ к библиотеке JS.

Ошибка могла быть обнаружена и устранена с помощью инструментов сканирования уязвимостей в конвейере управления версиями и развертывания.

Движущиеся части для управления цепочкой поставок программного обеспечения

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

Этап 1: Грамотность безопасного кодирования

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

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

Этап 2: Моделирование угроз

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

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

<?xml version="1.0" encoding="utf-8"?>
<KnowledgeBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <Manifest name="Basic threat modelling design" id="5d3b996b-bac2-8cf6-3b39-617bb67bf042" version="4.1.0.11" author="TwC MSEC" />
 <ThreatMetaData>
   <IsPriorityUsed>true</IsPriorityUsed>
   <IsStatusUsed>false</IsStatusUsed>
   <PropertiesMetaData>
     <ThreatMetaDatum>
       <Name>Title</Name>
       <Label>Title</Label>
       <HideFromUI>false</HideFromUI>
       <Values>
         <Value />
       </Values>
       <Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
       <AttributeType>0</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>UserThreatShortDescription</Name>
       <Label>Short Description</Label>
       <HideFromUI>true</HideFromUI>
       <Values>
         <Value>Threat modeling is critical and mandate phase in secure software development</Value>
       </Values>
       <Id>ac0f9ea8-aed5-4d95-4ce9-6787124d7b48</Id>
       <AttributeType>1</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>UserThreatDescription</Name>
       <Label>Description</Label>
       <HideFromUI>false</HideFromUI>
       <Values>
         <Value />
       </Values>
       <Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
       <AttributeType>0</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>Priority</Name>
       <Label>Priority</Label>
       <HideFromUI>true</HideFromUI>
       <Values>
         <Value>High</Value>
         <Value>Medium</Value>
         <Value>Low</Value>
       </Values>
       <Description>Priority</Description>
       <Id>ac0f9ea8-aed5-4d95-4ce9-617bb67bf042</Id>
       <AttributeType>1</AttributeType>
     </ThreatMetaDatum>
   </PropertiesMetaData>
 </ThreatMetaData>
 <GenericElements>
   <ElementType>
     <Name>Threat modeling Process</Name>
     <ID>GE.P</ID>
     <Description>General approach to define a threat model</Description>
     <ParentElement>ROOT</ParentElement>
     <Image>Image_ref</Image>
     <Hidden>false</Hidden>
     <Representation>Ellipse</Representation>
     <StrokeThickness>0</StrokeThickness>
     <ImageLocation>Centered</ImageLocation>
     <Attributes>
       <Attribute>
         <Id>002864b3-9a4e-4d21-8a4d-8aea1d2e3056</Id>
         <IsInherited>false</IsInherited>
         <IsOverrided>false</IsOverrided>
         <Name>codeType</Name>
         <DisplayName>Code Type</DisplayName>
         <Mode>Dynamic</Mode>
         <Type>List</Type>
         <Inheritance>Virtual</Inheritance>
         <AttributeValues>
           <Value>Not Selected</Value>
           <Value>Managed</Value>
           <Value>Unmanaged</Value>
         </AttributeValues>
       </Attribute>
     </Attributes>
   </ElementType>
 </StandardElements>
 </KnowledgeBase>

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

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

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

Этап 4. Сканирование с помощью автоматизированных инструментов

Автоматизация проверки кода перед слиянием с мастером имеет первостепенное значение. Невыполнение предопределенных проверок выявляет проблемы в коде и позволяет разработчикам использовать цикл обратной связи для рефакторинга и защиты всей кодовой базы.

WhiteSource для разработчиков, Codacy и Codecov — это автоматизированные инструменты проверки, доступные на торговой площадке GitHub для быстрой интеграции в вашу кодовую базу и выполнения требований технического стека. Эти инструменты используют подход сдвига влево для сканирования с открытым исходным кодом и индексации всех существующих репозиториев GitHub.

Этап 5: Статическое сканирование кода и тестирование безопасности

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

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

Пример кода:

trigger:
 branches:
   include:
   - feature
   - main
 paths:
   include:
   - src/*
   - tests/*

pool:
 Image: 'centos/latest'

jobs:
- job: codereview
 displayName: review and report

 steps:

 - checkout: self
   lfs: true

 - task: UsePythonVersion@0
   displayName: 'Set Python version to 3.9'
   inputs:
     versionSpec: '3.9'

 - script: pip3 install --user -r requirements.txt
   displayName: 'Installing required dependencies'

 - script: |
     python -m behave --junitxml=./validation_test-checks.xml
   displayName: 'Running behave tests'

 - task: PublishBehaveResults@1
   displayName: 'bumping out behave test results'
   condition: passOrFail()
   inputs:
     testResultsFiles: '**/validation_test-*.xml'
     testRunTitle: 'Publish behave test results for Python $(python.version)'

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

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

Из статей Infosec: Каждый день в Infosec появляется много информации, за которой трудно уследить. Подпишитесь на наш еженедельный информационный бюллетень , чтобы БЕСПЛАТНО получать все последние тенденции информационной безопасности в виде 5 статей, 4 тем, 3 видео, 2 репозиториев и инструментов GitHub и 1 оповещения о вакансиях!