Блеск и нищета сертифицированных решений

ivalnick — 29.10.2025 Когда-то я прослушал в ФГБУ «ВНИИМС» небольшую, но очень полезную лекцию о сертификации программного обеспечения. Из неё я вынес, что наличие сертификата подтверждает соответствие ПО стандартам, требованиям регулятора, позволяет повысить качество и как следствие снижает риски и повышает доверие клиентов.
Потом мы несколько раз сертифицировали наш программный продукт и я стал смотреть на сертификаты соответствия уже немного иначе.
Во-первых, объем испытаний, зависит прежде всего от пожеланий самого заявителя. Поскольку его увеличение ведёт как к росту цены, так и продолжительности испытаний, поэтому заявитель старается сократить его до возможного минимума, понять который можно только по протоколу испытаний.
Во-вторых, проверка ПО в испытательной лаборатории ограничивается преимущественно позитивным тестированием. То есть это не замена полноценному тестированию у разработчика, а выявление только грубых ошибок, которых быть просто не должно (при проведении первых сертификационных испытаний я получил отказ, потому что в инструкции по установке была опечатка и ПО просто не запустилось на ПК эксперта).
В-третьих, эксперт может быть не специалистом в предметной области и пропустить явные ляпы в логике или интерфейсе программы (у моих коллег в системе управления договорами был чудесный ляп: если в договоре аренды дата начала превышала дату окончания, то стоимость получалась отрицательная).

Ситуация немного меняется в случае обязательной сертификации (ФСБ, ФСТЭК, Минобороны), где объём проверок и процедура проведения испытаний имеют жёсткие регламентированные требования. Но даже в этом случае возникает одна общая для ПО проблема - версия сертифицированного ПО.

За редкими исключениями программный продукт после его выпуска и сертификации продолжает развиваться. Не важно, идёт ли речь об исправлении ошибок или расширении функционала, но по сути каждое изменение аннулирует сертификат соответствия, потому что он относится к предыдущей версии программы, а не к текущей.
И в этом случае возникают парадокс: либо мы пользуемся устаревшей версией программы с действующим сертификатом соответствия (для СКЗИ, например, это обязательно), которой мы пользоваться не можем из-за ошибок или отсутствие нужного функционала; либо мы пользуемся новой версией, которая сертификата соответствия не имеет и все преимущества его наличия обращаются в ничто.

Теоретическим решением этой проблемы была бы сертификации самого процесса разработки программного обеспечения, но она не даёт ответа на вопрос соответствия требованиям конкретной версии программного обеспечения.

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

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

Оставить комментарий

Популярные посты:

• Ранее
• Архив