The 2023 Open Source Program Office (OSPO) Survey is live!
Help quantify the state of enterprise open source by taking the 2023 OSPO survey.
Keeping open source software secure is a community responsibility. But with millions of projects, it’s hard to pinpoint the right signal from noise—and find and fix the vulnerabilities that really…
Keeping open source software secure is a community responsibility. But with millions of projects, it’s hard to pinpoint the right signal from noise—and find and fix the vulnerabilities that really matter. Over the next few weeks, we’re sharing stories from open source maintainers on what it takes to secure the world’s software. Second up: a Q&A with Metasploit Framework.
An official maintainer of the Metasploit Framework, Spencer McIntyre works for a US-based technology company doing offensive security-oriented research and development. Previously at a consulting firm where he dealt with clients from multiple industries—including healthcare, energy, and manufacturing—Spencer is an avid open source contributor and Python enthusiast.
By number of exploit modules, the Metasploit Framework is the largest open source penetration testing toolkit. It enables security professionals to test for the presence of vulnerabilities, demonstrate their impact, and validate security controls within their environment. The project has been under development for over 15 years now and has seen contributions from over 800 users since joining the GitHub platform in 2011.
Penetration testers around the world use the Metasploit Framework to demonstrate attacker capabilities and recommend security improvements to their clients. Internal security teams at many Fortune 500 companies, as well as government agencies, use it to test and secure their infrastructure. While the Metasploit Framework targets a specific set of users—pen testers—developers still benefit from its use indirectly, by improving the security of their projects.
Just like any other software project, one of the largest security issues the Metasploit Framework faces is dealing with external dependencies. Any software project is going to have its share of security vulnerabilities, so we need to be able to monitor for those affecting our dependency tree and determine whether or not they impact our project.
Within the Metasploit Framework specifically, one of the unique challenges that we face is the need for our “payloads” to operate within highly constrained environments. To demonstrate that a vulnerability is present, and to show the risk of exploiting it, we often end up running a piece of software on the remote system that is a part of our framework. Because it might run in a variety of environments, this software can’t rely on the presence of any third-party libraries or even modern operating system environments. This often requires us to put in a lot of effort into maintaining compatibility, and security features are no exception to that.
The Metasploit Framework gives users and organizations of all sizes free and open access to attacker capabilities and enables them to test and demonstrate vulnerabilities. This helps organizations to better understand which vulnerabilities are exploitable within their environment, and thus focus their remediation efforts where they’ll have the highest impact. For developers specifically, there’s a growing trend in using complex infrastructure as part of the software development lifecycle (SDLC). The Metasploit Framework can be used as part of a CI/CD pipeline to test for common security vulnerabilities as part of existing development infrastructure, allowing developers to more confidently ensure the integrity of their projects.
Make reasonable efforts to limit the number of dependencies and select the ones that are used carefully. Follow best practices like performing periodic security checks and reviewing the configuration of any bundled components.
We recently started using Snyk which sends us a report periodically to help us be aware of issues that may be affecting our codebase. We also use GitHub’s integration with GPG to sign our merge commits, allowing us to attribute a contribution to a specific developer with write access.
We regularly update the majority of our dependencies using some automation tools. In addition to that, we use Snyk to monitor our dependencies.
We peer review code contributions and also use extensive automated testing to catch potential issues. In addition to unit tests in Travis CI, we use Jenkins to run some usage checks. With the recent announcement that we’re developing version 6 of the Metasploit Framework, we’ve taken strides in key locations to attempt to be “secure by default” in our development pipeline. So far, that’s manifested as changes to encrypt traffic by default where possible.
Want to learn more about open source security? Read about:
Check back in soon—we’ll be diving into open source security projects and sharing security best practices from open source maintainers over the next few weeks.