Last year, Cybersecurity and Infrastructure Security Agency Director Jen Easterly gave a speech at Carnegie Mellon that emphasized the “secure by default” future that federal agencies are aiming for when they talk about driving security into earlier phases of software design.
What does this look like in practice, and how is this going to affect the federal government’s software procurement policies? Those are the types of questions that federal agencies and their software providers alike are asking as they brace for the new world of “software bills of materials” (aka “SBOMs”) and their disclosure requirements.
If you want a front-row seat to watch the federal government’s effort to make software “secure by default” in the next two years, memory safety is a great class of software vulnerability to watch. Let’s take a look.
What is memory safety?
Memory safety is a particularly ripe domain for software vulnerabilities. So much so that back in November, the National Security Agency issued guidance to “help software developers and operators prevent and mitigate software memory safety issues, which account for a large portion of exploitable vulnerabilities.”
Most low-level programming languages–like C++ and C–are memory unsafe. Developers have to manually configure and allocate the machine’s memory. If you make a mistake, your program can read or write data from the wrong type of memory. And that leads to bugs, crashes, data leaks and all kinds of potential exploits.
Dealing with memory safety in these low-level languages is something that gets taught in programming classes, but it’s tedious, error prone and time-intensive
Read more