RFC - Secure Software Guiding Principles (SSGP)

[SecurityCRob]

We would like feedback from the group on the Secure Software Guiding Principles document(1) that the team recently agreed to collaborate on. Please provide feedback and comments here in this issue, or file PRs with larger discrete sections of suggested wording. We will review this as a group at our 29Aug WG call. Thanks all.

(1) - https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/SecureSoftwareGuidingPrinciples.md

[jkmarz]

I received an interesting suggestion offline: renumbering the principles somewhat chronologically to map to product development lifecycles. Sounds reasonable to me! The suggested revised order would be as follows:

1. To learn and apply secure software design principles (such as least privilege).
2. To employ development practices that are in conformance with modern, industry-accepted secure development methods.
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 remediate 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, practices, 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 Guiding Principles, and from projects that publicly report security health metrics and adopt controls to prevent tampering of software packages.
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 Guiding Principles among our industry peers.

[david-a-wheeler]

I suggest swapping 1 and 2, so the first one becomes "To employ development practices that are in conformance with modern, industry-accepted secure development methods." That is basically the high-level overall statement, and you could argue all the rest are specific examples of that.

[david-a-wheeler]

It's a long name, but I think this should be named the "Secure Software Development Guiding Principles"? There's nothing here about operating production systems, or how to consume software as an end-user.

[jkjell]

nothing here about operating production systems, or how to consume software as an end-user

Should recommendations for operating production systems be added? With things like GitOps and Infrastructure as Code, many of the characteristics of operating productions systems are "developed". As far as consuming, the below speaks to it somewhat but, maybe there could be recommendations to adhere to a secure consumptions model (i.e. S2C2F)?

prioritize the sourcing of software from suppliers and developers who also pledge to develop in conformance with the Secure Software Guiding Principles

Might be a bit too early but, have there been any recommendations yet on how to make the pledge or find others who have?

[jkmarz]

Should recommendations for operating production systems be added? With things like GitOps and Infrastructure as Code, many of the characteristics of operating productions systems are "developed".

Hmm, could this fit into the planned implementation guide in relation to Principle #5?

As far as consuming, the below speaks to it somewhat but, maybe there could be recommendations to adhere to a secure consumptions model (i.e. S2C2F)?

For sure in the implementation guide there will be specific mention of S2C2F (and other frameworks/resources/methodologies).

have there been any recommendations yet on how to make the pledge or find others who have?

Happy to take suggestions!! Initial thoughts have ranged from using PRs to add names to a list to submitting signed documents (with signatories reflected on website).

[zmanion]

Here are a couple minor suggestions. I haven't been tracking this carefully and these may be too specific to be principles.

To provide reasonable advance notice before ending security fixes.

To provide software (including security updates) securely.

[jkmarz]

To provide reasonable advance notice before ending security fixes.

To provide software (including security updates) securely.

I think these would be great additions to the planned Implementation Guide!

[SecurityCRob]

this has been published.