Полное меню
- Актуальное
законодательство - Интернет
и право- - Рассылка ''Закон есть закон''
- - Форум сайта (архив)
- - Законодательство
- - Судебная практика (необычная)
- - Судебная практика (авторская)
- - Процедура UDRP и и решения WIPO
- - Книги серии ''Интернет и Право''
- - Книги в открытом доступе
- - Учебный курс ''Интернет и Право''
- - Учебный курс ''Доменные споры''
- - Литература по ''Интернет и Право''
- - Литература по интел. собственности
- - Научный уголок (работы гостей)
- - Авторские публикации
- Информационные
материалы - ЮРИДИЧЕСКИЕ
УСЛУГИ- - Перечень юридических услуг
- - Карта юридических услуг
- - Юридическая консультация
- - Доменные споры (RU), авторское право
- - Международный суд по доменам (COM)
- - Защита прав на маркетплейсе (WB, Ozon)
- - Защита прав в соцсетях (Vk, Ok, FB)
- - Купля-продажа домена, сайта, ПО
- - Досудебное урегулирование конфликта
- - Защита чести и деловой репутации
- - Отмена блокировки сайта/домена РКН
- - ФАС: товарные знаки, авторское право
- - Регистрация ПО/сайта (Роспатент)
- - Юридическая проверка домена
- - Нотариальное заверение сайтов
- - Способы и формы оплаты услуг
- - Мы в СМИ
- - О компании, клиенты
- - Наши дела и победы
- - Контакты и реквизиты
- Информация
о сайте -
ОписаниеИсточник публикации М., 2022 Примечание к документу Текст документа приведен в соответствии с публикацией на сайте /template/go.php?url=https://platform.gov.ru/ по состоянию на 22.09.2023. Название документа "Единая цифровая платформа Российской Федерации "ГосТех" для создания, развития и эксплуатации государственных информационных систем. Методические рекомендации по обеспечению безопасности при разработке программного обеспечения с использованием компонентов единой цифровой платформы Российской Федерации "ГосТех". Версия 1.0" "Единая цифровая платформа Российской Федерации "ГосТех" для создания, развития и эксплуатации государственных информационных систем. Методические рекомендации по обеспечению безопасности при разработке программного обеспечения с использованием компонентов единой цифровой платформы Российской Федерации "ГосТех". Версия 1.0"Оглавление"ГОСТЕХ" ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ
ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ С ИСПОЛЬЗОВАНИЕМ КОМПОНЕНТОВ ЕДИНОЙ ЦИФРОВОЙ
ПЛАТФОРМЫ РОССИЙСКОЙ ФЕДЕРАЦИИ "ГосТех"
ВЕРСИЯ 1.0
В настоящих методических рекомендациях использованы ссылки на следующие нормативно-правовые акты и стандарты:
Таблица 1
Правовые акты и стандарты
В настоящих методических рекомендациях применены следующие термины и сокращения с соответствующими определениями:
Таблица 2
Термины, сокращения и определения
Методические рекомендации по обеспечению безопасности при разработке ПО с использованием компонентов единой цифровой платформы Российской Федерации "ГосТех" (далее - Методические рекомендации) разработаны в целях реализации положений "Концепции создания и функционирования единой цифровой платформы Российской Федерации "ГосТех".
Методические рекомендации направлены на обеспечение необходимого уровня защиты информации, обрабатываемой ГИС на Платформе "ГосТех", посредством реализации мер, минимизирующих количество уязвимостей и недостатков программ на всех этапах жизненного цикла ПО.
Настоящий документ содержит рекомендации по реализации требований по разработке БПО на Платформе "ГосТех", установленных ГОСТ Р 56939.
При выявлении подтвержденных уязвимостей и недостатков программ критического и высокого уровня влияния во вновь создаваемом ПО при проведении его тестирования инструментальными средствами запрещается перевод такого ПО в продуктивную среду функционирования ГИС на Платформе "ГосТех".
На всех этапах жизненного цикла ПО должна быть обеспечена конфиденциальность информации о проекте архитектуры программы, исходном коде, средствах и результатах проводимых инструментальных тестирований ПО и его компонентов. В случаях привлечения к проведению инструментальных тестирований ПО экспертных организаций, с такими организациями должны быть заключены соответствующие соглашения о неразглашении определяющие требования по обеспечению конфиденциальности, контроль и ответственность за их невыполнение, либо обязательства о неразглашении должны быть включены в соответствующий государственный контракт (договор, соглашение), заключаемый с экспертной организацией.
Использование заимствованных компонентов (библиотек, фреймворков, интерпретируемых скриптов и др.) сторонних разработчиков допускается только при наличии текстов исходного кода данных компонентов, кроме компонентов, включенных в состав Платформы "ГосТех" в соответствии с настоящим документом и "Методическими рекомендации по включению сервисов в единую цифровую платформу Российской Федерации "ГосТех".
Графическое описание организации рекомендуемого процесса разработки БПО на Платформе "ГосТех" приведено в приложении N 1.
Методические рекомендации предназначены для использования Заказчиками при разработке технических заданий, на создание, развитие, эксплуатацию ГИС на Платформе "ГосТех" и Разработчиками ПО, выполняющими работы по созданию, развитию и эксплуатации ПО ГИС на Платформе "ГосТех" в рамках заключенных государственных контрактов (договоров, соглашений).
Данные методические рекомендации следует применять совместно с ГОСТ Р 56939 и ГОСТ Р 58412 для распределение ролей и обязанностей, связанных с реализацией мер по разработке безопасного ПО, между работниками Разработчика ПО, а также для идентификации и оценки угроз безопасности информации, которые могут возникать при разработке ПО.
Методические рекомендации не применяются при разработке ПО средств защиты информации и средств криптографической защиты информации. Такого типа ПО должно разрабатываться в строгом соответствии с требованиями законодательства Российской Федерации.
В целях предотвращения появления уязвимостей программы Заказчиком должны быть сформулированы требования по безопасности, предъявляемые к разрабатываемому ПО.
В качестве источников для формирования требований Заказчик может использовать требования законодательства Российской Федерации, правовых актов федеральных органов исполнительной власти, национальных и отраслевых стандартов, перечень требований Заказчика, предполагаемые сценарии применения ПО.
Для формирования требований Заказчику необходимо собрать информацию об области применения разрабатываемого ПО, составе планируемой к обработке информации, факте отнесения обрабатываемой информации в ГИС к категории информации ограниченного доступа и классе защищенности ГИС.
На основании полученных данных Заказчику необходимо выполнить:
- предварительный анализ потенциальных угроз безопасности информации ПО в соответствии с рекомендациями пункта 4.2 данного документа;
- идентифицировать и сформулировать цели защиты информации, достижение которых должно обеспечиваться разрабатываемым ПО;
- сформулировать и задокументировать требования по безопасности в форме функциональных и нефункциональных требований <1>.
--------------------------------
<1> Функциональные требования по безопасности: описывают действия, которые должно выполнять ПО в целях нейтрализации угроз безопасности информации, а нефункциональные требования описывают свойства и параметры ПО, имеющие отношение к нейтрализации угроз безопасности информации.
Требования по безопасности в зависимости от их назначения рекомендуется описывать в подразделах "Требования к надежности" и/или "Требования к функциональным характеристикам" раздела "Требования к программе или программному изделию" технического задания, разрабатываемого в соответствии с ГОСТ 19.201 или в отдельном разделе технического задания на создание или развитие ГИС на Платформе "ГосТех".
Техническое задание на создание, развитие ГИС на ЕЦП "ГосТех" должно быть согласовано Заказчиком с федеральным органом исполнительной власти в области обеспечения безопасности и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, в пределах их полномочий в части требований о защите информации, в соответствии с Постановление Правительства РФ от 6 июля 2015 г. N 676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации".
Пример требований по безопасности к разрабатываемому ПО:
- все поступающие в ПО входные данные должны подлежать контролю целостности, полноты и аутентичности;
- в ПО должна быть реализована обработка исключительных ситуаций, возникающих в процессе функционирования программы;
- информационные сообщения пользователю ГИС на Платформе "ГосТех" не должны содержать информацию о наименовании программных технических средств, использующихся в среде функционирования ПО и их версиях.
Рекомендованные требования по безопасности к разрабатываемому ПО в составе ГИС на Платформе "ГосТех" для различных классов защищенности, в соответствии с приказом ФСТЭК России от 11 февраля 2013 г. N 17 "Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах", приведены в Приложении N 2.
В целях определения актуальных угроз безопасности информации, а также в целях формирования исходных данных Разработчику ПО необходимо разработать и задокументировать проект архитектуры программы и провести моделирование угроз безопасности информации.
Проектирование архитектуры должно удовлетворять следующим принципам:
1) разумной простоты: ПО и его элементы, должны быть возможно более простыми (иметь минимально возможный размер исходного кода), чтобы уменьшить вероятность возникновения уязвимостей и упростить проверки безопасности;
2) безопасных умолчаний: доступ к информации, информационное и (или) управляющее взаимодействие в отсутствие разрешения на эту операцию должны быть запрещены;
3) полноты перекрытия: реализация механизма обеспечения безопасности должна иметь сквозной характер (охватывать все структурные элементы ПО);
4) разделения привилегий: механизм обеспечения безопасности должен позволять выполнять доступ к информации или выполнение иной операции на основе двух и более независимых факторов, где это возможно;
5) наименьших привилегий: каждый процесс должен обладать минимально необходимыми привилегиями для выполнения установленных для него задач;
6) минимизации зависимостей: количество элементов ПО, которые используются несколькими пользователями или субъектами с различными привилегиями, должно быть минимально;
7) эшелонированной защиты: наличие множественной защиты, в частности - в виде уровней, с целью предотвращения или сдерживания угроз безопасности информации;
8) трудозатрат: стоимость защиты не должна превосходить стоимость потенциальных потерь в случае успешного внешнего воздействия на ПО;
9) компромиссного механизма обнаружения: использование (где это позволяют требования безопасности информации) недорогого механизма надежного своевременного обнаружения факта внешнего воздействия на ПО взамен дорогостоящего механизма обеспечения безопасности, который способен предотвратить это воздействие.
Моделирование угроз безопасности информации должно быть проведено Разработчиком ПО на этапе выполнения проектирования архитектуры программы жизненного цикла ПО.
По результатам моделирования угроз Разработчику ПО необходимо скорректировать (уточнить) требования по безопасности, предъявляемые к разрабатываемому ПО и проект архитектуры программы.
Процедура моделирования угроз должна быть проведена для выявления потенциальных угроз безопасности информации, обоснования требований по безопасности, предъявляемых к разрабатываемому ПО в составе ГИС на Платформе "ГосТех", и выработки возможных мер по нейтрализации актуальных угроз безопасности информации.
В процессе моделирования должны быть рассмотрены угрозы безопасности информации, которые могут возникать в процессах разработки и использования ПО в составе ГИС на Платформе "ГосТех".
Для формирования перечня и описания угроз безопасности информации, которые могут возникать в процессах разработки ПО, следует использовать ГОСТ Р 58412 "Защита информации. Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО".
Для формирования перечня и описания угроз безопасности информации, которые могут возникать при использовании ПО в составе ГИС на Платформе "ГосТех", Разработчику ПО необходимо использовать:
- сведения о предполагаемых компонентах программы;
- сведения об интерфейсах компонентов программ;
- сведения о предполагаемых алгоритмах, методах и протоколах взаимодействия компонентов программы;
- сведения о вариантах и методах конфигурирования программы, ее компонентов, а также планируемой среды функционирования ПО;
- информацию о заимствованных компонентах сторонних разработчиков;
- информацию из банка данных угроз безопасности информации ФСТЭК России (/template/go.php?url=https://bdu.fstec.ru).
Также допускается использовать любую иную информацию, в том числе из открытых источников, связанную с типовыми сценариями компьютерных атак и угрозами безопасности информации.
Моделирование угроз рекомендуется проводить в рамках следующих этапов:
- структурный анализ потоков данных;
- перечисление угроз безопасности информации и оценка их актуальности;
- разработка мер для снижения рисков реализации актуальных угроз.
Реализация разработанных мер и проверка их эффективности должна быть проверена на этапах конструирования и комплексирования ПО и выполнения квалификационного тестирования ПО соответственно.
На этапе структурного анализа данных Разработчику ПО необходимо построить диаграмму потоков данных и проанализировать ее на наличие актуальных угроз, связанных с нарушением конфиденциальности, целостности и доступности обрабатываемой информации, например угроз, связанных с подменой данных, несанкционированным доступом, раскрытием информации, нарушением функционирования программы, исполнением произвольного кода и др.
Диаграмма потоков данных должна содержать и описывать следующие компоненты программы:
- процессы;
Внешние элементы - объекты (источники и потребители информации), являющиеся внешними по отношению к разрабатываемому ПО. К внешним источникам, например, можно отнести пользователей программы, программы и информационные системы, с которыми осуществляется обмен информацией.
Внутренние элементы - объекты (источники и потребители информации), входящие в состав разрабатываемого ПО как отдельные объекты.
Процессы - любые процессы, реализуемые в программе и осуществляющие обработку информации (преобразование входных данных в выходные).
Примером могут служить процедуры выполнения каких-либо расчетов и сортировки данных.
На диаграмме потоков данных каждый процесс должен быть пронумерован в формате a.b, где, a - номер группы процессов, реализующих одну бизнес-функцию в программе, b - номер процесса, идентифицирующий его в группе процессов. В случае если процесс самостоятельно реализует бизнес-функцию, то для такого процесса допускается нумерация вида a.0. Нумерация процессов осуществляется Разработчиком ПО для последующей реализации возможности прослеживания исходного кода программы к проекту архитектуры программы на этапе конструирования и комплексирования ПО.
Хранилище данных - файлы, репозитории, базы данных, таблицы в базах данных и иные сущности, осуществляющие хранение/временное хранение информации для ее последующего использования внешними элементами или процессами разрабатываемой программы.
Потоки данных - направления получения и передачи информации между внешними элементами, процессами и хранилищами данных. При описании потоков данных Разработчику ПО необходимо также указывать краткое описание входных и выходных данных, например "идентификатор пользователя", "результаты расчета", "бизнес-данные". Для повышения качества моделирования угроз, Разработчику ПО рекомендуется выделять на диаграмме потоки передачи информации ограниченного доступа и критических бизнес-данных, влияющих на процесс функционирования программ и ГИС на Платформе "ГосТех".
для диаграммы потоков данных
Рекомендуемое графическое изображение на диаграмме потоков данных компонентов программы представлено на рисунке 1. Пример диаграммы потоков данных программы, составленный с учетом рекомендации настоящего документа представлен на рисунке 2.
 По результатам структурного анализа все выявленные угрозы безопасности информации, их описание и возможные меры по их нейтрализации включаются Разработчиком ПО в итоговый перечень угроз безопасности информации, которые могут возникать в процессах разработки ПО и при использовании ПО в составе ГИС на Платформе "ГосТех", для их последующей оценки.
Оценка выявленных угроз безопасности информации проводится Разработчиком ПО и согласовывается с Заказчиком.
По результатам оценки должен быть определен уровень риска реализации для каждой выявленной актуальной угрозы (критический, высокий, средний, низкий).
Итоговый перечень актуальных угроз безопасности информации должен быть составлен в формате таблицы N 3.
Таблица 3
Результаты моделирования угроз должны быть отражены в разделе "Требования к программе или программному изделию" технического задания на разрабатываемое ПО и в моделях угроз безопасности информации ГИС на Платформе "ГосТех".
В целях получения непротиворечивых и предсказуемых результатов Разработчик ПО должен использовать идентифицированные инструментальные средства разработки (трансляторы, компиляторы, прикладные программы, используемые для проектирования и документирования, редакторы исходного кода программ, отладчики, интегрированные среды разработки и др.).
Для каждого используемого при разработке в составе ГИС на Платформе "ГосТех" инструментального средства Разработчику ПО необходимо определить и зафиксировать следующую информацию:
- наименование и идентификационные признаки инструментального средства;
- наименование разработчика инструментального средства;
- ссылку на эксплуатационные документы инструментального средства;
- значения применяемых при создании программы конфигураций инструментального средства.
Результаты проведенной процедуры идентификации должны быть отражены в проектной документации на разрабатываемое ПО или на создание/развитие ГИС на Платформе "ГосТех".
Рекомендуемая форма представления результатов в проектной документации и пример заполнения представлены в таблице N 4.
Таблица 4
разработки
Разработчик ПО должен актуализировать информацию об используемых инструментальных средствах в случаях добавления новых средств или исключения ранее использованных из процессов разработки ПО.
В целях повышения уровня контроля и предотвращения появления недокументированных функций в разрабатываем ПО Разработчик ПО должен создавать программу на основе проекта архитектуры программы, определенного в ходе выполнения процессов проектирования архитектуры программы.
Для достижения заявленной цели и создания БПО Разработчик ПО должен:
- декомпозировать и уточнить проект архитектуры программы для постановки конкретных технических задач работникам Разработчика ПО, ответственным за создание программы;
- обеспечить создание исходного кода программы на основе актуального проекта архитектуры программы;
- обеспечить прослеживаемость исходного кода программы к проекту архитектуры программы (описанию проектных решений, обеспечивающих выполнение идентифицированных требований к реализуемым функциям ПО и требований по безопасности);
- проверить корректность выполнения технических задач.
Проект архитектуры ПО должен описывать структуру программы, включающую в себя подсистемы и программные модули, их свойства и отношения между ними.
Архитектуру программы рекомендуется описывать в терминах подсистем и программных модулей.
Допускается декомпозиция программных модулей с выделением функций, классов, методов и внешних интерфейсов.
Документирование архитектуры программы рекомендуется выполнять с использованием следующих нотаций и в соответствии с положениями документа "Методические рекомендации по проектированию и утверждению целевой архитектуры домена с использованием Платформы "ГосТех":
- DFD (Data Flow Diagram) - диаграмма потоков данных.
- Диаграммы, используемые в методологиях группы IDEF, ArchiMate и C4;
- UML-диаграммы.
При проектировании программы Разработчику ПО следует руководствоваться принципами проектирования БПО, например: принцип минимальных привилегий, принцип эшелонированной защиты, принцип разделения обязанностей, принцип модульного проектирования, применение принятых стандартов, протоколов, форматов обмена данными.
Прослеживаемость исходного кода программы к проекту архитектуры должна быть обеспечена с помощью уникального ссылочного номера, с использованием которого возможно определить отношение между текстом исходного кода и описанием функциональных компонентов программы (функций, классов, методов, внешних интерфейсов др.) в проекте архитектуры.
Разработчик ПО для обеспечения прослеживаемости исходного кода к проекту архитектуры программы может использовать инструментальные средства.
Пример разметки исходного кода программы на языке программирования C++ для проекта архитектуры программы, представленной в формате диаграммы потоков данных (рисунок N 2), для обеспечения прослеживаемости:
/// Функция 1.1 RegUserProcedure (Краткое описание)
/*!
Регистрация пользователей в системе (Подробное описание)
*/
function RegUserProcedure($vars) {}
Для различных языков программирования разметка исходного кода может различаться в зависимости от их особенностей.
Разработчику ПО следует обеспечить конфиденциальность исходных кодов ПО и его компонентов, в том числе при применении в его отношении средств инструментального тестирования.
Прослеживаемость к архитектуре программы должна быть продемонстрирована Разработчиком ПО в проектной документации в виде диаграмм или таблиц, также рекомендуется продемонстрировать прослеживание для каждого файла или группе файлов с исходным кодом программы с указанием в названии идентификатора соответствия компоненту из проекта архитектуры программы (например, модуль или подсистема).
В целях снижения вероятности появления недостатков при создании программы, увеличения вероятности обнаружения недостатков программы и уменьшения количества ресурсов, на устранение недостатков Разработчик ПО при создании программы должен использовать рекомендованный данным документом перечень правил и рекомендаций оформления исходного кода, направленных на устранение недостатков программ в составе ГИС на Платформе "ГосТех" (потенциально уязвимых конструкций) в исходном коде.
В случае невозможности выполнения рекомендаций по оформлению исходного кода Разработчик ПО должен указывать обоснование факта отказа от их использования в форме комментариев в исходном коде программы.
Основные правила и рекомендации по оформлению исходного кода программ определяются для каждого из языков программирования, разрешенных к использованию для разработки ПО в составе ГИС на Платформе "ГосТех".
Примеры правил и рекомендаций оформления исходного кода для языков C#, JavaScript, Java представлены в Приложении N 3 настоящего документа и являются рекомендованными к применению при разработке ПО на Платформе "ГосТех".
Контроль соблюдения правил и рекомендаций осуществляется на этапах проведения статического анализа кода и экспертизы исходного кода как в автоматизированном режиме с использованием компонентов Платформы "ГосТех", так и ручном режиме.
Разработчик ПО должен проинформировать команды разработки о действующих правилах и рекомендациях по оформлению исходного кода на Платформе "ГосТех" и осуществлять самостоятельный контроль их соблюдения, так как выявление нарушений правил оформления исходного кода на этапе передачи ПО Заказчику может увеличить общее время создания ГИС на Платформе "ГосТех" и, как следствие, привести к нарушению сроков государственных контрактов (договоров, соглашений) и выставлению штрафных санкций Заказчиком в адрес Разработчика ПО.
Устранение нарушений правил и рекомендаций по оформлению исходного кода Разработчику ПО рекомендуется проводить сразу после получения отчетов с результатами проведения контрольных процедур на Платформе "ГосТех".
Статический анализ исходного кода программы должен проводиться в целях выявления недостатков программы (потенциально уязвимых конструкций) в исходном коде программы и проверки соответствия исходного кода порядку его оформления.
Статический анализ всех компонентов, входящих в состав разрабатываемого ПО должен быть проведен до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе "ГосТех" Разработчик ПО должен обеспечить проведение статического анализа добавленных или измененных частей ПО после каждого внесенного изменения.
Рекомендуется выбирать средства статического анализа, предоставляющие возможность проведения анализа различными методами статического анализа: сигнатурного, метода анализа потоков данных, межпроцедурного контекстно-чувствительного анализа, синтаксического анализа, выявления пути распространения ошибки в программе, формальной верификации.
Для повышения уровня покрытия используемых при разработке ПО языков программирования должны использоваться средства статического анализа, позволяющие осуществить статический анализ в отношении всего исходного кода ПО.
Дополнительно рекомендуется при сравнении и выборе средств статического анализа руководствоваться следующими параметрами и характеристиками:
- поддерживаемые языки программирования;
- типы обнаруживаемых недостатков программы;
- методы и правила категоризации выявленных недостатков по уровням критичности.
В целях сокращения времени на создание (развитие) ГИС на Платформе "ГосТех" рекомендуется осуществлять программную интеграцию средств статического анализа со средствами автоматизации процесса разработки ПО, например такими, как: интегрированная среда разработки, инструментальные средства для управления версиями ПО, которые используются в системе управления конфигурацией ПО, инструментальные средства, используемые для автоматизации процесса преобразования исходного кода программы в исполняемые файлы.
Статический анализ исходного кода программы необходимо проводить как в отношении исходного кода разрабатываемой программы, так и в отношении исходного кода компонентов, заимствованных у сторонних разработчиков.
Статический анализ исходного кода заимствованных компонентов возможно не проводить в случае использования доверенных заимствованных компонентов, в отношении которых проведен статический анализ исходного кода разработчиком таких компонентов.
При проведении статического анализа должны выявляться и устраняться следующие недостатки программы:
- несоответствие правилам и рекомендациям по оформлению исходного кода (приложение N 3);
- ошибки, связанные с безопасностью программы;
- остаточный отладочный код.
Результаты каждого проведенного статического анализа должны сохраняться в систему управления конфигурацией ПО.
Потенциальные ошибки в программе, выявленные в ходе статического анализа ПО, должны быть обработаны вручную для экспертного определения их истинности или ложности. Истинные ошибки в программе должны быть помечены как подлежащие исправлению. Просмотр выданных анализатором предупреждений необходимо выполнять в случае анализа измененных частей ПО - не позже, чем через 3 рабочих дня после выполнения анализа, в случае анализа ПО целиком - не позже, чем через 10 рабочих дней после выполнения анализа.
Устранение выявленных потенциальных ошибок в программе, которые в ходе просмотра были отнесены к истинным с уровнем влияния критический и высокий, должно быть выполнено при анализе измененных частей ПО - не позже, чем через 10 рабочих дней после выполнения анализа, при анализе ПО целиком - не позднее начала квалификационного тестирования ПО. Выполненные изменения исходного кода ПО должны быть отмечены в системе контроля версий исходного кода как исправляющие предупреждения статического анализа с указанием идентификаторов выданных предупреждений в хранилище результатов анализатора.
Выявленные в ходе статического анализа потенциальные ошибки в программе, которые не были признаны истинными в ходе разметки предупреждений, следует использовать в ходе динамического анализа на этапе квалификационного тестирования ПО в качестве дополнительной информации о возможно уязвимых местах программы, если используемые инструменты динамического анализа поддерживают такую возможность.
Контроль над ходом устранения выявленных потенциальных ошибок в программе следует выполнять не реже одного раза в месяц. Рекомендуется использовать соответствующие средства разработки (система контроля версий, отслеживания ошибок в программе) для формирования отчета о количестве выявленных и исправленных ошибок в программе.
В ходе проведения регулярного статического анализа ПО конфигурация и настройка статического анализатора должны пересматриваться по мере развития ПО, добавления сторонних компонентов, выхода новых версий статического анализатора и других факторов влияния. При этом должен учитываться заданный уровень безопасности, предъявляемый к конфигурации статического анализатора.
Обязательно статический анализ должен быть проведен для каждой версии ПО, поставляемой Заказчику.
В случае использования языка программирования, не поддерживаемого статическим анализатором, должна быть проведена экспертиза исходного кода исследуемого ПО.
По результатам проведения статического анализа исходного кода программы Разработчиком ПО должны быть устранены все дефекты критического и высокого уровня влияния.
Результаты проведенного статического анализа и факт устранения выявленных недостатков программы в отношении финальной версии ПО должны быть отражены в проектной документации на создание (развитие) ГИС на Платформе "ГосТех". Форма представления результатов приведена в таблице N 5. Допускается в процессе разработки ПО использовать электронные отчеты в формате, формируемом средствами статического анализа.
Следует обеспечить конфиденциальность информации, связанной с выявленными в ходе статического анализа исходного кода программы уязвимостями программы.
Таблица 5
исходного кода
Общие рекомендации по организации процесса статического анализа исходного кода программы представлены на рисунке N 3.
 статического анализа
В целях выявления потенциально уязвимых конструкций в исходном коде программы после проведения статического анализа исходного кода должна быть проведена экспертиза исходного кода, разрабатываемой программы и компонентов, заимствованных у сторонних разработчиков, если для этих компонентов доступен исходный код программы.
Экспертиза исходного кода всех компонентов, входящих в состав разрабатываемого ПО должна быть проведена до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе "ГосТех" Разработчик ПО должен обеспечить проведение экспертизы исходного кода добавленных или измененных частей ПО после каждого внесенного изменения.
В связи с трудоемкостью процедуры, экспертизу исходного кода рекомендуется проводить в отношении подмножеств исходного кода программы, реализующих наиболее критичные функции с точки зрения бизнес-процессов Заказчика и создания БПО.
Для проведения экспертизы исходного кода рекомендуется использовать инструментальные средства.
Инструментальные средства для проведения экспертизы исходного кода рекомендуется выбирать исходя из следующих параметров и характеристик:
- качество проводимого анализа;
- поддерживаемые форматы входных и выходных данных;
- возможность интеграции с другими инструментальными средствами, используемыми в процессе разработки ПО;
- поддержка многопользовательского режима работы;
- простота освоения, наличие эксплуатационных документов;
- производительность;
- требуемые ресурсы;
- стоимость.
Проведение экспертизы исходного кода рекомендуется проводить после устранения недостатков программы, выявленных по результатам статического анализа.
Экспертизу исходного кода заимствованных компонентов возможно не проводить в случае использования доверенных заимствованных компонентов, в отношении которых проведена экспертиза исходного кода разработчиком таких компонентов.
Результаты экспертизы и факт устранения выявленных недостатков программы должны быть представлены в виде протокола.
Общие рекомендации по организации процесса проведения экспертизы исходного кода программы представлены на рисунке N 4.
 исходного кода программы
Для подтверждения выполнения требований по безопасности, предъявляемых к разрабатываемому ПО в составе ГИС на Платформе "ГосТех", должно проводиться функциональное тестирование программы.
Функциональное тестирование всех компонентов, входящих в состав разрабатываемого ПО должно быть проведено до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе "ГосТех" Разработчик ПО должен обеспечить проведение функционального тестирования добавленных или измененных частей ПО после каждого внесенного изменения.
Методика функционального тестирования по проверке требований по безопасности к ПО должна быть включена в программу и методику испытаний на создание (развитие) ГИС на Платформе "ГосТех".
Оформление программы и методики испытаний должно осуществляться в соответствии с ГОСТ 19.301.
Программа и методика испытаний должна содержать план проведения функционального тестирований ПО, описание выполняемых тестов и перечень инструментальных средств, используемых для проверки, а также проверки обхода функциональных возможностей штатными средствами.
Рекомендованный формат описания процедуры тестирования представлен в таблице N 6.
Таблица 6
Программа и методика испытаний должна предусматривать проверки для всех требований, предъявляемых к разрабатываемому ПО и обеспечивать наиболее полную проверку этих требований.
Для автоматизации выполнения тестовых процедур, а также для автоматизации управления процессом тестирования и хранения информации о результатах проведения функционального тестирования могут использоваться инструментальные средства.
Все используемые инструментальные средства должны быть идентифицированными в соответствии с рекомендациями п. 5.1 данного документа.
Результаты проведения функционального тестирования ПО должны быть включены в протокол предварительных испытаний ГИС на Платформе "ГосТех".
Рекомендуемый формат оформления результатов функционального тестирования ПО представлен в таблице N 7.
Таблица 7
Все выявленные недостатки программы критического и высокого уровня влияния должны быть устранены Разработчиком ПО до момента ввода ГИС на Платформе "ГосТех" в эксплуатацию.
Общие рекомендации по организации процесса проведения функционального тестирования приведены на Рисунке N 5.
 функционального тестирования
В рамках проведения квалификационного тестирования разрабатываемого ПО должно быть проведено фаззинг-тестирование программы для выявления уязвимостей программы.
Фаззинг-тестирование должно быть проведено до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе "ГосТех" Разработчик ПО должен обеспечить проведение фаззинг-тестирования добавленных или измененных частей ПО после каждого внесенного изменения.
В процессе фаззинг-тестирования осуществляется манипулирование входными данными программы или ее компонентов и фиксирование нарушений штатного поведения в результате обработки таких данных.
Выявленные нарушения анализируются с целью формирования перечня потенциальных уязвимостей программы, который в дальнейшем используется при проведении тестирования проникновения.
Требуется выполнять фаззинг-тестирование модулей ПО с инструментированием кода модулей, обеспечивающим реализацию генетических алгоритмов фаззинг-тестирования, в случае если доступны инструменты, позволяющие осуществлять такое фаззинг-тестирование в отношении ПО и его модулей с учетом языков программирования, компиляторов и среды функционирования ПО.
При выборе инструментальных средств рекомендуется руководствоваться следующими характеристиками:
- поддерживаемые типы фаззинг-тестирования;
- поддерживаемые протоколы и форматы входных данных;
- наличие функции автоматического формирования отчетов о результатах тестирования (функция обратной связи).
Рекомендуется использовании в фаззинг-тестировании сборки ПО с санитайзерами, с целью выявления критических ошибок в программе, не приводящих к аварийному завершению.
Рекомендуется проводить фаззинг-тестирование в отношении всей программы или ее отдельных компонентов, например библиотек, исполняемых компонентов, обеспечивающих обработку входящего сетевого трафика, команд или файлов. Следует сосредоточить усилия в первую очередь на компонентах программы, требующих для функционирования повышенных привилегий или реализующий функции безопасности. Рекомендуется проводить фаззинг-тестирование для экспортируемых интерфейсов библиотек и для всех интерфейсов, через которые программа получает внешние данные. Следует проводить фаззинг-тестирование в отношении заимствованных у сторонних разработчиков компонентов.
Формирование тестовых наборов входных данных осуществляется вручную или с использованием инструментальных средств (фаззер). Для генерации тестовых наборов входных данных фаззер может использовать: эталонные образцы входных данных (файлы), исходный код программы или компонента программы, сведения о форматах входных данных программы, используемых протоколах взаимодействия.
Результаты фаззинг-тестирования должны быть представлены в виде протокола.
Следует обеспечить конфиденциальность информации, связанной с выявленными в ходе фаззинг-тестирования программы уязвимостями программы.
Общие рекомендации по организации процесса проведения фаззинг-тестирования приведены на Рисунке N 6.
 фаззинг-тестирования
В рамках проведения квалификационного тестирования разрабатываемого ПО для ГИС на Платформе "ГосТех" необходимо проводить динамический анализ кода программы для выявления недостатков программы.
Динамический анализ кода программы должен быть проведен до перевода ПО в продуктивную среду функционирования, с привлечением сторонней организации, обладающей компетенцией в области выявления уязвимостей программ, при этом в целях сокращения временного периода на создание (развитие) ГИС на Платформе "ГосТех" Разработчик ПО должен обеспечить проведение динамического анализа кода программы добавленных или измененных частей ПО после каждого внесенного изменения.
Динамический анализ кода программы должен проводится в режиме непосредственного исполнения (функционирования) кода с применением инструментальных средств.
Результаты тестирования должны быть представлены в виде протокола.
Следует обеспечить конфиденциальность информации, связанной с выявленными в ходе динамического анализа кода программы уязвимостями программы.
Для выполнения динамического анализа рекомендуется применять следующие методы:
- динамическая бинарная трансляция;
- анализ помеченных данных;
- снятие трассы, выявление пути распространения ошибки.
При выборе инструментальных средств рекомендуется руководствоваться следующими параметрами:
- поддерживаемые среды функционирования программ, для которых возможно проведение динамического анализа;
- типы обнаруживаемых недостатков и реализованные методы динамического анализа (анализ активности и потоков взаимодействия программы, динамическая бинарная трансляция, отслеживание помеченных данных, сканирование интерфейсов получения входных данных, трассировка).
Динамический анализ рекомендуется проводить поэтапно для различных частей исходного кода, разделенных по степени его критичности с точки зрения обеспечения информационной безопасности.
В зависимости от выбранных инструментальных средств и соответствующих методов проведения динамического анализа кода программы, в некоторых случаях, рекомендуется выполнение инструментации исходного кода, которую необходимо выполнить до осуществления преобразования исходного кода программы в исполняемый код. Этот факт следует учесть при внедрении процедур динамического анализа кода программы в процесс разработки ПО, а именно в описании процедуры преобразования исходного кода в исполняемый необходимо предусмотреть этап получения инструментированного экземпляра исходного кода программы или отдельных ее модулей.
Запуск инструментальных средств динамического анализа может выполняться непосредственно работниками вручную или осуществляться автоматически инструментальными средствами, которые используются в процессе конструирования и комплексирования ПО, в зависимости от наличия технической возможности автоматизации в конкретной реализации информационной технологии.
Динамический анализ рекомендуется применять на регулярной основе при выполнении одного или нескольких из следующих условий:
- любое преобразование исходного кода в исполняемый и выпуск любых промежуточных версий ПО;
- выпуск версий ПО, предназначенных для передачи Заказчику;
- наступление определенных временных условий, определяемых организационно-распорядительными документами Разработчика ПО (рекомендуется проводить динамический анализ не реже 1 раза в 180 дней);
- переход процесса разработки на новую стадию.
Общие рекомендации по организации процесса проведения динамического анализа приведены на Рисунке N 7.
 динамического анализа
В целях выявления уязвимостей Заказчиком должно быть организовано проведение тестирования на проникновение в отношении ГИС на Платформе "ГосТех", с привлечением сторонних организаций, обладающих компетенцией в области проведения такого рода испытаний.
В рамках организованного тестирования на проникновение также должны быть проведены тесты, направленные на выявление уязвимостей в ПО в составе ГИС на Платформе "ГосТех".
Тестирование на проникновение предполагает выявление уязвимостей программы путем моделирования (имитации) действий потенциального нарушителя.
Выполняемые тесты должны разрабатываться с учетом:
- проекта архитектуры программы;
- результатов моделирования угроз безопасности информации;
- результатов статического анализа;
- результатов экспертизы исходного кода;
- результатов динамического анализа кода программы;
- фаззинг-тестирования.
При определении проверяемых в ходе тестирования на проникновения тестовых конфигураций программы рекомендуется зафиксировать характеристики элементов среды функционирования ПО, например версии операционных систем или систем управления базами данных.
Для разработки тестов рекомендуется использовать общепризнанные стандарты и руководства по анализу защищенности, включая:
- Penetration Testing Execution Standard (PTES);
- Open Source Security Testing Methodology Manual (OSSTMM);
- Open Web Application Security Project (OWASP) Testing Guide;
- Common Vulnerability Scoring System (CVSS).
Тестирование на проникновение должно включать в себя следующие этапы:
- внешнее тестирование на проникновение, состоящее из анализа защищенности сетевого периметра среды функционирования ПО, направленное на получение доступа к ПО через элементы среды функционирования и дальнейшее развитие атаки через эти элементы;
- внутреннее тестирование на проникновение.
Внешнее тестирование на проникновение должно быть направлено на демонстрацию возможных сценариев атаки, позволяющие нарушителю обойти механизмы защиты среды функционирования ПО и функций безопасности ПО в целях получения максимальных привилегии в критически важных компонентах. Работы рекомендуется проводить методом "черного ящика" (без предварительных знаний о ПО и среде функционирования) от лица высококвалифицированного внешнего нарушителя со стороны сети Интернет.
В рамках внешнего тестирования на проникновение рекомендуется провести анализ защищенности сетевого периметра среды функционирования, направленный на получение доступа к ее элементам с наивысшими привилегиями.
Для этого рекомендуется провести следующие мероприятия:
- пассивный сбор информации об элементах среды функционирования ПО;
- активный сбор информации о среде функционирования ПО и самой программы, в том числе сканирование портов, идентификация доступных сетевых служб, ручной анализ отдельных служб;
- внешнее инструментальное сканирование, направленное на выявление уязвимостей в доступных сетевых службах среды функционирования;
- анализ безопасности программы с использованием инструментальных средств и ручного анализа;
- ручной анализ уязвимостей, включающий выявление недостатков аутентификации, важной информации в открытом доступе, недостатков контроля доступа;
- подбор учетных данных;
- эксплуатацию одной или нескольких выявленных уязвимостей.
Развитие атаки с использованием полученных привилегий и перечисленных выше методов.
Внутреннее тестирование должно продемонстрировать получение максимально возможного уровня доступа в критически важные элементы среды функционирования ПО с использованием модели внутреннего нарушителя.
Внутреннее тестирование на проникновение рекомендуется проводить без использования наложенных средств защиты информации среды функционирования и отключенными функциями защиты информации среды функционирования (при их наличии и технической возможности их отключения).
При внутреннем тестировании рекомендуется проводить следующие виды проверок (которые проводятся в зависимости от текущего уровня привилегий и приемлемости рисков, связанных с данными проверками):
- подключение к среде функционирования ПО, в том числе, при необходимости, обход механизмов защиты;
- активный сбор информации о среде функционирования, включая инструментальное сканирование открытых портов и идентификацию доступных сетевых служб;
- инструментальное сканирование, направленное на поиск известных уязвимостей на исследуемых компонентах ПО и ресурсах среды функционирования;
- анализ защищенности ПО как инструментальными, так и ручными методами;
- подбор учетных данных (идентификаторов, паролей, ключей) как напрямую путем прямых попыток доступа к ресурсам, так и офлайн-подбор на основе хеш-значений;
- эксплуатация одной или нескольких выявленных уязвимостей и повышение привилегий (при наличии возможности);
- развитие атаки с использованием перечисленных выше методов вплоть до получения доступа к одному или нескольким критически важным компонентам среды функционирования либо до исчерпания всех доступных на момент тестирования методов атак.
Результаты тестирования на проникновение должны быть отражены в тестовой документации на ГИС на Платформе "ГосТех". Описание организационных и (или) технических мер защиты, направленных на нейтрализацию недостатков программы и уязвимостей, выявленных по результатам тестирования, должны быть отражены в эксплуатационной документации на ГИС на Платформе "ГосТех".
Следует обеспечить конфиденциальность информации, связанной с выявленными в ходе тестирования на проникновение уязвимостями программы.
Общие рекомендации по организации процесса проведения тестирования на проникновение приведены на Рисунке N 8.
 на проникновение
В целях обнаружения модификации ПО или любого расхождения между оригиналом и версией, полученной Заказчиком, рекомендуется использовать механизмы электронной подписи Разработчика ПО (технология code signing) и (или) средства контрольного суммирования поставляемого дистрибутива программы, пломбирование упаковки с поставляемым дистрибутивом программы и документацией, наклейкой, разрываемой при первом вскрытии упаковки.
Средство контрольного суммирования должно соответствовать требованиям документов ФСТЭК России и ФСБ России и обеспечивать:
- вычисление контрольных сумм, заданных файлов/директорий по алгоритмам ГОСТ Р 34.11-2012;
- совместимость с операционными системами семейства Linux;
- возможность выгрузки результатов в структурированном формате, например CSV;
- возможность сравнения контрольных сумм заданных файлов/директорий в соответствии со списком.
При использовании средств автоматизации процесса доставки электронных версий документации и дистрибутивов ПО все версии электронных документов и дистрибутивов должны быть подписаны квалифицированной усиленной электронной подписью ответственного (уполномоченного) сотрудника Разработчика ПО.
Также в целях обнаружения модификации файлов программы (или отдельных ее частей, например, обновлений), распространяемых на физическом носителе или по каналам связи, рекомендуется обеспечивать возможность аутентификации источника, который служит хранилищем для распространяемых файлов.
В качестве мер для программ (и их частей), которые распространяются на физических носителях, применяется упаковка с применением средств, позволяющих обнаружить нарушение ее физической целостности (защитные ленты, наклейки, печати, которые разрушаются при нарушении целостности упаковки).
В комплекте эксплуатационных документов следует включить описание действий Заказчика, позволяющие выполнить проверку целостности упаковки, проверке электронных подписей и контрольных сумм экземпляров ПО.
Данные рекомендации должны применяться в совокупности с рекомендациями, представленными в документе "Методические рекомендации по включению сервисов в единую цифровую платформу Российской Федерации "ГосТех".
В состав поставляемого ПО должны быть включены эксплуатационные документы (Руководство пользователя и Руководство администратора) в объеме, достаточном для безопасной установки, инициализации и безопасного применения программы.
Руководство пользователя должно содержать описание:
- режимов работы средства;
- принципов безопасной работы средства;
- функций и интерфейсов функций средства, доступных каждой роли пользователей;
- параметров (настроек) безопасности средства, доступных каждой роли пользователей, и их безопасных значений;
- типов событий безопасности, связанных с доступными функциями средства;
- действий после сбоев и ошибок эксплуатации средства.
Руководство администратора должно содержать описание:
- действий по приемке поставленного средства;
- действий по безопасной установке и настройке средства;
- действий по реализации функций безопасности среды функционирования средства.
При развертывании ПО и его компонентов должна использоваться эталонная безопасная конфигурация.
В эксплуатационных документах следует определить перечень и эталонные значения конфигурационных параметров программы, которые должны быть разработаны с учетом требования безопасности. Данную информацию можно использовать для выявления уязвимостей программы, появившихся в результате определения конфигурации (параметров настройки) программы. Виды разрабатываемых эксплуатационных документов могут соответствовать ГОСТ 19.101.
Данные рекомендации должны применяться в совокупности с "Методическими рекомендациями по включению сервисов в единую цифровую платформу Российской Федерации "ГосТех".
Целью отслеживания и исправления обнаруженных недостатков и уязвимостей является сокращение негативного влияния недостатков программы на процессы Заказчика, которые автоматизируются ГИС на Платформе "ГосТех".
Отслеживание и исправление обнаруженных недостатков и уязвимостей должно осуществляться Разработчиком ПО в период действия гарантийных обязательств, указанных в государственном контракте (договоре, соглашении) на создание, развитие, эксплуатацию ГИС на Платформе "ГосТех".
Разработчик ПО должен определить и реализовать процедуры, позволяющие выполнять отслеживание и исправление обнаруженных ошибок в программе и уязвимостей, в том числе процедуры обеспечивающие прием и обработку сообщений от Заказчика об ошибках в программе и уязвимостях, а также запросов на их устранение путем обновления ПО и информировании Заказчика о выявленных уязвимостях и рекомендациях по их устранению.
Документация Разработчика ПО должна содержать:
- описание процедуры отслеживания и исправления обнаруженных ошибок в программе и уязвимостей;
- описание методов приема и обработки сообщений от Заказчика об ошибках в программе и уязвимостях;
- описание методов доведения до Заказчика информации о выявленных ошибка в программе и уязвимостях, а также рекомендаций по их устранению, в том числе путем обновления ПО.
Отслеживание и исправление обнаруженных ошибок в программе и уязвимостей обычно включают в себя следующие этапы:
- сбор информации об ошибках в программ и уязвимостях по результатам тестирований, проведенных на этапах "Конструирования и комплексирования ПО" и "Квалификационного тестирования";
- классификация и категоризация ошибок в программе и уязвимостей по уровням критичности;
- формирование задач на устранение ошибок в программе и уязвимостей "критического" и "высокого" уровней влияния;
- устранение ошибок в программе и уязвимостей;
- проверка и контроль устранения;
- выпуск экземпляра программы с устраненными ошибками в программе и уязвимостями;
- информирование Заказчика о выявленных ошибках в программе и уязвимостях, а также о рекомендациях по их устранению.
Разработчик ПО может осуществлять выпуск обновлений ПО в обход стандартной процедуры выпуска новых версий ПО в экстренных ситуациях <2> или Разработчик ПО должен предложить альтернативные меры нейтрализации угроз безопасности информации или угроз нарушения штатного режима функционирования ПО, включая использование дополнительных средств защиты информации.
--------------------------------
<2> К экстренным ситуациям относятся: выявление недостатков программы или уязвимостей или заимствованных компонентов в составе ПО, которые могут привести к нарушению свойств защиты информации, обрабатываемой ПО в составе ГИС на Платформе "ГосТех".
Для выполнения рекомендаций Разработчик ПО может использовать идентифицированные инструментальные средства, обеспечивающие хранение информации о недостатках программы, отслеживание и управление недостатками программы.
Ответственным за отслеживание и исправление обнаруженных недостатков и уязвимостей программы является Разработчик ПО.
Информацию о недостатках и уязвимостях рекомендуется фиксировать в виде структурированного отчета, содержащего следующие основные данные: идентификатор, краткое описание, подробное описание, шаги по воспроизведению, важность, срочность, категорию (уровень влияния/критичности), возможность применения обходного/компенсирующего решения, версия программы, в которой обнаружен недостаток. Дополнительно в отчет рекомендуется включать ссылки на различные файлы и другие материалы, необходимые для описания недостатка.
Идентификатор - это уникальное значение, которое позволяет отличить один отчет от другого.
Краткое описание отражает основную суть недостатка.
Подробное описание предоставляет детальные сведения о недостатке.
Шаги по воспроизведению описывают порядок действий, которые необходимо выполнить, чтобы недостаток проявился.
Возможность обхода предоставляет информацию, необходимую для описания условий, выполнение которых необходимо для исключения проявления недостатка без необходимости изменения исполняемого кода ПО.
Отчет о недостатках рекомендуется дополнять по мере изменения текущего состояния недостатка.
Целесообразно предусмотреть несколько значений, позволяющих определить текущее состояние недостатка в любой момент времени. Указанные значения могут отражать следующие состояния:
- начальное состояние, после обнаружения;
- состояние, когда недостаток подтвержден и начаты работы по его устранению;
- состояние после устранения недостатка;
- состояние после подтверждения устранения недостатка;
- завершение процесса устранения недостатка;
- устранение недостатка отложено;
- устранение недостатка не планируется.
Информация о недостатках и уязвимостях может быть получена от пользователей ГИС на платформе "ГосТех", работников Заказчика, работников Разработчика ПО, экспертных организаций и иных лиц, обеспечивающих поиск недостатков и уязвимостей программы с использованием функционального тестирования, статического анализа, динамического анализа, экспертизы исходного кода, фаззинг-тестирования, тестирования на проникновение, систематического поиска уязвимостей программы.
Информацию о недостатках, полученную из различных источников, целесообразно фиксировать и обрабатывать в едином хранилище. Для управления таким хранилищем и взаимодействия с ним целесообразно использовать специализированное ПО.
При устранении недостатков рекомендуется выполнять анализ причин возникновения недостатков, чтобы предотвратить появление новых недостатков по похожим причинам.
Для устранения недостатка в исходный код ПО и другие части разрабатываемого ПО вносятся необходимые изменения. После устранения недостатка следует выполнить проверку устранения и оповещение ответственных работников о данном факте, после чего внести изменение в отчет о недостатке, предоставить заказчику экземпляр ПО с устраненным недостатком.
В целях контроля и анализа защищенности ПО в составе ГИС на Платформе "ГосТех" должен проводиться систематический поиск уязвимостей.
Систематический поиск уязвимостей должен проводиться Разработчиком ПО как в отношении частей программы, которые создаются непосредственно Разработчиком ПО, так и в отношении заимствованных компонентов сторонних разработчиков на регулярной основе (не реже 1 раза в месяц) в период действия гарантийных обязательств, указанных в государственном контракте (договоре, соглашении) на создание, развитие, эксплуатацию ГИС на Платформе "ГосТех".
Выявление уязвимостей рекомендуется осуществлять как с использованием инструментальных средств, так и в ручном режиме.
Для выявления уязвимостей ПО рекомендуется использовать данные об уязвимостях из открытых источников, документацию на программу, а также данные, являющиеся результатом выполнения различных процедур безопасной разработки ПО (результаты статического анализа исходного кода, результаты экспертизы исходного кода, результаты функционального тестирования, результаты динамического анализа кода, результаты фаззинг-тестирования).
В случае выявления уязвимости в тестируемой версии программы следует идентифицировать все остальные версии программы, в которых есть обнаруженная уязвимость.
Разработчик ПО в отношении уязвимостей критического уровня влияния обязан принять меры по их устранению и в срок до 24 часов, с момента обнаружения уязвимости, проинформировать оператора ГИС на Платформе "ГосТех" и оператора Платформы "ГосТех" об о их наличии и способах устранения.
Разработчик ПО в отношении уязвимостей высокого уровня влияния обязан принять меры по их устранению и в срок до 7 дней, с момента обнаружения уязвимости, проинформировать оператора ГИС на Платформе "ГосТех" и оператора Платформы "ГосТех" об о их наличии и способах устранения.
В общем случае устранение выявленных уязвимостей должно осуществляться в соответствии с рекомендациями п. 8.1 данного документа.
Для идентификации различных версий программы Разработчику ПО следует проводить уникальную маркировку каждой версии программы и ее частей.
Для обозначения версий программ, исполняемых файлов, файлов установочного комплекта рекомендуется использовать группу цифр (номеров), разделенных точками.
Новые версии должны маркироваться посредством изменения вышеуказанных групп цифр в сторону увеличения, в зависимости от типа изменений, внесенных в программу. Группы цифр в некоторых случаях возможно дополнять буквенными значениями, также обладающими определенным смыслом.
Описание конкретного способа маркировки Разработчик ПО должен отразить в эксплуатационной документации, поставляемой Заказчику.
В целях поддержания соответствия разрабатываемого ПО заданным требованиям в течение всего жизненного цикла Разработчик ПО должен создать и использовать систему управления конфигурацией ПО, которая должна предоставлять возможность и средства для определения всех элементов конфигурации, на которые воздействует модификация тот или иной элемент конфигурации.
Рекомендуемый список элементов конфигурации разрабатываемого ПО определен в Приложении 4.
Для идентификации принадлежности и контроля целостности всех элементов конфигурации рекомендуется использовать технологии электронной подписи Разработчика ПО.
Подобная идентификация выполняется с использованием различных меток или путем создания отдельного перечня идентификаторов элементов конфигурации, которые связаны с реализацией функций безопасности.
Разработчик ПО должен обеспечить защиту элементов конфигурации ПО от угроз безопасности информации, связанных с нарушением их конфиденциальности, целостности, доступности и аутентичности.
Для защиты элементов конфигурации Разработчик ПО должен применять технические и организационные меры.
Разработчику ПО рекомендуется включать в состав документации на ПО, связанной с реализацией меры по разработке безопасного ПО, документы Разработчика ПО, соответствующие требованиям п. 5.8.3.1 ГОСТ Р 56939.
Разработчик ПО должен осуществлять резервное копирование элементов конфигураций.
Резервное копирование рекомендуется осуществлять в отношении всех элементов конфигурации ПО.
Периодичность проведения резервного копирования рекомендуется определять с учетом активности выпуска новых версий ПО и изменения его конфигураций.
При резервном копировании элементов конфигураций Разработчиком ПО должна обеспечиваться их конфиденциальность, целостность, доступность и аутентичность.
При восстановлении конфигурации из резервной копии Разработчиком ПО должна осуществляться проверка ее целостности и аутентичности.
Реализацию мер по резервному копированию и восстановлению элементов конфигурации следует осуществлять в соответствии с ГОСТ Р ИСО/МЭК 27002.
Разработчик ПО должен применять технические и организационные меры, обеспечивающие регистрацию всех событий, связанных с фактами изменения элементов конфигурации, в журналах регистрации событий.
Рекомендуется осуществлять регистрацию следующей информации:
- инициатор изменения;
- идентификатор элемента конфигурации;
- дата и время изменения элемента конфигурации;
- информация о субъекте, внесшим изменения (IP-адрес и/или иная информация, позволяющая идентифицировать субъект);
- информация о внесенном изменении.
Реализацию мер, обеспечивающих регистрацию всех событий, связанных с фактами изменения элементов конфигурации, в журналах регистрации событий следует осуществлять в соответствии с ГОСТ Р ИСО/МЭК 27002.
Разработчик ПО должен проводить периодическое обучение сотрудников с целью повышения их осведомленности в области разработки безопасного ПО.
В программу обучения рекомендуется включать курсы, посвященные моделированию угроз безопасности информации, проведению экспертизы исходного кода программы, тестированию на проникновение, статическому анализу исходного кода программы, сертификации средств защиты информации и иным направлениям обучения, связанным с разработкой БПО.
Программа обучения сотрудников должна ежегодно пересматриваться Разработчиком ПО для установления ее пригодности, адекватности и результативности для достижения установленных целей в области разработки безопасного ПО.
Обучение работников в области разработки безопасного ПО рекомендуется проводить с привлечением сторонних организаций, обладающих компетенцией в этой области и имеющих лицензию на осуществление образовательной деятельности
Программы обучения необходимо организовывать с учетом должностных и функциональных обязанностей соответствующих работников.
Для отдельных ролей может быть предусмотрено более детальное изучение аспектов обеспечения безопасности информации в зависимости от возложенных обязанностей: создание безопасного исходного кода, базовые методы преодоления механизмов защиты информации, типовые компьютерные атаки. Определенные работники могут проходить углубленное изучение проблем и методик в области обеспечения безопасности информации для последующего выполнения специфических задач в области безопасной разработки (статический анализ, тестирование на проникновение, динамический анализ, фаззинг-тестирование) и передачи знаний остальным работникам.
Программу обучения работников следует составлять с учетом технологий, языков программирования и инструментальных средств, которые используются в процессе разработки безопасного ПО на Платформе "ГосТех".
Разработчику ПО рекомендуется проводить регулярную оценку знаний работников в области разработки безопасного ПО. Оценка может быть проведена в виде тестирования. Периодическое тестирование позволяет получить сведения о наличии у работников необходимых знаний в области безопасной разработки и получить необходимые данные об эффективности принятой программы обучения. Эффективным средством для оценки реализованной программы обучения работников являются метрики, характеризующие процесс разработки ПО. Набор рассчитываемых метрик зависит от особенностей процесса разработки. Примеры метрик, которые могут быть использованы при оценке программы обучения, следующие: общее количество обнаруженных уязвимостей и недостатков программы за период времени, общее количество уязвимостей и недостатков программы, обнаруженных после передачи ПО Заказчику, средний уровень важности обнаруженных уязвимостей и недостатков программы, успешное прохождение тестовых процедур. Динамика изменения метрик в наблюдаемых периодах времени позволяет определить необходимость обновления программы обучения или отсутствие такой необходимости.
Дополнительные сведения об эффективности и пригодности используемой программы обучения могут быть также получены путем опроса работников, которые прошли обучение.
БЕЗОПАСНОГО ПО НА ПЛАТФОРМЕ "ГосТех"
К РАЗРАБАТЫВАЕМОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
В СОСТАВЕ ГИС НА ПЛАТФОРМЕ "ГосТех"
--------------------------------
<3> П. 2, ст. 5 Федерального закона от 27.06.2006 N 149-ФЗ.
Язык программирования C#
1. Именование переменных
1.1. Pascal casing
Описываются имена:
- всех определений типов, в том числе пользовательских классов, перечислений, событий, делегатов и структур;
- значения перечислений;
- readonly полей и констант;
- интерфейсов;
- методов;
- пространств имен (namespace);
- свойств;
- публичных полей;
1.2. Camel casing
Описываются имена:
- локальных переменных;
- аргументов методов;
- защищенных (protected) полей.
1.3. Суффиксы и префиксы
Применяются следующие суффиксы и префиксы:
- имена пользовательских классов исключений всегда заканчиваются суффиксом Exception;
- имена интерфейсов всегда начинаются с префикса "I";
- имена пользовательских атрибутов всегда заканчиваются суффиксом "Attribute";
- имена делегатов обработчиков событий всегда оканчиваются суффиксом EventHandler, имена классов-наследников от EventArgs всегда заканчиваются суффиксом EventArgs.
1.4. Аббревиатуры
При использовании аббревиатур в именах, капитализации подлежат аббревиатуры с двумя символами, в остальных аббревиатурах необходимо приводить к верхнему регистру только первый символ.
Например: namespace Sample.IO, class HttpUtil
2. Именование методов
Используйте конструкцию "глагол-объект" для именования методов. В частном случае, для методов, которые возвращают значение, используйте в паре "глагол-объект" для глагола Get, а для объекта - описание возвращаемого значения.
Например: ShowUserID(), GetUserID()
3. Именование переменных, полей и свойств.
При именовании переменных избегайте использования сокращенных вариантов, не отражающих содержание переменной (например, n вместо number). Не используйте венгерскую нотацию или используйте ее только для закрытых членов. Для имен элементов управления и локальных переменных сложных типов указывайте префиксы, описывающие тип элемента.
Например: txtSample.
Имена закрытых полей всегда начинаются с префикса "_" остальная часть имени описывается с помощью Camel Casing.
Например: private int_samplePrivateField;
Не используйте публичных или защищенных полей, вместо этого используйте свойства. Используйте автоматические свойства. Всегда указывайте модификатор доступа private, даже если разрешено его опускать. Всегда инициализируйте переменные, даже когда существует автоматическая инициализация.
4. Оформление кода
Используйте пустую строку между логическими секциями в исходном файле, классе, методе.
Располагайте открывающие и закрывающие фигурные скобки на новой строке. Используйте фигурные скобки для выражения if, даже когда в выражение входит только одна строка кода.
Используйте промежуточную переменную для передачи bool-значения результата функции в условное выражение if;
Например:
bool boolVariable = GetBoolValue();
if (boolVariable)
{
}
Ставьте пробелы вокруг операторов (= +-*/) и после запятой.
5. Объем кода
Избегайте файлов с более чем 500 строками кода.
Избегайте методов с более чем 200 строками кода.
Избегайте методов с более чем 5 аргументами, используйте структуры для передачи большого числа параметров.
Одна строка кода не должна иметь длину более 120 символов.
Язык программирования JavaScript
1. Именование переменных
Для имен идентификаторов (переменных и функций) используйте camelCase. Для глобальных переменных используйте верхний регистр. Для констант (например, PI) используйте верхний регистр. При именовании переменных избегайте использования сокращенных вариантов, не отражающих содержание переменной.
2. Оформление логических операций
Используйте пустую строку между логическими секциями в исходном файле, классе, методе. Используйте промежуточную переменную для передачи bool-значения результата функции в условное выражение if.
Например:
bool boolVariable = GetBoolValue();
if (boolVariable)
{
}
3. Оформление операторов
Всегда заканчивайте простой оператор точкой с запятой.
Правила для сложных операторов:
- поместите открывающую скобку в конец первой линии;
- используйте один пробел перед открывающей скобкой;
- поместите закрывающую скобку на новую линию без пробелов;
- не заканчивайте сложный оператор точкой с запятой.
Например:
Функция:
function divideByTwo(number) {
return (number / 2);
}
Петля:
for (i = 0; i <2; i++) {
x += i;
}
Условие:
if (time <5) {
mark = "5";
} else {
mark = "4";
}
4. Общие правила для определений объектов:
- поместите открывающую скобку на ту же линию, что и имя объекта;
- используйте двоеточие плюс один пробел между каждым свойством и его значением;
- используйте кавычки вокруг строковых значений, а не вокруг числовых значений;
- не добавляйте запятую после последней пары значение свойства;
- поместите закрывающую скобку на новую линию без пробелов;
- всегда заканчивайте определение объекта точкой с запятой.
Пример:
var person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor: "blue"
};
Короткие объекты могут быть записаны сжатыми, на одной линии, используя пробелы только между свойствами, как это:
var person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};
5. Отступы
Ставьте пробелы вокруг операторов (= +-*/) и после запятой. Используйте 4 пробела для отступа блоков кода. Не используйте вкладки (таблицы) для отступа.
6. Объем кода
Избегайте строк длиной более 80 символов.
Если инструкция JavaScript не умещается на одной строке, нужно разбить ее после оператора или запятой.
Например:
document.getElementById("demo").innerHTML =
"Hello Dolly.";
7. Загрузка JavaScript в HTML
Используйте простой синтаксис для загрузки внешних скриптов (атрибут Type не нужен):
<script src="myscript.js"></script>
Язык Java
1. Именование переменных, классов и интерфейсов
Рекомендуется использовать одно объявление на строку, так как это облегчает комментирование.
int level;
int size;
Примечание: в приведенных выше примерах используется один пробел между типом и идентификатором. Другой приемлемой альтернативой является использование табуляции для выравнивания идентификаторов в один линию (использование клавиши Tab которая равна обычно 4-м пробелам), например:
int level; // уровень отступа
int size; // размер таблицы
Object currentEntry; // текущий выделенный экземпляр таблицы
2. Объявление классов и интерфейсов
Методы должны быть сгруппированы по функциональности, а не по области или доступности. Для примера метод класса private может находиться между двумя public методами экземпляра.
3. Оформление кода
Размещайте объявления только в начале блоков (блоком является любой код, заключенный в фигурные скобки "{" и "}"). Не ждите объявления переменных до их первого использования;
void MyMethod() {
int int1;
if (условие) {
int int2;
...
}
}
Единственным исключением являются индексы циклов for, которые в Java могут быть объявлены в операторе for:
for (int i = 0; i < maxLoops; i++) { ...
Избегайте локальных объявлений, перекрывающих объявления более высокого уровня. Например, не объявляйте одну и ту же переменную перед блоком кода и во внутреннем блоке.
Старайтесь инициализировать локальные переменные там, где вы их объявляете. Единственная причина не инициализировать переменную в месте ее объявления - если ее начальное значение зависит от некоторых предварительных вычислений.
При написании Java классов и интерфейсов необходимо соблюдать следующие правила форматирования:
- не ставьте пробел между именем метода и скобкой "(" внутри которой указывается список его параметров;
- открывающая скобка "{" ставится в конце той же строки, где указан оператор объявления класса или интерфейса;
- закрывающая скобка "}" ставится на отдельной строке с тем же отступом, что и у соответствующего ему открывающего оператора, кроме случаев, когда имеем пустой оператор, то "}" должна появиться сразу после "{"
class Sample extends Object {
int ivar1;
int ivar2;
Sample(int i, int j) {
ivar1 = i;
ivar2 = j;
}
int emptyMethod() {}
...
}
- между методами должна быть одна пустая строка.
В качестве единицы отступов следует использовать 4 пробела. Табуляция должна быть установлена ровно каждые 8 пробелов (а не 4). Избегайте строк длиннее 80 символов.
Если выражение не помещается на одной строке, разбейте его в соответствии со следующими принципами:
- перенос осуществляется после запятой;
- перенос осуществляется перед оператором;
- предпочитайте переносы более высокого уровня для переноса нижнего уровня (вложенном уровне);
- выравнивайте новую строку выражения так, чтобы его начало было на том же уровне, как и в предыдущей строке;
- если приведенные выше правила приводят к запутанному (плохо читающемуся) коду или коду, который сжимается с правым краем, просто введите 8 пробелов вместо этого.
Пример:
function(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);
var = function1(longExpression1,
function2(longExpression2,
longExpression3));
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6;
Отступы в строках с оператором if следует применить по правилу 8 пробелов, так как если использовать стандартные 4 пробела, то поиск тела оператора будет затруднителен.
Пример:
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
Способы форматирования тернарных выражений:
alpha = (aLongBooleanExpression) ? beta : gamma;
alpha = (aLongBooleanExpression) ? beta
: gamma;
alpha = (aLongBooleanExpression)
? beta
: gamma;
4. Организация файлов
Файл состоит из разделов, которые должны быть разделены пустыми строками и необязательным комментарием, идентифицирующим каждую секцию. Файлы длиной более 2000 строк являются громоздкими и их следует избегать.
5. Файлы с исходным кодом Java
Каждый файл с исходным кодом Java содержит один class с ключевым словом public или интерфейс. Когда классы с ключевым словом private и интерфейсы связанны с public-классом, то их можно поместить в тот же файл с исходным кодом, что и public-класс. Класс с ключевым словом public должен быть размещен как первый класс или интерфейс в файле.
Файлы с исходным кодом Java имеют следующий порядок:
Начальный комментарий
Операторы package и import
Объявления классов и интерфейсов
6. Начальный комментарий
Все файлы с исходным кодом должны начинаться с комментария в стиле языка C, в котором перечислены авторы программы, дата, сведения об авторских правах, а также краткое описание того, что делает программа. Например:
/*
* Имя класса
*
* Информация о версии
*
* Информация об авторском праве
*/
7. Операторы
7.1. Простые операторы
Каждая строка должна содержать не более 1 оператора. Не используйте запятую для группировки нескольких операторов, даже если это видно невооруженным глазом.
7.2. Составные операторы
Составные операторы - это операторы, содержащие списки операторов, заключенные в фигурные скобки "{ операторы }". Вложенные операторы должны иметь отступ на один уровень больше, чем составной оператор. Открывающая скобка должна быть в конце той строки, с которой начинается составной оператор; закрывающая скобка должна начинаться с новой строки и с отступом, соответствующим началу составного оператора.
Скобки используются во всех операторах, даже в одиночных, когда они входят в состав управляющей структуры, таких, как оператор if-else или for. Это необходимо, чтобы избежать ошибок в случае добавления новых операторов, когда забыли указать фигурные скобки (если фигурных скобок нет, то управляющая конструкция типа if будет выполнять только одну строку после нее до знака ";").
7.3. Оператор return
Оператор return, возвращающий значение, не должен использовать скобки, если только их использование не сделает возвращаемое значение более понятным.
Например:
return;
return myDisk.size();
return (size ? size : defaultSize);
7.4. Операторы if, if-else, if-else-if-else
Операторы if всегда должны использоваться с фигурными скобками "{ }".
Группа операторов (как и единичное использование) if-else должна иметь следующий вид:
if (условие) {
операторы;
}
if (условие) {
операторы;
} else {
операторы;
}
if (условие) {
операторы;
} else if (условие) {
операторы;
} else if (условие) {
операторы;
}
7.5. Оператор цикла for
Оператор цикла for должен иметь следующий вид:
for (инициализация; условие; итерация) {
операторы;
}
Пустой оператор цикла for (тот, в котором вся работа выполняется в инициализации, условии и итерации) должен иметь следующий вид:
for (инициализация; условие; итерация);
При использовании оператора запятой в блоке инициализации или итерации оператора цикла for избегайте использования более чем трех переменных. Если необходимо, используйте отдельные операторы перед циклом for (для случая блока инициализации) или в конце цикла (для случая блока итерации).
7.6. Оператор цикла while
Оператор цикла while должен иметь следующий вид:
while (условие) {
операторы;
}
Пустой оператор цикла while должен иметь следующий вид:
while (условие)
7.7. Оператор цикла do-while
Оператор цикла do-while должен иметь следующий вид:
do {
операторы;
} while (условие)
7.8. Оператор switch
Оператор switch должен иметь следующую форму:
switch (условие) {
case ABC:
операторы;
/* провал */
case DEF:
операторы;
break;
case XYZ:
операторы;
break;
default:
операторы;
break;
}
Каждый раз, когда выбор проваливается (не включая оператор break), добавьте комментарий, где обычно находится оператор break. Это показано в предыдущем примере кода с комментарием /* провал */.
Каждый оператор switch должен включать выбор по умолчанию (default). Оператор break в выборе по умолчанию лишний, но он предотвращает возникновение ошибки, если позже еще один выбор добавится.
7.9. Оператор try-catch
Оператор try-catch должен иметь следующий формат:
try {
операторы;
} catch (ExceptionClass e) {
операторы;
}
8. Отступы
8.1. Пустые строки
Пустые строки улучшают читабельность, выделяя разделы кода, которые логически связаны между собой.
Две пустые строки всегда должны использоваться в следующих случаях:
- между секциями в файле исходного кода;
- между определениями классов и интерфейсов.
Одна пустая строка всегда должна использоваться в следующих случаях:
- между методами;
- между локальными переменными метода и его первым оператором;
- перед блочным или однострочным комментарием;
- между логическими участками кода внутри метода для улучшения читабельности.
8.2. Расстановка пробелов
Разделяющие пробелы должны ставиться при следующих обстоятельствах.
- Ключевое слово, за которым следует скобка, должны быть разделены пробелом. Например:
while (true) {
...
}
Обратите внимание, что пробел не должен использоваться между именем метода и его открывающей скобкой. Это помогает отличать ключевые слова от вызовов метода.
- Разделяющий пробел должен появляться после запятой в списке аргументов.
- Все бинарные операторы кроме "." должны быть отделены от своих операндов пробелами. Пробелом никогда не должны разделяться операнды и их унарные операторы, такие как унарный минус, инкремент ("++") и декремент "--") от их операндов. Например:
a += c + d;
a = (a + b) / (c * d);
while (d++ = s++) {
n++;
}
prints("size is" + foo + "\n").
- Выражения в операторе цикла for должны быть разделены пробелами. Например:
for (expr1; expr2; expr3)
- За приведением типа должен следовать пробел. Например:
myMethod((byte) aNum, (Object) x);
myFunc((int) (cp + 5), ((int) (i + 3))
+ 1);
Язык разметки документов HTML
1.1. Тип документа
Всегда объявляйте тип документа в качестве первой строки в документе:
<!DOCTYPE html>
Если требуется согласованность с тегами нижнего регистра, можно использовать:
<!doctype html>
Рекомендуется использовать имена элементов нижнего регистра.
<section>
<p>This is a paragraph.</p>
</section>
2.1 Закрытие всех элементов HTML
Рекомендуется закрыть все элементы HTML.
<section>
<p>This is a paragraph.</p>
<p>This is a paragraph.</p>
</section>
3.1. Закрытие пустых элементов HTML
В HTML5 необязательно закрывать пустые элементы.
Разрешены:
<meta charset="windows-1251">
Также разрешено:
<meta charset="windows-1251" />
Однако в XHTML и XML требуется закрывающая косая черта (/).
4.1. Использовать имена атрибутов нижнего регистра
Рекомендуется использовать имена атрибутов нижнего регистра, а также заключать значения атрибутов в кавычки.
<table class="striped">
5.1. Атрибуты изображения
Всегда добавляйте атрибут alt к изображениям. Этот атрибут важен, когда изображение по какой-либо причине не может быть отображено. Кроме того, всегда определяйте ширину и высоту изображения. Это уменьшает мерцание, потому что браузер может зарезервировать место для изображения перед загрузкой.
<img src="html5.gif" alt="HTML5" style="width:128px;height:128px">
6.1. Пробелы и знаки равенства
Не ставьте пробелы вокруг знака равенства. <link rel="stylesheet" href="styles.css">
Старайтесь избегать строк кода длиной более 80 символов.
7.1. Пустые строки и отступы
Не добавляйте пустые строки без причины.
Для удобочитаемости добавьте пустые строки для разделения больших или логических блоков кода.
Для удобочитаемости добавьте 2 пробела отступа. Не используйте клавишу TAB.
Не используйте ненужные пустые строки и отступы. Нет необходимости отступить каждый элемент:
<body>
<h1>Famous Cities</h1>
<h2>Tokyo</h2>
<p>Tokyo is the capital of Japan, the center of the Greater Tokyo Area,
and the most populous metropolitan area in the world.
It is the seat of the Japanese government and the Imperial Palace,
and the home of the Japanese Imperial Family.</p>
</body>
Пример таблицы:
<table>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
<tr>
<td>A</td>
<td>Description of A</td>
</tr>
<tr>
<td>B</td>
<td>Description of B</td>
</tr>
</table>
Пример списка:
<ol>
<li>London</li>
<li>Paris</li>
<li>Tokyo</li>
</ol>
8.1. Пропуск <html>, <body>, <head>
Не рекомендуется опускать тег <head>.
Не рекомендуется опускать <html>, <body>, <head>.
Элемент <html> является корнем документа. Это рекомендуемое место для указания языка страницы:
<!DOCTYPE html>
<html lang="en-US">
Объявление языка важно для приложений специальных возможностей (программы чтения с экрана) и поисковых систем.
Пропуск <html> или <body> может аварийно завершить работу DOM и XML ПО.
Пропуск <body> может привести к ошибкам в старых браузерах (IE9).
9.1. Метаданные
Элемент <title> необходим в HTML5. Сделайте название как можно более осмысленным:
<title>HTML5 Syntax and Coding Style</title>
Чтобы обеспечить правильную интерпретацию и правильную индексацию поисковых систем, как язык, так и кодировка символов должны быть определены как можно раньше в документе:
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="windows-1251">
<title>HTML5 Syntax and Coding Style</title>
</head>
10.1. Комментарии в формате HTML
Краткие комментарии должны быть написаны на одной строке, как это:
<!-- This is a comment -->
Комментарии, охватывающие более одной строки, должны быть написаны так:
<!--
This is a long comment example. This is a long comment example.
This is a long comment example. This is a long comment example.
-->
Длинные комментарии легче заметить, если они имеют отступ двух пробелов.
11.1. Таблицы стилей
Используйте простой синтаксис для связывания с таблицами стилей (атрибут Type не требуется):
<link rel="stylesheet" href="styles.css">
Короткие правила могут быть записаны сжатыми на одной строке:
p.intro {font-family: Verdana; font-size: 16em;}
Длинные правила должны быть написаны на несколько строк:
body {
background-color: lightgrey;
font-family: "Arial Black", Helvetica, sans-serif;
font-size: 16em;
color: black;
}
- поместите открывающую скобку на ту же линию, что и селектор;
- используйте один пробел перед открывающей скобкой;
- использовать 2 пробела отступа;
- используйте точку с запятой после каждой пары значение свойства, включая последнюю;
- используйте кавычки только вокруг значений, если значение содержит пробелы;
- поместите закрывающую скобку на новую линию без пробелов;
- избегайте линий более 80 символов.
12.1. Загрузка JavaScript в HTML
Используйте простой синтаксис для загрузки внешних скриптов (атрибут Type не нужен):
<script src="myscript.js">
РАЗРАБАТЫВАЕМОГО ПО
1. Программа (дистрибутив программы) и эталонные конфигурации.
2. Рекомендуемые схемы размещения элементов ПО для сред его функционирования (диаграммы развертывания).
3. Инструкция по установке ПО и его компонентов.
4. Руководство по обеспечению безопасности.
5. Программные и эксплуатационные документы.
6. Исходный код программы.
7. Среда функционирования и развертывания для разрабатываемого ПО.
8. Любая информация об изменениях элементов конфигурации, включая обновления ПО и устранения уязвимостей.
9. Информация, связанная с обновлениями ПО и устранениями уязвимостей программы.
10. Перечень выявленных недостатков программы и информация об их состоянии в базе данных уязвимостей Разработчика ПО.
11. Безопасные, тестовые, технологические конфигурации ПО (например, файлы cfg, ini или описание этих настроек для каждого сценария).
12. Документация на систему управления конфигурацией и ее элементы.
13. Документацию на систему управления изменениями; конфигурации контуров Разработчика ПО, тестового и промышленной эксплуатации (оборудование, ОС и др.).
14. Средства разработки и их опции, применяемых при разработке конкретного экземпляра ПО.
Дополнительно в список элементов конфигурации рекомендуется включать следующее:
документ, содержащий требования по безопасности, предъявляемые к разрабатываемому ПО;
документ, содержащий сведения о результатах моделирования угроз безопасности информации;
документ, содержащий сведения о проекте архитектуры программы;
документ, описывающий используемые инструментальные средства;
документ, содержащий информацию о прослеживаемости исходного кода программы к проекту архитектуры программы;
документ, содержащий порядок оформления исходного кода программы;
документ, содержащий сведения о результатах проведения статического анализа исходного кода программы;
документ, содержащий сведения о результатах проведения экспертизы исходного кода программы;
документ, содержащий сведения о результатах проведения функционального тестирования программы;
документ, содержащий сведения о результатах проведения тестирования на проникновение;
документ, содержащий сведения о результатах проведения динамического анализа кода программы;
документ, содержащий сведения о результатах проведения фаззинг-тестирования программы;
документ, содержащий описание процедуры передачи ПО Заказчику;
документ, содержащий описание процедур отслеживания и исправления обнаруженных ошибок в программе и уязвимостей;
документ, содержащий описание процедуры поиска Разработчиком ПО уязвимостей программы;
документ, описывающий реализацию и использование процедуры уникальной маркировки каждой версии ПО;
документ, описывающий использование системы управления конфигурацией ПО;
документ, описывающий меры, используемые для защиты инфраструктуры среды разработки ПО;
документ, содержащий сведения об обучении работников.
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/metodicheskie-rekomendacii/1/edina.html
На правах рекламы: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
или О'Хара).|
© Антон Серго, 1998-2026.
|
Разработка сайта |
|