Есть такая легендарная база Common Weakness Enumeration (CWE) — набор типичных программных и хардварных ошибок, систематизированный корпорацией MITRE, много лет консультирующей топовые ИТ-проекты

Есть такая легендарная база Common Weakness Enumeration (CWE) — набор типичных программных и хардварных ошибок, систематизированный корпорацией MITRE, много лет консультирующей топовые ИТ-проекты американский военных, силовиков, кибербезопасников, авиацию и медицину, и набравшей весьма крутую статистику по этому всему: https://cwe.mitre.org/

Сотни уязвимостей подробно разобраны, приведены примеры кода, что важно, с перекрёстными логическими ссылками, и т. д. Я из неё периодически ухватываю разные фишечки для курсов :)

Например, классика "Inaccurate Comments": https://cwe.mitre.org/data/definitions/1116.html

Если комментарии и код расходятся по смыслу, то либо разработчик сам не особо понимал, а что собственно он делает, пытаясь как-то "угадать" решение, либо он просто ленив :) Комментарии очень важны, и настоящий профи, который гордится своей работой и несёт за неё ответственность, гарантирует их правильность и своевременность (как правильно писать комменты, я подробно разбираю на курсе "Ясный Стиль").

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

Постоянно срывающиеся графики — это факт жизни в ИТ-мире. Вполне естественно отбрасывать всё, что не нужно прямо сейчас для того, чтобы продукт работал. Крайне мало кто из менеджеров оценивает качество исходного кода. Качество, если оно вообще рассматривается, обычно представляет собой ругань на все баги, которые постоянно всплывают в выпущенном продукте, или психоз относительно непрекращающегося потока ошибок ещё на фазе разработки, который cдвигает график все дальше и дальше.

В развитие темы: "Inclusion of Sensitive Information in Source Code Comments"

https://cwe.mitre.org/data/definitions/615.html

Я не раз встречал в процессе code review в комментах оставленные пароли, разные приватные ссылочки и т. д. А вот бояться, что хакеры по комментариям разберутся в коде, смешно. Если у них есть необфурцированные исходники, то и без комментов разберутся, ну чуть подольше. А если только бинарник, так в него комментарии не включаются :)

Менее тривиальный момент — "Data Element Aggregating an Excessively Large Number of Non-Primitive Elements"

https://cwe.mitre.org/data/definitions/1043.html

Классический пример — malloc() в цикле. Наличествует опасность потенциального бага, когда из кода непонятно, а сколько конкретно памяти будет запрошено (особенно актуально для embedded-разработчиков).

Вот это вообще юмор :)

"Excessive Use of Self-Modifying Code"

https://cwe.mitre.org/data/definitions/1123.html

"The product uses too much self-modifying code."

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

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

Наконец, любимое в нашем контексте: "Excessive McCabe Cyclomatic Complexity"

https://cwe.mitre.org/data/definitions/1121.html

Единственное, нету явной рекомендации, а какой этот "чрезмерный" порог? Массовке рекомендуется удерживать цикломатическую сложность не более 10-15, я предпочитаю похардкорнее — единичка :) Как этого добиваться, скоро в новом бесплатном курсе "СильныеИдеи++" на учебном сервере расскажу, ну и курс по декларативной модели тут тоже очень полезен.

Короче говоря, очень рекомендую периодически заглядывать в Top 25 Most Dangerous Software Weaknesses

https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html

по 1-2 штучки в неделю изучать, и коллегам рассказывать.

На втором и четвёртом местах располагается, похоже, вечная классика "Out-of-bounds Write/Read", распространившаяся десятки лет назад по всему миру с появлением Си, и по сей день ничего с ней не поделать. Надо правда учитывать специфику CWE, это база в значительной степени по программно-аппаратным комплексам, где много пишется на Си, на плюсах, а то и на ассемблере.

Первое место за Cross-site Scripting (и виноваты тут отнюдь не фронтендеры, а бэк, ну понятно, что особенно те кто на пыхе пишет :),

а третье, совсем смешно, ввод данных, которые не проверяются, или проверяются криво. Даже не знаю что сказать :) стажёры и те обычно уже знают, что инпут всегда надо валидировать.

https://cwe.mitre.org/data/definitions/20.html

Поглядывайте время от времени в CWE, там есть чему поучиться.

Телеграм: t.me/ainewsline

Источник: cwe.mitre.org

Комментарии: