Компания Google подвела итоги инициативы по внедрению в Android методов безопасной разработки (Safe Coding), таких как использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность. Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%.

Инженеры Google также сделали вывод, что основным источником проблем с безопасностью является новый код и поэтому внимание следует сосредоточить на модернизации методов разработки нового кода. Уже существующий код со временем становится более проверенным и безопасным (наблюдается экспоненциальная зависимость безопасности от времени), что делает не столь выгодными вложения в проекты по переписыванию существующего кода. Например, 5-летний код в среднем имеет в 3.4 раза меньшую плотность уязвимостей, чем новый код. Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза.
. . .
В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кода на языках безопасно работающих с памятью и обеспечении переносимости между новым и старым кодом
. . .
Скорость и качество разработки увеличивается за счёт упрощения тестирования и смещения выявления ошибок на ранние стадии разработки, на которых ошибки становятся заметны ещё до того, как разработчик приступает к проверке кода. В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++.

Методы безопасной работы с памятью позволили существенно снизить число уязвимостей в Android
https://www.opennet.me/opennews/art.shtml?num=61933

Оригинал
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

Тут автор Chef решил переосмыслить все эти наши терраформы и выпустил своё видение на этот счёт. Я не впечатлился, если честно, но может кому и интересно будет.

One cause of our feedback loop problem is that we’re bound up by the constraints of how other people implement their systems. For example - it might take AWS up to 10 minutes to provision an EKS cluster. The current tools can tell you if you have the syntax right, but they can’t tell you if it will work or not. To learn that? Gotta wait 10 minutes and pray for rain.

The other source of poor feedback loops is that we represent the definition of our infrastructure as code in the first place. This was a good idea at the time - we gained all the benefits of version control, we could do code review, build pipelines, and do continuous integration and delivery. But code is less malleable than data - it gets locked up behind syntax, it grows in complexity as the problem domain expands, as the abstractions pile up. It’s a static representation of a dynamic environment. With application code it works great - because the results are usually straightforward: an application artifact. But with infrastructure? It turns out to be a very awkward fit. It works, I’m not contesting that. But all you need to do to understand why it’s awkward is look at how hard we’ve pushed to effectively store and manage state, to artificially segment our infrastructure due to constraints of the implementation, and our failure to inspire our peers to work with us on complex infrastructure. It works, but it’s not nearly good enough.
. . .
We accomplish this in System Initiative by building models that exist at various levels of semantic scale, and then building interfaces that make sense at those levels. For example - your application likely has properties that are configurable, actions it can take (like being deployed or built) and infrastructure it requires. You can use the same fundamental system of digital twins we use for low level infrastructure and express the impact with relationships. Eventually[^2], we will provide a custom interface specifically for each job, built from the same underlying data and kept up to date through simple usage. By giving people a view into the data that best fits their needs, we enable them to work together - even when they’re just doing “their” part of the job.

System Initiative is the Future
https://www.systeminit.com/blog-system-initiative-is-the-future

Сайт
https://www.systeminit.com

Обсуждение на HackerNews
https://news.ycombinator.com/item?id=41648483

GitHub
https://github.com/systeminit/si

Пятница!

На недавно прошедшей LPC 2024 (Linux Plumbers Conference) было много чего реально интересного, я искренне люблю эту конфу, но один доклад прям запал в душу.

Доклад называется Flying the nest - a BPF port of Doom.

Doom портировали и запустили поверх виртуальной машины BPF.

Доклад изобилует огромным количеством различных технических подробностей касательно eBPF и экосистемы связанной с этой технологией. Помимо Doom, там было ещё два примера. Не смотря на это доклад смотрится достаточно легко и понятно.

Обещают открыть код всего это дела.

Всем, кто интересуется, рекомендую.

Доклад вырезал с трансляции и прикрепил к посту, ссылка на YouTube с таймкодом
https://www.youtube.com/live/rQtQ-Nd1ZmA?t=1675s

Слайды в виде PDF закину в комменты.