FYI:

I reordered the items in
"Concise Guide for Developing More Secure Software"
<https://docs.google.com/document/d/16jUqTEFG-wscZUGR-NGa_3a81GF3YILtH9XgOSkLCTM/edit#>
to match the proposed order discussed in today's meeting.

I also made proposed tweaks to add the points made today (we should have something about
reviews of proposed changes, and there should be something about only adding components
when they need to be added). As always, you can see the proposed changes as "suggested" text.

Improvements welcome.

I *think* we're getting close.

--- David A. Wheeler

Is there a "getting close" point where a document like this transitions to better change control than Google Docs? Speaking as a Docs addict of course, but I imagine once the wild/crazy commenting/rearranging is done, and we're tweaking, being able to handle PRs and publish it at a semantically meaningful URL knowing it's not been silently updated would be a good thing.

Brian

--
Brian Behlendorf
General Manager, Open Source Security Foundation
bbehlendorf@...
Twitter: @brianbehlendorf

Yup, after the initial drafting flurry is complete the documents move to the GitHub repo. Cf. https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs

--V

--

VM (Vicky) Brasseur
Director, Senior Strategy Advisor
Open Source Program Office
Wipro Limited
⏰ Time Zone: Pacific/West Coast US

David

I have looked at both documents and whilst they are a great start, I am slightly confused as to their scope.

Is it the intention that the guides apply to all software (OSS and proprietary software) or just OSS? I have noted that there are some points which state 'if OSS'but this isn't consistent throughout the documents. I wonder if the documents should be structured so that the OSS specific points are separated from the more general principles which would apply to ALL software.

Is it worth considering that the documents should focus more on the 'What' and the 'Why' as these are probably more stable and less on the 'How' as the approaches for demonstrating compliance etc will be continuosuly changing. It may also help make the documents accessible to a wider community and not just the developer community.

Regards

Anthony Harrison

On Aug 19, 2022, at 4:34 AM, Anthony Harrison <anthony.p.harrison@...> wrote:

David

I have looked at both documents and whilst they are a great start, I am slightly confused as to their scope.

Is it the intention that the guides apply to all software (OSS and proprietary software) or just OSS? I have noted that there are some points which state 'if OSS'but this isn't consistent throughout the documents. I wonder if the documents should be structured so that the OSS specific points are separated from the more general principles which would apply to ALL software.

Both are *ONLY* for software developers. One is for all software developers, the other is only software
developers who are considering using OSS (which is almost everyone but the focus
is on what's getting used). Here are the details. I did propose a change in 1 of the documents
to clarify things.

The "Concise Guide for Developing More Secure Software" explains its audience in its opening sentence:
"Here is a quick guide for software developers for software development, building, and distribution."
Thus it's for developers of *both* OSS & closed source. However, I agree that a
little clarification would be a good idea.
To clarify this, I added a suggestion for the word "all" in front of "software developers".
I think we've done a decent job of keeping the specific recommendations
broadly applicable to developers regardless of license. See:
https://docs.google.com/document/d/16jUqTEFG-wscZUGR-NGa_3a81GF3YILtH9XgOSkLCTM/edit#

The "Concise Guide for Evaluating Open Source Software" is specifically for evaluating OSS
by software developers.
As far as the audience goes, it is specific to software developers as its first sentence explains:
"As a software developer, before using open source software (OSS) dependencies or tools...".
The title itself says it's limited to JUST evaluating OSS, not software in general; that applies
to almost all developers (practically everyone uses OSS components), but focused on evaluating OSS.
I don't think we can practically generalize further to evaluating all software.
At a high level all software risks are software risks, regardless of license.
but the information available for OSS (and thus how to evaluate them)
is typically radically different from closed source.
E.g., in closed source software you typically can't learn about contributors, merge rate, examine
source code, etc. Evaluating software with the same process, while ignoring most
data about a very common kind of software, doesn't really make much sense.
https://docs.google.com/document/d/19015o63pA-sZPBN5-R7I7Cg8ICPxo6fXH8vOI1RgBYM/edit#

Let's walk though & see what I mean (here "OSS only" means they only make sense if you're evaluating an OSS component for potential use):

* "Determine whether the project has earned (or are well on the way to) an Open Source Security Foundation (OpenSSF) Best Practices badge." - OSS only
* "Examine information on https://deps.dev, including its OpenSSF Scorecards score and any known vulnerabilities." - OSS only
* "Determine whether the package dependencies are (relatively) up to date." - OSS only, OR you have a complete SBOM. Today complete SBOMs are rare (though we're trying to fix that).
* "Determine whether there’s documentation explaining why it’s secure (aka an “assurance case”)." - while a closed source product *might* have an assurance case, it's rare to be able to get it as a customer.
* "Are there automated tests included in its CI pipeline? What is its test coverage?" - OSS only. Technically a closed source vendor might supply this information, but it's rare & impractical to verify.
* "Use SAFECode’s guide Principles for Software Assurance Assessment (2019), a multi-tiered approach for examining software’s security." - This is the first one that can be clearly applied to anything.
* "How do they fare per the OpenChain Security Assurance Reference Guide (the August 2021 guide and more recent draft are available)?" - OSS only
* "Do the developers take advantage of code hosting security features where applicable (e.g., if they’re on GitHub, do they use push protection)?" - Technically a closed source software supplier could provide that data, but it's almost unheard of. It's quite obtainable for OSS.
... and so on.

Is it worth considering that the documents should focus more on the 'What' and the 'Why' as these are probably more stable and less on the 'How' as the approaches for demonstrating compliance etc will be continuosuly changing.

It's already focused more on what & why, and not much on "how".
If we omit "how" we risk people doing something else that doesn't address the risk.

If anything this document lacks more "how"; we generally don't link to step-by-step instructions,
which developers will probably want.

That said, if there's a specific case you think is poorly handled, please point it out!

It may also help make the documents accessible to a wider community and not just the developer community.

I don't see how we can make these documents short, useful, and also applicable to
those outside the developer community.

Don't get me wrong, addressing other audiences is great.
But we *already* ask end-users to take absurd steps to try to compensate
for badly-written software. I suspect it'd be more effective to create separate
documents for different audiences.

--- David A. Wheeler