├── DAF.md ├── DAF_public_v4.1.xlsx ├── LICENSE ├── README.md └── images ├── Heatmap.png ├── Model_Processes.png ├── Model_Technology.png └── The_Pyramid_of_Maturity.jpg /DAF.md: -------------------------------------------------------------------------------- 1 | > ASTP - AppSec Table Top by Positive Technologies 2 | 3 | ### Домен "Контроль ИБ артефактов, зависимостей и образов" 4 | 5 | >
6 | > Контроль использования сторонних компонентов [T-ADI-DEP] 7 | > 8 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 9 | > | --- | --- | --- | --- | --- | --- | 10 | > | T-ADI-DEP-0-1 | Управление зависимостями (Dependencies) в исходном коде осуществляется в каком-либо виде | 0 |- | SB-B-1 |- | 11 | > | T-ADI-DEP-1-1 | Существуют (формализованы) единые правила, определяющие возможность использования тех или иных зависимостей в коде.
Например, есть утвержденный документ, и/или страница в базе знаний, описывающие порядок использования зависимостей в коде. | 2 |- | SB-B-2 | TP2 | 12 | > | T-ADI-DEP-1-2 | Обновление существующих зависимостей выполняется вручную.
Например, если возникла необходимость использовать новую версию библиотеки в коде, то ее вручную выгружают и добавляют в проект | 2 |- | SB-B-2 |- | 13 | > | T-ADI-DEP-1-3 | Существует (описан, формализован) план реагирования на события ИБ, связанных с зависимостями. | 2 | SR2.7 |- | MI4 | 14 | > | T-ADI-DEP-1-4 | Выполняется харденинг (безопасная настройка) файлов конфигураций используемых пакетов open source software - OSS (например, nuget.config, .npmrc, pip.conf, pom.xml, etc.). | 2 |- | EM-A-1 | CNFG1 | 15 | > | T-ADI-DEP-1-5 | Зависимости с тэгом "latest" не применяются | 2 |- | SA-B-1 |- | 16 | > | T-ADI-DEP-2-1 | Разработчики получают и используют OSS компоненты, применяя только стандартизованные (формализованные и утвержденные) методы | 3 | SR2.7 |- |- | 17 | > | T-ADI-DEP-2-2 | Контролируется и регулируется использование новых (моложе 60 дней) и старых (неактуальных, заброшенных, старше 365 дней) OSS.
Например, настроен OSS firewall на предупреждение (или запрет) использования OSS, выпущенных\актуализированных более 365 дней назад и менее чем 60 дней | 3 |- | OM-B-1, OM-B-2, SB-B-2 |- | 18 | > | T-ADI-DEP-3-1 | Выполняется инвентаризация используемых зависимостей.
Например, создан внутренний репозиторий. | 4 | SR1.5 | SB-B-1 | SCA5 | 19 | > | T-ADI-DEP-3-2 | При выполнении Pull/Merge request предоставляется список всех уязвимостей используемых зависимостей.
Это может быть реализовано с помощью SCA решения | 4 |- |- |- | 20 | > | T-ADI-DEP-3-3 | Выполняется верификация цифровой подписи SBOM перед использованием зависимостей в сборке.
Это может быть реализовано с помощью SCA решения | 4 |- |- | SCS1
IA3 | 21 | > | T-ADI-DEP-3-4 | Выполняется автоматическое обновление используемых зависимостей.
Это может быть реализовано с помощью специальных утилит для обновления зависимостей. | 4 |- |- |- | 22 | > | T-ADI-DEP-4-1 | Выполняется самостоятельная сборка необходимых зависимостей в доверенной среде | 6 |- |- |- | 23 | > | T-ADI-DEP-4-2 | Выполняется создание и проверка цифровой подписи собранных зависимостей
Например, с помощью Cosign | 6 | SE2.4 | SB-A-1 | SCS1
IA3 | 24 | > | T-ADI-DEP-4-3 | Выполняется создание и проверка цифровой подписи на SBOM для собранных зависимостей
Например, с помощью Cosign | 6 |- |- | SCS1
IA3 | 25 | > 26 |
27 | 28 | >
29 | > Управление артефактами [T-ADI-ART] 30 | > 31 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 32 | > | --- | --- | --- | --- | --- | --- | 33 | > | T-ADI-ART-0-1 | Управление артефактами разработки присутствует в каком-либо виде | 0 |- | SA-B-2 |- | 34 | > | T-ADI-ART-1-1 | Все артефакты разработки хранятся в доверенных registry.
Например, используется внутренний реестр. | 1 |- |- | OSS2 | 35 | > | T-ADI-ART-1-2 | Строго ограниченный перечень лиц может помещать артефакты в registry.
Внутри registry настроены правила разграничения доступа. | 1 |- |- | AC2 | 36 | > | T-ADI-ART-1-3 | Для аутентификации в registry используются внешние сервисы.
Например, выполнена интеграция с LDAP или другим IdM, локальные учетные записи не используются. | 1 |- |- |- | 37 | > | T-ADI-ART-1-4 | Отключен анонимный доступ в registry | 1 |- |- | AC2
CNFG1 | 38 | > | T-ADI-ART-1-5 | Настроен и включен аудит любых изменений конфигурации хранилищ артефактов | 1 |- |- | CNFG1 | 39 | > | T-ADI-ART-2-1 | Разработчики получают артефакты для дальнейшей работы только из внутренних репозиториев | 3 |- |- |- | 40 | > | T-ADI-ART-2-2 | Выполняется создание хэш сумм артефактов перед отправкой их в registry, а также их проверка при сборке | 3 |- |- | SCS1
IA3 | 41 | > | T-ADI-ART-2-3 | Для взаимодействия с registry используются webhook с использованием TLS версии не ниже 1.2 | 3 |- |- |- | 42 | > | T-ADI-ART-3-1 | Выполняется создание цифровых подписей всех артефактов перед их отправкой в registry | 4 | SE2.4 |- | SCS1
IA3 | 43 | > | T-ADI-ART-3-2 | Для всех артефактов создается SBOM | 4 | SR1.5
SE3.6 |- |- | 44 | > | T-ADI-ART-3-3 | Используется многофакторная аутентификация для доступа к registry | 4 |- |- |- | 45 | > | T-ADI-ART-3-4 | Конвейер сборки (build pipeline) подписывает все артефакты, которые он создает | 4 | SE2.4 |- | IA3 | 46 | > | T-ADI-ART-4-1 | Выполняется шифрование всех артефактов в registry | 5 |- |- |- | 47 | > 48 |
49 | 50 | ### Домен "Защита окружения разработки" 51 | 52 | >
53 | > Защита рабочих мест разработчика [T-DEV-COMP] 54 | > 55 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 56 | > | --- | --- | --- | --- | --- | --- | 57 | > | T-DEV-COMP-0-1 | Применяются практики защиты рабочих мест разработчиков | 0 |- |- | CNFG1
MI1 | 58 | > | T-DEV-COMP-1-1 | Утверждены и применяются базовые требования к ПО и настройкам на корпоративных рабочих местах разработчиков.
Например, требования к антивирусу, обновлениям ОС, требования к паролям. | 1 |- |- |- | 59 | > | T-DEV-COMP-1-2 | Удаленный доступ с некорпоративных (и, соответственно, ненастроенных) устройств к инструментам разработки возможен только для ограниченного (небольшого) числа устройств. | 1 |- |- | AC2
MI1 | 60 | > | T-DEV-COMP-2-1 | Удаленный доступ к инструментам разработки возможен либо с корпоративных устройств с использованием MDM, либо через промежуточные\проксирующие системы, например, VDI или PAM. | 3 |- |- | MI1 | 61 | > 62 |
63 | 64 | >
65 | > Защита секретов [T-DEV-SM] 66 | > 67 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 68 | > | --- | --- | --- | --- | --- | --- | 69 | > | T-DEV-SM-0-1 | Существует практика управления секретами | 0 |- | SD-B-1 |- | 70 | > | T-DEV-SM-1-1 | Секреты в среде разработки защищаются встроенными механизмами инструментов разработки, например, CI/CD системы, без применения Secret Management систем. | 1 |- | SD-B-1 |- | 71 | > | T-DEV-SM-1-2 | Инциденты ИБ, связанные с использованием секретов в среде разработки, обрабатываются службой ИБ совместно с разработчиками. | 1 | CMVM1.1 | IM-A-2 | MI4 | 72 | > | T-DEV-SM-2-1 | Секреты окружения разработки хранятся в Secret Management инструменте, например, Hashicorp Vault. | 2 |- | SD-B-2 | IA2 | 73 | > | T-DEV-SM-2-2 | Разработчики и инженеры обмениваются секретамис помощью инструмента Secret Management, например, Hashicorp Vault | 2 |- | SD-B-2 |- | 74 | > | T-DEV-SM-3-1 | Секреты всех сред и инструментов (за исключением рабочих станций разработчиков и подобных adhoc сред) хранятся в SM (например, Vault), количество hardcoded секретов минимально. Случаи использования hardcoded секретов известны команде ИБ и запланирован отказ от их использования | 3 |- | SD-B-1 |- | 75 | > | T-DEV-SM-3-2 | Сформирована и применяется политика ротации секретов окружений разработки | 3 |- | SD-B-3 |- | 76 | > | T-DEV-SM-4-1 | Используются динамические секреты с ограничением доступа для сред | 6 |- |- |- | 77 | > 78 |
79 | 80 | >
81 | > Защита Build-среды [T-DEV-BLD] 82 | > 83 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 84 | > | --- | --- | --- | --- | --- | --- | 85 | > | T-DEV-BLD-0-1 | Применяются практики защиты инфраструктуры сборки ПО | 0 |- | SB-A-1 | CNFG1
SCS2 | 86 | > | T-DEV-BLD-1-1 | Доступ к среде сборки (build) (оркестратор, worker-узлы итд) ограничен (настроен RBAC) | 2 |- |- | AC2
MI1 | 87 | > | T-DEV-BLD-1-2 | Для всех узлов сборки (build worker) используется подход push (вместо pull) для передачи параметров | 2 |- |- |- | 88 | > | T-DEV-BLD-1-3 | Каждый узел сборки (build worker) имеет минимально необходимые сетевые доступы (для связи только с нужными сервисами и только по определенным портам\протоколам) | 2 |- | SB-A-2 | AC1
MI1 | 89 | > | T-DEV-BLD-1-4 | Выполняется централизованное хранение журналов (логов) сборки, включающее изменение настроек | 2 |- | SB-A-3 | SCS2 | 90 | > | T-DEV-BLD-2-1 | Осуществляется мониторинг и реагирование на инциденты для узлов сборки в части потребления вычислительных ресурсов (CPU, RAM, HDD и пр). | 3 | CMVM1.1 |- |- | 91 | > | T-DEV-BLD-3-1 | Каждый узел сборки (build worker) имеет отдельную роль (например, тестирование, компиляция, отправка артефактов), прочие задачи на нем не выполняются | 5 |- |- | TP3 | 92 | > | T-DEV-BLD-3-2 | Реализована настройка механизмов безопасности для узлов сборки | 5 |- | SB-A-1
SB-A-2 | CNFG1 | 93 | > | T-DEV-BLD-3-3 | Все настройки узлов сборки (build worker) централизованно хранятся в системе хранения исходного кода | 5 |- |- |- | 94 | > | T-DEV-BLD-4-1 | Создание среды сборки (build environment) выполняется автоматизировано (IaC) | 6 |- |- | SCS2 | 95 | > 96 |
97 | 98 | >
99 | > Защита source code management (SCM) [T-DEV-SCM] 100 | > 101 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 102 | > | --- | --- | --- | --- | --- | --- | 103 | > | T-DEV-SCM-0-1 | Применяются практики защиты репозитория кода | 0 |- |- |- | 104 | > | T-DEV-SCM-1-1 | Создавать и удалять репозитории могут только определенные пользователи (например, настроен RBAC) | 2 |- |- | AC2 | 105 | > | T-DEV-SCM-1-2 | Удалять issues могут только определенные пользователи (например, настроен RBAC) | 2 |- |- | AC2 | 106 | > | T-DEV-SCM-1-3 | Создавать teams/groups могут только определенные пользователи (например, настроен RBAC) | 2 |- |- | AC2 | 107 | > | T-DEV-SCM-1-4 | Количество администраторов VCS ограничено и регулярно проверяется | 2 |- |- |- | 108 | > | T-DEV-SCM-1-5 | Управление доступом к системе контроля версий осуществляется с использованием ролевой модели, созданной на основе принципа минимальных привилегий. Модель регулирует как минимум:
- Возможности по созданию репозиториев
- Возможности по удалению репозиториев
- Возможности по изменению видимости репозиториев | 2 |- |- |- | 109 | > | T-DEV-SCM-1-6 | Непривилегированным пользователям доступно создание только приватных репозиториев | 2 |- |- | AC2 | 110 | > | T-DEV-SCM-1-7 | При установке любых приложений и дополнений в Source code management системах (SCM) запрашивается одобрение (approval) администратора | 2 |- |- |- | 111 | > | T-DEV-SCM-2-1 | У всех копий (forks) кода включен аудит, а также назначен ответственный | 3 |- |- |- | 112 | > | T-DEV-SCM-2-2 | Регулярно осуществляется анализ и удаление неактивных пользователей из проекта | 3 |- |- |- | 113 | > | T-DEV-SCM-2-3 | Почтовые уведомления могут направляться только на доверенные (проверенные) домены | 3 |- |- |- | 114 | > | T-DEV-SCM-2-4 | Неактивные (ненужные) приложения (applications или дополнения) удаляются из SCM системы | 3 |- | OM-B-1 |- | 115 | > | T-DEV-SCM-2-5 | Для каждого репозитория по умолчанию установлены минимальные привилегии пользователей | 3 |- | SA-A-1 |- | 116 | > | T-DEV-SCM-2-6 | Для добавления нового пользователя в VCS используются только корпоративные email | 3 |- |- |- | 117 | > | T-DEV-SCM-3-1 | Все изменения видимости проекта отслеживаются | 4 |- |- |- | 118 | > | T-DEV-SCM-3-2 | Осуществляется идентификация неиспользуемых репозиториев и их архивирование | 4 |- |- |- | 119 | > | T-DEV-SCM-3-3 | Доступ к SCM осуществляется с использованием многофакторной аутентификации | 4 |- |- |- | 120 | > | T-DEV-SCM-3-4 | Доступ к VCS системам осуществляется только с разрешенных IP-адресов | 4 |- |- | AC1 | 121 | > | T-DEV-SCM-4-1 | Проводится анализ кода на наличие аномалий, релевантных организации (например, commit содержит слишком значительные изменения объемов кода или в commit'ов слишком много в определенный промежуток времени) | 6 |- |- | MI4 | 122 | > | T-DEV-SCM-4-2 | Доступ разработчиков к репозиторию осуществляется с использованием сертификатов, созданных только с использованием внутреннего CA (центр сертификации) компании (а не самоподписанные сертификаты) в качестве дополнительного фактора аутентификации | 6 |- |- |- | 123 | > 124 |
125 | 126 | 127 | >
128 | > Контроль внесения изменений в исходный код [T-DEV-SRC] 129 | > 130 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 131 | > | --- | --- | --- | --- | --- | --- | 132 | > | T-DEV-SRC-0-1 | Применяются практики контроля внесения изменений в исходный код | 0 |- | RT-A-3 |- | 133 | > | T-DEV-SRC-1-1 | Все изменения в исходном коде отслеживаются с использованием системы контроля версий (SCM) | 1 |- |- | GF1 | 134 | > | T-DEV-SRC-1-2 | Круг согласования запроса на слияние исходного кода начинается заново при внесении новых предложений по изменению | 1 |- |- | GF1 | 135 | > | T-DEV-SRC-1-3 | Разработчики не обладают правами "dismiss code change review", позволяющими обходить стандартную процедуру проверки кода | 1 |- |- | AC2 | 136 | > | T-DEV-SRC-1-4 | Для всех репозиториев включена опция linear history. В качестве вариантов merge доступны только squash и rebase merge | 1 |- |- |- | 137 | > | T-DEV-SRC-1-5 | Используется защита веток (branch protection) | 1 |- |- |- | 138 | > | T-DEV-SRC-2-1 | Осуществляется регулярный анализ и удаление неиспользуемых веток (branches) | 3 |- |- |- | 139 | > | T-DEV-SRC-2-2 | Запрос на слияние (merge request) реализуется только при успешном прохождении всех проверок | 3 | ST3.6 |- |- | 140 | > | T-DEV-SRC-2-3 | Все открытые ветки (branches) обновляются перед отправкой запроса на merge | 3 |- |- |- | 141 | > | T-DEV-SRC-2-4 | Слияние изменений в исходном коде разрешены только в случае отсутствия открытых комментариев и обсуждений | 3 |- |- |- | 142 | > | T-DEV-SRC-2-5 | Для каждого изменения исходного кода есть соответствующий тикет в системе управления заданиями (task maganement system, например, jira) | 3 |- |- |- | 143 | > | T-DEV-SRC-2-6 | Правила защиты, применяемые к веткам (branch protection rules), применяются в том числе к УЗ администраторов | 3 |- |- |- | 144 | > | T-DEV-SRC-3-1 | Для наиболее важных файлов определены и назначены Code Owners | 4 |- |- |- | 145 | > | T-DEV-SRC-3-2 | Code Owners согласовывают изменения файлов, которые им "принадлежат" | 4 |- |- |- | 146 | > | T-DEV-SRC-3-3 | Только подписанные commits (signed commit) допускаются к merge requests (особенно в main-ветку) | 4 | SE2.4 |- |- | 147 | > | T-DEV-SRC-3-4 | Каждое изменение в исходном коде (каждый commit) согласовывается как минимум двумя аутентифицированными пользователями | 4 |- |- |- | 148 | > | T-DEV-SRC-3-5 | Осуществляется контроль за удалением защищенных веток (protected branch) | 4 |- |- |- | 149 | > | T-DEV-SRC-4-1 | Для всех репозиториев функция "force push" доступна только для владельца | 6 |- |- |- | 150 | > 151 |
152 | 153 | >
154 | > Защита конвейера сборки [T-DEV-CICD] 155 | > 156 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 157 | > | --- | --- | --- | --- | --- | --- | 158 | > | T-DEV-CICD-0-1 | Применяются практики защиты конвейера сборки ПО | 0 |- | SB-A-1 | AC2
MI1 | 159 | > | T-DEV-CICD-1-1 | Доступ к конвейеру сборки ограничен (настроен RBAC) | 1 |- |- | SCS2 | 160 | > | T-DEV-CICD-1-2 | Выполняется централизованное хранение журналов событий конвейеров сборки | 1 |- |- |- | 161 | > | T-DEV-CICD-1-3 | Используется подход "CICD as a code" при создании конвейера разработки | 1 | SM3.4 |- |- | 162 | > | T-DEV-CICD-2-1 | Для каждого этапа сборки строго определены входные и выходные параметры и результаты | 3 |- |- |- | 163 | > | T-DEV-CICD-2-2 | Изменение конфигурационных файлов CI\CD (конвейеров сборки) непрерывно отслеживается | 3 |- |- |- | 164 | > | T-DEV-CICD-3-1 | Выполняется централизованное хранение всех логов стадии сборки (Build) | 4 |- |- | SCS2 | 165 | > | T-DEV-CICD-4-1 | Каждый конвейер (CICD), используемый для сборки, имеет единственное предназначение (например, тестирование, компиляция, отправка артефактов), прочие задачи на нем не выполняются | 5 |- |- | TP3 | 166 | > 167 |
168 | 169 | ### Домен "Безопасность заказной разработки" 170 | 171 | >
172 | > Безопасность заказной разработки [T-CODE-SPC] 173 | > 174 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 175 | > | --- | --- | --- | --- | --- | --- | 176 | > | T-CODE-SPC-0-1 | Предъявляются требования к подрядчикам в части заказной разработки | 0 |- |- |- | 177 | > | T-CODE-SPC-1-1 | Предъявляются базовые функциональные требования по ИБ к разрабатываемому подрядчиками ПО | 2 |- |- |- | 178 | > | T-CODE-SPC-1-2 | При выборе подрядчика, осуществлющего заказную разработку, учитываются его возможности, опыт, существующие у подрядчика мероприятия, связанные с безопасной разработкой ПО. | 2 |- |- |- | 179 | > | T-CODE-SPC-2-1 | Для критичных приложений, разработанных подрядчиками, регулярно проводятся пентесты/исходный код проверяется своими силами иоли другими специализированными подрядчиками | 4 |- |- |- | 180 | > | T-CODE-SPC-2-2 | Разработаны и учитываются при выобре подрядчика детальные критерии в части безопасной разработки:
- Требования к наличию и использованию анализаторов кода и компонентов при разработке ПО;
- Требования к предоставлению отчетов об отсутсвтии и\или исправлении уязвимостей в разрабатываемом ПО;
и др. | 4 |- |- |- | 181 | > | T-CODE-SPC-2-3 | В Компании разработаны и применяются процедуры для выявления и контроля устранения выявленных уязвимостей в разрабатываемом подрядчиокм ПО | 4 |- |- |- | 182 | > | T-CODE-SPC-2-4 | В контракты на разработку подрядчиком ПО включаются формулировки, требующие предоставление компании-заказчику спецификаций программного обеспечения (Software Bill of Materials, SBOM) для каждой версии ПО. Определены механизмы получения SBOM. | 4 |- |- |- | 183 | > | T-CODE-SPC-3-1 | Внутри компании-заказчика проводится композиционный анализ разработанного подрядчиками на заказ ПО | 5 |- |- |- | 184 | > | T-CODE-SPC-3-2 | Для всех приложений, разработанных подрядчиками ПО, проводятся пентесты/проходит проверку исходный код (в случае его предоставления) внутренними силами или при помощи специализированных подрядчиков | 5 |- |- |- | 185 | > | T-CODE-SPC-3-3 | Все предоставляемые подрядчиком (разработчиком ПО) артефакты (включая SBOM) подписываются электронной подписью. В компании-заказчике внедрен процесс проверки подписей предоставляемых артефактов | 5 |- |- |- | 186 | > | T-CODE-SPC-3-4 | В контракты на разработку подрядчиком ПО включаются формулировки, требующие предоставление всего исходного кода разрабатываемого ПО. | 5 |- |- |- | 187 | > | T-CODE-SPC-3-5 | Проводится статический анализ исходного кода для разработанного поставщиком ПО, выполняется анализ полученных результатов | 5 |- |- |- | 188 | > | T-CODE-SPC-4-1 | Вся заказная разработка ПО ведется подрядчиками (разработчиками ПО) в инфраструктуре компании-заказчика, с использованием всех инструментов безопасной разработки (SAST, DAST, OSA\SCA, Container security и др.) и в соответстии с процессами компании-заказчика | 7 |- |- |- | 189 | > 190 |
191 | 192 | ### Домен "Контроль кода, ИБ артефактов, зависимостей и образов" 193 | 194 | >
195 | > Статический анализ (SAST) [T-CODE-SST] 196 | > 197 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 198 | > | --- | --- | --- | --- | --- | --- | 199 | > | T-CODE-SST-0-1 | Выполняется статический анализ исходного кода разрабатываемого ПО | 0 |- | ST-A-1 | SPA3 | 200 | > | T-CODE-SST-1-1 | Анализ исходного кода применяется, как минимум, ситуативно. | 2 | CR1.2 | ST-A-1 |- | 201 | > | T-CODE-SST-1-2 | В SAST используются, как минимум, правила по умолчанию | 2 |- | ST-A-1 |- | 202 | > | T-CODE-SST-2-1 | Выполняется регулярное сканирование отдельных частей кода, например:
- изменений в коде по результатам спринтов
- код разработанных framework
- итд | 3 |- | ST-A-2 | QA5 | 203 | > | T-CODE-SST-2-2 | Неиспользуемые правила анализа в SAST отключены | 3 |- | ST-A-2 | SPA4 | 204 | > | T-CODE-SST-2-3 | Выполнена интеграция SAST в CI (отдельный скрипт для каждой команды) | 3 | SM3.4
CR1.4
CR1.5 | ST-A-3 | SPA5 | 205 | > | T-CODE-SST-2-4 | Используются плагины SAST в IDE [при их наличии] | 3 |- |- | SPA3 | 206 | > | T-CODE-SST-3-1 | Выполняется регулярное сканирование SAST полной кодовой базы | 4 |- | ST-A-1 | QA5 | 207 | > | T-CODE-SST-3-2 | Используются кастомизированные правила | 4 | CR2.6 | ST-A-2 | SPA4
VM2 | 208 | > | T-CODE-SST-3-3 | Выполнена интеграция SAST с инструментом code quality (например, SonarQube) | 4 |- |- |- | 209 | > | T-CODE-SST-4-1 | Выполняется сканирование исходного кода open source компонентов (сканирование на malware, protestware и т.д.) | 7 |- | SB-B-3 |- | 210 | > 211 |
212 | 213 | >
214 | > Композиционный анализ (SCA) [T-CODE-SC] 215 | > 216 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 217 | > | --- | --- | --- | --- | --- | --- | 218 | > | T-CODE-SC-0-1 | Выполняется композиционный анализ разрабатываемого ПО | 0 | SM3.5 | SB-B-2 | OSS1
SCA1 | 219 | > | T-CODE-SC-1-1 | В SCA используются, как минимум, политики анализа по умолчанию | 1 | SE3.8 |- | SCA1 | 220 | > | T-CODE-SC-1-2 | Применяется выборочная блокировка подключаемых библиотек вручную при выявлении дефектов ИБ | 1 |- |- |- | 221 | > | T-CODE-SC-1-3 | В SCA сохраняется история всех используемых (использованных) библиотек | 1 | SR1.5 |- |- | 222 | > | T-CODE-SC-2-1 | Библиотеки с уязвимостями с высоким рейтингом, включая RCE, блокируются по договоренности между ИБ и разработчиками | 2 |- | DM-A-2 |- | 223 | > | T-CODE-SC-2-2 | Осуществляется контроль получения образов (получение только из доверенных репозиториев) | 2 |- |- |- | 224 | > | T-CODE-SC-2-3 | Выполняется проверка цифровых подписей и хэшей компонентов | 2 | SE2.4 | SB-A-1 |- | 225 | > | T-CODE-SC-2-4 | Настроена интеграция SCA в CI/CD | 2 | SM3.4
CR1.4
CR1.5 | ST-A-3 | SCA1
SCA3 | 226 | > | T-CODE-SC-2-5 | Выполняется проверка на лицензионную чистоту | 2 | SR2.7 | SB-B-2 | OSS4 | 227 | > | T-CODE-SC-3-1 | Подключение всех возможных open source feeds | 4 |- |- |- | 228 | > | T-CODE-SC-3-2 | Совмещение практик SAST и SCA для идентификации уязвимостей в коде (effective usage analyse. Например, библиотека уязвима, но при этом НЕ используется уязвимый метод) | 4 | CR3.2 |- |- | 229 | > | T-CODE-SC-3-3 | Используются SCA плагины для IDE для pre-commit hooks | 4 |- |- |- | 230 | > | T-CODE-SC-3-4 | Библиотеки со статусом End of life блокируются по договоренности между ИБ и разработчиками | 4 |- | OM-B-2 |- | 231 | > | T-CODE-SC-4-1 | Использование платных feeds, обогащающих результаты анализа open source компонентов | 6 |- |- |- | 232 | > 233 |
234 | 235 | >
236 | > Анализ образов контейнеров [T-CODE-IMG] 237 | > 238 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 239 | > | --- | --- | --- | --- | --- | --- | 240 | > | T-CODE-IMG-0-1 | Выполняется сканирование образов контейнеров на наличие уязвимостей | 0 |- |- |- | 241 | > | T-CODE-IMG-1-1 | Сканирование образов контейнеров на наличие уязвимостей регламентировано и выполняется стандартизированным набором инструментов | 1 |- |- |- | 242 | > | T-CODE-IMG-1-2 | Выполняется сканирование образов контейнеров. Запуск сканирования происходит в ручном режиме. | 1 |- |- | OSS3 | 243 | > | T-CODE-IMG-1-3 | Применяется выборочная блокировка образов контейнеров вручную при выявлении дефектов ИБ | 1 |- |- |- | 244 | > | T-CODE-IMG-2-1 | Выполняется сканирование образов контейнеров в CI/CD на наличие уязвимостей | 2 | SM3.4 |- |- | 245 | > | T-CODE-IMG-2-2 | Выполняется периодическое сканирование образов контейнеров, размещенных во внутренних репозиториях, на наличие уязвимостей | 2 |- |- |- | 246 | > | T-CODE-IMG-2-3 | При обнаружении дефектов ИБ в образах контейнеров автоматизированно создаются задачи на их устранение в тикет-системе | 2 |- |- |- | 247 | > | T-CODE-IMG-3-1 | Выполняется проверка цифровых подписей образов контейнеров | 3 | SE2.4 |- |- | 248 | > | T-CODE-IMG-3-2 | Non-compliant ресурсы блокируются по договоренности между ИБ и разработчиками | 3 |- |- |- | 249 | > | T-CODE-IMG-4-1 | Сборки в CI/CD блокируются при найденных уязвимостях в образах контейнеров по договоренности между ИБ и разработчиками. | 4 |- |- |- | 250 | > 251 |
252 | 253 | >
254 | > Идентификация секретов [T-CODE-SECDN] 255 | > 256 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 257 | > | --- | --- | --- | --- | --- | --- | 258 | > | T-CODE-SECDN-0-1 | Применяются практики поиска секретов | 0 |- |- | SPA7 | 259 | > | T-CODE-SECDN-1-1 | Механизмы идентификации секретов применяются как минимум в SCM системах | 1 |- |- |- | 260 | > | T-CODE-SECDN-1-2 | Инструменты идентификации секретов запускаются вручную | 1 |- |- |- | 261 | > | T-CODE-SECDN-1-3 | В инструментах идентификации секретов используются настройки поиска секретов, заданные по умолчанию | 1 |- |- | SPA7 | 262 | > | T-CODE-SECDN-1-4 | Инциденты ИБ, связанные с использованием найденных секретов, разрешаются совместно с разработчиками | 1 | CMVM1.1 | IM-A-2 |- | 263 | > | T-CODE-SECDN-2-1 | Инструменты идентификации секретов охватывают:
  - Все версии кода, хранящиеся в SCM
  - Манифесты IaC
  - Артефакты:
      - образы Docker,
      - Все репозитории
      - Облачную инфраструктуру
      - Сканирование и блокирование  секретов во   время стадий pull/Merge | 2 |- |- |- | 264 | > | T-CODE-SECDN-2-2 | В инструментах идентификации секретов используются кастомизированные настройки поиска секретов. | 2 | CR2.6 |- | SPA7
VM2 | 265 | > | T-CODE-SECDN-2-3 | При обработке событий ИБ, связанных с найденными секретами используется приоритизация | 2 |- | IM-B-2 |- | 266 | > | T-CODE-SECDN-3-1 | При наличии в коде секретов commit'ы блокируются по договоренности между ИБ и разработчиками
| 3 |- |- |- | 267 | > | T-CODE-SECDN-3-2 | Сканирование секретов также включает в себя:
- Рабочие станции разработчиков и любые adhoc среды
- Логи сборок (Build logs) | 3 |- |- |- | 268 | > | T-CODE-SECDN-4-1 | Hardcoded секреты отсутствуют | 5 |- | SD-B-2 |- | 269 | > 270 |
271 | 272 | >
273 | > Контроль безопасности Dockerfile’ов [T-CODE-DOCKERFS] 274 | > 275 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 276 | > | --- | --- | --- | --- | --- | --- | 277 | > | T-CODE-DOCKERFS-0-1 | Применяются практики безопасного написания Dockerfiles | 0 |- |- |- | 278 | > | T-CODE-DOCKERFS-1-1 | Разработан регламент по безопасному написанию Dockerfiles. | 1 |- |- |- | 279 | > | T-CODE-DOCKERFS-1-2 | Выполняется ручной контроль безопасности Dockerfile | 1 |- |- |- | 280 | > | T-CODE-DOCKERFS-2-1 | Dockerfiles проверяются автоматизировано в pipeline. | 2 |- |- |- | 281 | > 282 |
283 | 284 | ### Домен "Анализ ПО в режиме runtime - Preprod" 285 | 286 | >
287 | > Динамический анализ приложений (DAST) в PREPROD среде [T-PREPROD-DAST] 288 | > 289 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 290 | > | --- | --- | --- | --- | --- | --- | 291 | > | T-PREPROD-DAST-0-1 | Применяются практики динамического тестирования (DAST) | 0 |- | ST-A-1 | DPA2 | 292 | > | T-PREPROD-DAST-1-1 | Динамическое сканирование используется как минимум для пользовательского интерфейса | 3 |- | ST-A-1 |- | 293 | > | T-PREPROD-DAST-1-2 | Динамическое сканирование выполняется вручную | 3 |- |- |- | 294 | > | T-PREPROD-DAST-2-1 | Отключены неиспользуемые в сканере правила | 4 |- | ST-A-2 | DPA3 | 295 | > | T-PREPROD-DAST-2-2 | Выполняется сканирование без аутентификации (с полным покрытием пользовательского интерфейса):
-  Spider- сканирование (https://www.zaproxy.org/docs/desktop/addons/spider/)
-  Сканирование зависимостей | 4 | ST1.4 |- |- | 296 | > | T-PREPROD-DAST-2-3 | Выполняется сканирование с аутентификацией:
 - Выполняется сканирование зависимостей
 - При сканировании происходит использование всех возможных ролей и пользовательских типов
 - Поддержка существующих сессий
 - При сканировании используются функции log in/log out
 - Выполняется Spider-сканирование после аутентификации | 4 | ST1.4 |- |- | 297 | > | T-PREPROD-DAST-2-4 | Настроена интеграция сканера с инструментами CI/CD | 4 |- | ST-A-3 | DPA4 | 298 | > | T-PREPROD-DAST-3-1 | Выполняется сканирование в том числе скрытых путей | 5 |- |- | VM2 | 299 | > | T-PREPROD-DAST-3-2 | Используются доработанные (кастомизированные) параметры при сканировании для максимального покрытия входных параметров | 5 |- | ST-A-2 | DPA3
VM2 | 300 | > | T-PREPROD-DAST-3-3 | При сканировании используется бизнес-логика сканируемого приложения. Например, выполняется login, вносятся изменения в учетную запись, выполняется добавление товара в корзину и др. | 5 |- | RT-B-2 |- | 301 | > | T-PREPROD-DAST-3-4 | Выполняется раздельное сканирование backend и frontend, включая:
- Сканирование SOAP сервисов
- Сканирование сервисов proxy, которые передают запросы между frontend и backend
- fuzzing XML и JSON данных, которые передаются в API сервисы | 5 | ST2.6 |- | QA3
DPA1 | 302 | > | T-PREPROD-DAST-4-1 | Выполняется сканирование всех путей и взаимодействий (в т.ч. с backend) | 6 |- |- |- | 303 | > | T-PREPROD-DAST-4-2 | Используется несколько сканеров для увеличения поверхности сканирования и получения пересекающихся результатов | 6 |- | ST-A-1 |- | 304 | > | T-PREPROD-DAST-4-3 | Используются custom профили для динамического тестирования с повышенной интенсивностью и тяжестью для критичных частей приложения | 6 |- | ST-B-1 |- | 305 | > 306 |
307 | 308 | >
309 | > Тестирование на проникновение перед внедрением приложений в продуктив [T-PREPROD-PENTEST] 310 | > 311 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 312 | > | --- | --- | --- | --- | --- | --- | 313 | > | T-PREPROD-PENTEST-0-1 | Применяется тестирование на проникновение в среде Preprod | 0 |- | ST-B-2 | ISA3
ESA3 | 314 | > | T-PREPROD-PENTEST-1-1 | Тестирование на проникновение в среде Preprod проводится регулярно | 1 |- | ST-B-2 | ISA3
ESA3 | 315 | > | T-PREPROD-PENTEST-1-2 | Проводятся пентесты Preprod среды методом "черный ящик" (пентестер не знает ничего об атакуемой Preprod среде, кроме базовой информации о ней - доменные имена, ip-адреса) | 1 |- | ST-B-2 |- | 316 | > | T-PREPROD-PENTEST-1-3 | Проводятся пентесты методом "серый ящик" (пентестер знает все об атакуемой Preprod среде - архитектуру среды и анализируемого ПО, их версии, имеет доступ к исходному коду ПО и пр.) | 1 | PT2.2 | ST-B-2 |- | 317 | > | T-PREPROD-PENTEST-2-1 | Разработан и применяется регламент, описывающий проведение тестирования на проникновение в среде Preprod | 2 |- |- | ISA3
ESA3 | 318 | > | T-PREPROD-PENTEST-4-1 | Проводится анализ безопасности инструментов безопасной разработки (анализируются, например, инструменты SAST или OSA\SCA на предмет наличия в них уязвимостей или дефектов - можно ли без авторизации "украсть" отчеты, конфиги и пр) | 6 |- |- |- | 319 | > 320 |
321 | 322 | >
323 | > Функциональное ИБ-тестирование [T-PREPROD-SECTEST] 324 | > 325 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 326 | > | --- | --- | --- | --- | --- | --- | 327 | > | T-PREPROD-SECTEST-0-1 | Выполняется тестирование ИБ функционала разрабатываемого ПО | 0 |- | ST-A-1 | QA1 | 328 | > | T-PREPROD-SECTEST-1-1 | Функциональное ИБ-тестирование проводится (ситуативно, нерегламентированно) | 1 |- | RT-A-1 |- | 329 | > | T-PREPROD-SECTEST-2-1 | Разработан и применяется регламент, описывающий проведение функционального ИБ-тестирования | 2 | ST1.1 | PC-A-2 | QA1 | 330 | > | T-PREPROD-SECTEST-2-2 | Не менее 5% функциональных ИБ-тестов автоматизированы | 2 | ST2.5 | RT-A-1 | QA2
QA5 | 331 | > | T-PREPROD-SECTEST-3-1 | Более 20 % тестов функций ИБ-тестирования автоматизированы | 6 | ST2.5 | RT-A-3 | QA2
QA5 | 332 | > 333 |
334 | 335 | >
336 | > Анализ инфраструктуры PREPROD среды на уязвимости [T-PREPROD-VULN] 337 | > 338 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 339 | > | --- | --- | --- | --- | --- | --- | 340 | > | T-PREPROD-VULN-0-1 | Сканирование инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости производится в каком бы то ни было виде | 0 |- |- | ISA1 | 341 | > | T-PREPROD-VULN-1-1 | Сканирование инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости производится периодически в ручном режиме при помощи инструментов автоматизации или скриптов. (ситуативно нерегламентированно) | 2 |- |- |- | 342 | > | T-PREPROD-VULN-1-2 | Производится установка обновлений на элементы инфраструктуры, в т.ч. устранение выявленных уязвимостей | 2 |- | EM-B-2 | CNFG1 | 343 | > | T-PREPROD-VULN-2-1 | Выполняется регулярное сканирование наиболее критических компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости, а также выстроен процесс по их исправлению | 4 |- |- | ISA1 | 344 | > | T-PREPROD-VULN-2-2 | Выполняется регулярное выполнение задач инвентаризации активов PREPROD (среды тестирования и разработки ПО) сред автоматизированными средствами | 4 | SM3.1
AM2.9 |- |- | 345 | > | T-PREPROD-VULN-2-3 | Обновления безопасности регулярно устанавливаются на основные элементы инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратор и операционные систем серверов) | 4 |- | EM-B-3 | CNFG1 | 346 | > | T-PREPROD-VULN-3-1 | Выполняется регулярное сканирование всех компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО), а также выстроен процесс по их исправлению | 5 |- |- | ISA1 | 347 | > | T-PREPROD-VULN-3-2 | Выполняется автоматизированная проверка основных компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратора и операционных систем серверов) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий | 5 |- |- | CNFG1 | 348 | > | T-PREPROD-VULN-3-3 | Выполняется регулярное сканирование на уязвимости инфраструктуры PREPROD (среды тестирования и разработки ПО) автоматизированными средствами в режиме пентеста | 5 |- |- |- | 349 | > | T-PREPROD-VULN-3-4 | Обновления безопасности регулярно устанавливаются на все элементы инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратор и операционные систем серверов) | 5 |- |- |- | 350 | > | T-PREPROD-VULN-4-1 | Выполняется автоматизированная проверка всех компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) на соответствие лучшим практикам , а также организован процесс по исправлению несоответствий | 7 |- |- |- | 351 | > | T-PREPROD-VULN-4-2 | Осуществляется регулярная замена устаревшего неподдерживаемого производителями ПО для компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) | 7 |- | OM-B-3 |- | 352 | > 353 |
354 | 355 | >
356 | > Контроль безопасности манифестов (k8s, terraform и т.д.) [T-PREPROD-MANSEC] 357 | > 358 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 359 | > | --- | --- | --- | --- | --- | --- | 360 | > | T-PREPROD-MANSEC-0-1 | Выполняется ИБ тестирование файлов конфигураций (Dockerfiles, K8s manifests, Terraform, etc) | 0 |- | EM-A-3 | SPA1 | 361 | > | T-PREPROD-MANSEC-1-1 | Применяется анализ Dockerfile на наличие дефектов ИБ. | 2 |- |- | SPA1 | 362 | > | T-PREPROD-MANSEC-2-1 | Используется контроль конфигураций (k8s, IaC и т.п.) на наличие дефектов ИБ. | 3 | SE2.2 |- | SPA1 | 363 | > 364 |
365 | 366 | ### Домен "Защита ПО и инфраструктуры в режиме runtime" 367 | 368 | 369 | >
370 | > Управление секретами [T-PROD-SM] 371 | > 372 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 373 | > | --- | --- | --- | --- | --- | --- | 374 | > | T-PROD-SM-0-1 | Применяются практики управления секретами и защиты секретов | 0 |- |- | IA2 | 375 | > | T-PROD-SM-1-1 | Для управления секретами частично применяются встроенные механизмы ПО. Инструменты по управлению секретами не используются. | 1 |- |- |- | 376 | > | T-PROD-SM-1-2 | Инциденты ИБ, связанные с использованием секретов, разрешаются совместно с владельцами систем. | 1 | CMVM1.1 |- | MI4 | 377 | > | T-PROD-SM-2-1 | Используются инструменты по управлению секретами, но их использование не регламентировано. | 2 |- |- | IA2 | 378 | > | T-PROD-SM-2-2 | При разборе событий ИБ, связанных с секретами, используется приоритизация (ранжирование) этих событий.
Например, событию A присваивается более высокий приоритет при обработке, чем событию B. Правила приоритизации событий ИБ формализованы. | 2 |- |- | MI4 | 379 | > | T-PROD-SM-3-1 | Секреты всех сред  (за исключением Dev сред) хранятся в  системе управления секретами (допускается ситуативное использование hardcoded-секретов) | 3 |- |- | IA2 | 380 | > | T-PROD-SM-3-2 | Используется автоматизированная ротация секретов. | 3 |- |- |- | 381 | > | T-PROD-SM-3-3 | Разработаны и применяются регламенты по использованию инструментов по управлению секретами | 3 |- |- |- | 382 | > | T-PROD-SM-4-1 | Используются динамические секреты, генерируемые под каждую сессию взаимодействия систем | 5 |- |- | IA2 | 383 | > | T-PROD-SM-4-2 | Hardcoded секреты отсутствуют в продуктивной среде | 5 |- |- |- | 384 | > 385 |
386 | 387 | >
388 | > Тестирование на проникновение продуктивной среды [T-PROD-PENTEST] 389 | > 390 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 391 | > | --- | --- | --- | --- | --- | --- | 392 | > | T-PROD-PENTEST-0-1 | Проводится тестирование на проникновение в среде Prod | 0 |- |- | ISA3
ESA3 | 393 | > | T-PROD-PENTEST-1-1 | Проводятся пентесты Prod среды методом "черный ящик" (пентестер не знает ничего об атакуемой Prod среде, кроме базовой информации о ней - доменные имена, ip-адреса) | 2 |- |- |- | 394 | > | T-PROD-PENTEST-1-2 | Тестирование на проникновение в среде Prod проводится регулярно | 2 | PT1.1 |- | ISA3
ESA3 | 395 | > | T-PROD-PENTEST-1-3 | Проводятся пентесты методом "серый ящик" (пентестер знает все об атакуемой Prod среде - архитектуру среды и анализируемого ПО, их версии, имеет доступ к исходному коду ПО и пр.) | 2 | PT2.2 |- |- | 396 | > | T-PROD-PENTEST-2-1 | Разработан регламент, описывающий критерии и частоту проведения тестов на проникновение в среде PROD | 3 |- |- |- | 397 | > | T-PROD-PENTEST-3-1 | Разработана и внедрена программа Bug bounty | 4 | CMVM3.4 |- | TS2
ESA1 | 398 | > | T-PROD-PENTEST-4-1 | Проводятся пентесты вида "социальная инженерия", направленные и адаптированные на разработчиков | 7 |- |- |- | 399 | > | T-PROD-PENTEST-4-2 | Проводятся Red Team \ Purple Team учения с привлечением разработчиков | 7 | PT3.1
CMVM3.3 | EG-A-2 |- | 400 | > 401 |
402 | 403 | >
404 | > Динамический анализ приложений (DAST) в продуктивной среде [T-PROD-DAST] 405 | > 406 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 407 | > | --- | --- | --- | --- | --- | --- | 408 | > | T-PROD-DAST-0-1 | Применяются практики динамического тестирования (DAST) | 0 |- |- | DPA2 | 409 | > | T-PROD-DAST-1-1 | Динамическое сканирование используется как минимум для пользовательского интерфейса | 4 |- |- |- | 410 | > | T-PROD-DAST-1-2 | Используется пассивное сканирование с помощью зеркалирования трафика | 4 |- |- |- | 411 | > | T-PROD-DAST-1-3 | Динамическое сканирование выполняется вручную | 4 |- |- |- | 412 | > | T-PROD-DAST-2-1 | Используются механизмы активного и пассивного сканирования | 5 |- |- |- | 413 | > | T-PROD-DAST-2-2 | Выполняется сканирование без аутентификации (с полным покрытием пользовательского интерфейса):
-  Spider- сканирование (https://www.zaproxy.org/docs/desktop/addons/spider/)
-  Сканирование зависимостей | 5 |- |- |- | 414 | > | T-PROD-DAST-2-3 | Выполняется сканирование с аутентификацией:
 - Выполняется сканирование зависимостей
 - При сканировании происходит использование всех возможных ролей и пользовательских типов
 - Поддержка существующих сессий
 - При сканировании используются функции log in/log out
 - Выполняется Spider-сканирование после аутентификации | 5 |- |- |- | 415 | > | T-PROD-DAST-2-4 | Настроена интеграция сканера с инструментами CI/CD | 5 |- |- | DPA4 | 416 | > | T-PROD-DAST-2-5 | Отключены неиспользуемые в сканере правила | 5 |- |- | DPA3 | 417 | > | T-PROD-DAST-3-1 | Выполняется сканирование в том числе скрытых путей | 6 |- |- |- | 418 | > | T-PROD-DAST-3-2 | Используются доработанные (кастомизированные) параметры при сканировании для максимального покрытия входных параметров | 6 |- |- | DPA3 | 419 | > | T-PROD-DAST-3-3 | При сканировании используется бизнес-логика сканируемого приложения. Например, выполняется login, вносятся изменения в учетную запись, выполняется добавление товара в корзину и др. | 6 |- |- |- | 420 | > | T-PROD-DAST-3-4 | Выполняется раздельное сканирование backend и frontend, включая:
- Сканирование SOAP сервисов
- Сканирование сервисов proxy, которые передают запросы между frontend и backend
- fuzzing XML и JSON данных, которые передаются в API сервисы | 6 | ST2.6 |- | QA3
DPA1 | 421 | > | T-PROD-DAST-4-1 | Выполняется сканирование всех путей и взаимодействий (в т.ч. с backend) | 7 |- |- |- | 422 | > | T-PROD-DAST-4-2 | Используется несколько сканеров для увеличения поверхности сканирования и получения пересекающихся результатов | 7 |- |- |- | 423 | > | T-PROD-DAST-4-3 | Используются custom профили для динамического тестирования с повышенной интенсивностью и тяжестью для критичных частей приложения | 7 |- |- |- | 424 | > 425 |
426 | 427 | >
428 | > Управление изменениями инфраструктуры и доступом к ней [T-PROD-ACCESS] 429 | > 430 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 431 | > | --- | --- | --- | --- | --- | --- | 432 | > | T-PROD-ACCESS-0-1 | Применяются практики автоматизации жизненного цикла инфраструктуры (например, подход IaC), а также необходимые меры защиты | 0 |- | OM-B-3 |- | 433 | > | T-PROD-ACCESS-1-1 | Код инфраструктуры (IaC) хранится, в том числе, за пределами централизованного хранилища кода (SCM-системы) | 1 |- |- |- | 434 | > | T-PROD-ACCESS-1-2 | Использование концепции Infrastructure as code. Продуктивная среда описана в виде кода, регулярно актуализируется и является воспроизводимой. | 1 |- |- |- | 435 | > | T-PROD-ACCESS-1-3 | Реализован процесс контроля версий конфигурации инфраструктуры в виде кода (IaC) | 1 |- |- |- | 436 | > | T-PROD-ACCESS-1-4 | Доступ к продуктивной среде предоставлен ограниченному числу доверенных пользователей | 1 |- |- | AC2
MI1 | 437 | > | T-PROD-ACCESS-1-5 | Запрещено использование паролей по умолчанию | 1 |- |- |- | 438 | > | T-PROD-ACCESS-2-1 | Доступ к коду конфигурации инфраструктуры (файлам, описывающим IaC) предоставлен ограниченному числу пользователей | 3 |- |- | AC2 | 439 | > | T-PROD-ACCESS-2-2 | Настроен, включен и обрабатывается аудит любых изменений для конфигураций внедрения в любые среды | 3 |- |- |- | 440 | > | T-PROD-ACCESS-3-1 | Автоматизация внедрения в любые непродуктивные среды | 4 |- |- |- | 441 | > | T-PROD-ACCESS-4-1 | Автоматизация внедрения в любые продуктивные среды | 7 |- |- |- | 442 | > 443 |
444 | 445 | >
446 | > Контроль сетевого трафика (L4-L7) [T-PROD-NETWORK] 447 | > 448 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 449 | > | --- | --- | --- | --- | --- | --- | 450 | > | T-PROD-NETWORK-0-1 | Выполняется контроль сетевого трафика в PROD сегменте | 0 |- |- | AC1 | 451 | > | T-PROD-NETWORK-1-1 | Выполняется контроль сетевого трафика на уровне межсетевых экранов (L3/L4) в PROD сегменте | 1 | SE1.2 |- | AC1 | 452 | > | T-PROD-NETWORK-1-2 | PROD инфраструктура находится в выделенном сетевом сегменте | 1 |- |- | AC1
MI1 | 453 | > | T-PROD-NETWORK-2-1 | Настроены и используются глобальные сетевые политики на уровне сред контейнеризации | 2 |- |- | CNFG1 | 454 | > | T-PROD-NETWORK-2-2 | Настроены и используются L7 сетевые политики контроля трафика | 2 | SE1.1 |- | MI1
MI2 | 455 | > | T-PROD-NETWORK-3-1 | Настроены и используются кастомизированные сетевые политики для различных микросервисов (namespace) | 3 |- |- |- | 456 | > 457 |
458 | 459 | >
460 | > Контроль выполняемых и процессов и их прав доступа [T-PROD-RUN] 461 | > 462 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 463 | > | --- | --- | --- | --- | --- | --- | 464 | > | T-PROD-RUN-0-1 | Выполняется контроль и защита исполняемых процессов | 0 |- |- |- | 465 | > | T-PROD-RUN-1-1 | Используются средства контроля Runtime для сред контейнеризации (Kyverno, OPA gatekeeper, pod security admission, другие валидаторы) со стандартными настройками | 2 |- |- |- | 466 | > | T-PROD-RUN-2-1 | Используются кастомизированные политики Runtime для сред контейнеризации, как минимум уровня всего кластера | 3 |- |- | VM2 | 467 | > | T-PROD-RUN-3-1 | Настроены и используются кастомизированные Runtime политики для отдельных контейнерных приложений | 5 | SE3.3 |- |- | 468 | > 469 |
470 | 471 | >
472 | > Анализ инфраструктуры PROD среды на уязвимости [T-PROD-VULN] 473 | > 474 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 475 | > | --- | --- | --- | --- | --- | --- | 476 | > | T-PROD-VULN-0-1 | Применяется сканирование инфраструктуры на уязвимости в Prod сегменте | 0 |- |- | ISA1
ESA3 | 477 | > | T-PROD-VULN-1-1 | Сканирование инфраструктуры на уязвимости проводится, как минимум, вручную и ситуативно | 1 |- |- | ISA1 | 478 | > | T-PROD-VULN-1-2 | Производится установка обновлений на элементы инфраструктуры, в т.ч. устранение выявленных уязвимостей | 1 |- | EM-B-2 |- | 479 | > | T-PROD-VULN-2-1 | Выполняется регулярное сканирование компонентов инфраструктуры PROD, обеспечивающей доступ пользователем из сети Интернет на уязвимости, а также выстроен процесс по их исправлению | 2 |- |- |- | 480 | > | T-PROD-VULN-2-2 | Выполняется регулярное выполнение задач инвентаризации активов PROD автоматизированными средствами | 2 | SM3.1
AM2.9
CMVM2.3 |- |- | 481 | > | T-PROD-VULN-2-3 | Обновления безопасности регулярно устанавливаются на основные элементы инфраструктуры PROD (например, оркестратор и операционные систем серверов) | 2 |- | EM-B-3 | CNFG1 | 482 | > | T-PROD-VULN-3-1 | Выполняется регулярное сканирование всех компонентов инфраструктуры PROD, а также выстроен процесс по их исправлению | 3 | CMVM3.5 |- | ISA1
ESA3 | 483 | > | T-PROD-VULN-3-2 | Выполняется автоматизированная проверка основных компонентов инфраструктуры PROD (например, оркестратора и операционных систем серверов) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий | 3 | CMVM3.5 |- | CNFG1 | 484 | > | T-PROD-VULN-3-3 | Выполняется регулярное сканирование на уязвимости инфраструктуры PROD автоматизированными средствами в режиме пентеста | 3 | CMVM3.5 |- |- | 485 | > | T-PROD-VULN-3-4 | Обновления безопасности регулярно устанавливаются на все элементы инфраструктуры PROD (например, оркестратор и операционные систем серверов) | 3 |- |- |- | 486 | > | T-PROD-VULN-4-1 | Выполняется автоматизированная проверка всех компонентов инфраструктуры PROD на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий | 5 | CMVM3.5 | PC-A-3 |- | 487 | > | T-PROD-VULN-4-2 | Осуществляется регулярная замена устаревшего неподдерживаемого производителями ПО в инфраструктуре PROD | 5 |- | OM-B-3 |- | 488 | > 489 |
490 | 491 | >
492 | > Анализ событий информационной безопасности [T-PROD-EVENTS] 493 | > 494 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 495 | > | --- | --- | --- | --- | --- | --- | 496 | > | T-PROD-EVENTS-0-1 | Собираются (хоть какие-то) события от элементов PROD инфраструктуры | 0 |- |- | MI4 | 497 | > | T-PROD-EVENTS-2-1 |
Разработана и применяется политика аудита в PROD инфраструктуре  (например, Kubernetes Audit policy)
Логи собираются, но не обрабатываются (например, хранятся внутри кластера Kubernetes) | 2 |- |- | MI4 | 498 | > | T-PROD-EVENTS-3-1 |
Все логи PROD инфраструктуры (например, Kubernetes) обрабатываются в SIEM, созданы правила корреляции в SIEM для идентификации инцидентов | 3 | SE3.3
CMVM1.1 |- | MI4 | 499 | > 500 |
501 | 502 | ### Домен "Обучение и база знаний" 503 | 504 | >
505 | > Обучение специалистов [P-EDU-AWR] 506 | > 507 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 508 | > | --- | --- | --- | --- | --- | --- | 509 | > | P-EDU-AWR-0-1 | Производится обучение разработчиков в части ИБ | 0 |- | EG-A-1 | ET2 | 510 | > | P-EDU-AWR-1-1 | В Компании есть базовый тренинг по ИБ | 1 |- | EG-A-1 | ET1 | 511 | > | P-EDU-AWR-1-2 | Обучение по ИБ для команд разработки осуществляется ситуативно | 1 |- |- | ET2 | 512 | > | P-EDU-AWR-2-1 | Проводятся регулярные тренинги по ИБ для всех разработчиков (внешний, внутренний, электронный тренинг) | 3 | T1.1
T2.9 | EG-A-2 | ET2 | 513 | > | P-EDU-AWR-2-2 | Процесс обучения для разработчиков формализован (например, существует Регламент повышения осведомленности в области безопасной разработки) | 3 |- | EG-A-3 |- | 514 | > | P-EDU-AWR-2-3 | Проводятся специализированные тренинги по ИБ для Security Champion | 3 | T2.5
T2.9 | EG-A-2 | TAS1 | 515 | > | P-EDU-AWR-2-4 | Внедрена и используется специализированная централизованная платформа для проведения обучения по ИБ | 3 |- | EG-A-3 | ET4 | 516 | > | P-EDU-AWR-3-1 | В Компании внедрена и работает программа поощрения внутреннего обмена опытом | 5 | T2.12 | EG-B-3 | ET2
TAS2 | 517 | > | P-EDU-AWR-3-2 | В Компании разработана и внедрена система мотивации сотрудников за прохождение ИБ обучения | 5 | T3.1 |- | ET2
ET4 | 518 | > | P-EDU-AWR-4-1 | Команда ИБ регулярно участвует в CTF-like соревнованиях (или тренируется в кибер-полигоне) в контексте Web, SSDLC
| 6 |- |- | ET4 | 519 | > 520 |
521 | 522 | >
523 | > Управление базой знаний DSO [P-EDU-KB] 524 | > 525 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 526 | > | --- | --- | --- | --- | --- | --- | 527 | > | P-EDU-KB-0-1 | Существуют внутренние информационные ресурсы (базы знаний) с правилами и рекомендациями по безопасной разработке | 0 |- | EG-B-3 | SP1
SC2 | 528 | > | P-EDU-KB-1-1 | Существуют локальные базы знаний у участников разработки в рамках одной команды | 1 |- |- | SP3 | 529 | > | P-EDU-KB-2-1 | Существует централизованный ресурс (общая база знаний), хранящий базовые правила и рекомендации по безопасной разработке | 3 | SM1.1
SR1.1
SR1.2 |- | SP1 | 530 | > | P-EDU-KB-2-3 | Единая база знаний обновляется (нерегулярно, ответственные формально не выделены, QA не проводится) | 3 | SR1.1
SR1.2 |- | SP2 | 531 | > | P-EDU-KB-3-1 | Централизованный ресурс (общая база знаний), хранит единые детальные правила и рекомендации по безопасной разработке, относящиеся, как к компании в целом, так и к отдельным командам разработки | 4 | SR1.2
SR3.3 |- | SC2 | 532 | > | P-EDU-KB-3-2 | Единая база знаний обновляется регулярно, назначены ответственные за ее обновление как внутри команд, так и в компании, выполняется QA созданные материалов в базе знаний | 4 | SR1.2
SR2.2 |- | SP2 | 533 | > | P-EDU-KB-4-1 | Разработаны и внедрены стандарты написания документации, единая база знаний следует таким стандартам и содержит необходимый комплект документов и информации к разрабатываемому ПО | 5 |- |- |- | 534 | > 535 |
536 | 537 | ### Домен "Контроль и формирование требований ИБ к ПО" 538 | 539 | >
540 | > Оценка критичности приложений и моделирование угроз [P-REQ-TM] 541 | > 542 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 543 | > | --- | --- | --- | --- | --- | --- | 544 | > | P-REQ-TM-0-1 | Выполняется оценка критичности и/или моделирование угроз для разрабатываемых приложений | 0 |- | TA-B-1 | TMR1
TMR2 | 545 | > | P-REQ-TM-1-1 | Проводится моделирование угроз по требованиям compliance (например, для ПО для ЗОКИИ) или для наиболее критичных | 2 |- |- | TMR3 | 546 | > | P-REQ-TM-1-2 | Определены формальные критерии критичности приложений | 2 | AA1.4 | TA-A-1 | OAD2 | 547 | > | P-REQ-TM-1-3 | Для всех новых разрабатываемых приложений проводится оценка критичности | 2 | AA1.4 | TA-A-1 | TMR2 | 548 | > | P-REQ-TM-2-1 | Модели угроз разрабатываются в том числе и для технических средств | 3 |- |- | TMR2 | 549 | > | P-REQ-TM-2-2 | Моделирование угроз осуществляется для ВСЕХ НОВЫХ приложений | 3 | AA1.1 |- | TMR2 | 550 | > | P-REQ-TM-2-3 | Оценка критичности выполняется для всех приложений | 3 | AA1.4 | TA-A-2 | OAD2 | 551 | > | P-REQ-TM-3-1 | Модели угроз разрабатываются в том числе и для бизнес-процессов | 4 |- | SM-A-1 |- | 552 | > | P-REQ-TM-3-2 | Процесс моделирования угроз для разрабатываемого ПО стандартизован (есть шаблоны МУиМН, определены подходы к актуализации угроз и пр) | 4 | AM1.3
AA2.1
AA2.2 | TA-B-2 |- | 553 | > | P-REQ-TM-3-3 | Модели угроз регулярно пересматриваются | 4 |- | TA-B-3 | TMR2 | 554 | > | P-REQ-TM-4-1 | К каждому разрабатываемому ПО определены "Abuse cases" (сценарии нелегитимного использования ПО), такие кейсы учитываются при моделировании угроз и доработке ПО | 5 | AM2.1 | RT-B-2 |- | 555 | > 556 |
557 | 558 | >
559 | > Определение требований ИБ, предъявляемых к ПО [P-REQ-RD] 560 | > 561 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 562 | > | --- | --- | --- | --- | --- | --- | 563 | > | P-REQ-RD-0-1 | К разрабатываемым приложениям предъявляются требования по информационной безопасности | 0 |- | SR-A-1 |- | 564 | > | P-REQ-RD-1-1 | Разработаны и предъявляются базовые требования по ИБ к разрабатываемому ПО | 1 |- | SR-A-2 | TMR4 | 565 | > | P-REQ-RD-1-2 | Подразделение ИБ одобряет\согласовывает решения, которые влияют на уровень ИБ разрабатываемого приложения | 1 |- | SR-A-2 |- | 566 | > | P-REQ-RD-2-1 | Дополнительные требования по ИБ формируются с учетом актуальных угроз по результатам моделирования угроз | 2 |- |- | TMR6 | 567 | > | P-REQ-RD-2-2 | Требования по ИБ стандартизованы (например, разработаны чеклисты) | 2 |- | SR-A-2 | TMR4 | 568 | > | P-REQ-RD-2-3 | Подразделения ИБ участвуют в создании архитектуры разрабатываемого ПО | 2 | SFD1.2 |- |- | 569 | > | P-REQ-RD-3-1 | Дополнительные требования по ИБ формируются с учетом актуальных угроз для бизнес-функций (по результатам соответствующего моделирования угроз) | 4 |- | TA-B-2 |- | 570 | > | P-REQ-RD-3-2 | Дополнительные требования по ИБ формируются с учетом результатов анализа рисков | 4 |- |- | TMR5
RM2 | 571 | > | P-REQ-RD-3-3 | Ключевые решения, которые влияют на уровень ИБ разрабатываемого приложения, принимаются на архитектурном комитете | 4 |- | SA-A-3 (???) | TP4 | 572 | > 573 |
574 | 575 | >
576 | > Контроль выполнения требований ИБ [P-REQ-CR] 577 | > 578 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 579 | > | --- | --- | --- | --- | --- | --- | 580 | > | P-REQ-CR-0-1 | Контролируется выполнение требований ИБ к разрабатываемому ПО | 0 | CP2.3 | SR-A-2 |- | 581 | > | P-REQ-CR-1-1 | Требования ИБ к разрабатываемому ПО проверяются на этапе выпуска ПО в продуктовую среду | 1 | SM1.4
CP2.3 | SB-A-3 | VC2
ISA2 | 582 | > | P-REQ-CR-2-1 | Осуществляется контроль выполнения требований ИБ к разрабатываемому ПО посредством функциональных тестирований ИБ и тестирований на проникновение | 2 | SM1.4
CP2.3
ST1.3 | RT-B-2 and ST-B-2 | VC2
ISA2 | 583 | > | P-REQ-CR-3-1 | Производится валидация отсутствия уязвимостей в программном коде ПО (например, применение Quality gates, которые зафиксированы в документе) | 5 | SM1.4
SM2.2 | SD-A-2 and SB-A-3 | VC1 | 584 | > | P-REQ-CR-4-1 | Производится проверка и согласование технического задания и проекта архитектуры, разработанных с учетом требований ИБ | 6 | SM1.4 | AA-A-1 |- | 585 | > 586 |
587 | 588 | >
589 | > Разработка стандартов конфигураций разрабатываемого ПО [P-REQ-STDR-App] 590 | > 591 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 592 | > | --- | --- | --- | --- | --- | --- | 593 | > | P-REQ-STDR-App-0-1 | Создаются стандарты конфигурирования разрабатываемого ПО | 0 |- | EM-A-1 | IA1 | 594 | > | P-REQ-STDR-App-1-1 | Стандарты конфигурирования разрабатываемого ПО есть, но не формализованы (т.е. это НЕ стандарты, а рекомендации или легаси настройки) | 3 |- | EM-A-1 |- | 595 | > | P-REQ-STDR-App-1-2 | Стандарты конфигурирования (рекомендации, легаси настройки) разрабатываемого ПО применяются вручную | 3 |- |- |- | 596 | > | P-REQ-STDR-App-2-1 | Стандарты конфигурирования разрабатываемого ПО разработаны для ключевых систем | 4 |- | EM-A-1 | CNFG1 | 597 | > | P-REQ-STDR-App-3-1 | Разработаны и применяются для всех систем | 5 |- | EM-A-2 | CNFG1 | 598 | > | P-REQ-STDR-App-3-3 | Использование подхода IaC | 5 |- |- |- | 599 | > | P-REQ-STDR-App-4-1 | Выполняется регулярное обновление профилей конфигурирования с учетом risk-based approach | 6 |- | EM-A-3 | CNFG2 | 600 | > 601 |
602 | 603 | >
604 | > Разработка стандартов конфигураций для компонентов инфраструктуры [P-REQ-STDR-Infr] 605 | > 606 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 607 | > | --- | --- | --- | --- | --- | --- | 608 | > | P-REQ-STDR-Infr-0-1 | Создаются стандарты конфигурирования компонентов инфраструктуры | 0 |- |- | PA1 | 609 | > | P-REQ-STDR-Infr-1-1 | СККИ есть, но не формализованы (т.е. это НЕ стандарты, а рекомендации или легаси настройки) | 1 |- |- |- | 610 | > | P-REQ-STDR-Infr-1-2 | СККИ (рекомендации, легаси настройки) применяются вручную | 1 |- |- | PA1 | 611 | > | P-REQ-STDR-Infr-2-1 | СККИ разработаны для ключевых инфраструктурных систем | 2 | SR3.4 |- | CNFG1 | 612 | > | P-REQ-STDR-Infr-2-2 | Производится выборочный контроль применения СККИ (без использования средств автоматизации) | 2 |- |- |- | 613 | > | P-REQ-STDR-Infr-3-1 | Разработаны и применяются для всех систем | 3 | SR3.4 |- | CNFG1 | 614 | > | P-REQ-STDR-Infr-3-2 | Используются автоматизированные средства контроля применения СККИ | 3 |- |- |- | 615 | > | P-REQ-STDR-Infr-3-3 | Использование подхода IaC | 3 |- |- | PA1 | 616 | > | P-REQ-STDR-Infr-4-1 | Регулярное обновление СККИ с учетом risk-based approach | 5 |- |- | CNFG2 | 617 | > 618 |
619 | 620 | ### Домен "Управление ИБ дефектами" 621 | 622 | >
623 | > Обработка дефектов ИБ [P-DEFECT-MNG] 624 | > 625 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 626 | > | --- | --- | --- | --- | --- | --- | 627 | > | P-DEFECT-MNG-0-1 | Выполняется контроль устранения дефектов ИБ | 0 |- |- | VM1 | 628 | > | P-DEFECT-MNG-1-1 | Обработка дефектов разрабатываемого ПО осуществляется при необходимости (onDemand, ситуативно, отсутствует системный подход) | 1 |- | DM-A-2 | VM1 | 629 | > | P-DEFECT-MNG-2-1 | Все дефекты критического уровня обрабатываются в приоритетном порядке | 2 |- | DM-A-2 |- | 630 | > | P-DEFECT-MNG-2-2 | Поиск дефектов автоматизирован и является частью CI\CD | 2 | SM3.4 | SD-A-2 |- | 631 | > | P-DEFECT-MNG-3-1 | Для каждого дефекта ИБ создается задача в Task tracker (например, в Jira). Осуществляется контроль устранения дефекта (выполнения задачи) | 3 | PT1.2
CMVM1.3
CMVM3.1 | DM-A-2 | VM1 | 632 | > | P-DEFECT-MNG-3-2 | Внедрен и контролируется SLA по исправлению дефектов ИБ | 3 |- | DM-A-3 | VM1
VM3 | 633 | > | P-DEFECT-MNG-3-3 | На QG проверяется отсутствие дефектов заданного уровня критичности (и это является критерием прохождения QG) | 3 | SM2.2 | SB-A-3 | SPA5
VC1
PA3 | 634 | > | P-DEFECT-MNG-4-1 | Дефекты обрабатываются в соответствии с risk-based approach | 7 |- | DM-A-2 | CNFG2
VM1 | 635 | > 636 |
637 | 638 | >
639 | > Консолидация дефектов ИБ [P-DEFECT-CNS] 640 | > 641 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 642 | > | --- | --- | --- | --- | --- | --- | 643 | > | P-DEFECT-CNS-0-1 | Выполняется централизованное хранение и обработка отчетности по найденным дефектам ИБ | 0 |- | DM-A-2 | VM1 | 644 | > | P-DEFECT-CNS-1-1 | Внедрено и используется централизованное хранилище отчетов по дефектам ИБ разрабатываемого ПО | 3 | CR2.8 |- | VM1 | 645 | > | P-DEFECT-CNS-1-2 | Отчетность выгружается и хранится централизовано для ряда проверок\инструментов | 3 |- |- | SPA6 | 646 | > | P-DEFECT-CNS-2-1 | Отчетность выгружается и хранится централизовано для всех проверок\инструментов, которые есть в Компании и которые анализируют разрабатываемое ПО | 4 | CR2.8 |- |- | 647 | > | P-DEFECT-CNS-3-1 | Внедрена и используется SGRC для управления отчетами | 5 | SM3.1 |- |- | 648 | > | P-DEFECT-CNS-3-2 | Отчеты загружаются в SGRC в ручном режиме | 5 | SM3.1
CR2.8 |- |- | 649 | > | P-DEFECT-CNS-4-1 | Отчеты загружаются в SGRC в автоматическом режиме | 6 | SM3.1
CR2.8 |- |- | 650 | > | P-DEFECT-CNS-4-2 | Существует перечень ответственных за работу с дефектами, описаны пути эскалаций устранения дефектов ИБ | 6 |- |- |- | 651 | > 652 |
653 | 654 | ### Поддомен. Оценка эффективности процессов 655 | 656 | >
657 | > Управление набором метрик ИБ [P-MET-SET] 658 | > 659 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 660 | > | --- | --- | --- | --- | --- | --- | 661 | > | P-MET-SET-0-1 | Метрики процессов DSO не разработаны | 0 |- |- | RM1 | 662 | > | P-MET-SET-2-1 | Определены и описаны метрики процессов DSO | 3 | SM3.3 | SM-B-1 | RM3 | 663 | > | P-MET-SET-2-2 | Определены целевые значения по каждой метрике процессов DSO | 3 |- | SM-B-2 | RM3 | 664 | > | P-MET-SET-3-1 | Выполняется регулярный пересмотр собираемых метрик процессов DSO | 4 | SM3.3 |- | RM4 | 665 | > | P-MET-SET-3-2 | Выполняется регулярная корректировка целевых значений | 4 |- | SM-B-3 |- | 666 | > 667 |
668 | 669 | >
670 | > Контроль исполнения метрик [P-MET-EX] 671 | > 672 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 673 | > | --- | --- | --- | --- | --- | --- | 674 | > | P-MET-EX-0-1 | Выполняется контроль метрик DSO | 0 |- | SM-B-3 |- | 675 | > | P-MET-EX-2-1 | Выполняется сбор и анализ метрик процессов DSO | 3 | SM3.3 |- |- | 676 | > | P-MET-EX-2-2 | Выполняется формирование отчетов и сравнение результатов метрик процессов DSO с целевыми показателями | 3 |- |- |- | 677 | > | P-MET-EX-3-1 | Сбор и анализ метрик для всех команд | 4 |- |- |- | 678 | > | P-MET-EX-3-2 | Проводится регулярная оценка эффективности реализуемых мероприятий на основе собираемых метрик процессов DSO | 4 |- |- | OAD5 | 679 | > | P-MET-EX-3-3 | Выполняется визуализация результатов сбора метрик процессов DSO (формирование дашбордов. Например, в Grafana) | 4 | SM2.1 |- |- | 680 | > | P-MET-EX-4-1 | Производится модернизация и совершенствование бизнес-процессов на основании собираемых метрик процессов DSO. Есть такие примеры (или же описан где-то такой процесс) | 6 | CP3.3 |- |- | 681 | > 682 |
683 | 684 | ### Домен "Функциональные роли" 685 | 686 | >
687 | > Security Champions [P-ROLE-SC] 688 | > 689 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 690 | > | --- | --- | --- | --- | --- | --- | 691 | > | P-ROLE-SC-0-1 | Используются практики Security Champion - регулярное взаимодействие с командами разработки по вопросам ИБ | 0 | SM2.3 | EG-B-1 | TAS4 | 692 | > | P-ROLE-SC-1-1 | Функции Security Champion выполняются, как минимум, специалистами ИБ | 1 |- |- | TAS4 | 693 | > | P-ROLE-SC-2-1 | В команде\проекте есть выделенный security champion | 3 |- | EG-B-1 | TAS4 | 694 | > | P-ROLE-SC-2-2 | Security Champion продвигает внутри команды лучшие практики в части безопасной разработки, делится с командами AppSec данными об уязвимостях и новых методах и практиках ИБ | 3 |- |- | SC2 | 695 | > | P-ROLE-SC-3-1 | Security Champion проводит R&D работу в части использования новых инструментов ИБ и отчитывается о результатах AppSec команде | 4 |- |- | TAS4 | 696 | > | P-ROLE-SC-3-2 | Security Champion поддерживает используемые в цикле безопасной разработки инструменты ИБ в актуальном состоянии | 4 | CR1.7 |- | TAS4 | 697 | > | P-ROLE-SC-3-3 | Security Champion проводит проверку безопасности кода в своей области экспертизы | 4 |- | EG-B-1 | SC2 | 698 | > | P-ROLE-SC-3-4 | Security Champion участвует в разработке PoC и тестировании новых инструментов ИБ | 4 |- |- |- | 699 | > | P-ROLE-SC-4-1 | Security Champion проводит тренинги по безопасной разработке и ИБ в целом для новых разработчиков | 7 | Т1.8 |- | SC2 | 700 | > | P-ROLE-SC-4-2 | Security Champion работает до 3х месяцев в команде AppSec в рамках практик ротации работников | 7 |- |- |- | 701 | > | P-ROLE-SC-4-3 | Security champion проводит проверки (review) моделей угроз, безопасного дизайна, а также peer-review работ, выполненных другими security champion | 7 |- |- | SC2
SPA2 | 702 | > | P-ROLE-SC-4-4 | Security champion выполняет PoC для новых эксплойтов, а также проверку приложений на выполнение требований по ИБ | 7 |- |- |- | 703 | > 704 |
705 | 706 | >
707 | > Разграничение ролей процесса DSO [P-ROLE-RESP] 708 | > 709 | > |ID| Описание | Уровень зрелости | BSIMM| SAMM | ASTP 710 | > | --- | --- | --- | --- | --- | --- | 711 | > | P-ROLE-RESP-0-1 | Существует разграничение ролей процесса безопасной разработки | 0 |- |- |- | 712 | > | P-ROLE-RESP-1-1 | В подразделении ИБ определены специалисты, отвечающие за безопасность разрабатываемого ПО (в дополнение к другой деятельности) | 1 |- | EG-B-2 | TAS1 | 713 | > | P-ROLE-RESP-1-2 | Обязанности и ответственность за безопасность разрабатываемого ПО закреплены формально (приказ, должностная инструкция и пр.) | 1 |- |- |- | 714 | > | P-ROLE-RESP-2-1 | Выделены сотрудники ИБ (роли), основной обязанностью которых является безопасность разработки (DSO) | 3 |- |- | TAS1 | 715 | > | P-ROLE-RESP-2-2 | Сформирована матрица ролей в части DSO | 3 |- |- |- | 716 | > | P-ROLE-RESP-2-3 | Разработан и введен в действие регламент безопасной разработки | 3 |- | PC-A-1 | OAD3
SC2 | 717 | > | P-ROLE-RESP-3-1 | Разработана и используется RACI-матрица для всего процесса DSO | 4 |- |- |- | 718 | -------------------------------------------------------------------------------- /DAF_public_v4.1.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Jet-Security-Team/DevSecOps-Assessment-Framework/5d8df394527929a5a6ea8e20cb12184c98fee668/DAF_public_v4.1.xlsx -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | ======================================================================================================== 2 | "THE BEER-WARE LICENSE" (Revision 42): 3 | -------------------------------------------------------------------------------------------------------- 4 | * Jet Infosystems DevSecOps Team made this Framework. As long as you retain this notice * 5 | * you can do whatever you want with it. If we meet some day, and you think this Framework is worth it, * 6 | * you can buy us a beer. * 7 | -------------------------------------------------------------------------------------------------------- 8 | A small and optional request: 9 | -------------------------------------------------------------------------------------------------------- 10 | > If you use our Framework for commercial purposes, in local or government development regulations, < 11 | > for marketing or other public purposes, if you talk about this Framework in articles or < 12 | > at conferences, please let us know. < 13 | > Telegram: DevSecOps_Assessment_Framework < 14 | > Mail: daf@jet.su < 15 | ======================================================================================================== 16 | 17 | 18 | 19 | ======================================================================================================== 20 | "ЛИЦЕНЗИЯ BEER-WARE" (Версия 42): 21 | -------------------------------------------------------------------------------------------------------- 22 | * Команда DevSecOps АО "Инфосистемы Джет" создала этот Фреймворк. До тех пор, пока вы * 23 | * видите это уведомление, вы можете делать с этими материалами все, что угодно. Если мы однажды * 24 | * встретимся, и вы будете считать, что материал был вам полезен, можете купить нам пиво. * 25 | -------------------------------------------------------------------------------------------------------- 26 | Небольшая и необязательная просьба: 27 | -------------------------------------------------------------------------------------------------------- 28 | > Если вы используете наш Фреймворк в коммерческих целях, в разработке локальных или государственных < 29 | > нормативных актов, в маркетинговых или иных публичных целях, если рассказываете об этом Фреймворке < 30 | > в статьях или на конференциях — сообщайте, пожалуйста, нам. < 31 | > Telegram: DevSecOps_Assessment_Framework < 32 | > Mail: daf@jet.su < 33 | ======================================================================================================== 34 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # DevSecOps Assessment Framework (DAF) 2 | 3 | ### Cодержание 4 | 5 | - [Введение](#введение) 6 | - [Важный дисклеймер](#важный-дисклеймер) 7 | - [Цели и задачи DAF](#цели-и-задачи-daf) 8 | - [Описание DAF](#описание-daf) 9 | - [Карта DAF (ex - *Пиратская карта*)](#карта-daf) 10 | - [Модель Технологии](#модель-технологии) 11 | - [Модель Процессы](#модель-процессы) 12 | - [Маппинг со стандартами и Тепловая матрица](#маппинг-со-стандартами-и-тепловая-матрица) 13 | - [Маппинг со стандартами](#маппинг-со-стандартами) 14 | - [Тепловая матрица (Heatmap)](#тепловая-матрица-heatmap) 15 | - [Пирамида зрелости (ex - *Кирилламида*)](#пирамида-зрелости) 16 | - [Как пользоваться фреймворком](#как-пользоваться-фреймворком) 17 | - [Материалы, используемые при создании](#материалы-используемые-при-создании) 18 | - [Связаться с нами](#связаться-с-нами) 19 | 20 | ## Введение 21 | 22 | Есть множество полезных фреймворков, позволяющих оценить процессы безопасной разработки, например, SAMM, BSIMM, DSOMM, MSDL. Также есть лучшие практики, бенчмарки, рекомендуемые подходы к защите контейнеров и сред контейнерной оркестрации, такие как NSA Kubernetes Hardening Guide, или, например CIS for Kubernetes. Помимо этого, существует множество инструментов, повышающих защищенность при формировании и совершенствовании процессов DevSecOps (SAST, DAST, SCA, Container security, Secret management и другие) со своими рекомендациями по настройкам и их использованию. Но нет чего-то одного, описывающего, что конкретно и в какой последовательности нужно делать, чтобы выстроить процесс безопасной разработки, а также чтобы объективно оценить существующий уровень зрелости безопасной разработки и понять, куда двигаться дальше. 23 | 24 | Эту проблему призван решить DevSecOps Assessment Framework (DAF). Он включает в себя не просто набор рекомендаций и лучших подходов из разных областей DevSecOps, но еще и большой экспертный опыт нашего сообщества, структурированный и адаптированный под современные реалии. Некоторые практики из общеизвестных фреймворков не добавлены в DAF, но при этом сформированы новые и более детальные. Все модели, домены, поддомены и практики описаны понятным языком во избежание двусмысленностей и разных толкований. 25 | 26 | ### Важный дисклеймер 27 | 28 | В открытый доступ выложены не все наши наработки по DAF. Но мы считаем, что основная часть фреймворка DAF все же должна быть публичным достоянием, а именно: 29 | 30 | - Карта DAF (ex - *Пиратская карта*); 31 | - Модели *Технологии* и *Процессы*, включенные в них домены, поддомены и практики, а также маппинг этих практик на другие широкоизвестные фреймворки (BSIMM, SAMM, DSOM и пр.); 32 | - Маппинг со стандартами и Тепловая матрица зрелости; 33 | - Пирамида зрелости (ex - *Кирилламида*). 34 | 35 | **Все это навсегда останется общедоступным.** 36 | 37 | Однако, есть и “закрытая” часть, которую мы реализуем в наших проектах по аудиту с использованием DAF. В ней есть: 38 | 39 | - Опросные листы для команд разработки для более удобного сбора информации от них “оффлайн”; 40 | - Супердетальные примеры того, “как проверить, что та или иная практика ДЕЙСТВИТЕЛЬНО выполняется”, а также примеры того, как необходимо реализовывать КАЖДУЮ практику; 41 | - RoadMap (дорожная карта развития) построения процессов DevSecOps на основе каждой практики и ее реализации из пункта выше; 42 | - Динамическая “иллюминация” - подсветка каждой ячейки Пирамиды зрелости (Кирилламиды), тепловой карты и Карты DAF (Пиратской карты), в зависимости от степени выполнения практик; 43 | - Детальный и кастомизируемый отчет по аудиту на основе DAF; 44 | - Автоматизированный расчет FTE специалистов DevSecOps \ AppSec для внедряемых инструментов DevSecOps с учетом количества команд разработки и планируемых задач; 45 | - и многое другое. 46 | 47 | ## Цели и задачи DAF 48 | 49 | При внедрении практик и процесса безопасной разработки ПО первый и самый главный вопрос, с которым сталкиваются компании — **«С чего начать?»**. Для того, чтобы ответить на этот вопрос, нужно преодолеть следующий путь: 50 | 51 | 1. Определить, где вы находитесь сейчас; 52 | 2. Определить, в какую сторону хотите развиваться; 53 | 3. Зафиксировать целевое состояние; 54 | 4. Определить инициативы, реализация которых поможет достичь целевого состояния; 55 | 5. Проанализировать всю собранную информацию для оценки необходимых ресурсов; 56 | 6. Сформировать дорожную карту реализации инициатив; 57 | 7. Реализовать инициативы. 58 | 59 | Основные задачи, которые ставились при создании DAF: 60 | 61 | - сформировать набор практик, который будет охватывать весь процесс безопасной разработки с детализацией; 62 | - сформировать набор практик, которые будут действительно актуальны; 63 | - сделать максимально простой процесс оценки зрелости; 64 | - сформировать подход к определению текущего уровня зрелости организации и практик, которые к этому уровню относятся; 65 | - сформировать понятную визуализацию для удобства восприятия результатов; 66 | - сформировать инкрементальный подход к уровням зрелости. 67 | 68 | ## Описание DAF 69 | 70 | DevSecOps Assessment Framework — это фреймворк оценки зрелости процесса безопасной разработки ПО. В данном случае под словом фреймворк мы понимаем набор инструментов, принципов, правил, руководств и процессов, которые помогают создавать безопасное ПО. 71 | 72 | **DAF состоит из трех компонентов:** 73 | 74 | - Карта DAF (ex - *Пиратская карта*); 75 | - Маппинг со стандартами и Тепловая матрица; 76 | - Пирамида зрелости (ex - *Кирилламида*). 77 | 78 | ### Карта DAF 79 | 80 | > (ex - *Пиратская карта*) 81 | 82 | *Карта DAF* — это верхнеуровневый взгляд на весь фреймворк. Она включает в себя все аспекты процесса безопасной разработки с этапа планирования до перевода ПО в промышленную эксплуатацию. Карта делится на два блока: модель *Технологии* и *Процессы*. 83 | 84 | #### Модель *Технологии* 85 | 86 | ![new_model_technology](./images/Model_Technology.png) 87 | 88 | #### Модель *Процессы* 89 | 90 | ![new_model_processes](./images/Model_Processes.png) 91 | 92 | ### Маппинг со стандартами и Тепловая матрица 93 | 94 | #### Маппинг со стандартами 95 | 96 | Маппинг со стандартами содержит различные практики, а также критерии оценки (”Верно” и “Неверно” для нулевого этапа, а также “Выполняется”, “Частично выполняется” и “Не выполняется” для практик 1го и последующих этапов зрелости). В маппинге практики сгруппированы в поддомены, а поддомены - в домены. Для соответствия конкретному этапу зрелости может потребоваться выполнение одной или нескольких практик. 97 | 98 | [Маппинг со стандартами в формате markdown (v4.6.4)](DAF.md) 99 | 100 | #### Тепловая матрица (Heatmap) 101 | 102 | ![new_Heatmap](./images/Heatmap.png) 103 | 104 | Тепловая матрица показывает степень выполнения практик в рамках определенного поддомена в соответствии с четырьмя этапами зрелости каждой практики (в процентах). Например, если для соответствия ТРЕТЬЕМУ этапу “Идентификация секретов” требуется соблюдение 4х условий, но на момент аудита выполняется только 2 условия, то в матрице отобразится значение “50%” соответствия третьему этапу. 105 | 106 | Основная цель тепловой матрицы — **визуализация полученных данных.** 107 | 108 | В Таблице оценки и Тепловой матрице существуют следующие этапы зрелости (по аналогии с большинством других общеизвестных фреймворков): 109 | 110 | - **Этап 0: Uninitiated** 111 | 112 | > На этом этапе компания не имеет никаких формализованных процессов или инструментов безопасной разработки. Практики могут использоваться случайным образом по инициативе отдельных работников. 113 | 114 | - **Этап 1: Beginners** 115 | 116 | > На этом этапе зрелости практик в компании начинают появляются инструменты, используемые при безопасной разработке с минимальной зоной покрытия и без автоматизации. Появляются базовые процессы. 117 | 118 | - **Этап 2: Intermediate** 119 | 120 | > Процессы на этом этапе становятся повторяемыми и управляемыми, происходит расширение зоны покрытия используемых инструментов, внедрение автоматизации. Компания начинает применять методики для планирования, выполнения и отслеживания активностей. Однако эти методики могут быть не всегда последовательными или не полностью документированными. Инструменты по прежнему не покрывают весь процесс безопасной разработки. 121 | 122 | - **Этап 3: Advanced** 123 | 124 | > На данном этапе фактически инструменты безопасной разработки обеспечивают максимальное покрытие и автоматизацию. Все процессы являются последовательными и полностью документированными 125 | 126 | - **Этап 4: Experts** 127 | 128 | > Когда все процессы и инструменты развиты максимально, нет предела совершенству. Можно по прежнему что-то улучшить и повысить зрелость. 129 | 130 | ### Пирамида зрелости 131 | 132 | > (ex - *Кирилламида*) 133 | 134 | Понятие родилось из слияния слова *Пирамида* и имени ее основателя — ***Кирилла Бочкарева***. Только теперь она перестала быть пирамидой в угоду удобства навигации, но понятие надежно закрепилось за этой частью DAF. 135 | 136 | Пирамида зрелости нужна для отображения последовательности внедрения практик безопасной разработки с максимальной детализацией всех активностей. 137 | 138 | ![Пирамида зрелости](./images/The_Pyramid_of_Maturity.jpg) 139 | 140 | **Зачем она нужна:** 141 | 142 | - **Понять текущее положение дел в рамках всего процесса безопасной разработки**: Компания может определить на каком уровне зрелости находится в данный момент. 143 | - **Планировать**: Пирамида зрелости позволяет планировать следующие шаги в развитии процессов безопасной разработки. 144 | - **Мотивировать**: Отслеживая прогресс в Пирамиде зрелости, команды разработки могут видеть свое развитие, что может служить мотивацией для дальнейших улучшений. 145 | - **Стандартизировать**: Пирамида зрелости может служить основой для внутренних стандартов и правил, устанавливаемых компанией, для повышения качества процессов безопасной разработки. 146 | 147 | **Выбор целевого уровня** Пирамиды зрелости происходит по следующему алгоритму: 148 | 149 | 1. По умолчанию целевой уровень – «Базовый», включающий в себя внедрение базовых инструментов и процессов, а также их необходимую на начальном этапе область действия. 150 | 2. В случае если практики безопасной разработки ПО на **каждом** из уровней 0-2 выполняются на 80-100%, то необходимо выбрать целевой уровень «Повышенный» или «Продвинутый». 151 | 3. В случае если практики безопасной разработки ПО на каждом из уровней 0-2 выполняются на 80-100%, а практики уровней 3-5 выполняются менее чем на 80% на **любом** из уровней, целевым стоит выбрать уровень «Развитый». 152 | 4. В случае если практики безопасной разработки ПО на **каждом** из уровней 0-5 выполняются не менее чем на 80%, целевым уровнем может являться «Экспертный» или «Космический». 153 | 154 | > Практики, расположенные на более низких уровнях Пирамиды зрелости, имеют более высокий приоритет реализации по сравнению с практиками, расположенными на более высоких уровнях. 155 | 156 | ## Как пользоваться фреймворком 157 | 158 | Краткий гайд: 159 | 160 | 1. Самый правильный путь — открыть вкладку “Маппинг со стандартами”, в которой собраны все домены, поддомены и практики и заполнять последовательно все практики сверху вниз. Можно сгруппировать все строки по поддоменам (группа строк “2” в левом верхем углу листа excel) и, если какой-то поддомен вообще не реализуется у вас в компании, то можно просто пропустить его и не заполнять (оставить “Неверно” в нулевом уровне и по всем практикам этого поддомена оставить “Не выполняется”) 161 | 2. Для “распараллеливания” процесса заполнения всех практик их можно отдавать отдельно целыми поддоменами в соответствующие структурные подразделения вашей компании для выставления ответов. 162 | 3. После заполнения всех практик на листе “Маппинг со стандартами” можно оценить на этом же листе в каком процентном соотношении закрывается тот или иной поддомен у вас в компании. На вкладке “Heatmap” (Тепловая матрица) будет также видно это процентное соотношение, но еще и с “динамической иллюминацией” (автоматизированным раскрашиванием ячеек поддоменов в зависимости от указанных вами ответов на листе “Маппинг со стандартами”) 163 | 4. Листы “Кирилламида” (Пирамида зрелости) и “Карта DAF” в публичной версии не имеют “динамической иллюминации”, но 164 | 1. Карта DAF позволяет верхнеуровнево представить наполнение моделей доменами, а доменов поддоменами с практиками. Такая визуализация неплохо подходит для отчета по проведенному аудиту 165 | 2. Пирамида зрелости позволит оценить насколько зрелыми являются процессы безопасной разработки у вас в компании. Для более наглядной визуализации можно, например, раскрасить самостоятельно ячейки с группами практик (например, T-CODE-IMG-1, T-PREPROD-DAST-2 и все остальные в соответствующие цвета в зависимости от процента выполнения каждой из этих групп практик на вкладке “Heatmap”) и\или посчитать средний процент выполнения каждой группы практик на всех уровнях зрелости Кирилламиды. А затем определить текущий уровень зрелости и определить целевой уровень согласно методики из описания DAF. 166 | 5. Раскрашенная Пирамида зрелости также неплохо подойдет для отчета об аудите процессов безопасной разработки. 167 | 168 | Если у вас есть свои мысли или идеи что нужно поправить, как лучше пользоваться фреймворком - обязательно пишите нам, мы постараемся всё учесть! 169 | 170 | ## Материалы, используемые при создании 171 | 172 | Для создания фреймворка были проанализированы и использованы следующие материалы: 173 | 174 | - Международные лучшие практики: 175 | - [Building Security In Maturity Model (BSIMM)](https://www.synopsys.com/software-integrity/software-security-services/bsimm-maturity-model.html); 176 | - [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/); 177 | - [DevSecOps Maturity Model (DSOMM)](https://dsomm.owasp.org/); 178 | - [Microsoft Security Development Lifecycle (SDL)](https://www.microsoft.com/en-us/securityengineering/sdl); 179 | - [ГОСТ Р 58412-2019. РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. Угрозы безопасности информации при разработке программного обеспечения](https://docs.cntd.ru/document/1200164529); 180 | - [A Model For Measuring Improvement Of Security In Continuous Integration pipelines](http://essay.utwente.nl/88916/1/Akujobi_EEMCS_faculty%20%28002%29.pdf); 181 | - [Open Source Software (OSS) Secure Supply Chain (SSC) Framework Simplified Requirements](https://github.com/microsoft/oss-ssc-framework/blob/main/specification/framework.md). 182 | - Практики от Center for Internet Security (CIS): 183 | - [CIS Software Supply Chain Security Guide](https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide); 184 | - [CIS GitHub Benchmark](https://www.cisecurity.org/insights/blog/cis-benchmarks-february-2023-update). 185 | - Best practices: 186 | - Aqua Cloud Native Security Maturity Model; 187 | - [Secrets Management Maturity Model](https://blog.gitguardian.com/a-maturity-model-for-secrets-management/). 188 | - Наш опыт, а также опыт наших заказчиков. 189 | 190 | ## Связаться с нами 191 | 192 | И еще небольшая просьба: если вы используете наш фреймворк в коммерческих целях, в разработке локальных или государственных нормативных актов, в маркетинговых или иных публичных целях, если рассказываете об этом фреймворке в статьях или на конференциях — сообщайте, пожалуйста, нам (например, в чат или просто в почту). 193 | 194 | - [Telegram: DevSecOps_Assessment_Framework](https://t.me/DevSecOps_Assessment_Framework) 195 | - [Mail: daf@jet.su](mailto:daf@jet.su) 196 | 197 | Эта информация нам крайне пригодится для понимания охвата и полезности нашего фреймворка. 198 | -------------------------------------------------------------------------------- /images/Heatmap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Jet-Security-Team/DevSecOps-Assessment-Framework/5d8df394527929a5a6ea8e20cb12184c98fee668/images/Heatmap.png -------------------------------------------------------------------------------- /images/Model_Processes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Jet-Security-Team/DevSecOps-Assessment-Framework/5d8df394527929a5a6ea8e20cb12184c98fee668/images/Model_Processes.png -------------------------------------------------------------------------------- /images/Model_Technology.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Jet-Security-Team/DevSecOps-Assessment-Framework/5d8df394527929a5a6ea8e20cb12184c98fee668/images/Model_Technology.png -------------------------------------------------------------------------------- /images/The_Pyramid_of_Maturity.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Jet-Security-Team/DevSecOps-Assessment-Framework/5d8df394527929a5a6ea8e20cb12184c98fee668/images/The_Pyramid_of_Maturity.jpg --------------------------------------------------------------------------------