Risk responsibility

[loochy]

Departments want to hold someone responsible for each piece of code or software in case something goes wrong, and there is a responsible party. There are several ways to approach this, including:

1. Proprietary software: Whoever sold it is responsible. But black box/hidden code is not inherently more secure, and pointing the finger does not necessarily solve a problem.

2. Enterprise managed Open Source: Allows for free license with paid support. Also provides someone to be responsible, but has the same problem as 1, in that departments are tied to that service provider and code is not necessarily internally understood and optimized.

3. Internally managed Open Source: Training and supporting internal capacity that builds on a (volunteer) community for OS tools. Requires more department commitment, but means all code is internally understood and flexibility is maintained. However, blame doesn't go outside department.

Is the "point the finger" paradigm the best we can do? Internal capacity is required no matter which option is chosen to ensure best use of any software or tool. We do not need to be limited to option 1 or 2 for comprehensive security (contra what I have heard from some here at Open First day), and there may be many further possibilities.

[gcharest]

Thanks for this! Indeed, we need to better understand the need for finger pointing. I'll bring this for discussion at the Rules working group. Let's keep the discussion going here as well!

[gcharest]

Update: we are going to work with @ptd-tbs & her team from cyber to make sure this is covered.

[loochy]

Good to hear! It's a complex issue that needs proper expertise to work toward something better.

[keithdouglas]

Be sure that the "build it processes" include a software/application security expert and involve them early!!

[gcharest]

Yes, security should be a constant and your security experts should be part of the team throughout the journey, not a checkbox at some point in your process!