Привет, Хабр! Меня зовут Максим Сыропятов, я отвечаю в Arenadata за безопасную разработку. В этой статье расскажу, как мы перенесли систему лицензирования инструмента статического анализа SVACE в облако — без костылей, туннелей и физического железа. Поделюсь, какие ограничения нам пришлось обойти, зачем это вообще понадобилось и что дало такое решение в контексте безопасности и стабильности разработки.

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

Почему SVACE?

Кодовая база ключевых продуктов Arenadata — ADB, ADQM, ADH и ADS — состоит преимущественно из компонент Java, C и C++ и требует детального анализа потоков данных. SVACE успешно закрывает эту задачу благодаря мощному taint-анализу и построению AST на основе реальных параметров сборки, что позволяет находить уязвимости глубже и точнее альтернативных решений.

Не менее важно и то, как SVACE вписывается в наш регуляторный контур. Отчёты, формируемые инструментом, принимаются сертифицирующими органами как есть, поэтому сбор пакета артефактов для ФСТЭК России проходит быстрее, а продуктовые релизы выходят без дополнительных задержек. Сегодня вся линейка Arenadata ежедневно проходит автоматический статический анализ в SVACE, что позволяет одинаково высоко держать планку безопасности во всех наших решениях.

Зачем мы решили мигрировать в облако?

Наша инфраструктура полностью базируется в облаке, за редким исключением физических серверов. Однако использование HASP-ключа не вписывается в концепцию cloud-native, но выбора у нас не было. Когда ключ оказался у нас, а депрессия сменилась принятием, инженеры отправились на колокацию и подключили его к USB-разъёму сервера. Команда безопасности начала адаптировать технологию USB-over-IP, изучая нюансы attach-/detach-механизмов и их влияние на лицензионный ключ. Когда решение было почти готово, один из физических стендов отправили на профилактику, после которой он так и не вернулся в строй из-за логистических сложностей. Как несложно догадаться, именно с этого стенда и был подключён наш ключ.

Этот риск мы осознавали с самого начала, поэтому событие не стало неожиданностью. Давайте разберём сложности, с которыми можно столкнуться при пробросе USB-устройства в облачную инфраструктуру:

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

  

• Ограничения лицензирования
  Изначально лицензия на использование SVACE предоставлялась в виде физического токена, который необходимо было подключить к серверу. Однако такая модель создавала значительные риски: токен мог повредиться или отключиться, а нестабильность соединения мешала корректному анализу, который мог занимать более 12 часов.

• Проблема блокировки ключа
  Лицензия могла использоваться только одним клиентом одновременно. Чтобы она стала доступной для другого пользователя, требовался корректный detach. Если же процесс отсоединения выполнялся с ошибкой, ключ становился недоступен для всех.

  

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

Решение через облако:

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

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

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

Подход с программной лицензией

После консультаций с командой разработки SVACE мы выяснили, что возможен переход от физического HASP-ключа к программной лицензии, которая привязывается к уникальному аппаратному идентификатору (Hardware ID) конкретной машины. Данная привязка осуществляется через вычисление аппаратного фингерпринта — уникальной комбинации характеристик оборудования и настроек виртуальной машины, благодаря чему лицензия становится неотделимой от конкретного виртуального устройства.

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

Изменения, из-за которых пересчитывается аппаратный идентификатор:

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

2. Изменение типа или количества виртуальных процессоров (vCPU). Подобные изменения напрямую влияют на вычисляемые характеристики оборудования.

3. Изменение сетевого адреса (MAC-адреса) виртуальной машины. Поскольку сетевые интерфейсы и их параметры участвуют в формировании фингерпринта, смена MAC-адреса неизбежно ведёт к изменению идентификатора.

Изменения, не влияющие на аппаратный фингерпринт:

1. Переключение режима «прерываемая виртуальная машина». Это изменение является чисто организационным и не влияет на аппаратную конфигурацию.

2. Изменение объёма оперативной памяти. RAM не входит в набор параметров, влияющих на идентификатор.

3. Переименование виртуальной машины. Это действие также является лишь административным и не затрагивает аппаратную часть.

4. Установка дополнительного программного обеспечения. Изменение ПО не затрагивает аппаратные характеристики, используемые при вычислении Hardware ID.

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

Следующим шагом стала интеграция драйвера Sentinel в образ виртуальной машины, предназначенной для выполнения анализа кода. Технически этот процесс сводился к следующему: драйвер лицензирования Sentinel встраивался в docker-образ, используемый GitLab Runner, таким образом, чтобы каждый запуск CI-/CD-процесса мог напрямую взаимодействовать с сервером лицензий через стандартные протоколы TCP и UDP по порту 1947.

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

Установка драйвера Sentinel для сервера лицензирования

Для организации сервера лицензирования SVACE прежде всего требуется установить драйвер Sentinel. Существует несколько способов его получения и установки:

• Драйвер может входить в состав архива с дистрибутивом самого инструмента SVACE.

• Актуальную версию установочного пакета можно скачать напрямую с официального сайта Sentinel.

• Возможна установка драйвера вместе со SVACE из apt-репозитория ИСП РАН. В этом случае при установке необходимо указать опцию --install-recommends.

После установки драйвера сервер готов к первоначальной настройке. При первом обращении к веб-интерфейсу Sentinel Admin Control Center по адресу http://127.0.0.1:1947 через браузер на сервере будет автоматически создан базовый конфигурационный файл hasplm.ini.

Если прямой доступ к веб-интерфейсу затруднён или невозможен, можно предварительно создать файл hasplm.ini с необходимой конфигурацией и разместить его по пути /etc/hasplm/hasplm.ini.

После выполнения этих шагов веб-консоль Sentinel Admin Control Center станет доступна на порту 1947 (при условии, что порт не заблокирован фаерволом), что позволит продолжить удалённую настройку.

;*************************************************************************
;*
;* Sentinel License Manager configuration file
;*
;* Version 28.1 1.137506
;*
;*
;*************************************************************************



[SERVER]
name = <server_name>
certificate =
privatekey =
identity_storage_encrypt = no
pagerefresh = 3
linesperpage = 12
accremote = 1
adminremote = 1
enablehaspc2v = 0
old_files_delete_days = 30

enabledetach = 0
enableautodetach = 0
autodetachhours = 2
reservedseats = 0
reservedpercent = 0
detachmaxdays = 14
commuter_delete_days = 7
disable_um = 0
idle_session_timeout_mins = 720

requestlog = 1
loglocal = 0
logremote = 1
logadmin = 1
errorlog = 1
rotatelogs = 0
access_log_maxsize = 500
error_log_maxsize = 500
zip_logs_days = 0
delete_logs_days = 10
pidfile = 0
passacc = 0

accessfromremote = anyone
accesstoremote = 1
bind_local_only = 0
listen_also = 1
id_public_addr =
proxy = 0
proxy_host =
proxy_port = 8080
proxy_username =
proxy_password =


[REMOTE]
broadcastsearch = 0
serversearchinterval = 30


[ACCESS]
;*set network connection permission in CUDR notation. Example allowed acces from test network: allow = 192.168.0.1/24


[USERS]


[VENDORS]


[EMS]
emsurl = http://localhost:8080
emsurl = http://127.0.0.1:8080


[TRUST]


[LOGPARAMETERS]
text = {timestamp} {clientaddr}:{clientport} {clientid} {method} {url} {function}({functionparams}) result({statuscode}) {newline}

После размещения файла hasplm.ini в расположении /etc/hasplm/hasplm.ini веб-консоль Sentinel Admin Control Center станет доступна по адресу http://[IP-адрес_сервера]:1947 (при условии, что порт 1947 открыт и не блокируется фаерволом), что позволит выполнять дальнейшую настройку удалённо.

В веб-консоли перейдите на страницу Sentinel Keys. В случае чистой установки здесь будет отображаться как минимум один локальный ключ. В столбце ACTIONS напротив этого ключа будет кнопка Fingerprint. Нажатие на эту кнопку инициирует скачивание файла с расширением .c2v.

Этот файл .c2v содержит уникальный «отпечаток» (Fingerprint) аппаратного обеспечения виртуальной машины. Фингерпринт является основанием для генерации программной лицензии, которую вы впоследствии получите от службы поддержки.

Далее мы отправили этот фингерпринт в поддержку и через некоторое время получили файл лицензии и дополнительные файлы .so для того, чтобы лицензия могла быть применена, и инструкцию к ним. Само применение лицензии происходит через меню Update/Attache прямо в веб-интерфейсе Sentinel.

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

После применения лицензии настройку Sentinel можно приостановить.

У нас в продакшене используется GitLab (для тестов мы используем свой тестовый), следующим шагом мы установили GitLab Runner и зарегистрировали его на тестовом сервере в качестве Docker Executor.

concurrent = 1
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "docker_svace"
  output_limit = 409600
  url = "your-gitlab-ip"
  id = 1
  token = "<your-token>"
  token_obtained_at = 2024-06-03T04:58:32Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.cache]
    MaxUploadedArchiveSize = 0
  [runners.docker]
    tls_verify = false
    image = "alpine:stable"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    network_mtu = 0

ARG UBUNTU_VERSION=22.04
FROM ubuntu:${UBUNTU_VERSION}

ENV DEBIAN_FRONTEND=nointeractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends ca-certificates gnupg2 curl git && \
    echo 'deb [signed-by=/usr/share/keyrings/ispras-archive-keyring.gpg] https://repo.ispras.ru/apt /' | tee /etc/apt/sources.list.d/ispras.list && \
    curl -fsSL https://repo.ispras.ru/apt/key.asc | gpg --dearmor > /usr/share/keyrings/ispras-archive-keyring.gpg

ARG VER=4.0.250303
ARG SVACER_VER=10.0-1

RUN apt-get update && \
    apt-get install -y --install-recommends svace=${VER} svacer=${SVACER_VER} && \
    rm -rf /var/lib/apt/lists/*


LABEL \
    scanner.version=${VER} \
    svacer.version=${SVACER_VER} \
    scanner.name="svace" \
    image.source="https://gitlab.ispras.ru/svace/svace-support"

На этом этапе нужно собрать и запушить образ в ваш репозиторий образов. И у нас всё готово для тестов!

stages:
  - build
 

svace_job:
  stage: build
  image: <Адрес_репозитория_образов>:<Тэг_образа> # например harbor.example.com/gitlab/svace:3.4.240516
  tags:
    - svace #Тег по которому найдется нужный раннер
  before_script:
    #Если данные для анализа не подготовлены заранее, то окружение должно быть подготовленно для корректной сборки проекта
    - some environement settings
  script:
    - svace init
    - svace build <your default build command>
	#Далее можно провести анализ следующим шагом или запаковать результаты перехвата сборки и проанализировать отдельно 
    #- tar -czf $CI_PROJECT_DIR/svace-dir.tar.gz .svace-dir
	- svace analyze
	#Если результаты нужно загрузить в свейсер
	- svacer --debug import --svace svace --project ${CI_PROJECT_NAME} --branch ${CI_COMMIT_BRANCH} --snapshot ${CI_COMMIT_SHA}
	- svacer --debug upload <svacer_host_address>
  after_script:
    # Пакуем результаты сборки, анализа и импорта
    - tar -czf $CI_PROJECT_DIR/svace-analyzed-dir.tar.gz .svace-dir
	- tar -czf $CI_PROJECT_DIR/svacer-analyzed-dir.tar.gz .svacer-dir
  artifacts:
    name: "svace-${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}"
    when: always
    paths:
      - $CI_PROJECT_DIR/svace-analyzed-dir.tar.gz
      - $CI_PROJECT_DIR/svacer-analyzed-dir.tar.gz .svacer-dir
    expire_in: 5 days

От тестов к продакшену: узкие места и поиск решения

После того как базовая связка с лицензией, привязанной к «виртуалке», заработала на тестовом стенде, мы начали прогонять её на реальных проектах. Тесты показали, что в целом подход рабочий. Но быстро стало понятно, что такой сетап, как есть, в продакшене не взлетит из-за нескольких критичных нюансов.

Во-первых, неэффективное использование ресурсов. Если бы мы просто перенесли эту схему в прод, нам пришлось бы держать там «прожорливую» машину. Ведь для анализа больших проектов SVACE требует приличные вычислительные мощности (CPU, RAM). Эта «тачка» простаивала бы всё время, пока не идёт анализ. Да, можно изобретать какие-то скрипты для запуска виртуальной машины on-demand прямо перед стартом пайплайна, но это выглядит как довольно «колхозный костыль», который добавит точек отказа и сложностей в поддержке.

Во-вторых (и это, пожалуй, главная боль, связанная с лицензией Hardware ID), лицензия прибита гвоздями к конфигурации виртуальной машины. Как мы выяснили на тестах, любое изменение числа vCPU или объёма RAM приводит к изменению аппаратного фингерпринта. А это означает одно — лицензия слетает! Приходится опять писать в поддержку ИСП РАН, запрашивать новую лицензию под новую конфигурацию, ждать... В мире Agile и DevSecOps, где инфраструктура должна быстро адаптироваться под задачи, такая жёсткая привязка и ручной процесс перезапроса лицензии — это просто убийство гибкости.

Мы поняли, что так жить нельзя. Надо было как-то развязать сервер лицензий и машину, которая выполняет тяжёлые вычисления. И тут мы стали внимательнее изучать свойства нашей программной лицензии и документацию Sentinel. Заметили атрибут Network в описании. «Хм, а это что?» — подумали мы и начали копать.

Копание принесло золотую жилу! Мы выяснили: Sentinel поддерживает клиент-серверную модель работы с программными лицензиями. Это означает, что можно разделить роли: один экземпляр Sentinel Runtime работает как сервер лицензий, а другой — как клиент, получающий лицензию по сети. Под капотом обоих — всё тот же Sentinel Runtime, но благодаря настройке и конфигурации они выполняют разные функции. Это позволило нам развязать вычисления и лицензирование: теперь сервер лицензий — это отдельная лёгкая виртуальная машина, не нагруженная задачами анализа кода.

Финальная архитектура в проде: разделяем лицензию и вычисления

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

Статичный сервер-лицензиат: поднимаем отдельную виртуальную машину с минимально необходимыми ресурсами. На ней крутится только Sentinel License Server с нашей программной лицензией. Эта «тачка» живёт постоянно, но потребляет очень мало ресурсов. Она может даже присоседиться к другому сервису на одной ВМ, если так удобнее. Главное, чтобы сервер, на котором располагается лицензия, был доступен c клиента на порту 1947 по протоколам UDP и TCP!

Динамические клиенты-раннеры: в качестве клиентов выступают виртуальные машины с GitLab Runner. Эти ВМ не живут постоянно. Они поднимаются динамически, по требованию, когда запускается CI-/CD-пайплайн, требующий анализа SVACE. Для управления их жизненным циклом и поднятия с нужными характеристиками (достаточными для анализа) мы используем Docker Machine из заранее настроенного темплейта.

Sentinel Client в docker-образе: клиентская часть Sentinel интегрируется непосредственно в docker-образ, который используется GitLab Runner для запуска задач анализа. Это делается на этапе сборки образа. При старте контейнера Runner вместе с SVACE стартует и сервис Sentinel Client. Модифицируем наш Dockerfile.

Для реализации этой схемы потребовались два ключевых компонента: конфигурационный ini-файл для клиента Sentinel (который указывает, где искать сервер лицензий) и Dockerfile для сборки образа Runner, включающего SVACE и клиент Sentinel.

;*************************************************************************
;*
;* Sentinel License Manager configuration file
;*
;* Version 29.3 1.147349 at svace-test-recipient
;*
;*
;*************************************************************************



[SERVER]
name = svace-test-recipient
certificate =
privatekey =
identity_storage_encrypt = no
pagerefresh = 3
linesperpage = 12
accremote = 1
adminremote = 1
enablehaspc2v = 0
old_files_delete_days = 90

enabledetach = 0
enableautodetach = 0
autodetachhours = 2
reservedseats = 0
reservedpercent = 0
detachmaxdays = 14
commuter_delete_days = 7
disable_um = 0
idle_session_timeout_mins = 720

requestlog = 0
loglocal = 0
logremote = 0
logadmin = 0
errorlog = 1
rotatelogs = 0
access_log_maxsize = 0
error_log_maxsize = 0
zip_logs_days = 0
delete_logs_days = 0
pidfile = 0
passacc = 0

accessfromremote = anyone
accesstoremote = 1
bind_local_only = 0
id_public_addr =
proxy = 0
proxy_host =
proxy_port = 8080
proxy_username =
proxy_password =


[REMOTE]
broadcastsearch = 1
serversearchinterval = 30
serveraddr = <ip_address-sentinel-license-server>


[ACCESS]


[USERS]


[VENDORS]


[EMS]
emsurl = http://localhost:8080
emsurl = http://127.0.0.1:8080


[TRUST]


[LOGPARAMETERS]
text = {timestamp} {clientaddr}:{clientport} {clientid} {method} {url} {function}({functionparams}) result({statuscode}) {newline}

Модифицируем Dockerfile, добавляем директиву COPY, копируем ini-файл нашего клиента Sentinel.

ARG UBUNTU_VERSION=22.04
FROM ubuntu:${UBUNTU_VERSION}

ENV DEBIAN_FRONTEND=nointeractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends ca-certificates gnupg2 curl git && \
    echo 'deb [signed-by=/usr/share/keyrings/ispras-archive-keyring.gpg] https://repo.ispras.ru/apt /' | tee /etc/apt/sources.list.d/ispras.list && \
    curl -fsSL https://repo.ispras.ru/apt/key.asc | gpg --dearmor > /usr/share/keyrings/ispras-archive-keyring.gpg

ARG VER=4.0.250303
ARG SVACER_VER=10.0-1

RUN apt-get update && \
    apt-get install -y --install-recommends svace=${VER} svacer=${SVACER_VER} && \
    rm -rf /var/lib/apt/lists/*
	
COPY ./hasplm-recepient.ini /etc/hasplm/hasplm.ini


LABEL \
    scanner.version=${VER} \
    svacer.version=${SVACER_VER} \
    scanner.name="svace" \
    image.source="https://gitlab.ispras.ru/svace/svace-support"

ВАЖНО! В такой схеме нужно перед анализом в пайплайне запустить сервер Sentinel командой <code> /usr/sbin/hasplmd_x86_64 -s </code>.

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

Для запуска раннеров у нас на данный момент используется механизм динамического создания VM в Yandex Cloud по заданному темплейту с ограничением на количество запускаемых раннеров по определённому тегу. Нам подошёл этот вариант потому, что он позволяет на уровне GitLab организовать очередь из проектов, подлежащих анализу. Из коробки Sentinel очередь не поддерживает. Сама лицензия имеет свойство Concurrency, которое определяет, сколько анализов можно запустить одновременно (в нашем случае 1). Если лицензия занята одним клиентом и на сервер приходит второй — сервер сообщает, что лицензий свободных нет. В итоге Job падает с ошибкой — нам такой сценарий неинтересен.

Куда развиваться дальше

Текущая архитектура устраивает нас по ряду практических причин. Виртуальные машины поднимаются строго по запросу CI-процесса и прекращают работу сразу. Поэтому, когда триггерится Job на анализ, первым делом запускается механизм создания VM с раннером, в котором присваивается сервисный тег (например, svace-analyze), и лимит на раннер с таким тегом установлен тем значением, сколько одновременных анализов вам доступно. Таким образом, на уровне GitLab, если в момент работы пайплайна триггер будет снова активирован, следующий пайплайн встанет в очередь и будет ожидать завершения первого анализа.

Второй положительный для нас момент в том, что мы можем конфигурировать вычислительные ресурсы машины. Это делается через темплейт, из которого берётся информация для создания VM. В частности, мы можем задать количество ядер и оперативной памяти, которая требуется для машины. Если мы захотим изменить эти значения — достаточно внести изменения в темплейт, что добавляет гибкости нашему решению после завершения анализа, поэтому ресурсы не простаивают. Даже «толстая» машина с большим объёмом vCPU и RAM остаётся экономичной: на средних и небольших проектах она работает считаные десятки минут, не успевая накопить заметные счета за облачные часы, а на крупных проектах её мощности достаточно, чтобы пройти статический анализ без тайм-аутов и ручных вмешательств.

Тем не менее у нас есть идея следующего шага — автоматическая подстройка конфигурации под реальный объём кода. Концепция проста: до старта пайплайна мы оцениваем размер репозитория (число файлов, общее количество строк, исторические метрики времени анализа) и на основе этой оценки выбираем наиболее подходящий flavor виртуальной машины. Скрипт-оркестратор мог бы запрашивать у облачного API именно такую конфигурацию, а после анализа освобождать ресурсы. В результате маленькие проекты выполнялись бы на более лёгких инстансах, а крупные — на мощных, но только тогда, когда это действительно нужно.

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

Что дала облачная инфраструктура SVACE — преимущества и результаты перехода

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

Производительность и скорость разработки:

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

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

Масштабируемость и гибкость под нагрузку:

• Мы имеем возможность добавлять или убирать vCPU/RAM, подстраивая конфигурацию под проект, при этом не ломая лицензию, основанную на Fingerprint.

• Ушли от обслуживания физической фермы: теперь всё управление виртуальными машинами централизовано и выполняется «по кнопке».

Сетевая лицензия:

• Лицензия живёт в соседнем облаке с тестом. Достаточно настроить правильные доступы.

• Ушли от туннеля, ушёл риск, связанный со сложной сетевой структурой.

Оптимизация затрат:

• Платим только за ресурсы, которые реально потребляются во время анализа или тестов.

• Отсутствие физического оборудования снизило прямые CAPEX и OPEX: больше не тратимся на апгрейды, склад запчастей и простои при профилактике.

Простота обновлений и сопровождения:

• Облачные образы SVACE и сопутствующих сервисов обновляются автоматически, без остановки пайплайнов.

• Использовали базовые инструменты и не создавали свой велосипед, который нужно поддерживать отдельно.

• Нет жёсткой привязки к конкретной версии или конфигурации: инфраструктура и инструмент анализа эволюционируют синхронно.

• Реализован функционал очередности с помощь нативных средств GitLab CI.

Эффект для команды и пользователей:

• Автоматизация рутин позволяет инженерам сосредоточиться на задачах безопасности и качества кода, а не на «админке».

• Конечные пользователи видят стабильный доступный сервис: анализы запускаются по требованию, без очередей и падений из-за нехватки лицензий.

Заключение

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