In an earlier blog article last month, we talked about the top used open source projects from Census II report and security vulnerabilities in these projects. The exposure from using open source projects is real and certainly not insignificant. In this article, we will look at a companion report from Linux Foundation namely the “Improving Trust and Security in Open Source projects”. It offers good advice on how to deal with issues raised in Census II report.
“Improving Trust and Security in Open Source projects” is part of the Trust and Security Initiative (TSI) from Linux Foundation. It describes eight Best Practices with specific tasks supporting them that should be used by the open-source teams to secure the software they produce. It defines 3 levels of “security maturity” (I liked the term) as follows:
- Basic practices that everyone should do, regardless of the project type and maturity.
- Standard practices provide a higher level of assurance but usually require higher degree of overhead and therefore suited to more mature projects and teams.
- Advanced practices are designed for teams producing mission critical software or for teams wishing to use and / or demonstrate security as a differentiator
We will now take a high level view of the eight best practices below:
- Roles and Responsibilities – This defines the “who” of a teams security program. It essentially describes how each organization should assign responsibility for policy and technical security to individuals. The key message here is that everyone in the organization is made aware security is everyone’s responsibility.
- Security Policy – This defines the “what” of a teams security program. It essentially describes how each organization should publish a policy that describes, at a high level how the organization thinks about and intends to implement security.
- Know Your Contributors – This sections defines tasks so that organizations can trust those contributing to the project and so that consumers can trust the software was produced by well intentioned people. Fundamental aspects here are to verify the identity of all contributors and mandating strong authentication.
- The Software Supply Chain – This section describes how to lock-down the tool chain and verify that things flow across it. A basic requirement here is to accept PR’s (Pull Requests) only and these PR’s should require a peer review which includes security. Another basic requirement is to ensure that security issues are assigned immediately for faster triaging. A key aspect is to use Software Composition Analysis and assess dependent components for known security vulnerabilities.
- Technical Security Guidance – This sections addresses the much needed lack of technical security guidance prevalent today.
- Security Playbooks – The goal here is to define “how” to do specific security processes, specifically incident response and vulnerability management.
- Security Testing – This section describes various techniques and levels of security testing. Basic tasks include performing linting on all checkins to prevent developers from checking in secret keys or using vulnerable code.
- Secure Releases and Updates – This is the final practice but likely the most important for end users. One the most basic things is to define a security release criteria. Such a criteria should include processes that have been followed and results such as no high risk vulnerabilities.
If you are interested in a deep dive into these best practices, please read our eBook.
ThreatWatch provide capabilities that you can leverage to build and deliver secure software to your customers. DevOps SKU from ThreatWatch is specifically geared for this. Here is a quick look at the capabilities:
| ThreatWatch Capability / Feature | Mapping to Best Practice |
| Bill Of Materials | PST-10 |
| Report of security vulnerabilities in 3rd party (FOSS) components | SC-9, SP-2, PST-1 |
| Study SCA for any License compliance issues | PST-1 |
| Identify any outdated versions of (FOSS) components being used | SC-9 |
| Identify any secrets embedded in your source code | PST-1, SC-8 |
| Run CIS benchmarks to assess the security posture of your cloud (AWS/Azure/GCP) | MTSG-3 |
| Perform Threat Modeling by creating virtual assets in ThreatWatch | PST-4, PST-5 |
| Perform DAST for your web applications and portals in an automated manner | |
| Integrate with your CI/CD pipeline to fail the build on any policy violations (like presence of critical vulnerabilities, license violations, etc.) |
If you are interested in knowing more, please write to us at info@threatwatch.io