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

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

Для РБПО это принципиальная проблема. Нужно заранее определить, какие проверки обязательны, где они выполняются, что блокирует выпуск, кто отвечает за устранение нарушения и как оформляется временное принятие риска. Один из способов выстроить такой процесс в масштабе компании — внутренняя платформа разработки, или IDP.

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

Если порядок нигде не закреплен, каждая команда отвечает на эти вопросы по-своему. То же происходит с доступами, окружениями, зависимостями и выпуском.

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

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

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

Так часть регламентов начинает исполняться технически, а не только существовать в документации. При этом ответственность разработчика за код и специалистов по ИБ за требования безопасности сохраняется.

Astra Developer Platform, или ADP, предназначена для разработки и выпуска доверенного программного обеспечения. Платформа связывает работу с кодом, сборку, поставку, безопасность и эксплуатацию в общие сценарии.

Разработчик начинает работу через единый интерфейс ADP на базе Backstage. Для новой прикладной системы по шаблону создаются ее карточка, репозиторий, конвейер и окружение, после чего подключаются доступы, секреты, развертывание и наблюдение.

Отдельные задачи выполняют специализированные компоненты платформы. GitFlic отвечает за код, изменения, сборку и автоматические проверки, GitFlic Atlas хранит результаты сборок, пакеты и зависимости. Argo CD используется для развертывания, Боцман предоставляет среду исполнения на Kubernetes, Astra Секреты работает с чувствительными данными, а Astra Monitoring собирает сведения о состоянии приложений.

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

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

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

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

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

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

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

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

В продуктовых материалах ADP указаны ориентиры для стандартного сценария: пять минут на создание нового сервиса и десять минут на создание окружения. Там же заявлены четыре обязательные практики безопасности.

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

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

Один из сценариев ADP связан с переносом разработки с x86 на ARM, в том числе с адаптацией приложений под процессоры Baikal. При таком переходе нужно повторно проверить зависимости, сборочную среду и работу приложения, но общие правила сборки, проверки и выпуска не приходится проектировать заново для каждой целевой архитектуры.

Похожая задача возникает при разработке программного обеспечения для АСУТП. Здесь особенно важны контролируемый технологический контур, воспроизводимость сборки и сохранение истории выпуска.

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

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

В ADP этот подход распространяется на весь путь приложения, от создания и обязательных проверок до выпуска и эксплуатации. Те же принципы используются и в сценариях с ARM, Baikal и АСУТП, где особенно важны воспроизводимость и контроль технологического контура.