Правила безопасной разработки.

Базово овладев (а это значит — понять и применять) OWASP Top 10, уже можно говорить, что у вас есть базовый уровень DevSecOps.

У меня был доклад на PiterPy 2023 по теме "Векторы атак: взгляд разработчика". Хоть сам TOP и обновился с 2023 года, доклад не теряет актуальности. Сами проблемы не куда не деваются, они приоритезируются и добавляются новые или происходит объединением их в новую категорию. Рекомендую посмотреть доклад

Это не что-то новое.
Я часто говорю, что за нас уже давно многое придумано, и нам стоит просто переиспользовать практики.

А практик много:

• DevOps
• DevSecOps
• системный дизайн
• теория программирования
• etc...

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

Но даже при этом всем люди все еще совершают, казалось бы, типичные ошибки.
(И у меня бывает, я тоже человек.)

Только вот цена ошибок разная.

О каких ошибках я говорю, вот пример:

Если порефлексировать, пользователи Trivy совершили две ошибки.

Первая и она очевидная.
Отсутствие фиксации зависимости через digest.

Что такое digest?
Это когда зависимость фиксируется не просто по номеру версии, а еще и проверяется hash-сумма.
Если она не совпадает, то зависимость не ставится и пайплайн падает.

Вторая, менее очевидная ошибка.
Отсутствие dependency cooldown.

Суть очень простая:
не тянуть свежевышедшие версии зависимостей сразу.
Дать им “отлежаться”, как новой куртке, которую вы купили.

Как это могло спасти?

Если бы старые версии не были затронуты (как это часто и бывает), то те, у кого есть dependency cooldown, просто не обновились бы сразу и спокойно переждали.

А те, у кого его нет:
получили уведомление о новой версии → обновились → втащили уязвимую зависимость.

Просто потому что побежали впереди паровоза и взяли версию, которую еще не успело провалидировать комьюнити.

И даже не всегда дело в уязвимостях.

Любая зависимость может:
— иметь баги
— быть несовместимой

Ей нужно время “отлежаться”.

Я, например, когда выходит новый Python, жду 1–2 патч-версии, прежде чем тащить его в прод.

К слову об OWASP:
https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

И тут все уже, как я писал про практики, описано. Бери и делай.

Я бы сюда еще добавил идею из:
https://owasp.org/Top10/2025/A06_2025-Insecure_Design/

Про “не доверяй никому”.

Потому что все люди, и все ошибаются.
Даже в условном Google в OSS могут появляться сомнительные или небезопасные изменения.

В итоге dependency cooldown это просто задержка.

Например:
— не брать версии младше N дней
— или фиксировать версии и обновлять их вручную с лагом

И ты автоматически пропускаешь значительную часть таких атак.

Важно: это не серебряная пуля.

Но это дешевый и эффективный фильтр от булшита.

Больше постов у меня в Telegram-канале: https://t.me/sergeiozeranskii или через поиск в Telegram по запросу «Сергей Озеранский».