АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Безопасное программирование

Безопасное программирование — методика разработки программного обеспечения, направленная на предотвращение случайного внедрения уязвимостей и обеспечение устойчивости к воздействию вредоносных программ и несанкционированному доступу. Баги и логические ошибки являются основной причиной появления уязвимостей программного обеспечения.

Современные подходы к безопасному программированию включают применение риск-ориентированного подхода (в частности, в соответствии с приказом ФСТЭК № 117), который предполагает выстраивание защиты на основе актуальной модели угроз и оценки рисков, а не фиксированных наборов мер[1]. Важной частью методологии DevSecOps стало внедрение процессов непрерывного управления безопасностью приложений (ASPM) на протяжении всего их жизненного цикла.

С массовым распространением ИИ-ассистированной разработки (так называемого «вайб-кодинга») и автономных агентов методики безопасного программирования были адаптированы для защиты от новых векторов атак[2]. В рамках обеспечения безопасности цепочек поставок (Supply Chain Security) требуется защита не только традиционных зависимостей и конвейеров сборки, но и самих ИИ-моделей, серверов MCP и наборов данных[3].

Описание

Безопасное программное обеспечение — программное обеспечение, разработанное с использованием комплекса мер, направленных на недопущение появления и ликвидацию уязвимостей программы в соответствии с требованиями стандарта ГОСТ Р 56939-2024[4].

Задача безопасного программирования — защита данных пользователя от кражи и повреждения, а также сохранение контроля над системой. Небезопасная программа является потенциальной целью для злоумышленников, которые могут использовать уязвимости для просмотра, изменения или удаления информации, влияния на работу программ и сервисов, внедрения вредоносного кода в систему[5].

В соответствии с приказом ФСТЭК России № 117 (вступает в силу 1 марта 2026 года) расширена ответственность разработчиков и подрядчиков за безопасность создаваемого программного обеспечения[6][7].

Терминология

В англоязычной литературе встречаются два термина, которые могут быть переведены как «безопасное программирование»:

Оборонительное программирование — принцип разработки ПО, при котором разработчики стремятся учесть все возможные ошибки и сбои, максимально изолировать их и, по возможности, восстановить работоспособность программы при возникновении неполадок. Это делает программное обеспечение более стабильным и менее уязвимым. Пример аппаратной реализации этого принципа — сторожевой таймер, а также вычисление контрольных сумм для выявления ошибок при передаче данных[8].

Безопасное программирование — методика написания программ, устойчивых к атакам со стороны вредоносных программ и злоумышленников. Безопасное программирование позволяет защитить данные пользователя от кражи или порчи. Кроме того, небезопасная программа может предоставить злоумышленнику доступ к управлению сервером или компьютером пользователя, а последствия могут быть различны: от отказа в обслуживании одному пользователю до компрометации секретной информации, потери обслуживания или повреждения систем тысяч пользователей[5].

Важность

Вопросы обеспечения безопасности и работоспособности системы рассматриваются на этапах её проектирования[9]. Требования к безопасности продуктов и систем ИТ определяются из анализа существующих и прогнозируемых угроз, принятой политики безопасности, а также исходя из условий применения[10]. Внедрение решений по обеспечению безопасности после завершения разработки системы — дорогостоящий и сложный процесс. Поэтому рекомендуется учитывать требования к безопасности на всех этапах жизненного цикла системы[9]. На этапе проектирования для выявления потенциальных целей злоумышленников применяются современные методологии моделирования угроз, такие как STRIDE (категоризация угроз по шести типам) и PASTA (риск-ориентированная методология анализа угроз и атак)[11][12].

Информационная система подразделяется на физический и логический уровни. Понимание того, что именно требуется защищать, позволяет выбрать и применить подходящие защитные меры. Границы между уровнями определяются политикой безопасности, регламентирующей определённые объёмы информации и технологий. Иногда на одной машине могут находиться и общедоступные, и конфиденциальные данные, что влечёт наложение нескольких политик безопасности. Разработчики должны учитывать эти границы и отражать их в проектной документации и политиках безопасности[9]. Они обязаны уметь обеспечивать безопасность при проектировании, разработке, управлении, настройке, интеграции и тестировании[13].

Анализ и обеспечение безопасности — ресурсоёмкая задача, увеличивающая стоимость программного продукта. Если раньше ставили целью абсолютное устранение рисков, то сейчас ключевым становится анализ затрат и выгод от внедрения систем защиты. Иногда экономические последствия внедрения «жёстких» средств защиты могут не оправдать издержки. Следует учитывать не только прямые финансовые, но и, например, репутационные потери. Прямые расходы — это приобретение и внедрение технологии; косвенные — снижение производительности, дополнительное обучение персонала[14]. По данным 2026 года, стоимость исправления уязвимостей экспоненциально возрастает на поздних этапах разработки: если принять затраты на устранение дефекта на этапе проектирования за базовую единицу (1x), то на этапе разработки они увеличиваются примерно в 10 раз (10x), а на этапе эксплуатации — в 100 раз (100x)[15][16].

Принципы

Существует множество технологий разработки безопасного ПО, но есть универсальные принципы, учитываемые при любом подходе[17]:

  • работоспособность и полезность;
  • безопасность — защита от внешних угроз, атак и сохранение работоспособности после них;
  • надёжность — устойчивое к ошибкам поведение при некорректных данных;
  • конфиденциальность — безопасная работа с чувствительной информацией;
  • целостность и корректность бизнеса — организация сопровождения, прозрачность и законность пользовательских действий.

Корпорация Microsoft для обеспечения этих требований продвигает «Инициативу по обеспечению безопасного будущего» (Secure Future Initiative, SFI), пришедшую на смену концепции «Вычисления, заслуживающие доверия». Новая инициатива опирается на три ключевых принципа: безопасность в дизайне (Secure by Design), безопасность по умолчанию (Secure by Default) и безопасность операций (Secure Operations)[18].

Обобщённо данные принципы отражают большинство подходов по обеспечению безопасности ПО[19].

В условиях массового применения инструментов искусственного интеллекта реализация принципа «безопасность в дизайне» (Secure by Design) базируется на подходе «нулевого доверия», при котором любой сгенерированный ИИ код по умолчанию рассматривается как ненадёжный внешний ввод, требующий тщательной проверки[20].[21] Для предотвращения «архитектурного дрейфа» и накопления уязвимостей бизнес-логики архитектурный анализ теперь требует обязательного человеческого надзора за общей структурой системы, а также применения семантического и кросс-файлового анализа[22].[21] Верификация логики кода включает анализ намерений и поведения для выявления скрытых дефектов, строгую персональную ответственность разработчиков за предложенные ИИ изменения (с обязательным код-ревью), внедрение автоматизированных барьеров безопасности в конвейеры CI/CD и жёсткий контроль зависимостей для защиты от внедрения злоумышленниками выдуманных пакетов (slopsquatting)[20].[23][22]

Классификация и виды уязвимостей

Классификаторы

Стандартизованные описания уязвимостей существенно упрощают работу специалистов по информационной безопасности. Существуют различные классификаторы[24]:

  • CVE — словарь конкретных уязвимостей отдельных продуктов;
  • CWE — база данных видов уязвимостей, с описаниями способов их предотвращения, обнаружения и исправления;
  • SecurityFocus BID;
  • OSVDB — открытая база, созданная тремя некоммерческими организациями. Прекратила работу 5 апреля 2016 года, блог продолжает функционировать;
  • Secunia — лента уязвимостей компании Secunia (Дания) в области компьютерной и сетевой безопасности;
  • IBM ISS X-Force.

Современные анализаторы кода и инструменты аудита используют подобные базы для проверки программ, что повышает доверие к продукту и облегчает подготовку отчётов для стандартов[24].

Метрики

Любая программа потенциально может стать целью атаки. Обнаружив уязвимость, злоумышленники используют её для кражи данных, порчи информации, управления системами[5]. Для оценки риска используется система CVSS — набор шкал, позволяющих назначать баллы угрозам и ранжировать приоритеты устранения[25][26][24]:

  • базовая — свойства уязвимости, не зависящие от среды исполнения; описывает сложность эксплуатации и потенциальный ущерб;
  • временная — учитывает временные факторы (например, наличие патча);
  • контекстная — учитывает специфику среды применения.

Последние две метрики корректируют базовые показатели[26].

Виды уязвимостей

Примеры распространённых ошибок, приводящих к угрозам безопасности[27]:

Перечислить все уязвимости невозможно — ежеднедневно появляются новые. В приведённом списке — типовые ошибки, способные привести к серьёзным последствиям. Например, вспышку червя Blaster вызвала ошибка в двух строках кода[30].

Методы защиты и инструменты

Эффективная стратегия защиты — предотвращение ошибок и уязвимостей, что требует регулярной проверки входных данных. Например, средства защиты от атак переполнения буфера — контроль длины входных данных; перед добавлением в БД — проверка на внедрение SQL-кода; перед выводом на web-страницу — защита от XSS. Избыточные проверки усложняют разработку и могут привести к новым ошибкам, поэтому необходима их разумная комбинация[30].

Средства защиты могут предоставляться компилятором или операционной системой. Современные компиляторы, такие как GCC, Clang и MSVC, поддерживают широкий спектр механизмов безопасности. Для защиты от переполнения буфера применяются стековые канарейки (флаг -fstack-protector в GCC и Clang) и технологии теневого стека (аппаратная поддержка через -mshstk). Контроль целостности потока управления (CFI) обеспечивается как программными методами (-fsanitize=cfi в Clang, /guard:cf в MSVC), так и за счёт аппаратной поддержки, например Intel CET (-fcf-protection в GCC и Clang). Также во всех трёх компиляторах реализованы санитайзеры (AddressSanitizer, UndefinedBehaviorSanitizer, а в Clang — MemorySanitizer) для автоматического обнаружения ошибок работы с памятью и неопределённого поведения[31][30].

Современные операционные системы также внедряют защитные технологии, например ASLR (рандомизация адресного пространства) поддерживается в Linux и Windows. Также применяются неисполнимые стеки (W^X, PaX и др.)[30].

Для web-сервисов атаки типа SQL-injection, XSS, CSRF, clickjacking являются типовыми. Современные фреймворки значительно упрощают реализацию безопасных web-приложений, освобождая от необходимости ручных проверок данных и предоставляя более безопасные ORM-интерфейсы для работы с БД[32][33].

DevSecOps и автоматизация

Современные практики DevSecOps предполагают автоматизированную интеграцию инструментов безопасности на различных этапах конвейера CI/CD. Это позволяет выявлять уязвимости как на уровне исходного кода, так и в работающем приложении[34].[35] На ранних этапах разработки (при фиксации кода или сборке) применяется статический анализ (SAST), выявляющий уязвимости в исходном коде без его запуска (например, SQL-инъекции, XSS и переполнения буфера). На этапе сборки также интегрируется анализ состава программного обеспечения (SCA) для поиска известных уязвимостей (CVE), устаревших пакетов и проблем с лицензиями в сторонних библиотеках и open-source компонентах[36].[35] После успешной сборки и развёртывания в тестовой среде используется динамический анализ (DAST), направленный на поиск уязвимостей времени выполнения в работающем приложении, включая ошибки конфигурации и проблемы аутентификации[36].[35] Для анализа потоков данных изнутри работающего приложения в реальном времени внедряется технология интерактивного тестирования (IAST). Она работает через агенты инструментации (например, для JVM, .NET или Node.js) и обеспечивает высокую точность обнаружения угроз с указанием конкретной уязвимой строки кода[37].[38] Процессы безопасной разработки регламентируются стандартом ГОСТ Р 56939-2024, устанавливающим обязательные требования к инструментам автоматизации. Согласно стандарту, необходимо использовать системы управления изменениями и версиями, средства проверки правил кодирования и экспертизы кода, а также инструменты статического, динамического (включая фаззинг-тестирование) и композиционного анализа. Дополнительно требуется автоматизировать проверку безопасности используемых секретов и процессы реагирования на информацию об уязвимостях[39].

Безопасность цепочек поставок

В 2026 году атаки на цепочки поставок программного обеспечения (Supply Chain) и зависимости с открытым исходным кодом стали одной из главных угроз безопасности. За первые четыре месяца года было выявлено более 2500 вредоносных пакетов в реестре PyPI и свыше 2200 в npm. Злоумышленники внедряют вредоносный код в популярные пакеты, а также атакуют инфраструктуру CI/CD, подменяя доверенные теги и извлекая секреты из памяти процессов сборки[40]. Для защиты от подобных угроз применяется SBOM (англ. Software Bill of Materials) — структурированный перечень программных компонентов, содержащий детализированную информацию о составе программного обеспечения. В российской нормативной базе (согласно требованиям ГОСТ Р 56939-2024 и методикам ФСТЭК) SBOM должен представляться в машиночитаемом формате CycloneDX. Документ включает хеш-суммы компонентов, ссылки на репозитории и специфические метки, определяющие принадлежность компонента к поверхности атаки или функциям безопасности[41]. Современные инструменты анализа состава программного обеспечения (SCA) и анализа SBOM ориентированы на выявление «отравленных» пакетов (тайпсквоттинг) и проактивную блокировку угроз. Такие решения, как Xygeni, Aikido Security, Veracode SCA и Sonatype Lifecycle, обеспечивают поведенческое обнаружение вредоносного кода, анализ достижимости уязвимостей и автоматическую блокировку загрузки опасных компонентов до их попадания в конвейер разработки[42].[43]

Искусственный интеллект в разработке

Массовое применение искусственного интеллекта для генерации кода (так называемый «вайб-кодинг») привело к росту проблем с безопасностью. По данным исследований, к маю 2026 года количество обнаруженных уязвимостей в кодовых базах увеличилось на 70 %[44]. Среди основных рисков выделяются массовое тиражирование типовых ошибок (таких как SQL-инъекции, XSS и SSRF)[45], утечки конфиденциальных данных и API-ключей[46], а также уязвимость ИИ-агентов к промпт-инъекциям[47]. Высокая скорость генерации кода часто опережает возможности команд безопасности по его проверке, что способствует накоплению технического долга[45].

Для минимизации рисков методика безопасной разработки с использованием ИИ-ассистентов базируется на концепции «нулевого доверия» (Zero Trust) к сгенерированному коду[48]. Любой созданный алгоритмами код рассматривается как недоверенный ввод, требующий обязательного ревью человеком[49]. В процесс разработки внедряется непрерывное автоматизированное сканирование: статический анализ кода (SAST), анализ состава программного обеспечения (SCA) и сканирование секретов[50]. Эти проверки осуществляются на этапах коммита и создания запросов на слияние, дополняясь строгим контролем зависимостей и запретом на передачу реальных учётных данных в запросы к ИИ[49].

Ущерб

Информация о новых уязвимостях используется злоумышленниками для написания вирусов. Так, один из первых известных сетевых червей (червь Морриса) в 1988 году эксплуатировал переполнение буфера в Unix-демоне finger, что привело к заражению около 6000 машин[51]. По данным Счётной палаты США, экономический ущерб составил от 10 до 100 миллионов долларов.

В 2016 году компьютерные вирусы нанесли мировой экономике ущерб в 450 миллиардов долларов[52]. В последующие годы экономический ущерб от киберпреступности значительно вырос: по оценкам аналитических центров, в 2024 году он составил около 9,5 трлн долларов, в 2025 году — 10,5 трлн долларов, а в 2026 году этот показатель оценивается в сумму до 12,5 трлн долларов[53][54].

В 2017 году ущерб от вируса WannaCry оценили в 1 миллиард долларов. Заражения были зафиксированы как минимум в 150 странах[55][56]. Вирус использовал эксплойт EternalBlue, эксплуатировавший уязвимость в протоколе SMB, связанную с переполнением буфера[57][58][59][60].

Примечания

  1. ↑ Приказ ФСТЭК № 117: Риск-ориентированный подход. Клерк. Клерк.ру (1 марта 2026). Дата обращения: 27 августа 2026.
  2. ↑ Secure Coding with AI Cheat Sheet. OWASP Cheat Sheet Series. OWASP (1 августа 2026). Дата обращения: 27 августа 2026.
  3. ↑ OWASP Global AppSec EU 2026: Key Takeaways on Secure Software Supply Chain, MCP Security, and the AI BOM. Xygeni Blog. Дата обращения: 27 августа 2026.
  4. ↑ ГОСТ Р 56939-2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. protect.gost.ru. Росстандарт. Дата обращения: 27 августа 2026.
  5. ↑ 1 2 3 Introduction to Secure Coding Guide (англ.). developer.apple.com. Apple Inc.. Дата обращения: 27 августа 2026. Архивировано 26 сентября 2017 года.
  6. ↑ Приказ ФСТЭК 117: ключевые требования в 2026 году. academyit.ru. Академия АйТи. Дата обращения: 27 августа 2026.
  7. ↑ Приказ ФСТЭК № 117: что изменится для разработчиков ПО. rarus-soft.ru. Рарус Софт. Дата обращения: 27 августа 2026.
  8. ↑ M. Tim Jones. Defensive Programming (англ.). drdobbs.com (1 февраля 2005). Дата обращения: 28 июня 2024. Архивировано 13 ноября 2017 года.
  9. ↑ 1 2 3 Stoneburner G., Hayden C., Feringa A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security) : [англ.]. — National Institute of Standards and Technology, 2004.
  10. ↑ Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий : [рус.]. — ФСТЭК России, 2002.
  11. ↑ Threat Modeling Tools Compared (англ.). Versprite. Дата обращения: 27 августа 2026.
  12. ↑ Threat Modeling Best Practices (англ.). Practical DevSecOps. Дата обращения: 27 августа 2026.
  13. ↑ Stoneburner G., Hayden C., Feringa A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security) : [англ.]. — National Institute of Standards and Technology, 2004. — P. 6—8.
  14. ↑ Stoneburner G., Hayden C., Feringa A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security) : [англ.]. — National Institute of Standards and Technology, 2004. — P. 8.
  15. ↑ Стоимость исправления уязвимостей на разных этапах SDLC. ssdlc.ru. Дата обращения: 27 августа 2026.
  16. ↑ Внедрение безопасной разработки (Secure SDLC). in4security.com. Дата обращения: 27 августа 2026.
  17. ↑ Сафонов, В. О. (2008). “Современные технологии разработки надежных и безопасных программ”. Компьютерные инструменты в образовании (1): 25—33. Дата обращения 2024-06-28. |access-date= требует |url= (справка)
  18. ↑ Secure Future Initiative: July 2026 Progress Report (Interactive Version) (англ.) (PDF). Microsoft (1 июля 2026). Дата обращения: 27 августа 2026.
  19. ↑ Wheeler D. A. Secure Programming HOWTO - Creating Secure Software (англ.) (2015). Дата обращения: 27 августа 2026. Архивировано 7 декабря 2000 года.
  20. ↑ 1 2 Best AI Code Security Solutions (англ.). Orca Security Blog. Дата обращения: 27 августа 2026.
  21. ↑ 1 2 Secure Coding Practices: 7 Best Practices, OWASP Guidance, and AI Era Tips (англ.). Checkmarx. Дата обращения: 27 августа 2026.
  22. ↑ 1 2 AI Code Security: Risks, Best Practices, and Tools (англ.). Cycode Blog. Дата обращения: 27 августа 2026.
  23. ↑ Best AI Code Review Tools (англ.). SonarSource. Дата обращения: 27 августа 2026.
  24. ↑ 1 2 3 А. Комаров. Меряем уязвимости, Хакер (2009), С. 48–51. Архивировано 7 августа 2025 года. Дата обращения: 28 июня 2024.
  25. ↑ Mell, P. (2006). “Common Vulnerability Scoring System”. IEEE Security & Privacy [англ.]. 4 (6): 85—89. Дата обращения 2024-06-28. |access-date= требует |url= (справка)
  26. ↑ 1 2 Common Vulnerability Scoring System v3.0: Specification Document (англ.). first.org. FIRST. Дата обращения: 27 августа 2026. Архивировано 16 ноября 2025 года.
  27. ↑ Howard, M. 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them : [англ.] / M. Howard, LeBlanc D., Viega J.. — McGraw Hill Professional, 2009. — ISBN 9780071626767.
  28. ↑ Вахрушев, И.А.; Каушан В.В., Падарян В.А., Федотов А.Н. (2015). “Метод поиска уязвимости форматной строки”. Труды ИСП РАН. 27 (4): 23—38. Дата обращения 2024-06-28. |access-date= требует |url= (справка)
  29. ↑ Saltzer J.H., Schroeder M.D. The Protection of Information in Computer Systems (англ.) (1975). Дата обращения: 27 августа 2026. Архивировано 30 ноября 2024 года.
  30. ↑ 1 2 3 4 Seacord, R. C. Secure Coding in C and C++ : [англ.]. — Addison-Wesley, 2013. — ISBN 9780132981972.
  31. ↑ Sanitizers. docs.conan.io. Дата обращения: 27 августа 2026.
  32. ↑ Security in Django (англ.). docs.djangoproject.com. Django Software Foundation. Дата обращения: 27 августа 2026. Архивировано 5 сентября 2025 года.
  33. ↑ Ruby on Rails Security Guide (англ.). guides.rubyonrails.org. Дата обращения: 27 августа 2026. Архивировано 7 октября 2025 года.
  34. ↑ Top 18 DevSecOps Tools for the AI Era: Securing the SDLC in 2026. Checkmarx. Дата обращения: 27 августа 2026.
  35. ↑ 1 2 3 Incorporate SAST, SCA, and DAST in the SDLC. Checkmarx. Дата обращения: 27 августа 2026.
  36. ↑ 1 2 DevSecOps: Integrating Security in Your CI/CD Pipeline. Testriq. Дата обращения: 27 августа 2026.
  37. ↑ IAST vs DAST vs SAST Comparison Guide. Secure Coding Hub. Дата обращения: 27 августа 2026.
  38. ↑ SAST vs DAST vs IAST: Which Testing Method Wins Where in 2026. Ox Security. Дата обращения: 27 августа 2026.
  39. ↑ ГОСТ Р 56939-2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. Интернет-закон. Дата обращения: 27 августа 2026.
  40. ↑ State of Open Source Supply Chain Attacks. StepSecurity. Дата обращения: 27 августа 2026.
  41. ↑ ФСТЭК утвердила методику выявления уязвимостей и НДВ в ПО. RTM Group. Дата обращения: 27 августа 2026.
  42. ↑ Топ-10 инструментов SCA для DevSecOps. Xygeni. Дата обращения: 27 августа 2026.
  43. ↑ Top Enterprise SCA Tools. Aikido Security. Дата обращения: 27 августа 2026.
  44. ↑ Число уязвимостей в коде выросло на 70% на фоне вайб-кодинга. РБК Компании. РБК. Дата обращения: 27 августа 2026.
  45. ↑ 1 2 Где подходит вайб-кодинг и когда он опасен. Uplab. Дата обращения: 27 августа 2026.
  46. ↑ Vibe-Coding: Как ИИ меняет разработку и что это значит для безопасности. Anti-Malware.ru. Дата обращения: 27 августа 2026.
  47. ↑ Вайб-кодинг и безопасность: кейсы. The Code Media. Дата обращения: 27 августа 2026.
  48. ↑ Best AI Code Review Tools. SonarSource. Дата обращения: 27 августа 2026.
  49. ↑ 1 2 AI Code Assistant Security Risks. Lock.pub. Дата обращения: 27 августа 2026.
  50. ↑ Best AI Code Security Solutions. Orca Security. Дата обращения: 27 августа 2026.
  51. ↑ Касперски, Крис. Записки исследователя компьютерных вирусов. — Питер, 2005. — P. 90. — ISBN 5469003310.
  52. ↑ Luke Graham. Cybercrime costs the global economy $450 billion: CEO (англ.), CNBC International (7 февраля 2017). Архивировано 30 сентября 2025 года. Дата обращения: 27 августа 2026.
  53. ↑ Cybercrime To Cost The World $9 Trillion Annually In 2024 (англ.). Cybercrime Magazine. Cybersecurity Ventures. Дата обращения: 27 августа 2026.
  54. ↑ Economic Impact of Increasing Cybercrime (англ.). Aftra.io. Дата обращения: 27 августа 2026.
  55. ↑ Мария Бондаренко. Ущерб от вируса WannaCry оценили в $1 млрд, РБК (25 мая 2017). Архивировано 4 августа 2024 года. Дата обращения: 28 июня 2024.
  56. ↑ Григорий Матюхин. Эксперты назвали рекордную сумму ущерба от вируса WannaCry, Hi-Tech Mail.ru (25 мая 2017). Архивировано 15 октября 2017 года. Дата обращения: 28 июня 2024.
  57. ↑ William Gamazo Sanchez. MS17-010: EternalBlue’s Large Non-Paged Pool Overflow in SRV Driver (англ.). trendmicro.com. Trend Micro (2 июня 2017). Дата обращения: 27 августа 2026. Архивировано 5 июня 2017 года.
  58. ↑ WannaCry ransomware used in widespread attacks all over the world (англ.). securelist.com. Лаборатория Касперского (12 мая 2017). Дата обращения: 27 августа 2026. Архивировано 27 сентября 2025 года.
  59. ↑ Роман Боровко. Экономический ущерб от вирусов, CNews Analytics (2003). Архивировано 6 октября 2024 года. Дата обращения: 28 июня 2024.
  60. ↑ Net Losses: Estimating the Global Cost of Cybercrime (англ.). mcafee.com. McAfee. Дата обращения: 28 июня 2024. Архивировано 24 октября 2017 года.

Литература

  • Касперски К. Записки исследователя компьютерных вирусов. — СПб.: Питер, 2005. — 316 с. — ISBN 5469003310.
  • ГОСТ Р 56939-2016: Защита информации. Разработка безопасного программного обеспечения. Общие требования. — Стандартинформ, 2016.
  • ГОСТ Р ИСО/МЭК 25010-2015: Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов. — Стандартинформ, 2015.
  • ФСТЭК России. Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий. — 2002.
  • Информационная безопасность бизнеса. Исследование текущих тенденций в области информационной безопасность бизнеса. — Лаборатория Касперского, 2014.
  • Комаров А. Меряем уязвимости. // Журнал Хакер, 2009, №1, с. 48—51.
  • Сафонов В. О. Современные технологии разработки надежных и безопасных программ. // Компьютерные инструменты в образовании, 2008, №1, с. 25—33.
  • Вахрушев И.А., Каушан В.В., Падарян В.А., Федотов А.Н. Метод поиска уязвимости форматной строки. // Труды ИСП РАН, 2015, т. 27, №4, с. 23—38.
  • Howard M., LeBlanc D., Viega J. 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. — McGraw Hill Professional, 2009. — 464 p. — ISBN 9780071626767.
  • Seacord R. C. Secure Coding in C and C++. — 2nd ed. — Addison-Wesley, 2013. — 600 p. — ISBN 9780132981972.
  • Stoneburner G., Hayden C., Feringa A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security). — National Institute of Standards and Technology, 2004.
  • Wheeler D. A. Secure Programming HOWTO - Creating Secure Software. — 2015.
  • Malware History. // BitDefender, 2010, с. 23—24.
  • Howard M., LeBlanc D. Writing Secure Code. — 2nd ed. — Microsoft Press, 2002. — 512 p. — ISBN 9780735615885.
  • Saltzer J.H., Schroeder M.D. The Protection of Information in Computer Systems. — 1975.
  • Mell P., Scarfone K., Romanosky S. Common Vulnerability Scoring System. // IEEE Security & Privacy, 2006, т.4, №6, с.85—89.
  • Net Losses: Estimating the Global Cost of Cybercrime. — McAfee, 2014. — [Архивировано из оригинала 24 октября 2017 года].
  • Seacord R. C. The CERT C Secure Coding Standard. — Pearson Education, 2008. — 720 p. — ISBN 9780132702461.
  • Long F. The CERT Oracle Secure Coding Standard for Java. — Addison-Wesley Professional, 2012. — 699 p. — ISBN 9780321803955.

Ссылки

Категории