Эбби Кирнс, генеральный директор ActiveState – Интервью

Эбби Кирнс является генеральным директором ActiveState и технологическим руководителем с более чем 25-летним опытом строительства и масштабирования организаций по разработке программного обеспечения. Ранее она занимала должность технического директора Puppet, где помогла руководить стратегическим преобразованием, завершившимся приобретением компании Perforce Software. Ранее в своей карьере она была генеральным директором Cloud Foundry Foundation, где руководила ростом одной из крупнейших открытых облачных платформ в отрасли. Эбби в настоящее время является членом совета директоров Akka (ранее Lightbend). Она известна тем, что помогает компаниям переводить основные сдвиги в облаке, открытом исходном коде и ИИ в четкую стратегию продукта и роста предприятия.

ActiveState – это канадская компания по разработке программного обеспечения, основанная в 1997 году, которая предоставляет инструменты и платформы для предприятий для построения, управления и обеспечения безопасности открытого программного обеспечения. Ее основная oferta, платформа ActiveState, помогает командам разработки, DevOps и безопасности автоматизировать управление зависимостями, обнаруживать и устранять уязвимости, а также создавать безопасные, воспроизводимые среды разработки на нескольких языках программирования, таких как Python, Perl и Tcl. Доставляя предварительно построенные, проверенные компоненты открытого исходного кода и интегрируя их в существующие рабочие процессы, ActiveState стремится снизить риски безопасности в цепочке поставок программного обеспечения, одновременно повышая производительность разработчиков и ускоряя доставку приложений.

Вы провели свою карьеру на пересечении открытого исходного кода, облачных платформ и трансформации предприятий, от руководства Cloud Foundry Foundation до работы в качестве технического директора Puppet. Что привело вас к принятию на себя роли генерального директора ActiveState, и какова ваша видение компании в этой следующей фазе роста?

Основная линия моей карьеры заключалась в работе на пересечении сообщества и инфраструктуры в моменты, когда отрасль принимает решения, которые будут иметь значение в течение многих лет. Cloud Foundry был таким моментом для облачных платформ. Puppet был таким моментом для управления конфигурациями и ранних стадий того, что мы теперь называем DevSecOps. ActiveState – это момент для управления открытым исходным кодом.

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

Видение этой следующей фазы rõко: ActiveState становится дефолтным ответом на вопрос о том, откуда берется открытый исходный код для предприятий. Не сканер. Не отчет. Доверенный, проверенный, постоянно исправляемый источник, на который организации могут указать, когда регулирующие органы, советы директоров или реагирующие на инциденты спрашивают, как они управляли своей цепочкой поставок программного обеспечения.

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

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

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

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

Вы сказали, что неуправляемый открытый исходный код становится основной уязвимостью для предприятий. Почему управление открытым исходным кодом теперь поднимается на уровень совета директоров, и что руководители все еще недооценивают?

Это достигает совета директоров, потому что регулирующая среда изменила структуру ответственности. Закон об устойчивости кибербезопасности ЕС, требования к раскрытию информации SEC, руководство CISA по безопасному проектированию: эти рамки меняют вопрос от “У вас был сканер?” до “Можете ли вы доказать, что ваше программное обеспечение было безопасным в момент его создания?” Это очень разные вопросы, и большинство организаций не могут ответить на второй.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда инструменты ИИ все чаще генерируют код и зависимости, как вы видите эволюцию роли отобранных или доверенных экосистем открытого исходного кода в течение следующих нескольких лет?

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

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

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

Отобранные экосистемы – это инфраструктурный ответ на проблему, которую разработка ИИ сделала неизбежной.

Как одна из немногих женщин-генеральных директоров в области открытого исходного кода и инфраструктуры, какие изменения вы видели в разнообразии руководства за годы, и что еще нужно улучшить?

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

Бизнес-кейс для закрытия оставшегося разрыва не является абстрактным. Проблемы, над которыми работает эта отрасль сейчас, риск цепочки поставок программного обеспечения, управление ИИ, организационные изменения, необходимые для того, чтобы сделать безопасность первоочередной практикой, – это сложные проблемы. Разнообразные команды производят лучшие результаты на сложных проблемах. Не как вопрос стремления, а как вопрос того, как разные перспективы выявляют предположения, которые гомогенные команды пропускают. Я видела это напрямую. Организации, которые сделали реальный прогресс в принадлежности, а не только представительстве, – это те, где этот операционный преимущество проявляется в работе.

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

Спасибо за отличное интервью, читателям, которые хотят узнать больше, следует посетить ActiveState.