DevSecOps

How teams can make use of the White House report on secure and measurable software

White House software report

The White House Office of the National Cyber Director (ONCD) released a report last week on how the industry can get on a path to secure and measurable software.

ONCD’s report highlights two areas that would improve software security and calls on the technical community to take steps to address them. The first starts with the use of memory-safe programming languages, the other focuses on the development of diagnostics to measure cybersecurity quality.

Here’s a quick thumbnail:

Memory-safe programming languages: The report specifically asks software manufacturers to move away from legacy programming languages such as C and C++ because of the memory safety risks they introduce, which have largely been solved for in newer programming languages. 

Measuring cybersecurity quality: The ONCD report also introduces the idea that as a community, we need to have better ways to measure security quality within software, primarily in three distinct areas: the developer process, software analysis and testing, and the execution (runtime) environment.

There’s a very real reason that C & C++ languages still have a lot of adoption despite having very well-known security issues: they're faster, they offer substantially more granularity in a lot of cases, think memory allocation, which is also the same thing that causes the risk they are trying to eliminate. They also serve a very wide array of purposes that are hard to mimic. It’s literally used for everything: hardware, kernels, drivers, and operating systems.

Challenges with measuring software security

It’s a challenging one, primarily because of the complexity around current application development and all its moving pieces, and also because often the visibility into and understanding of how each area of the application or build environment are correlated is missing, which leads to a lack of context. 

Without that context, measurability becomes generic and not very helpful. Consider CVSS scores and how they are used today despite the fact that a CVSS often means nothing in the context of how a vulnerability maps to actual risk within an application or development environment.

What to do about building secure and measurable software   

First, where possible, start using only modern programming languages that are memory safe to help eliminate large subsections of known risks found in older programming languages, such as out-of-bound read/writes or use after free vulns. In cases where products are already built in older languages with known memory risk, there are a few steps that can make them more secure. First, make sure to use modern idioms to help produce safer and more reliable code. Use security tooling such as fuzzers and sanitizers to find issues before they go into production. Finally, use appropriate privilege separation where possible to minimize blast radius should a vuln in your app get exploited. 

Regarding metrics, it all comes down to visibility and correlation. If all the information the company has about applications is in siloes, it’s very difficult to create meaningful metrics. An application security posture management tool can help consolidate and correlate the information coming from all the organization’s different application security tooling, development environments, and cloud environments. 

Understanding what risk metrics are relevant to the organization and its risk appetite will also help the team build universal policies, which will make it easier to build metrics that can show progress as the organization matures its application security program. 

Teams also need to use metrics that show relevant and actual risk reduction. This requires an understanding of how applications, runtime environments, and mitigations are connected and correlated, which comes from having a holistic view of the software factory and code produced within it. Did we just close out a bunch of low vulns that don’t matter? Did we spend time on a critical vuln that was already mitigated elsewhere, or wasn’t relevant to our risk profile?

Along with that visibility, teams need to create meaningful metrics that help drive an application security program and delivers the secure and measurable software the ONCD report talks about.

Joe Nicastro, Field CTO, Legit Security     

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds