Guidance for managers

[ColinDaglish]

On the private to public guidance, and perhaps even on the general page, it would be helpful for line managers to have a bit of a guide for things that they should do before agreeing to sign-off a repo.

It is kind of included in the flow chart, but I think it could be easier to digest in bullet or checklist form.

Thinking like:

Things to consider in your risk assessment before going public

• How sensitive are the repositories outputs?
• What is your organisations risk appetite?
• What is the chance of sensitive information being pushed to the repository in the future (e.g. passwords, data, company secrets)?
• Were there any potential secrets stored within the repositories git history from when the repo was private?
• How confident are you in the quality of the code? - do you need to put some indicators on it, to manage users expectations e.g.

The minimal recommended steps

• [ ] I have considered my organisations risk appetite
• [ ] I have conducted a risk assessment on the repository identified ways to mitigate risks above the appetite level
• [ ] A colleague has peer reviewed my repository for sensitive or confidential information
• [ ] I believe the risks are already within tolerance, or I have implemented mitigations to bring it within tolerance
• [ ] A senior colleague has peer reviewed my risk assessment and mitigations and they agree it is within tolerance

[r-leyshon]

Great points made, thanks for this @ColinDaglish . Just a quick note to check if you've seen the fit for publishing checklist - it's a bit buried in reference item 3, half way down the page on the NHS website. We'll promote this a bit more in the next iteration. This checklist forms the backbone of the review. However, some of the points you have raised here are pertinent and not handled there, so we'll look at implementing your suggestion.

[ColinDaglish]

Yes, I think it'd be good if we could essentially replicate and reference that checklist, and put it right at the top, with a few amendments to make it more explicit.

• Fit for purpose (unless you are intentionally looking for help to make it fit for purpose)
• clearly documented instructions on how to install, run, and contribute
• No credentials, secrets, or personally identifiable information left in the repository (including it's history)
• No sensitive data should be stored in the repository. (It can be quite helpful to have staged dummy or synthetic data to speed up test execution)

[r-leyshon]

Really like the badge set you've linked to. Will pass links to the open source interest group for their consideration.