Developing secure coding in Azure Sphere

Hey pjmlp! As a Microsoft employee, I agree with your assessment that an embarrassing number of modern vulnerabilities come from a lack of memory safety, particularly in C. Personally, I have been an Ada dev, I am a fan of Rust and Golang and I love the innovation and progress being made in the space of language design. That being said, the value of open source software is in building what you need on top of what exists, and a huge amount of software exists in the open or in the private IP that is in C. As an engineer, the drive for purity and perfection in me would love to see it all converted to something like Rust. But I also recognize there is value in not reinventing the wheel for every project and that technology enables smaller groups to do more by building on things that exist. Also, keep in mind that while those languages are promising in many ways, supporting any additional languages is a challenge in the very small memory footprint Azure Sphere has.

The idea that castle walls are meaningless when the foundation is built on quicksand is a quality sentiment. But it is also not an apt analog to what you see in Azure Sphere. A customer application is never serving as the foundation in a complex platform whose security is built on the combination of hardware, OS software and cloud services. A search will lead you to some impressive blog posts and whitepapers from researchers who have attempted to breach the strong foundations of Azure Sphere, even bringing 0-day Linux kernel exploits to the table, and not finding quicksand. What I think drives Azure Sphere forward is that “being perfect” in coding, even in memory safety, is not the meaning of security. Azure Sphere implements those 7 properties linked above, none of which are “be perfect in your code”. What Azure Sphere brings to the table is not a promise that trust can never be lost, it is the idea that trust can be renewed.