Remove risk management that isn't unique to open source

[konklone]

This section on risk management:

Never at any time should configuration information such as IP addresses, etc. be published to the public. An organization's open-source plan will need to specifically address what tools and procedures will be employed to create and manage risk associated with the public branch of the code. Here are specific areas to pay attention to when determining what comprises the public branch of the code:

• Physical configuration - including items behind reverse proxies firewalls
• Code logic - this includes logic and/or business rules that are not for public consumption. For example, no hard coded rules that would expose information that is not appropriate for the public. Another example is hard coding an item that requires elevated access to view.
• Code and Data - the code must be scanned and virus-free. There should be no vulnerability that would create a loophole. For example usernames, machine names, keys, passwords should not be revealed in the code or in the data. Careful attention must be paid to not release PII information to the public.
• Consistently track all the software libraries and versions that are utilized in the environment. This way when a vulnerability is discovered there is one source to go to see what areas of the project could be affected
• Establish a security audit process ensuring the code is free of security errors such as inadequate buffer protection, poor input validation, session management problems, etc.
• Coding standards must be developed to assure implementation consistency and streamline review processes
• Operations scanning - security scanning can be inherited from traditional security review processes

The last 4 items are all things that should be done for all code, not just open source code. By including them as part of an "open source framework", it implies that open source code has a higher need for security and quality review than closed-source code, which is not the case. I'd go so far as to say that a closed-source code base should be managed as if it is open, to avoid making security decisions that depend on the code or business logic remaining a secret.

Instead, I would focus on the security issues that are more specifically relevant to open source, such as separating private configuration details (e.g. passwords or API keys) from public business logic.

[alfred-ortega]

I agree that these items should be done for code regardless of whether or not it is open source. However github's documentation (https://help.github.com/articles/remove-sensitive-data/) also states that sensitive data should be removed and explains how. So to me this is just a reiteration of good practices not an implication of higher requirements for open source. If our code is going to be out in the open then a reminder of policy and secure thinking is a good thing in my book. Common sense isn't so common and it's better to remind folks then discover a leak later. :-)

http://blog.nortal.com/mining-passwords-github-repositories/

http://www.securityweek.com/github-search-makes-easy-discovery-encryption-keys-passwords-source-code

[konklone]

If our code is going to be out in the open then a reminder of policy and secure thinking is a good thing in my book. Common sense is so common and it's better to remind folks then discover a leak later. :-)

Totally. One easy way to get both done is to interrupt the list before the last 4 and add something like "And as a reminder, the same things that make closed source secure also make open source secure:" and then continue on.

[pammiller0]

@konklone @alfred-ortega got it and totally agree. I will segment the list into general reminder for all coding and the above items that are specific to open source. Thanks!!