Trivalent

dition, as outlined in our Secure by Design whitepaper and in our memory safety strategy, we are deeply committed to building security into the foundation of our products and services. > That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++. Secureblue; https://github.com/secureblue/Trivalent has hardened_malloc. Memory safety notes and Wikipedia concept URIs: https://news.ycombinator.com/item?id=33563857 ... A graded memory safety standard is one aspect of security. > Tailor memory safety requirements based on need: The framework should establish different levels of safety assurance, akin to SLSA levels, recognizing that different applications have different security needs and cost constraints. Similarly, we likely need distinct guidance for developing new systems and improving existing codebases. For instance, we probably do not need every single piece of code to be formally proven. This allows for tailored security, ensuring appropriate levels of memory safety for various contexts. > Enable objective assessment: The framework should define clear criteria and potentially metrics for assessing memory safety and compliance with a given level of assurance. The goal would be to objectively compare the memory safety assurance of different software components or systems, much like we assess energy efficiency today. This will move us beyond subjective claims and towards objective and comparable security properties across products.