What does it take to make secure software? The Open Source Security Foundation (OpenSSF) has a few ideas (10 of them, in fact).

This week at the OpenSSF Day Japan event in Tokyo, the nonprofit group run by the Linux Foundation issued the release of ten guiding principles that aim to help organizations develop more secure software. OpenSSF, which focuses on improving open source security, developed the principles to provide a framework for companies to follow best practices throughout their development lifecycles.

The Secure Software Development Guiding Principles outline core practices that producers and suppliers of software can pledge to align with when creating proprietary and open source software. By adopting these methods, OpenSSF hopes to cultivate software that is secure by default.

These practices cover a wide range of security measures, from building secure features into design to being transparent about known issues. They emphasize taking a proactive approach across the entire software lifecycle.

The 10 Secure Software Development Guiding Principles are the following:

1. To employ development practices that are in conformance with modern, industry-accepted secure development methods.
2. To learn and apply secure software design principles (such as least privilege).
3. To learn the most common kinds of vulnerabilities and to take steps to make them unlikely or limit their impact.
4. To check for and address known and potential critical vulnerabilities prior to releasing software, then monitor for vulnerabilities subsequently throughout the supported life of the product.
5. To harden and secure our software development infrastructure against compromise or infiltration against the same principles, practice, and expectations set for the software developed on and built from them.
6. To prioritize the sourcing of software from suppliers and developers who also pledge to develop in conformance with the Secure Software Development Guiding Principles, and from projects that publicly report security health metrics and adopt controls to prevent tampering of software packages, and that actively address known/discovered malicious software.
7. To provide software supply chain understandability to consumers of our software consistent with evolving industry standards, practices, and tooling.
8. To manage responsible vulnerability disclosure programs that are inclusive of upstream dependencies and have publicly documented vulnerability reporting and remediation policies.
9. To publish security advisories consistent with evolving industry best practices.
10. To actively collaborate with and participate in industry and regulatory initiatives related to securing the software supply chain, and to evangelize adoption of the Secure Software Development Guiding Principles among our industry peers.

"These principles are already practiced by many organizations," David A. Wheeler, director of Open Source Supply Chain Security, Open Source Security Foundation (OpenSSF) told SDxCentral. "What’s new is this clear crystallization of the principles we think developers should commit to. It’s much easier to get more people to do something if it’s clearly explained."

Wheeler noted that the 10 principles are high-level concepts  that can be achieved in many ways. He doesn't expect that some form of enforced compliance will be one of the ways the principles are used.

"We do measure compliance in other areas, but we aren’t currently planning to measure compliance with these principles in that way," he said.

The goal of the principles, according to OpenSSF is to, "…welcome every organization producing and supplying software that uses open source components to consider following and signing on endorsing these great practices”. Wheeler said that the OpenSSF wants people to follow these principles because they are developers of software.

More specifically, OpenSSF does its work in support of open source technologies. Wheeler said that one of the primary ways OpenSSF is working to help in the implementation of the guiding principles is to provide training, tools, and guidance to make it easier to implement the principles.

For example, the principles say developers will do the following::

• “Learn and apply secure software design principles (such as least privilege)” and "learn the most common kinds of vulnerabilities and to take steps to make them unlikely or limit their impact”
  –  The OpenSSF's free Secure Software Development Fundamentals Courses help make that a reality.
• “Check for and address known and potential critical vulnerabilities prior to releasing software, then monitor for vulnerabilities subsequently throughout the supported life of the product”
  -- OpenSSF encourages the use of tools to counter vulnerabilities. OpenSSF Scorecard and Best Practices Badge provide ways to measure and get credit for this.
• “Harden and secure our software development infrastructure against compromise or infiltration against the same principles, practices, and expectations set for the software developed on and built from them.”
  – The  Supply-chain Levels for Software Artifacts, or SLSA ("salsa") focuses on this; today it focuses on countering build-time attacks, and OpenSSF is expanding to other areas, such as protecting source code forges).

There can potentially be any number of different issues that could be a challenge for an organization implementing the OpenSSF guidelines.

In Wheeler's view, the biggest challenge is cultural. He noted that software is normally developed to provide some specific function, and security is often not considered. In addition, he said that most universities don’t require future developers to know how to develop secure software, and many developers don’t learn their craft in a university. "The information exists, but many developers don’t realize they need to learn it or need to apply it," Wheeler said. "These principles provide a starting point for developers to state that these security principles are important, and thus that other developers should also consider them important."