Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technical/procedural improvements #5

Open
jimmo opened this issue Jan 1, 2021 · 5 comments
Open

Technical/procedural improvements #5

jimmo opened this issue Jan 1, 2021 · 5 comments

Comments

@jimmo
Copy link
Member

jimmo commented Jan 1, 2021

The fact that the source code for COVIDSafe was released on GitHub was a big step, and then later that the repositories could be used for raising issues and pull requests.

What suggestions do you have for similar technical and procedural innovations that should be part of all government projects going forward?

@jimmo
Copy link
Member Author

jimmo commented Jan 1, 2021

Here are some of my suggestions (mostly based on COVIDSafe):

  • Source code for all projects (i.e. the COVIDSafe server), including full commit history
  • Implement an industry-standard security disclosure procedure (e.g. https://disclose.io/)
  • Implement a bug bounty process (e.g. https://bugcrowd.com/
  • The DTA should become a CNA
  • All source code releases must include additional components such as test servers, unit tests, build environment, etc.
  • Supporting technical documentation, including design and research
  • Source code must be available before initial launch, with appropriate time for public review
  • Share engagement and usage metrics (in as much detail as privacy allows)
  • Do open source properly (i.e. use sensible open source licenses)
  • Use GitHub effectively (i.e. use forks and submodules correctly rather than copying code)

@vteague
Copy link
Member

vteague commented Jan 1, 2021

100% Agree. And the 'sensible open source licenses' would imply no more discouraging terms and conditions such as asking people to repay the cost to suppliers arising from their access to the code.

@mukeshtiwari
Copy link

@jimmo I would like to add one more point to this discussion that if a software program is used by government in decision making, then it should be formally verified. It may seem too much, but it will ensure that the software program has no bug, and every single decision is taken based on "correct" output. It would eliminate the bug bounty process (but I am in favour of it because sometimes specifications are not very strong). Moreover, it will help Australia in developing a capability in formal verification, which has already been shown in seL4 project.

@sarafalamaki
Copy link

Formal verification is quite difficult, and there are a lot of programs used by governments. It'd be good if they at least open source them. The problem is that almost all programming work in NSW gov is outsourced, and in many cases, the government doesn't own or have access to the source, or the competence to change it or even publish it.

@yaakov-h
Copy link
Member

yaakov-h commented Jan 2, 2021

In addition to @jimmo's points, I'd also like to see open publication of full documentation, methodology, and data for any manual user acceptance tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants