Эбби Кернс, генеральный директор 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 потратила двадцать лет на построение инфраструктуры для закрытия этого разрыва. Моя задача – убедиться, что рынок понимает, почему закрытие его срочно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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