Important to a project’s overall success and impact is its documentation. Keeping an accessible and public record of a project is imperative to attracting new users and contributors and shortening the amount of time spent adapting to its use and function. From the point of view of security, your project should publicly document its vulnerability disclosure policy. Most commonly, this is done via the previously mentioned “security.md” file (see here).
Documentation that is current needs to detail the function and safe usage of a project, its security disclosure process and goals, and name all third party tools, libraries, and projects utilized. It should be easily read, well defined, and outlined in a way that promotes its usage to eliminate burden on users, developers, and maintainers. Ideally, documentation should be available at locations easily accessible to users such as on any relevant websites and project repositories. Accessible documentation prevents misuse of projects and promotes proper and secure function.
Creating a Statement Bill of Materials (or “SBOM”) can be a great opportunity to outline and manage aspects of software in a manner that is easily shared and understood. Being transparent about your organization’s supply chain provides context for users to make educated decisions about how they can securely utilize software. Simultaneously, maintainers can utilize SBOMs to help build and manage their software’s compliance while users can track dependencies and supply chain security risks.
- Update Documentation
- List of third party libraries in project
- List of tools, security practices, goals, etc
- List of access privileges
- Create SBOM (if relevant)
- Utilize OS tools like https://github.com/awesomeSBOM/awesome-sbom to determine if a SBOM is right for your organization
| Back | Next |