4. Безопасная разработка и цепочка поставки4. Secure development and the supply chain
От governance SSDF и security-by-design до кода, SCA, SAST, тестов и доказательств выпуска.From SSDF governance and security by design through to code, SCA, SAST, testing and release evidence.
Лицензионный аудит компонентовSoftware component licence audit
- АудиторияAudience
- Разработчики, специалисты SCA и участники лицензионного согласования.Developers, SCA specialists and licence reviewers.
- ПредпосылкиPrerequisites
- Понимание зависимостей и различия между компонентом и его лицензией.Understanding dependencies and the difference between a component and its licence.
- Измеримый результатMeasurable outcome
- Проследить источник лицензионных данных и отделить нормализацию SPDX от юридического решения.Trace licence data sources and distinguish SPDX normalisation from a legal decision.
- АртефактArtefact
- Карточка компонента: источник, лицензия, неопределённости и маршрут согласования.A component record covering its source, licence, uncertainties and review route.
- Критерий / рубрикаAssessment criteria
- Сохранены исходные данные и неизвестные значения; автоматический результат не подменяет правовую оценку.Original data and unknown values are retained; automated results do not replace legal review.
- Маршрут и времяRoute and time
- 45–60 минут: источники лицензий, нормализация, разбор карточки и фиксация решения.45–60 minutes: licence sources, normalisation, a component record and a documented decision.
Открыть материал ↗Open material ↗
Сервис SBOM-аудита: устройство и результатыSBOM audit service: architecture and results
- АудиторияAudience
- Архитекторы, разработчики и руководители проектов.Architects, developers and project leads.
- ПредпосылкиPrerequisites
- Базовые знания веб-сервисов и жизненного цикла разработки.Basic knowledge of web services and the development lifecycle.
- Измеримый результатMeasurable outcome
- Выделить границы сервиса, роли пользователей и способы проверки результатов разработки.Identify service boundaries, user roles and ways to verify development outcomes.
- АртефактArtefact
- Краткий разбор архитектуры с перечнем проверяемых утверждений.A short architecture review listing verifiable claims.
- Критерий / рубрикаAssessment criteria
- Для каждого утверждения указано нужное доказательство; состояние исторического проекта не выдано за текущий production.Each claim states the evidence it needs; a historical project state is not presented as current production.
- Маршрут и времяRoute and time
- 45–60 минут: устройство проекта, результаты, самостоятельный разбор доказательств.45–60 minutes: project architecture, results and an independent evidence review.
Открыть материал ↗Open material ↗
Сервис «РБПО-аудит»: композиционный анализRBPO Audit: software composition analysis
- АудиторияAudience
- Разработчики и специалисты по безопасной разработке.Developers and secure development specialists.
- ПредпосылкиPrerequisites
- Представление о зависимостях, SBOM и составе программного продукта.Understanding of dependencies, SBOMs and software product composition.
- Измеримый результатMeasurable outcome
- Объяснить путь компонента от инвентаризации до решения о его использовании.Explain the path from component inventory to an acceptance decision.
- АртефактArtefact
- Схема потока SBOM с точками проверки и ответственными ролями.An SBOM flow diagram with verification points and responsible roles.
- Критерий / рубрикаAssessment criteria
- Различены исходные сведения, результаты анализа и решение человека; обозначены ограничения кейса.Source data, analysis results and human decisions are distinguished, with the case limitations stated.
- Маршрут и времяRoute and time
- 45–60 минут: исторический обзор проекта, схема потока, обсуждение границ автоматизации.45–60 minutes: historical project overview, flow diagram and discussion of automation limits.
Открыть материал ↗Open material ↗
Безопасная разработка: история, стандарты и процессыSecure development: history, standards and processes
- АудиторияAudience
- Разработчики, преподаватели и руководители команд.Developers, lecturers and team leads.
- ПредпосылкиPrerequisites
- Базовое представление о жизненном цикле программного обеспечения.Basic understanding of the software development lifecycle.
- Измеримый результатMeasurable outcome
- Сопоставить три меры безопасной разработки с процессами и ожидаемыми свидетельствами.Map three secure development measures to processes and expected evidence.
- АртефактArtefact
- Таблица «процесс — действие — свидетельство» на основе лекции.A process–action–evidence table based on the lecture.
- Критерий / рубрикаAssessment criteria
- Для каждой меры указан процесс, результат и способ проверки; редакции стандартов различены.Each measure names a process, outcome and verification method; standard editions are distinguished.
- Маршрут и времяRoute and time
- 60–90 минут: обзор истории и процессов, затем самостоятельная таблица; EP01 доступен на английском.60–90 minutes: review the history and processes, then prepare a table; EP01 is available in English.
Открыть материал ↗Open material ↗
Не ищите шаблон: постройте безопасную разработкуStop looking for a template: build secure development
Главная авторская лекция: люди, инструменты и процессы сначала; честные документы — следом.The flagship lecture: people, tools and processes first; honest documents after.
- АудиторияAudience
- Руководители разработки, архитекторы, DevSecOps, AppSec и команды соответствия.Development managers, architects, DevSecOps, AppSec and compliance teams.
- ПредпосылкиPrerequisites
- Реальный программный продукт или процесс, который предстоит построить либо изменить.A real software product or process that is about to be built or changed.
- Измеримый результатMeasurable outcome
- Отделить бумажную имитацию от работающего контура и найти разрывы в триаде и evidence.Distinguish paper compliance from a working loop and find the gaps in the triad and in the evidence.
- АртефактArtefact
- Карта people → tools → process → gate → evidence → document для одного значимого риска.A people → tools → process → gate → evidence → document map for one significant risk.
- Критерий / рубрикаAssessment criteria
- У каждого действия есть владелец, средство, правило, проверяемый выход и связь с решением о выпуске.Every action has an owner, a tool, a rule, a verifiable output and a link to the release decision.
- Маршрут и времяRoute and time
- 45–60 минут; входная лекция перед ГОСТ Р 56939, SSDF и прикладными практиками AppSec.45–60 minutes; the entry lecture before GOST R 56939, SSDF and applied AppSec practice.
Открыть главную лекциюOpen the flagship lecture
Подготовка процессов РБПО к сертификацииPreparing for certification of secure development processes (FSTEC orders No. 240 and No. 230)
Процесс существует только там, где остаётся воспроизводимое evidence.A process exists only where it leaves reproducible evidence.
- АудиторияAudience
- Руководители разработки, AppSec и команды соответствия.Development managers, AppSec and compliance teams.
- ПредпосылкиPrerequisites
- Карта текущего SDLC, роли, репозитории и pipeline.A map of the current SDLC, the roles, the repositories and the pipeline.
- Измеримый результатMeasurable outcome
- Сопоставить один процесс РБПО с практикой SSDF и найти три разрыва evidence.Map one secure software development process onto an SSDF practice and find three evidence gaps.
- АртефактArtefact
- Матрица process → owner → gate → evidence → retention → gap.A process → owner → gate → evidence → retention → gap matrix.
- Критерий / рубрикаAssessment criteria
- Оценивается выполненная задача, а не наличие документа; выборки и владельцы определены.The assessment looks at the task actually performed, not at the existence of a document; samples and owners are defined.
- Маршрут и времяRoute and time
- 6–8 академических часов; после общего РБПО, перед внутренним аудитом.6–8 academic hours; after the general secure software development course, before the internal audit.
Открыть курсOpen the course
Разработка безопасного программного обеспеченияSecure software development: the fundamentals
Единая нить от требований к эксплуатации.A single thread from requirements to operation.
- АудиторияAudience
- Разработчики, архитекторы, QA, DevSecOps и product security.Developers, architects, QA, DevSecOps and product security.
- ПредпосылкиPrerequisites
- Базовый SDLC, Git и понимание дефекта и риска.A basic SDLC, Git and an understanding of defects and risk.
- Измеримый результатMeasurable outcome
- Разместить пять security-задач по этапам SDLC и назначить проверяемые gates.Place five security tasks across the SDLC stages and assign verifiable gates.
- АртефактArtefact
- Security overlay процесса с ролями, входами, выходами и критериями.A security overlay of the process with roles, inputs, outputs and criteria.
- Критерий / рубрикаAssessment criteria
- Каждый gate блокирует конкретный риск, имеет owner, evidence и процедуру исключения.Every gate blocks a specific risk and has an owner, evidence and an exception procedure.
- Маршрут и времяRoute and time
- 6–8 академических часов; затем ТЗ, архитектура, SCA, SAST и тестирование.6–8 academic hours; then requirements specifications, architecture, SCA, SAST and testing.
Открыть курсOpen the course
Композиционный анализ программного обеспеченияSoftware composition analysis (SCA)
Компонент, происхождение, лицензия и уязвимость в одном решении.Component, provenance, licence and vulnerability in a single decision.
- АудиторияAudience
- Разработчики, DevSecOps, AppSec и license compliance.Developers, DevSecOps, AppSec and licence compliance.
- ПредпосылкиPrerequisites
- Сборочная система, dependency manifests и базовые понятия SBOM.A build system, dependency manifests and the basics of SBOM.
- Измеримый результатMeasurable outcome
- Проследить пять компонентов до версии, источника, лицензии и vulnerability status.Trace five components to their version, source, licence and vulnerability status.
- АртефактArtefact
- SBOM/ППК-фрагмент и решение allow, remediate, replace или reject.An SBOM or FSTEC software component list extract and an allow, remediate, replace or reject decision.
- Критерий / рубрикаAssessment criteria
- Прямые и транзитивные зависимости видимы, provenance подтверждён, исключение ограничено сроком.Direct and transitive dependencies are visible, provenance is confirmed, and any exception is time-limited.
- Маршрут и времяRoute and time
- 4–6 академических часов; затем SPDX, ППК и supply-chain gate.4–6 academic hours; then SPDX, the FSTEC software component list and the supply-chain gate.
Открыть курсOpen the course
Статический анализ безопасности приложенийStatic application security testing (SAST)
Finding становится полезным после triage, исправления и retest.A finding becomes useful only after triage, a fix and a retest.
- АудиторияAudience
- Разработчики C/C++, security champions и AppSec-инженеры.C/C++ developers, security champions and AppSec engineers.
- ПредпосылкиPrerequisites
- Сборка проекта, unit tests и основы CWE.A buildable project, unit tests and the basics of CWE.
- Измеримый результатMeasurable outcome
- Классифицировать пять срабатываний, исправить одно истинное и доказать retest.Classify five warnings, fix one true positive and demonstrate the retest.
- АртефактArtefact
- Карточка finding с CWE, потоком данных, patch, negative test и результатом повторного анализа.A finding card with the CWE, the data flow, the patch, a negative test and the result of the repeat analysis.
- Критерий / рубрикаAssessment criteria
- Причина устранена, warning не просто подавлен; для C/C++ проверены sanitizers, -fstack-protector-strong и _FORTIFY_SOURCE.The cause is removed rather than the warning merely suppressed; for C/C++, sanitizers, -fstack-protector-strong and _FORTIFY_SOURCE are checked.
- Маршрут и времяRoute and time
- 6–8 академических часов; после secure coding, перед CI quality gate.6–8 academic hours; after secure coding, before the CI quality gate.
Открыть курсOpen the course
Динамический анализ ПО: проект стандарта и практикаDynamic software analysis: draft standard and practice
Разбор проекта, инструменты, фаззинг и доказательства исправления.Draft standard, tools, fuzzing and evidence of remediation.
- АудиторияAudience
- Студенты, разработчики C/C++ и специалисты по безопасной разработке.Students, C/C++ developers and secure development engineers.
- ПредпосылкиPrerequisites
- Основы C++, сборка программ, терминал Linux и локальный учебный стенд.Basic C++, compilation, a Linux terminal and a local learning environment.
- Измеримый результатMeasurable outcome
- Найти и воспроизвести сбой фаззером, объяснить причину и проверить исправление.Find and reproduce a crash, explain its root cause and verify the fix.
- АртефактArtefact
- Вход, вызывающий сбой, отчёт ASan, исправленный код и журнал повторной проверки.A crashing input, an ASan report, corrected code and retest evidence.
- Критерий / рубрикаAssessment criteria
- Сбой воспроизводится до исправления; после исправления старый вход и корпус проверены.The crash is reproduced before the fix; the old input and corpus are retested after it.
- Маршрут и времяRoute and time
- Самостоятельный темп: теория, подготовка стенда, AFL++, libFuzzer и отчёт.Self-paced: theory, environment setup, AFL++, libFuzzer and a report.
Открыть материалыOpen the materials
Нефункциональное тестирование безопасности ПОNon-functional software security testing (process No. 19)
Надёжность, robustness и attack surface через наблюдаемые свойства.Reliability, robustness and attack surface as observable properties.
- АудиторияAudience
- QA, разработчики системного ПО и инженеры безопасности.QA, systems software developers and security engineers.
- ПредпосылкиPrerequisites
- Требования, тестовый стенд и умение автоматизировать проверки.Requirements, a test lab and the ability to automate checks.
- Измеримый результатMeasurable outcome
- Составить и выполнить три negative test для отказоустойчивости или некорректного ввода.Write and run three negative tests for fault tolerance or malformed input.
- АртефактArtefact
- Тест-план с oracle, лимитами, логами и минимальным воспроизводимым failure.A test plan with the oracle, resource limits, logs and a minimal reproducible failure.
- Критерий / рубрикаAssessment criteria
- Есть ожидаемое безопасное поведение, ресурсы ограничены, результат повторяется после исправления.Expected safe behaviour is defined, resources are capped, and the result is reproducible after the fix.
- Маршрут и времяRoute and time
- 4–6 академических часов; после требований и до release decision.4–6 academic hours; after requirements and before the release decision.
Открыть курсOpen the course
Архитектурный анализ и ППКArchitecture analysis. Building and submitting the FSTEC software component list (processes 6, 7, 16, 17)
Доверие к компонентам начинается с границ и provenance.Trust in components starts with boundaries and provenance.
- АудиторияAudience
- Архитекторы, product security, SCA и руководители разработки.Architects, product security, SCA specialists and development managers.
- ПредпосылкиPrerequisites
- Контекстная диаграмма, сборочная спецификация и владельцы компонентов.A context diagram, the build specification and the component owners.
- Измеримый результатMeasurable outcome
- Выделить trust boundaries и принять обоснованное решение по пяти компонентам.Identify the trust boundaries and take a reasoned decision on five components.
- АртефактArtefact
- Архитектурная схема, ППК/SBOM-фрагмент и журнал решений по компонентам.An architecture diagram, an extract of the FSTEC software component list or SBOM, and a component decision log.
- Критерий / рубрикаAssessment criteria
- Версия, источник и назначение однозначны; риск, лицензия и замена рассмотрены отдельно.Version, source and purpose are unambiguous; risk, licence and replacement are considered separately.
- Маршрут и времяRoute and time
- 6–8 академических часов; после проектирования, совместно с SCA и threat modeling.6–8 academic hours; after design, alongside SCA and threat modeling.
Открыть курсOpen the course
Лицензии SPDX на русскомSPDX licences in Russian, with suitability verdicts
Справочник для точной идентификации, а не автоматический юридический вывод.A reference for precise identification, not an automatic legal conclusion.
- АудиторияAudience
- Разработчики, SCA и специалисты license compliance.Developers, SCA and licence compliance specialists.
- ПредпосылкиPrerequisites
- Текст лицензии или декларация компонента и понимание контекста распространения.The licence text or the component declaration, plus an understanding of the distribution context.
- Измеримый результатMeasurable outcome
- Идентифицировать пять лицензий корректными SPDX expression и отметить неопределённости.Identify five licences with correct SPDX expressions and flag the uncertainties.
- АртефактArtefact
- Таблица component → evidence → SPDX ID/expression → obligations → reviewer.A component → evidence → SPDX ID/expression → obligations → reviewer table.
- Критерий / рубрикаAssessment criteria
- WITH и OR/AND применены корректно, источник текста сохранён, совместимость не заявлена без анализа.WITH and OR/AND are applied correctly, the source of the text is retained, and compatibility is not claimed without analysis.
- Маршрут и времяRoute and time
- 2–4 академических часа; вместе с SCA и политикой допуска компонентов.2–4 academic hours; taken together with SCA and the component approval policy.
Открыть справочникOpen the reference
От рабочего кода к выпускаемому продуктуFrom working code to a shippable product
Жизненный цикл, языки, стеки и четыре класса дефектов.The lifecycle, languages, stacks and four classes of defect.
- АудиторияAudience
- Разработчики, архитекторы и инженеры выпуска.Developers, architects and release engineers.
- ПредпосылкиPrerequisites
- Один язык программирования, сборка, тесты и базовый pipeline.One programming language, a build, tests and a basic pipeline.
- Измеримый результатMeasurable outcome
- Проследить один дефект от причины в коде до gate, исправления и evidence выпуска.Trace one defect from its cause in the code through the gate, the fix and the release evidence.
- АртефактArtefact
- Мини-кейс assurance: исходный дефект, patch, тест, hardening и release checklist.A short assurance case study: the original defect, the patch, the test, hardening and a release checklist.
- Критерий / рубрикаAssessment criteria
- Причина и последствие разделены, исправление проверено, артефакты можно повторить из репозитория.Cause and consequence are separated, the fix is verified, and the artefacts can be reproduced from the repository.
- Маршрут и времяRoute and time
- 4–6 академических часов; мост от secure coding к SSDLC и DevSecOps.4–6 academic hours; the bridge from secure coding to SSDLC and DevSecOps.
Открыть курсOpen the course
Языки, архитектура и безопасный SQLLanguages, architecture and safe SQL
Дефект инъекции как связка API, данных и теста.The injection defect as the point where API, data and test meet.
- АудиторияAudience
- Начинающие разработчики и преподаватели программирования.Junior developers and programming teachers.
- ПредпосылкиPrerequisites
- Функции, строки, SQL и запуск автоматического теста.Functions, strings, SQL and the ability to run an automated test.
- Измеримый результатMeasurable outcome
- Заменить небезопасную сборку SQL параметризованным запросом и пройти negative tests.Replace unsafe SQL string building with a parameterised query and pass the negative tests.
- АртефактArtefact
- Код до/после, набор тестов и краткое объяснение trust boundary.Before and after code, a test suite and a short explanation of the trust boundary.
- Критерий / рубрикаAssessment criteria
- Payload остаётся данными, функциональный тест сохранён, regression test падает на старом варианте.The payload stays data, the functional test still passes, and the regression test fails on the old version.
- Маршрут и времяRoute and time
- 3–4 академических часа; затем AppSec, SAST и расширенный secure coding.3–4 academic hours; then AppSec, SAST and extended secure coding.
Открыть курсOpen the course
Безопасность приложений: курс и практикумApplication security: the two-day programme and its materials
Threat modeling, требования и тестирование веб-приложения.Threat modeling, requirements and testing of a web application.
- АудиторияAudience
- Разработчики, QA, AppSec и security champions.Developers, QA, AppSec and security champions.
- ПредпосылкиPrerequisites
- HTTP, Git, базовая разработка веб-приложений и локальный контейнерный стенд.HTTP, Git, basic web development and a local containerised lab.
- Измеримый результатMeasurable outcome
- Выбрать три ASVS-требования, выполнить versioned WSTG-сценарии и подтвердить исправление.Select three ASVS requirements, run the versioned WSTG scenarios and confirm the fix.
- АртефактArtefact
- Threat model, verification matrix и finding с patch и retest.A threat model, a verification matrix and a finding with its patch and retest.
- Критерий / рубрикаAssessment criteria
- Top 10 используется как обзор риска, ASVS как требование, WSTG как тест; scope и evidence явны.Top 10 is used as a risk overview, ASVS as the requirement and WSTG as the test; scope and evidence are explicit.
- Маршрут и времяRoute and time
- 2 учебных дня плюс самостоятельная лабораторная работа на локальном стенде.2 teaching days plus independent work in a local lab.
Открыть курсOpen the course
Каталог угроз для анализа безопасности ПОThreat catalogue for software security analysis
227 исходных записей: 177 в выборке ПО и 50 вне её области. Справочник и обоснования на русском языке.227 source records: 177 in the software selection and 50 outside its scope. Reference content and rationales are in Russian.
- АудиторияAudience
- Архитекторы, разработчики и специалисты AppSec, составляющие модель угроз ПО.Architects, developers and AppSec specialists preparing a software threat model.
- ПредпосылкиPrerequisites
- Описание архитектуры, активов, границ доверия и предполагаемого нарушителя.An architecture description, assets, trust boundaries and an assumed attacker.
- Измеримый результатMeasurable outcome
- Обосновать применимость пяти угроз и исключение двух для выбранного программного объекта.Justify five applicable threats and two exclusions for a selected software asset.
- АртефактArtefact
- Матрица: УБИ, актив, условие применимости, решение и обоснование; выгрузка выбранных записей.A matrix of threat ID, asset, applicability condition, decision and rationale; an export of selected records.
- Критерий / рубрикаAssessment criteria
- Исходное описание отделено от авторского отбора; каждое решение связано с архитектурой, а не только с наличием записи в каталоге.Source descriptions remain separate from the author's selection; every decision follows the architecture, not merely catalogue membership.
- Маршрут и времяRoute and time
- Рекомендуемая самостоятельная работа: 45–60 минут; затем уточнение модели угроз в процессе РБПО по ГОСТ Р 56939-2024.Suggested independent work: 45–60 minutes; then refine the threat model within secure development under GOST R 56939-2024.
Открыть справочникOpen the reference