Эта статья составлена г-ном Чжан Яном, директором отдела решений Jihu GitLab, который поделился темой «На волне всплеска кода и сопровождения программно-определяемых автомобилей» на конференции AUTOSEMO.
Проблемы программно-определяемых автомобилей
«Программное обеспечение пожирает мир», — сказал в 2011 году основатель Netscape Марк Андриссен. Быстрое развитие индустрии программного обеспечения в последние годы также подтвердило это утверждение. Смартфоны — очень яркий пример: различные приложения полностью изменили повседневные потребности людей.
В автомобильной промышленности также наступила эпоха программно-определяемых автомобилей. В сфере «умных» автомобилей затраты на программное обеспечение составляют все большую долю затрат на автомобили, а ценность, которую приносит программное обеспечение, меняет всю бизнес-модель «умных» автомобилей . Как показано на кривой улыбки ниже, на обоих концах всей цепочки автомобильной промышленности появляются более интересные бизнес-модели, которые могут принести пользу.
Возьмем типичный пример: систему подписки на программное обеспечение. В ранней модели продаж автомобилей покупка и продажа автомобилей осуществлялась в основном «разовой продажей». После продажи автомобиля OEM-производителю было трудно заработать деньги пользователя (за исключением некоторого возможного обслуживания). Однако в рамках модели подписки на программное обеспечение, если пользователь хочет использовать определенную функцию автомобиля (например, автономное вождение, дистанционный автоматический запуск и остановку кондиционера и т. д.), он может сделать это, подписавшись на автомобильное программное обеспечение. Месячная подписка дает вам возможность пользоваться ею в течение одного месяца. Если вы больше не хотите его использовать, просто отмените подписку. Преимущество этого в том, что пользователи имеют право свободного выбора и могут «настраивать» некоторые функции автомобиля с помощью программного обеспечения под свои нужды.ОЕМ-производители таким образом не только повышают привязанность к пользователям, но и добавляют дополнительную функцию. это позволяет им найти способы для компаний продолжать увеличивать доходы.
Программное обеспечение определяет автомобили, так что же определяет программное обеспечение? Ответ: код. Основой запуска программного обеспечения является код, а в контексте программно-определяемых автомобилей, по статистике профессиональных организаций: умный автомобиль имеет около 100 миллионов строк кода, что значительно больше, чем у больших пассажирских самолетов (около 15 миллионов строк). и истребители (около 25 миллионов строк) и объем кода некоторых известных операционных систем (например, Windows Vista, около 40 миллионов строк). И это данные на 2020 год. С бурным развитием умного вождения эти данные могут достичь ошеломляющих 500 миллионов в 2025 году .
Кроме того, как видно из рисунка ниже, при традиционной модели разработки программного обеспечения количество дефектов (включая проблемы качества и безопасности), возникающих на этапе кодирования, является самым большим (85%), но реальное обнаружение большого количество дефектов находится на стадии посткодирования.Эта ситуация порождает две проблемы:
-
Устранение дефектов задерживается, а обратная связь по проблемам происходит медленно, что приводит к относительно длительному циклу ремонта;
-
Стоимость ремонта высокая. Как видно из рисунка, стоимость исправления дефектов, допущенных на этапе кодирования, самая низкая, а стоимость ремонта дефектов, обнаруженных во время работы программного обеспечения, чрезвычайно высока, примерно в 640 раз выше, чем на этапе кодирования.
Эта ситуация еще более серьезна для автомобильного программного обеспечения, а с развитием интеллектуальных автомобилей проблемы, возникающие из-за резкого увеличения объема кода, огромны. Это проблема для OEM-производителей, уровня 1 или тех, кто занимается программным обеспечением в рамках всего автомобильного программного обеспечения. экосистема.Это одинаково для всех организаций.
Как справиться с проблемой взрыва кода
Программное обеспечение в автомобильной промышленности отличается от программного обеспечения в общей отрасли. В некоторых случаях скорость доставки может быть немного медленнее, а стоимость немного выше, но безопасность — это красная линия, которую нельзя ставить под угрозу. « Программное обеспечение можно перезапустить, но жизнь нельзя перезапустить .» Безопасность — самая большая проблема, которую распространение кодов создает для автомобильного программного обеспечения.
Как обеспечить безопасность программного обеспечения?
Сначала приведем два примера. Первый - самолет Boeing 737 Max. Как мы все знаем, самолет 737 Max ранее уже участвовал в двух авариях. Позже появились предположения, что авария может быть связана с программным обеспечением на самолете, которое предотвращает сваливание самолета и теряя контроль. Из-за этой проблемы большое количество самолетов 737 Max было приостановлено, а многие подтвержденные заказы были отменены. Если бы подобное произошло в автомобильной промышленности, ни одна автомобильная компания не смогла бы выдержать отзыв, приостановку или даже приостановку продаж из-за проблем с программным обеспечением автомобиля. А когда затрагивается такая тема, как личная безопасность, влияние общественного мнения может оказаться разрушительным для автомобильных компаний.
Второе — это событие уязвимости log4j «эпической уязвимости». log4j — это компонент с открытым исходным кодом, который используют пользователи по всему миру, поэтому, когда была обнаружена уязвимость, она затронула многих пользователей по всему миру. На самом деле это типичная проблема безопасности цепочки поставок программного обеспечения с открытым исходным кодом.
Чтобы справиться с проблемами, связанными с функциональной безопасностью и информационной безопасностью, в области исследований и разработок автомобильного программного обеспечения или в области безопасности существует множество стандартов или спецификаций, таких как ISO 26262, MISRA, AUTOSAR, OWASP Top10 и CWE Top 25. С помощью этих стандартов или спецификаций повышается качество и безопасность автомобильного программного обеспечения.
Кроме того, следует отметить еще один момент, который представляет собой новую концепцию с наступлением эры программно-определяемых автомобилей — СБОМ. SBOM — это спецификация программного обеспечения, список компонентов программного обеспечения. Основной проблемой, которой занимается SBOM, является безопасность цепочки поставок программного обеспечения с открытым исходным кодом . При нынешнем росте уровня внедрения открытого исходного кода немногие компании создают все системы с нуля.Они в основном используют некоторые платформы или библиотеки с открытым исходным кодом для ускорения создания своих собственных продуктов. Возникает вопрос: как обеспечить соответствие безопасности используемых или упоминаемых компонентов с открытым исходным кодом? Если используемые компоненты с открытым исходным кодом содержат какой-либо вредоносный код или даже некоторые уязвимости высокого риска, риски будут велики. SBOM очень хорошо решает вышеуказанные проблемы, проводя инвентаризацию корпоративных цифровых активов.
SBOM также решает еще одну проблему: соблюдение лицензий. У Jihu GitLab много клиентов автомобильных компаний, и их бизнес необходимо экспортировать за границу. Если во время этого процесса игнорировать вопрос о соответствии лицензии на программное обеспечение, это может привести к блокировке зарубежного бизнеса. Например, программное обеспечение автомобильной компании содержит некоторое программное обеспечение, которое содержит "сильное заражение". "сексуальная" лицензия (например, GPL), но исходный код не открыт. В настоящее время это фактически нарушает некоторые лицензионные особенности этих лицензий. Они не разрешены в стране и за рубежом, а также в зарубежных странах. также сталкиваются с глобализацией.Конкуренция и связанные с ней правила очень строгие.
Китайским компаниям нелегко вести бизнес за границей.Многие друзья по всему миру ищут возможности для своих оппонентов совершить ошибки.Соблюдение лицензий - очень простое звено в области программного обеспечения.Если у компании возникают проблемы с безопасностью из-за соблюдения лицензий, Выход предприятий за границу неизбежно приведет к невосполнимым потерям и серьезным последствиям.
Возвращаясь к ответу на проблемы обеспечения безопасности, вызванные распространением кода, можно отметить три основных решения на уровне кода.
Первая часть — тестирование покрытия кода, которое подпадает под категорию модульного тестирования. Модульное тестирование — лучший способ проверить, правильно ли работает каждая часть кода (классы, функции, условия и т. д.) с точки зрения «белого ящика». Это также важный способ выявления проблем программного обеспечения на ранних стадиях разработки программного обеспечения. разработка. Однако его недостатки также очевидны, поскольку для написания этих тестовых кодов также требуется технический персонал, что предполагает вложение ресурсов. Однако благодаря постоянным исследованиям и развитию AIGC в области программного обеспечения интеллектуальная генерация кода модульных тестов не является фантазией и в конечном итоге будет реализована в ближайшем будущем. Следует отметить, что при модульном тестировании необходимо учитывать количество, то есть некоторый охват функций в коде, и качество, то есть охват условных ветвей.
Вторая часть — статический анализ кода . Эта часть не требует от R&D выполнения множества вещей, им нужно лишь настроить соответствующие инструменты или процессы для проверки кода. Проверка в основном состоит из двух частей: проверка стандартов кодирования и проверка безопасности кода. Стандарты кодирования призваны улучшить удобство сопровождения кода и облегчить непрерывную итеративную эволюцию программного обеспечения. Проверка безопасности кода может использовать SAST для сканирования, чтобы выявить потенциальные проблемы безопасности в коде;
Третья часть — это упомянутый ранее SBOM. Используйте список SBOM для анализа некоторой информации об уязвимостях и информации о лицензии сторонних компонентов.
Содержимое этих трех частей может быть реализовано на этапах кодирования и создания жизненного цикла программного обеспечения, эффективно помогая команде исследований и разработок решать проблемы, связанные с безопасностью и качеством программного обеспечения, как можно раньше. Это концепция изменения безопасности, оставленная в системе DevSecOps, о которой мы часто упоминаем .
Так называемый сдвиг безопасности влево означает, что безопасность начинает вмешиваться на ранних стадиях жизненного цикла разработки программного обеспечения. Например, на этапе кодирования или даже на более ранней стадии проектирования, соответствующие меры безопасности включаются. это: проблемы безопасности. Раннее обнаружение, ранний ремонт и минимальные затраты. Так как же реализовать DevSecops?
Основные моменты безопасного движения влево при приземлении
Первое — это изменение философии . Будь то DevOps или DevSecOps, основная идея — разрушить барьеры между различными ролями. Это полностью отличается от каскадной модели (НИОКР → Тестирование → Безопасность → Эксплуатация и обслуживание). Модель DevSecOps требует некоторых инициатив, чтобы разрушить стены между функциональными ролями и позволить всему персоналу служить единой цели.
Например, для сотрудников НИОКР, если после написания и отправки кода обнаружена уязвимость безопасности, уязвимость безопасности необходимо устранить; для сотрудников службы безопасности необходимо настроить контроль доступа и уточнить управление этими проблемами безопасности. например, «Не все обнаруженные проблемы необходимо устранять немедленно», «Все ли проблемы безопасности необходимо устранять» и т. д., а также возможность общаться с персоналом, занимающимся исследованиями и разработками, чтобы помочь им выполнить некоторые исправления или улучшения уязвимостей; для менеджеров, по сути, это точка зрения Бога, которая требует общего понимания выпускаемого автомобильного программного обеспечения, а также его качества и безопасности. Таким образом, с концептуальной точки зрения реализация DevSecOps на самом деле требует объединения этих ролей, и все сотрудничают, чтобы хорошо выполнять свою работу в области безопасности .
Конечно, для достижения хорошего сотрудничества между несколькими ролями одного управления недостаточно. Иными словами, нам нужно использовать инструменты для построения сборочной линии цифрового мира. Например, конечным продуктом линии сборки деталей является автомобиль, затем конечным продуктом линии сборки кода является программное обеспечение, а линия сборки кода — это то, о чем сейчас все часто говорят как о CI/CD. Таким образом, в будущем автомобильные компании будут иметь две производственные линии: первая будет находиться в физическом мире или промышленном мире и будет использоваться для производства комплектных автомобилей, а вторая будет представлять собой линию сборки программного обеспечения, используемую для создания программного обеспечения, необходимого для работы предприятия. .
Этот программный конвейер требует инструментов для его реализации. Это означает использование инструментов для создания конвейера с замкнутым циклом.
Суть в том, что после того, как разработчики отправят код, они должны иметь возможность автоматически компилировать и собирать код, тестировать, проверять безопасность и т. д. Все эти операции в высокой степени автоматизированы и не требуют слишком большого вмешательства человека. После завершения всех автоматизированных шагов сотрудники отдела исследований и разработок, тестирования, безопасности и другой персонал могут найти некоторые отчеты о безопасности и качестве на уровне кода, уровня приложения или полученные из различных сред, а затем продолжить итерацию на основе сообщенных данных. который образует полный замкнутый контур трубопровода.
После уточнения понятий, методов и инструментов остальное реализуется.
Путь реализации безопасного сдвига влево
Практика реализации безопасного смещения влево в основном состоит из трех этапов:
➤ Шаг первый: закрепить корпоративные спецификации НИОКР
Спецификации корпоративных исследований и разработок должны учитывать не только качество кодирования, но и безопасность. Например, после того как сотрудники отдела исследований и разработок завершат локальную разработку, им необходимо отправить измененный код в базу данных. Какие условия должны быть выполнены, прежде чем измененный код может быть включен в базу данных? Например, ASPICE может обеспечить двустороннюю отслеживаемость требований и кода. Тогда компании могут потребовать от сотрудников отдела исследований и разработок установить однозначное соответствие между изменениями кода и идентификаторами требований при отправке кода. Кроме того, некоторые файлы, содержащие ключевую информацию, не должны быть Его следует перенести в базу кода, а также существуют другие спецификации управления ветвями, которым необходимо следовать.
Есть "доступ к коду", и есть соответствующий "доступ к коду". Так называемый "доступ к коду" относится к тем стандартам, которым должен соответствовать код, разработанный сотрудниками НИОКР, при его объединении с основной веткой, что предполагает проверку кода. ., что является «полем ответственности кода», уважаемым в отрасли. Этот процесс должен быть безопасным, и тестировщики могут вместе просматривать измененный код. Это можно сделать, просматривая результаты сборки CI/CD и отчеты о данных измененного кода. В конечном итоге необходимо гарантировать, что если результаты сборки CI/CD сбой или отчеты о данных. Это показывает, что измененный код имеет серьезные проблемы с качеством или безопасностью, тогда код не следует объединять, и пока код можно объединить, его можно напрямую разместить в сети.
➤ Шаг 2. Непрерывная интеграция
Непрерывная интеграция означает автоматизацию всего модульного тестирования, сканирования качества и сканирования безопасности, упомянутых ранее. Для пользы всей команды требуется только одна ручная настройка. Этот процесс не имеет ничего общего с языками программирования и подходит для автомобильных или облачных приложений, просто необходимо использовать автоматизированные средства для объединения соответствующих процессов.
➤ Шаг 3. Эффективная проверка кода
Если вы хотите решить больше проблем с безопасностью или качеством на этапе разработки, важным средством является проверка кода. Эта проверка кода состоит из двух частей. Первая часть должна быть основана на некоторых отчетах о данных, созданных на втором этапе непрерывной интеграции, чтобы судить о том, соответствует ли измененный код собственным стандартам исследований и разработок компании, и эти стандарты должны быть способны пройти проверку на заказ. правила на инструменте. Чтобы добиться практической реализации и, наконец, хорошо выполнить работу по проверке кода, включив в систему проверки всех людей, связанных с качеством и безопасностью кода; вторая часть — это проверка вручную, которая заключается в обнаружении проблем в коде. невооруженным глазом. Конечно, Jihu GitLab в настоящее время также активно изучает возможность использования AIGC для реализации автоматической проверки кода, такой как оценка измененных кодов, указание на проблемы в коде, предоставление предлагаемых кодов и т. д.
Jihu GitLab интегрировал решение DevSecOps
Внедрение DevSecOps невозможно осуществить с помощью одного или двух инструментов, поскольку в системе DevSecOps есть три роли, которые должны работать вместе: сотрудники отдела исследований и разработок, службы безопасности и управленческого персонала. Перспективы этих трех ролей различны: сотрудники исследований и разработок в основном пишут код, сотрудники службы безопасности в основном решают вопросы безопасности, а менеджеры несут большую ответственность за общее управление. Но одна общая точка соприкосновения среди этих трех — это запрос на слияние кода, который является частью левой части рисунка ниже: Когда измененный код необходимо объединить, измененный код должен быть проверен. Только в этом процессе все роли могут быть согласованы. , поэтому каждая компания должна внедрять проверку кода в процесс разработки программного обеспечения.
Следует отметить, что этот процесс также порождает новые проблемы: сложность цепочки инструментов . Исследования и разработки, тестирование, эксплуатация и обслуживание, менеджеры проектов и т. д. — все имеют свои собственные инструменты, и в результате между этими инструментами возникает серьезная фрагментация. Jihu GitLab сама по себе представляет собой интегрированную платформу DevSecOps, которая позволяет менеджерам проектов, специалистам по исследованиям и разработкам, тестированию, эксплуатации и техническому обслуживанию сотрудничать на платформе с унифицированным интерактивным интерфейсом. Возможности, предоставляемые десятью интегрированными функциями, могут охватывать весь процесс общей разработки программного обеспечения.
Эта интегрированная платформа DevSecOps имеет четыре основных преимущества: целостность, единообразие, высокая производительность и масштабируемость.
честность
Под целостностью понимаются 7 типов сканирования безопасности, встроенных в GitLab, которые могут охватывать весь жизненный цикл разработки программного обеспечения. И одна вещь, которая требует специального пояснения, заключается в том, что когда необходимо использовать определенную функцию безопасности, необходимы всего две строки кода для добавления сканирования безопасности в конвейер CI/CD, который в основном доступен из коробки.
единство
Единообразие означает, что сотрудники отдела исследований и разработок, службы безопасности или управления имеют соответствующие информационные панели безопасности для просмотра отчетов о данных, связанных с безопасностью.
высокая производительность
Jihu GitLab может параллельно выполнять сканирование нескольких методов защиты, что может значительно повысить эффективность сканирования безопасности.
Масштабируемый
Масштабируемость — очень важный момент. Хотя GitLab сам по себе имеет множество встроенных возможностей безопасности, зачастую у клиентов есть некоторые инструменты безопасности, которые они используют. В настоящее время мы можем использовать командную строку или API для интеграции этих инструментов в JiHu GitLab CI. /CD, и пока выходные данные этих инструментов имеют формат JSON, соответствующий требованиям JiHu GitLab, данные можно визуализировать, встраивать в MR или отображать на информационной панели. Это еще одна ценность Jihu GitLab, открытого продукта с открытым исходным кодом.
Ценность GitLab DevSecOps
Согласно исследовательскому отчету Forrester, рентабельность инвестиций, полученная при использовании интегрированной платформы DevSecOps Jihu GitLab, достигает 427%. Причин много. Например, предприятиям не нужно приобретать много цепочек инструментов. Соответственно, им не нужно слишком много людей для обслуживания множества цепочек инструментов. Эти два аспекта могут действительно увеличить доходы и сократить расходы или сократить затраты и повысить эффективность. Кроме того, благодаря сокращению цепочек инструментов проблема островов данных больше не будет существовать.Все данные, связанные с исследованиями и разработками программного обеспечения, будут находиться на единой платформе.Предприятия могут легко получить эти данные для проведения анализа эффективности всего исследования. и процесс разработки. Затем примите некоторые меры для повышения эффективности НИОКР.
Кроме того, Jihu GitLab предоставляет китайским пользователям полностью локализованную сервисную поддержку корпоративного уровня, позволяя пользователям проводить эффективные и безопасные исследования и разработки автомобильного программного обеспечения с помощью интегрированной платформы DevSecOps, помогая автомобильным компаниям повысить свою конкурентоспособность и выйти за границу.