Аббі Кернс, генеральний директор ActiveState – Серія інтерв’ю

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

ActiveState – канадська компанія з програмного забезпечення, заснована в 1997 році, яка надає підприємствам інструменти та платформи для будівництва, управління та захисту відкритого джерела програмного забезпечення. Її основна пропозиція, платформа ActiveState, допомагає командам розробки, DevOps та безпеки автоматизувати управління залежностями, виявляти та усувати уразливості та створювати безпечні, репродуктивні середовища розробки для декількох мов програмування, таких як Python, Perl та Tcl. Надавши попередньо складені та перевірені відкриті компоненти та інтегрувавши їх у існуючі робочі процеси, ActiveState спрямована на зменшення ризиків безпеки в ланцюжку постачання програмного забезпечення, одночасно покращуючи продуктивність розробників та прискорюючи доставку застосунків.

Ви провели свою кар’єру на перетині відкритого джерела, хмарних платформ та трансформації підприємств, від керівництва Cloud Foundry Foundation до обіймання посади технічного директора в Puppet. Що спонукало вас зайняти посаду генерального директора в ActiveState, і яка ваша бачення компанії в цьому наступному етапі зростання?

Через весь мій кар’єру була робота на перетині спільноти та інфраструктури в моменти, коли галузь приймає рішення, які будуть мати наслідки протягом років. Cloud Foundry був таким моментом для хмарних платформ. Puppet був таким моментом для управління конфігурацією та ранніх стадій того, що ми зараз називаємо DevSecOps. ActiveState – це момент для управління відкритим джерелом.

То, що спонукало мене сюди, – це проблема, яку я спостерігав протягом довгого часу. Кожне підприємство, з яким я зустрічався, працює на відкритому джерелі. Більшість з них не можуть сказати з впевненістю, яке відкрите джерело вони використовують, чи було воно патчено, чи хто відповідає за рішення про його використання. Ця прогалина між тим, як фундаментальним відкрите джерело стало, та тим, як мало організацій застосовують до нього дисципліну, – це місце, де накопичується ризик галузі. ActiveState витратив двадцять років на будівництво інфраструктури для закриття цієї прогалини. Моя робота полягає в тому, щоб переконати ринок у тому, що закриття цієї прогалини є терміновим.

Бачення цього наступного етапу ясне: ActiveState стає стандартною відповіддю на питання про те, звідки походять підприємства відкритого джерела. Не сканер. Не звіт. Довірений, перевірений, постійно усунутий джерело, на яке організації можуть вказати, коли регулятори, ради директорів або служби реагування на інциденти запитують, як вони керували ланцюжком постачання програмного забезпечення.

ActiveState позиціонує себе як критичний шар у забезпеченні безпеки ланцюжа постачання програмного забезпечення в той час, коли штучний інтелект прискорює генерацію коду. Як штучний інтелект фундаментально змінює ризиковий профіль відкритого джерела програмного забезпечення?

Розробка з допомогою штучного інтелекту порушує фундаментальну припущення, на якій була побудована вся інфраструктура управління відкритим джерелом: те, що розробник прийняв свідоме рішення про включення залежності.

Кожен мандат SBOM, кожний інструмент SCA, кожен робочий процес управління уразливостями припускає, що був людина в циклі, яка вибрала бібліотеку. Коли штучний інтелект генерує код, залежності з’являються у виробництві, які ніхто не вибрав, не переглянув чи навіть не знає про їхнє існування. Інструменти управління шукають рішення. Штучний інтелект робить зміни у виробництві, які обходять рішення зовсім.

Є другий шар цього. Інструменти кодування, які спонукали до прийняття штучного інтелекту, бенчмарки продуктивності, опитування розробників, зірки GitHub, жодна з цих оціночних рамок не включала безпеку як першочергову міру. Галузь оптимізувалася для швидкості та правильності та відправила інфраструктуру без запитання, чи безпечний її висновок. Це не провал інструментів. Це провал керівництва у прийнятті рішень про прийняття.

Ви сказали, що некероване відкрите джерело стає великою уразливістю підприємств. Чому управління відкритим джерелом тепер піднімається на рівень ради директорів, і чого керівники все ще недооцінюють?

Воно досягає рівня ради директорів, оскільки регуляторна середовище змінило структуру відповідальності. Акт про кіберстійкість ЄС, вимоги щодо розкриття інформації SEC, керівництво CISA щодо безпечного дизайну: ці рамки змінюють питання з “Чи мав ви сканер?” на “Чи можете ви довести, що ваше програмне забезпечення було безпечним на момент походження?” Це зовсім різні питання, і більшість організацій не можуть відповісти на друге.

Того, чого керівники все ще недооцінюють, – це те, що це структуральна проблема, а не проблема ресурсів. Організації, які реагують на ризик відкритого джерела, додаючи більше інструментів сканування, не розв’язують основну проблему. Сканування виявляє проблеми після того, як вони вже увійшли до вашої середовища.

Коли все підкреслюється, нічого не пріоритезується, і об’єм попереджень стає своєю операційною дисфункцією. Організації, які успішно пройдуть через це, не будуть тими, хто купує більше інструментів. Це будуть організації, які змінюють спосіб прийняття рішень про те, яке відкрите джерело потрапляє до їхньої середовищі, і хто відповідає за ці рішення.

Як організації повинні переглянути відкрите джерело як інфраструктуру, а не лише як зручність для розробки?

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

Це не поточна реальність. Відкрите джерело – це фундамент сучасного програмного забезпечення. Дев’яносто шість відсотків застосунків включають компоненти відкритого джерела. Воно не є шаром зручності на вершині пропрієтарної інфраструктури. Воно є інфраструктурою. І інфраструктура повинна керуватися як інфраструктура, з явними політиками щодо того, що потрапляє до середовища, визначеним володінням для технічного обслуговування та усунення, та відповідальністю, яка сидить на правильному рівні організації.

Організації, які попереду в цьому, зробили свідомий зсув: споживання відкритого джерела – це стратегічне рішення з безпекою та фінансовими наслідками, а не стандартна установка, яку розробники керують індивідуально. Цей зсув вимагає політики, операційного процесу та явної виконавчої відповідальності. Більшість організацій ще не зробили цього зсуву.

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

Поточний зсув, спонукалий штучним інтелектом, дуже схожий на попередні технологічні зсуви. Коли хмара з’явилася як модель доставки, організації, які сприймали її як чистий технологічний вибір, зробили зовсім інші помилки, ніж організації, які визнали її як архітектурний та операційний зсув. Ті, хто не зробив переходу у керуванні, платили за це протягом років у тіньовому ІТ, перевитратах, та боргу з безпеки та технічного боргу.

Того, що відрізняє поточний зсув, спонукалий штучним інтелектом, – це швидкість та невидимість. Прийняття хмари було видимим. Ви знали, коли ваша організація мігрувала робочі навантаження з локального на хмарне. DevOps був видимим: організації перебудовували команди, змінювали конвеєри розгортання та переписували процеси. Інструменти кодування штучного інтелекту приймаються розробником за розробником, викликом за викликом, та ризик накопичується у кодовій базі, перш ніж більшість організацій зареєстрували, що було прийнято рішення про керування.

Порушення також асиметричне способом, яким хмара та DevOps не були. Ці переходи створили нові категорії ризику, але в основному зберегли припущення, що людина була відповідальною за код, який відправлявся. Штучний інтелект підкрадається цьому припущенню в точці, де його найважче виявити. Це робить цей перехід іншим. Виставлення відбувається невидимо, поки воно не стане видимим.

Багато компаній борються з перетворенням прийняття відкритого джерела на сталий бізнес-модель. Що відрізняє компанії, які успішно роблять це, від тих, які не успішні?

Організації, які побудували сталий бізнес на відкритому джерелі, мають одну спільну рису: вони дисципліновані щодо того продукту, який вони насправді продають. Вони не продають відкрите джерело програмного забезпечення, яке є безкоштовним. Вони продають експертизу, операційну підтримку, інфраструктуру керування та керовану службу, яка робить безкоштовне програмне забезпечення життєздатним у масштабі підприємств.

Навпаки, організації, які не успішні, зазвичай плутають прийняття спільноти з комерційним успіхом. Вони не одне й те саме. Висока кількість зірок GitHub або велика спільнота сигналізує про те, що розробники знаходять проєкт корисним. Це не сигналізує про те, що покупці заплатять за нього, чи те, що річ, яку розробники знаходять корисною, є тією самою річчю, яку організації насправді потребують. Переклад з прийняття розробниками на підприємницьку цінність вимагає будівництва чогось понад відкрите джерело само по собі, та організації, які не роблять цього розрізнення явно у своїй позиції, продукті та русі продажів, схильні не вижити у переході до масштабу.

З вашого досвіду масштабування підприємств, орієнтованих на розробників, які є найбільшими керівницькими викликами при переході від продукту, який веде зростання, до операцій у масштабі підприємств?

Найбільшим викликом є те, що навички та інстинкти, які зробили вас успішним у зростанні, веденому продуктом, працюють проти вас у масштабі підприємств. Зростання, ведене продуктом, винагороджує швидке рух, ітерацію у відкритому просторі, оптимізацію для досвіду розробників та дозволяє прийняттю вести комерційний рух. Продажі підприємств винагороджують обдуманий процес, виконавчі відносини, довгі цикли та здатність відображати ваш продукт у результатах, які важливі для покупців, які не є розробниками.

Помилка керівництва, яку я бачу найчастіше, полягає в тому, що перехід головним чином є проблемою руху продажів. Це не так. Це проблема проекту організації. Команда, яка побудувала продукт, позиціювання та ранні відносини з клієнтами, часто не є командою, яка може виконати рух підприємств. Визнання цього без втрати того, що зробило продукт вартим купівлі, є справжнім викликом. Керівники, які роблять це добре, є тими, хто чесно говорить про те, які частини організації повинні еволюціонувати, та хто будує нові можливості без демонтажу культури, яка створила продукт.

Ви працювали широко на перетині безпеки та продуктивності розробників. Як компанії можуть балансувати швидкість та інновації з зростаючою потребою у безпечних та довірених компонентах програмного забезпечення?

Позиціонування швидкості проти безпеки – це фальшивий вибір, який зберігся тому, що інструменти підтримували його. Коли безпека реалізується як ворота огляду в кінці процесу розробки, це є瓶шею. Коли вона реалізується як кероване джерело довірених компонентів, які розробники витягують на початку процесу, це не сповільнює нічого.

Ті, хто розв’язали цей конфлікт, зробили це, змінивши місце, де відбувається безпека. Не переглядаючи код після того, як він написаний. Не скануючи артефактів після того, як вони побудовані. Керуючи тим, що потрапляє до каталогу, з якого розробники та інструменти штучного інтелекту витягують. Якщо джерело довірене, швидкість не обмежена безпековим оглядом, оскільки робота з безпекою відбулася раніше. Це архітектурне рішення, а не культурне. Воно вимагає інвестицій в інфраструктуру керування, але не вимагає вибору між рухом швидко та безпечним відправленням.

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

Роль кураторських, довірених джерел відкритого джерела перейде від найкращої практики до базової вимоги. Цей перехід спонукається двома речами, які не повернуться назад.

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

Друге – швидкість розробки штучного інтелекту. Коли інструменти штучного інтелекту генерують більше коду та витягують більше залежностей, об’єм неконтрольованих компонентів, які потрапляють до виробництва, перевищить будь-яку організаційну здатність переглянути їх вручну. Організації, які встановили кураторський, керований політикою каталог як стандартне джерело для своїх розробників та інструментів штучного інтелекту, зможуть збігти швидкість штучного інтелекту з відповідним керуванням безпеки. Організації, які все ще покладаються на публічні реєстри та ручний огляд, будуть стикатися з розширюванням прогалини між тим, як швидко код генерується, та тим, як ретельно він оцінюється.

Кураторські екосистеми – це інфраструктурна відповідь на проблему, яку розробка штучного інтелекту зробила невідворотною.

Як одна з небагатьох жінок-генеральних директорів у сфері відкритого джерела та інфраструктури, які зміни ви бачили у лідерській різноманітності за роки, і що ще потрібно покращити?

Було справжнє змінення. Коли я почала свою кар’єру, представництво жінок у виконавчих ролях у відкритому джерелі та інфраструктурі було достатньо низьким, щоб винятки були помітними. Це менше правда зараз. Є більше жінок у старших технічних та виконавчих посадах, більше організацій, які перейшли від фази декларативної різноманітності до здійснення структурних змін, та більше моделей для того, яким може бути лідерство в цій сфері.

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

Належність все ще нерівномірна по всій галузі. Бути в кімнаті не те саме, що мати свою перспективу справжньо зваженою. Ця відмінність – це місце, де наступна фаза прогресу повинна відбутися.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати ActiveState.