Security Controls for Open Sourcing your code. about open-source-logiciel-libre

[CalvinRodo]

@nschonni I agree.

This control is mainly for the comfort of my organization. But I may change it.

http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html#a2583316

That is an interesting read on Linus Torvalds opinion on signing commits.

I think it would be better if it was changed to signing tags.

So something like.

Signed Tags

Releases should be tagged and signed by a maintainer. This should ensure the source code is not modified after the fact.

[nschonni]

👍 the only one I think might cause hurdles is the "Signed Commits" since that might beyond casual contributions.

[nschonni]

That sounds like a good practice. Although I usually tell people that tags should be immutable, some people sometimes want to delete or force push them.

Maybe GoC X.0 plan will have the next Entrust replacement work as a Git signing key 😜

[CalvinRodo]

Yeah that's an issue for sure, the reason for signing is I've had comments from folks in our IT sec teams about the risk of hosting source code on a platform we don't control. There are concerns that a malicious actor could modify our code without our knowledge.

[LaurentGoderre]

The wording for the peer review seems to harsh. The point of code review is to ensure code quality, not to lay blame for bugs.

[gcharest]

In the latest version of the requirements, we're removing the security aspect as there are already existing policy instruments and will try to address/guide through the playbook instead.

Policy instrument (current document) should address the rules whereas the Playbook should provide all the required guidance and clarification for nuances to not create redundancies.

That's the intent so far. Happy to hear suggestions!

[gcharest]

Playbook

[CalvinRodo]

@LaurentGoderre good point, the goal isn't to spread blame but spread responsibility, so if someone is gone and there is a question about some code the reviewer should be able to answer it.

[LaurentGoderre]

Yeah, that makes sense.

[gcharest]

And we're actually going back with sections on Security as some of them are not necessarily covering specific topics found in the current discussion.

[keithdouglas]

There should also be a formal process to do periodic reviews just to ensure quality of commits, too. SCA is nice, but having external review by a security assessor or someone trained by one is likely a good idea.

[CalvinRodo]

There should also be a formal process to do periodic reviews just to ensure quality of commits, too. SCA is nice, but having external review by a security assessor or someone trained by one is likely a good idea.

@keithdouglas

So the idea would be to review some commits or to review the project itself?

I don't think external reviews are a horrible idea but am curious as to what they would be reviewing for?

Do you have examples of things that they could look for that say an automated process couldn't catch?

[keithdouglas]

@CalvinRodo : Both commits and the over-all stance of the project make sense to me. The idea would be to do little bits so the big picture is easier later.

As for external reviews: psychologists talk about what is called "confirmation bias". This is the very human weakness of only seeking evidence in something's favour rather than looking for disconfirming evidence too. The role of a security assessor in any context the way I see it is to help avoid confirmation bias - and that's why they are at arm's length.

As for examples: depends on the tool chain, but detecting vulnerabilities is an undecidable (in the sense of computability theory) process so having lots of different "ways to think about it" help. Specific examples where the tools tend to do badly are at boundaries between systems or processes, etc., things like weak or broken authentication, possible race conditions, ...

[CalvinRodo]

I think periodic audits of code quality by an external party is fine just as long as we don't make it a mandatory part of a release.

I can't think of a better way to slow down something then to bring in someone with little to no knowledge of the business or the context of the work to review every single line of code or commit.

[keithdouglas]

We've thought a lot more since my earlier remarks and are working internally on a more Agile version of the SA&A process. Note that regardless - the security controls for the project etc. is not really up to the dev teams at all - they can certainly go "above and beyond", but by the letter of the law (so to speak) IT security has to decide what is necessary (based on what business needs are present). We're working on a way to have these needs partially determined up front so they can be added to back log items immediately.

[LaurentGoderre]

@keithdouglas security can't block development practices that are universally recognized in the name of security. ITSec should focus on helping dev team improve security instead of acting as a gate keeper, especially since security is an ongoing effort, not something that only should happen at checkpoints.

[keithdouglas]

@LaurentGoderre, that's precisely why we want a version of the "business needs for security" to be started as soon as an Idea document or any other little piece of governance for the a project is available - thus reducing what is done at checkpoints.

As for "universally recognized", I agree, but provided it is done relative to the security stance of what is being developed. And for that one needs a risk assessment (and a background context) and hence also a security assessor to determine these.