Диск разработчика и сертификация

drug

New member
Сообщения
20
#1
Добрый день.
Правильно я понимаю, что библиотеки с диска разработчика (например, boost или Qt), которые использовались при разработке приложения, тоже должны включаться в исходные коды для сертификации? Т.е. если приложение на 5000 строк нужно сертифицировать, то нужно еще и сертифицировать мегабайты кода буста и кутэ?
 

ALSE_User

New member
Сообщения
390
#2
Сертификация в системе МО и в системе ФСТЭК суть разные процессы. Вам в какой системе?
 

Карл

New member
Сообщения
418
#3
а зачем сертифицировать qt, если оно и так в составе астры ?
 

ALSE_User

New member
Сообщения
390

Карл

New member
Сообщения
418
#5

ALSE_User

New member
Сообщения
390
#6
не совсем понял суть ответа
вопрос - если разраб сделал на qt из состава астры свое ПО (слинковал динамически), то зачем ему сертифицировать qt еще раз ?
QT как инструмент разработки не сертифицирован, поэтому в разных системах сертификации могут быть предъявлены требования по сертификации ВСЕХ средств разработки и конечных продуктов. Все зависит от требований заказчика и органов по аттестации.
 

Карл

New member
Сообщения
418
#7
хм, если для разработанного ПО нужен пакет libqt5core5a, находящийся в репозитарии основном (main), то получается его и не надо еще раз сертифицировать ?
 

drug

New member
Сообщения
20
#8
Сертификация в системе МО и в системе ФСТЭК суть разные процессы. Вам в какой системе?
Хороший вопрос) Я исполнитель и внизу цепочки, но скорее всего МО

не совсем понял суть ответа
вопрос - если разраб сделал на qt из состава астры свое ПО (слинковал динамически), то зачем ему сертифицировать qt еще раз ?
Вот тут полностью солидарен. Учитывая что fly построен на Qt и он очевидно сертифицирован, вместе с Qt. Отсюда и вопрос.

На предыдущей работе мы могли спокойно использовать все, что идет в поставке Астры. А тут видимо политика изменилась и стало все резко неудобно.
 

drug

New member
Сообщения
20
#9
QT как инструмент разработки не сертифицирован, поэтому в разных системах сертификации могут быть предъявлены требования по сертификации ВСЕХ средств разработки и конечных продуктов. Все зависит от требований заказчика и органов по аттестации.
А что значит как инструмент разработки? Мы не собираемся поставлять клиенту среду разработки. Мы ему готовые бинарники поставляем и разрабатывать он ничего не будет. Опять же, если мне для сертификации нужно все сертифицировать, в том числе и тот код, который был использован при разработке сертифицированной ОС - то это выглядит странно, как минимум. Или же это просто попытка увеличить рынок сертификационных лабораторий?
 

ALSE_User

New member
Сообщения
390
#11
Хороший вопрос) Я исполнитель и внизу цепочки, но скорее всего МО


Вот тут полностью солидарен. Учитывая что fly построен на Qt и он очевидно сертифицирован, вместе с Qt. Отсюда и вопрос.

На предыдущей работе мы могли спокойно использовать все, что идет в поставке Астры. А тут видимо политика изменилась и стало все резко неудобно.
Если МО, то придется сертифицировать все бинарники, которые Вы им поставляете.
А вообще то вопрос к заказчику (что в договоре на разработку/поставку написано) и к тому органу по аттестации, который вашу организацию обслуживает. Вы этот орган и спросите - что нужно сертифицировать/аттестовывать и действуйте в русле ответов.
 

drug

New member
Сообщения
20
#12
Если МО, то придется сертифицировать все бинарники, которые Вы им поставляете.
Это понятно. Вопрос в том, почему я должен сертифицировать бинарники Qt, которые использовались при сборке fly? Они же уже по определению сертифицированы? Конечно, РусБитТех может сказать, что у них модифицированные исходники, но это просто банально же подкладывание свиньи разработчикам.
У меня вопрос именно к разработчикам Астры, почему усложнили жизнь остальным разработчикам.
 
Последнее редактирование:

ALSE_User

New member
Сообщения
390
#13
Это понятно. Вопрос в том, почему я должен сертифицировать бинарники Qt, которые использовались при сборке fly? Они же уже по определению сертифицированы? Конечно, РусБитТех может сказать, что у них модифицированные исходники, но это просто банально же подкладывание свиньи разработчикам.
У меня вопрос именно к разработчикам Астры, почему усложнили жизнь остальным разработчикам.
Так Вы разработчикам это вопрос и задайте, в техподдержке... Здесь Вы представителей РусБИТТех-а вряд ли сыщете.
 

drug

New member
Сообщения
20
#14
Так Вы разработчикам это вопрос и задайте, в техподдержке... Здесь Вы представителей РусБИТТех-а вряд ли сыщете.
Вот странно, что техподдержка здесь отсутствует. Монетизируют все постепенно. Но вдруг кто-то из разработчиков (не Астры) уже сталкивался с сертификацией продуктов на базе Астры 1.7 и может поведать что к чему.
 

oko

New member
Сообщения
1 222
#15
*в сторону*
По линии МО все зависит от: кривизна первичного ТЗ -> кривизна его согласования -> кривизна его правок на основе прошлых кривых ТЗ -> дебилизм вышестоящих по отношению к нижестоящим == как правило вовсе не то, что хотелось, зато проверяться должно от и до, увы. Но в некоторых случаях удается продавить позицию, что "используя компоненты по Х классу НДВ, не следует их повторно проверять в рамках результирующего продукта на тот же самый Х класс НДВ"...
По линии ФСТЭК все зависит всецело от сертификационной лаборатории и кривизные первичного ТЗ (Задания по безопасности / Технических условий). Но в общем случае, если модификаций в юзаемых либах из состава дистрибутива нет, + эти либы также проходили сертификацию по ОУД == не требуется проверка этих компонент. А если разрабатываемый софт для выполнения функций безопасности тупо дергает системные проверенные тулзы, то вообще красота...
По линии ФСБ... Ну, там своя атмосфера, ага...

Поэтому, imho, запрашиваем у Астры официальное письмо с перечнем интересующих нас компонент, которые планируем юзать, на предмет: распространяется ли на них в полной мере условия сертификата соответствия по требуемому уровню ОУД или НДВ (этот уровень уже должны сами знать). Если ответ устраивает - прикрываемся им в период последующей разработки и сертификации. Если не устраивает, то пытаемся договориться и выснить полноту картины в нужно сертификационной лаборатории. Третьего, боюсь, не дано...
И это простой случай, когда мы не разрабатываем непосредственно новое СЗИ (тем более СКЗИ), а делаем тупо "доверенный софт" под "доверенную ОС"...