Repository navigation
Pattern idea: Secure InnerSource #369
Description
A question came up in Slack about how to practice InnerSource in a secure way.
I am summarizing the conversation here, removing any names of people/companies to comply with Chatham House Rule.
The question was:
My company is trying to adopt an InnerSource model.
Our security team is not comfortable with opening up source code internally. They are worried that it would lead to code leaks.What should we do to reduce the associated risk?
Definition code leak in this context:
A bad employee may get the code and expose it on the Internet.
This could negatively impact company branding or have other negative impacts on the company, depending on what was leaked and the industry the company is in.
Naming ideas for a possible pattern
- Secure InnerSource
- Security and InnerSource
- Satisfying Security Concerns
- Addressing Security Concerns
- Security Concerns and Mitigation
- Working with Security
- Security and Transparency
- Security and Discoverability
- Secure Discoverability
- Discoverability in a Secure Way
Reacted by Mishari Muqbil
Activity
spier commentedon Nov 24, 2021
Solution 1 - RBC
(not from the Slack conversation)
This talk from GitHub Universe 2021 is mentioning this topic:
Making InnerSource & Developer Experience Real at one of Canada's Top 5 Banks - by Anthony Vacca, Sr. Director, OSPO & Developer Experience
They could not make all repositories public inside of RBC (i.e. they could not make them all available as InnerSource).
To solve for these constraints, they created an internal public InnerSource org with only 3 rules that they negotiated with their Security Team are:
spier commentedon Nov 24, 2021
Solution 2
That is usually a concern, and here is where InnerSource has a trade off.
To mitigate and reduce the risks what you could do:
Keep in mind that number 2 will likely have an impact on contributions due to the additional step to access the code.
We do only 1 at our company.
spier commentedon Nov 24, 2021
Solution 3
We differentiate between multiple sharing levels depending on the nature of the code in the repository:
For restricted source, we use a tool that automatically adds the
README.mdand some other meta data to an internal repository in GitHub, allowing the GitHub search feature to include this data in the search results. Note: This is similar to Solution 2, point 2 above.Phrased slightly differently
Problem
Balancing openness versus preventing code leak
Solution
Define multiple confidentiality levels with associated policies, including sharing level in the SCM:
spier commentedon Nov 24, 2021
Solution 4
Our company just started an InnerSource experiment recently.
Below are our practices to mitigate the concerns of the security team:
From my experience, security is usually in conflict to the transparency on information, but the importance is its relative balance. If we make the repositories more transparency, simultaneously we can place more security measures to protect the repositories from other angles like access control, monitoring, detection.
The rationale behind all of this:
There are always security concerns related to sharing more information within an organization. Ii is almost impossible to remove out all the concerns. What we can do is to mitigate the concerns through technique, policy, process and communication (the most important part).
Therefore when naming a pattern about this, I would call it "Security concerns and mitigation". I like the term “mitigation” in the name to cover any possible solutions towards the concerns.
bartgolsteijn commentedon Nov 24, 2021
How about Addressing Security Concerns as title?
spier commentedon Nov 24, 2021
Also nice! I added it to the list above.
When turning this into a pattern, we can use any of these as a working title to begin with. Then when the pattern is ready, we can reevaluate and change the title, depending on what fits the content of the pattern best.
Would that approach work?
lenucksi commentedon Nov 26, 2021
A lot of what I see here is basic good software engineering practices, such as "don't have unprotected secrets in repos".
Another part of open/innersource/restricted with a very good reason including "try hard to fix the reasons for restriction" I have seen in working already.
And I find the inclusion of checks into CI/CD pipelines and the inclusion of the security experts early on to be a good idea. In case of publication you likely want a check of what you publish anyway.
Nice collection. Looking forward to see where it goes.
spier commentedon Nov 26, 2021
Thanks for the input @lenucksi .
What did you mean by the sentence below? I think there is some word missing.
mishari commentedon Jan 10, 2022
When talking about security, it's useful to frame discussions around confidentiality (maintaining secrets), integrity (no unauthorised changes), and resiliency/availability and the wording of the pattern should address these issues specifically.
My 2c on this pattern:
spier commentedon Jan 10, 2022
Good idea to explain more specifically what is meant when we say "secure" @mishari!
I think we might have a first version of this pattern ready soon, that we can share as a PR.
Let's work in your input then.
Initial commit of 'Secure InnerSource' pattern. Implements #369.
Initial version of the 'Balancing Openness and Security' pattern (aka…
spier commentedon Jan 22, 2022
hi @mishari . I just remembered your comment above about this pattern.
We have not fully worked in your feedback into the pattern yet.
As a matter of fact, I think we have only integrated point (2).
For your description of how GitLab is approaching this topic, we could try to get somebody from GitLab in the ISC Community to improve this pattern directly. What do you think?
For the other points, do you want to check where in the pattern (now called Balancing Openness and Security) those could be integrated, and send a PR for the same?