When the University buys IT services from a commercial supplier, there is typically an agreement placing certain obligations on the supplier to ensure security of the services. If the University obtains OSS under such an agreement there will usually be some level of assurance regarding the maintenance and security of the software. Where software is available free of charge, there may be no such obligation to maintain the code.
If you are considering using software that does not come under such a contractual agreement, you should address the following:
Distribution packages. On open-source platforms such as Linux, the software may well be packaged and supported as part of a major distribution. Consider whether it’s feasible to use that rather than a standalone installation – while not always suitable, it can make maintenance far easier. Further considerations when using an OSS distribution are given in Appendix A.
Due diligence. Choose tools and applications that are well maintained, with active and reliable developer communities. When you intend to use software in critical systems and for confidential information, use our checklist to assess its suitability.
Vulnerability management. Unless fully supported through a distribution, ensure that you monitor public and community vulnerability feeds and ensure updates and security patches are applied promptly. OSS vulnerabilities are not always well reported and so you should include developer fees in your monitoring.
Dependency management. Managing dependencies outside of a distribution can be challenging. Minimise and track dependencies and avoid code fragments and multiple code versions.
Treat OSS as code. Above all, treat OSS as code you have written. You are responsible for ensuring that the code is secure and that good secure development practices are in place, such as vulnerability scans and code reviews before deployment. If you rely on the developer community to do part of the job, ensure you have done appropriate due diligence using our checklist.