Поддерживает веб-приложения, API, сетевые сервисы и облачные инфраструктуры. Вот тут можешь посмотреть официальный репозиторий и детали по используемым флагам вот тут. Поддерживает параллельную обработку для массового сканирования. Работает в связке с subfinder, httpx, naabu. Не имеет собственных настроек политик. Управление политиками Quality Gate осуществляется на уровне конвейера при его вызове. Лицензия MIT.

- Шаблоны с протоколами code/javascript требуют цифровой подписи и явного указания флага -code для запуска
- Следует использовать режим -disable-unsigned-templates, который разрешает выполнение только подписанных шаблонов и запускайте только в изолированной среде
- Запуск не проверенных шаблонов от третьих лиц опасен из-за риска внедрения вредоносного кода.
- Перед запуском анализируйте id, info, payloads и fuzzing на предмет подозрительных операций
- Используйте флаги ограничения скорости -rl и количества параллельных запросов -c 

nuclei -u https://example.ru # Сканирование одиночной цели
nuclei -l targets.txt # Сканирование списка целей
nuclei -u https://example.ru -t cves/2021/CVE-2021-12345.yaml # Запуск конкретного шаблона
nuclei -u https://example.ru -tags jira -s critical,high # Фильтрация по тегам и серьезности
nuclei -u https://example.ru -as # Автоматическое определение технологий
subfinder -d example.ru | httpx | nuclei # Интеграция с инструментами разведки
nuclei -l openapi.json -im openapi # Сканирование OpenAPI
nuclei -t template_with_code.yaml -code -c 50 -rl 100 # Безопасный запуск шаблонов с кодом
docker run projectdiscovery/nuclei:latest -u https://example.ru # Запуск сканирования c docker

security_scan:
  stage: test
  image: golang:latest
  before_script:
    - go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest
  script:
    - nuclei -u $URL -t /templates -json -o nuclei-report.json
  artifacts:
    paths:
      - nuclei-report.json

stages {
        stage('Security Scan') {
            steps {
                sh '''
                    # Установка Nuclei
                    go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
                     
                    # Запуск сканирования
                    $HOME/go/bin/nuclei -u $URL -t $NUCLEI_TEMPLATES -json -o nuclei-report.json
                '''
            }
        }
    }
     
    post {
        always {
            archiveArtifacts artifacts: 'nuclei-report.json', fingerprint: true
        }
    }
}

Итого: инструмент является полезным для использования, но требует дополнительной подготовки, что позволит тебе натыкаться на прорблемные зоны, где ты увидишь именно свой потенциал для роста. Отметим, что:

- Следует использовать environment с указанием тестируемого URL = 'https://example.com' и используемым NUCLEI_TEMPLATES = '/templates'
- Имеет огромную базу актуальных шаблонов и низкий уровень ложных срабатываний
- Поддерживает множества протоколов (HTTP, TCP, DNS, SSL)
- Имеет риски выполнения вредоносных шаблонов из-за отсутствия опыта
- Имеет последующий потенциальный DoS-эффект на продакшн-системы
- Необходима экспертиза для написания собственных шаблонов
- Тестирует кроме web, также API, облачную инфраструктуру (AWS S3, Azure, etc.), сетевые устройства, включая сторонних поставщиков

Continuous Integration/ Continuous Delivery — это автоматизация процессов разработки, которая включает непрерывную интеграцию и непрерывную доставку. Автоматизация нацелена на SDLC цикл.

- Изоляция контроллера: сборки не на встроенном узле, а инициализируются из глобальных переменных
- Не допускается наличие не используемых переменных среды
- Не запускать сборку от ТУЗ с привилегированными правами
- Средства сборки и деплоя не должны требовать расширение прав доступа
- Обеспечивать строгий рендеринг пользовательского контента: файлы из рабочих директорий, архивные артефакты и т.д.
- В процессе CI\CD должна быть исключена возможность переполнений и несанкционированной перезаписи.
- Не допускается вызов внешних зависимостей на этапе деплоя

- Каждый Stage изолируется и разделяет операции функционально
- Учётные записи, используемые или вызываемые при сборке или деплое, должны проходить предварительную аутентификацию:
- аутентификация должна быть персональной и обеспечивать возможность отслеживать действия;
- аутентификация должна быть обеспечена для пользователей всех уровней доступа (администраторы, супервизоры)

- Все jobs необходимо разделять по назначению: CI (сборка, тестирование, анализ кода и т.д. - обособленно и не взаимодействует со средами эксплуатации, а CD использует отдельные УЗ
- Библиотеки, сборки и шаблоны конвейеров следует хранить отдельно от управляющего конфига
- Рекомендуется использовать отдельные репозитории для сборок и шаблонов для изоляции конфигураций
- Подключаемые скрипты: Groovy, Shell, Python и др. не должны содержать проверок или условий, позволяющих обходить этапы сборки, тестирования или других критических стадий конвейера
- Для обеспечения целостности и отслеживания изменений необходимо автоматически собирать хэш-сумму профиля конвейера или конфигурации при каждой сборке
- На этапе CD требуется проверка хэш-суммы профайла

- Ниже maintainer нет возможности самостоятельно выбирать окружение и быть ограничены
- Деплой не должен выполняться без MR
- Все pre-действия должны включать полные метаданные артефакта — параметры сборки, атрибуты поставки и идентификаторы версий
- Все callback-действия внутри конвейера,
- Build и тд. должны выполняться только для приложений, упакованных в Docker-контейнеры для единообразия сред
- В CI рекомендуется запускать несколько типов тестов: интеграционные, unit-тесты, регрессионные тесты
- При неуспешной сборке артефакт не должен попадать в репозиторий артефактов
- Среды деплоя: staging, production и тд. должны быть логически и физически разделены
- Все post-действия в конвейере не должны вызываться независимо и обязаны выполняться только после завершения соответствующих pre- или main-этапов

Используется при описании текущего сводного статуса проекта и features. Это общий документ/ справочник, который по сути одинаково понятен разработчикам, аналитикам, саппорту, менеджерам и ИБ.

Плохой пример: «Добавить кнопку «Верификация» в авторизованную часть 2FA, класть данные логов, кто заходил, потому что нужно потом строить из них графики»

Хороший пример: «Обеспечить безопасность пользовательских учетных записей и противодействовать нелигитимному доступу внутри инфраструктуры в случае компрометации учетной записи. С помощью интеграции у клиента, а также нас, появится возможность осуществлять контроль и гарантировать безопасное легитимное подключение» (чувствуете как это сложна и не понятно)

Плохой пример: «Потому что требует решгулятор эту фичу для соответствия требованиям»

Хороший пример: «Потому что это может дать нам возможность быстрого прохождения верификации и контроля пользователей, обезопасить user story и быть уверенными в защищенности данных (ссылка на результаты эксперимента/ расчет/ кейс)»

Win Condition отвечает на один простой вопрос — как мы поймем, что у нас получилось. Это может быть любая количественная или качественная метрика, событие оценки. Главные критерии качества для Win Condition — измеримость, однозначная трактуемость и простота (принцип Invest).

Fail Condition отдельно можно не прописывать. По умолчанию предполагаем, что при не достижении Win Condition мы автоматически попали в состояние Fail.

User Story: описываем что и для чего получит пользователь, ИБ, команда разработки и тд, с примерами и комментариями.

Хардкорные ФТ: описываем всю бизнес логику пошагово (применимо при проработке сложных кейсов.

- PRD хватает для того, чтобы техническая команда вместе могла провести первичную декомпозицию.
- Логика использования PRD в ИБ - встраивание Shift Left процесса в разработку и фиксация требований ИБ, а также контроль, сбор evidence.
- Именно он (или ссылка на него) составляет описание user story, которая потом декомпозируется на tasks (задачи)
- После окончания работ/ описания требований или иных дополнений над задачами - PRD становится документацией о том, как это работало и почему/ зачем было реализовано.
- PRD пишется для больших и сложных вещей, где есть много зависимостей и очень важно сохранить для истории как это работало.

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

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

Приводился довод ИФНС об отсутствии у ОАО оснований для предъявления к вычету НДС по счету-фактуре, подписанному штампом-факсимилом — воспроизводящим личную подпись руководителя организации-поставщика.

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

В передаче дела по заявлению о признании незаконными актами налогового органа по начислению налогов, начислению пеней, привлечении к налоговой ответственности по п. 1 ст. 122 НК РФ для пересмотра надзора судебных актов - было отказано, поскольку представленные доказательства подтверждают наличие хозяйственных операций между заявителями и ООО по факту наличия факсимильной подписи.

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

$ git init # Инициализация пустого локального репозитория
$ git remote add origin URL_link # Связывание удалённого репозитория с именем "origin" по ссылке "URL_link" с локальным

$ git pull origin name_branch # Ветка из которой мы берем изменения для тестирования
$ git remote show # Показать подключенные удалённые репозитории
$ git status  # Показывает состояние локального репозитория (отслеживаемые, изменённые, новые файлы и пр.)

$ git add . # Добавить в индекс все новые, изменённые, удалённые файлы из текущей директории и её поддиректорий
$ git commit -S -m"added sources" # Зафиксировать в коммите проиндексированные изменения (закоммитить), добавить сообщение

$ git push origin name_branch # Отправляем изменения из локального репозитория в удалённый в ветку "name_branch"
$ git show HEAD # Информация о последнем комите (git log -1)
$ git push --set-upstream origin new-name # Установка upstream (связывает локальную ветку с удаленной)
$ git push origin :old-name # Удаление старой ветки в удаленном репо
$ git push origin new-name # Публикация новой ветки

$ git log --oneline --graph --decorate --all
$ tree -I "katalog|katalog" # Вывод с исключением каталогов для дерева проекта

$ git init # Инициализация пустого локального репозитория
$ git remote add origin URL_link # Связывание удалённого репозитория с именем "origin" по ссылке "URL_link" с локальным

$ git pull origin name_branch # Ветка из которой мы берем изменения для тестирования
$ git remote show # Показать подключенные удалённые репозитории
$ git status  # Показывает состояние локального репозитория (отслеживаемые, изменённые, новые файлы и пр.)

$ git add . # Добавить в индекс все новые, изменённые, удалённые файлы из текущей директории и её поддиректорий
$ git commit -S -m"added sources" # Зафиксировать в коммите проиндексированные изменения (закоммитить), добавить сообщение

$ git push origin name_branch # Отправляем изменения из локального репозитория в удалённый в ветку "name_branch"
$ git show HEAD # Информация о последнем комите (git log -1)
$ git push --set-upstream origin new-name # Установка upstream (связывает локальную ветку с удаленной)
$ git push origin :old-name # Удаление старой ветки в удаленном репо
$ git push origin new-name # Публикация новой ветки

$ git log --oneline --graph --decorate --all
$ tree -I "katalog|katalog" # Вывод с исключением каталогов для дерева проекта

$ git remote set-url origin ssh://git@github.com_gitlab.com/username/newRepoName.git # Замена URL
$ git remote -v # Проверка правильности указанного link
$ git remote set-head origin -a
$ git pull --rebase origin name_branch # Переинициализация

$ git reset HEAD file # Убирает файл из индекса
$ git reset HEAD~ # Отмена последнего commit
$ git reset --hard HEAD~ # Удаление commit с изменениями

$ git push origin --delete name_branch / git branch -rD origin/name_branch
$ git branch -d name_branch # Удаление локального репо
$ git checkout -- file # Отменяет изменение

$ git clean -fdn # Удаляет неотслеживаемые файлы и каталоги с предварительным просмотром

# Установка новой master/main ветки
$ git fetch origin
$ git fetch origin # Жесткая перезапись репозитория

$ git branch -u origin/gpages gpages
$ git branch -m master gpages

- Модератор: Дудник Степан Технический директор, ВHDTech, лидер сообщества FinDevSecOps АФТ
- Герасимов Фёдор Эксперт отдела безопасной разработки, ИТ-холдинг Т1, руководитель сообщества FinDevSecOps АФТ
- Макрушин Денис Директор по продуктам безопасной разработки, Яндекс, лидер сообщества FinDevSecOps АФТ
- Когос Константин Директор Института интеллектуальных кибернетических систем, НИЯУ МИФИ
- Погорелко Егор Руководитель направления исследования и разработки РУНЦ «Безопасности», МГТУ им. Н.Э. Баумана