Бизнес со скоростью сборки

Этой статьёй мы, команда научно-технического центра «НЭК ТЭХ», начинаем серию публикаций, целью которых ставим:

• описать степень влияния РБПО на бизнес;
• показать возможности, которые открывает бизнесу внедрение РБПО.

РБПО – фундамент масштабирования или как превратить РБПО из статьи расходов в инструмент роста прибыли

Любой владелец бюджета на РБПО в тех или иных понятиях пытался донести до лиц, принимающих решения, содержание следующего раздела, и думается не один раз.

Классическая презентация РБПО представляет собой логическую цепочку, где бизнес пытаются убедить через цифры.

Задача бизнеса - приносить доход бенефициарам. Что значит доход? Как его измерить?

Классическая формула

ДОХОД = ВЫРУЧКА − РАСХОДЫ

Конечно, можно пошутить, что:

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

В реальности же картина разительно отличается. Для увеличения доходов (надоев), некоторые фермеры даже включают коровам классическую музыку и раскрашивают стены коровника в определённые цвета.

Честно о расходах на РБПО.

РБПО — это неизбежные расходы. На что придётся потратиться?

1. Очевидные затраты: сканеры и ПО для анализа.
2. Неочевидные расходы, о которых часто забывают или ошибаются в оценках: дорогие, дефицитные на рынке специалисты.

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

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

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

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

Из чего обычно складываются эти большие суммы? Методология-технологии-ресурсы. В динамике статьи трат будут примерно выглядеть так:

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

В качестве частного случая, для примера рассмотрим внедрение процедур композиционного анализа.

ПО для композиционного анализа: зачем его внедрять?

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

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

1. Лицензионная чистота – ряд библиотек могут иметь лицензионные ограничения. Например, некоторые библиотеки являются условно-бесплатными для использования в некоммерческих проектах, а для коммерческой разработки требуется покупка лицензии. Использование нескольких таких компонентов может повлечь за собой серьёзные проблемы. В иностранной практике показателен иск Oracle против Google (Java в Android). Суть обвинения Oracle в том, что Google незаконно использовал части API языка Java (около 11,5 тыс. строк кода) при разработке Android. Oracle затребовал компенсацию порядка 6 млрд долларов, позже в материалах фигурировали цифры до 9 млрд. В конечном итоге Верховный Суд признал использование добросовестным, однако на юристов были затрачены огромные суммы. В российской практике суммы намного скромнее, однако, репутационный ущерб и прочие издержки могут быть неприятны даже для крупных компаний. При этом избежать проблем заранее помог бы композиционный анализ.
2. Ряд компонентов, используемых при разработке, могут быть «заброшены», существовать без поддержки и развития, уязвимости в этих компонентах могут быть использованы злоумышленниками для атаки на разрабатываемые продукты, и предупредить такую ситуацию заранее помогает композиционный анализ.
3. Неактуальные компоненты представляют угрозу, неожиданное выявление таковых уже на стадии эксплуатации продукта наносит ущерб репутации и приводит к тому, что приходится внепланово переписывать код продукта для поддержки актуальных версий компонентов, дополнительно тестировать.

Существуют и другие риски, специфичные для конкретных типов продукта и бизнесов.

РБПО многогранно, поэтому обозначим только несколько практик, для расширения «вертолётного взгляда» на вопрос.

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

1. Уязвимость, дефект или ошибка выявлены по итогам расследования инцидента у заказчика (инцидент произошёл, есть ущерб).
2. Уязвимость, дефект или ошибка выявлены в ходе эксплуатации (случайное выявление, без инцидента и без ущерба).
3. Уязвимость, дефект или ошибка выявлены в ходе приёмки системы, построенной на базе программного обеспечения.
4. Уязвимость, дефект или ошибка выявлены на этапе наладки (работник интегратора заметил, чаще всего случайно, какие-то признаки наличия дефектов ПО и подтвердил догадку в процессе внедрения).
5. Дефект или функциональная ошибка выявлены на этапе функционального тестирования.
6. Дефект или ошибка выявлены на этапе динамического тестирования.
7. Дефект или ошибка выявлены на этапе статического анализа.
8. Дефект оформления кода выявлен локальным инструментом разработчика (линтером).

Если в последнем случае устранение уязвимости, дефекта или ошибки происходит практически сразу, в случае 7 – после триажа в плановые сроки, в случае 6 – чуть позднее, в случае 5 – гораздо позднее во времени, то устранение на этапе наладки (4) вносит энтропию в нормальный режим разработки, со сдвигом сроков сдачи, в случае 3 – сроки сдвигаются до следующей комиссии (может быть несколько месяцев), в случае системы, находящейся в эксплуатации – в процесс разработки проникает хаос и сдвигаются сроки по другим продуктам, а при инциденте страдают не только сроки продукта, других продуктов, но и выгорают разработчики, ухудшается репутация компании, потенциально возможны санкции регуляторов, судебные иски и т.д.

По стоимости устранения¹ всё, что выявлено на стороне разработки, намного дешевле, чем выявленное у Заказчика, т.к. добавляются логистические расходы, командировочные специалистов, штрафы за нарушение сроков и т.д. Устранение найденных на заводских этапах уязвимостей, ошибок и дефектов кода различается по стоимости в пределах порядка.

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

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

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

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

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

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

Исходя из вышеизложенного, предлагается при внедрении РБПО делать акцент не только на финансовой выгоде, но на том, что оно является триггером, который запускает возможности для компании. В ИТ такие проекты известны как enabled project² — это проект, в котором информационные технологии являются не просто вспомогательным инструментом, а критически важным компонентом для достижения бизнес-целей и получения ценности. Так же РБПО увеличивает прозрачность процессов, тем самым позволяет повысить их потенциальную управляемость.

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

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

Команда научно-технического центра «НЭК ТЭХ» занимается, в том числе, разработкой встраиваемого программного обеспечения: терминалы релейной защиты, устройства сбора и передачи данных, приборы учёта и т.д., при этом разработка очень часто ведётся на низкоуровневых языках программирования с использованием специфических фреймворков.

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

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

Вопросы, на которые бизнес должен обязательно получить ответ, оценивая, стоит ли выбрать стратегию сокращения издержек в краткосрочной перспективе за счёт отказа от внедрения процессов РБПО:

• Готовы ли участники рынка идти на технологическое партнёрство с компанией, у которой не внедрены процессы РБПО?
• Когда проблемы с безопасностью технологического партера могут стать «чёрной меткой», влияя на результаты совместной работы, а совместный продукт, разработанный вместе с таким безответственным партнёром, будет менее конкурентоспособен уже на старте?
• Нужен ли такой технологический партнёр или его следует сразу избегать?

Примечания

Источники оценок: IBM Systems Sciences Institute, NIST Planning Report 02-3, отраслевые отчёты по стоимости инцидентов.

Классическим случаем enabled project для ИТ является внедрение в компании CRM-системы в отделе продаж: сам по себе софт не даёт прибыли, но он включает (enables) новые бизнес-процессы, сквозную аналитику и рост выручки.