Open-Source Software Security: A Comprehensive Checklist For Founders (2024)

Because we’re a cybersecurity company, we pay close attention to the third-party devtools and packages we rely on while developing our own software. Even more so when it comes to open-source software (OSS).

You probably remember the Heartbleed bug that made the front pages ten years ago, in April 2014.

OpenSSL is an open-source implementation of the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols widely used to secure communications between clients and servers over the internet, most notably in https websites.

One of the features OpenSSL provides is the handling of “heartbeats,” small messages sent between machines to keep connections open even when no actual data is being exchanged. A heartbeat message includes a payload and the payload length.

In a vulnerable version of OpenSSL, when a heartbeat request was received, the server would read the payload length specified by the client and then send back a message containing the same amount of data as specified in the payload length field.

The critical flaw was that the server did not verify whether the actual length of the received payload matched the payload length specified in the request, which allowed attackers to specify a payload length larger than the actual size of the payload. This buffer over-read allowed attackers to steal information that, under normal conditions, would be protected by SSL/TLS encryption.

Of course the impact was catastrophic.

The Heartbleed bug occurred due to improper input validation of the payload length in the heartbeat message, and a more thorough code review could have prevented the issue.

This incident highlights the importance of rigorous OSS security practices in the development and maintenance of open-source software projects―to protect them from vulnerabilities, unauthorized access, and malicious activities.

Why OSS Security

OSS security is important because open source software plays a fundamental role in the modern digital infrastructure―powering everything from small websites to large-scale enterprise systems. Since open source code is often freely available, it is widely adopted across industries.

However, the same openness that makes open source software appealing also exposes it to significant security risks. Anyone can examine the source code, identify vulnerabilities, and potentially exploit them before they are discovered and patched by the community.

The widespread use of open source software means that vulnerabilities in a single piece of code can have a far-reaching impact.

The collaborative nature of open source development also implies that security is a shared responsibility across a diverse, global community. While this can lead to rapid identification and fixing of issues, in practice security is sometimes overlooked or insufficiently prioritized, especially in projects maintained by small teams or individual contributors.

Ensuring OSS security is key for maintaining trust in the open source ecosystem, however: developers rely on open source software with the expectation that it is secure and reliable.

OSS security involves securing the code itself, the dependencies (libraries, frameworks, etc.) that the code relies on, and the overall software supply chain: it’s a tremendous, sometimes intimidating, task. To help you get started, we’ve compiled a list of 6 best practices for securing open-source software projects.

1. Regularly Update Dependencies

Dependencies are the software libraries, frameworks, and other devtools your project relies on. They often have their own sub-dependencies, creating a complex web of interrelated software that makes it hard to keep up.

When a vulnerability is discovered in a library or framework, the maintainers usually release a patch or an update to address the issue. Regularly updating dependencies is key to protecting your software from known vulnerabilities. But it’s also up to you to make sure the update is not going to break your system―don’t auto-apply updates! (e.g the recent Crowdstrike incident)

Hackers exploit outdated dependencies as a way to gain unauthorized access to systems, so the longer a vulnerability remains unpatched in your dependencies, the higher the risk of an attack.

• Automate dependency management - Use tools like Dependabot to automatically check for and notify you of new updates to your dependencies. These tools can often be configured to automatically create pull requests when a new version of a dependency is released to simplify the update process.
• Use dependency scanning tools - Dependency scanners monitor and analyze dependencies for known security vulnerabilities.
• Regularly review and test updates - Establish a routine schedule for reviewing and applying dependency updates. This could be part of your sprint cycle or a dedicated monthly task. Before applying updates to your production environment, ensure they are tested thoroughly in a staging environment to prevent any unexpected issues.

2. Conduct Thorough Code Reviews

Code reviews serve as a first line of defense against introducing security vulnerabilities in your open-source software.

Without a rigorous review process, it’s easy for subtle bugs to slip through unnoticed.

Code reviews also provide an opportunity for knowledge sharing and skill development within the development community. When experienced developers review the contributions of others, they can provide valuable feedback, suggest best practices, and help less experienced contributors learn how to write more secure code.

By consistently applying high standards of security and quality, the project builds trust among its users.

Define and document a clear code review process that every contribution must go through. This process should outline who is responsible for reviewing code and the criteria that will be used to evaluate contributions (e.g test coverage) to enforce consistency and prevent vulnerabilities.

3. Implement Automated Security Testing

While manual reviews are crucial, automated tools can analyze large codebases for known vulnerabilities and provide reviewers with a starting point for their manual analysis. Integrating these tools into your continuous integration/continuous deployment (CI/CD) pipeline can help catch issues early in the development cycle.

• Integrate static and dynamic analysis tools - Static analysis tools examine the code without executing it, identifying potential vulnerabilities such as insecure coding practices, buffer overflows, and unhandled exceptions. Dynamic analysis tools, on the other hand, test the running application, simulating real-world attacks to uncover vulnerabilities that might not be apparent in static code analysis.
• Adopt security monitoring - Security monitoring is the ongoing assessment of your codebase and environment for new vulnerabilities and threats. By setting up automated alerts and reports with tools like GitHub’s Dependabot or other similar platforms, you can stay informed about potential security issues in real-time.
• Document how to run and write tests - Ensure that your automated security tests are well-documented and easy to run locally. This documentation should include instructions on how to set up the testing environment, run the tests, and interpret the results. Also provide guidelines on writing new security tests, including best practices and common pitfalls to avoid.

4. Set Up a Vulnerability Disclosure Program

A VDP provides a structured process for external parties like security researchers, developers, and users to report security issues responsibly and efficiently, before they can be exploited by malicious actors.

The likelihood of discovering security vulnerabilities increases as more individuals look into your code. However, without a clear and structured way to report these vulnerabilities, issues may go unreported or be disclosed publicly without a chance for remediation.

• Define a clear reporting process - Start by establishing a clear and easy-to-follow process for reporting vulnerabilities. Include a dedicated communication channel like an email address (e.g., dante@onboardbase.com), where reports can be submitted. Ensure that the contact information is easily accessible on your project’s website or repository. Provide guidelines on what information should be included in the report like a description of the vulnerability, steps to reproduce it, and the potential impact. Make it clear that reports should be treated confidentially until the issue is resolved.
• Establish a response and remediation workflow - Once a vulnerability is reported, it’s crucial to have a predefined workflow for responding to the report and managing the remediation process. Assign a security team or designated individuals who will be responsible for triaging and validating the reported vulnerabilities. This workflow should also include steps for patching the vulnerability, testing the fix, and deploying it to the affected systems. Consider creating a public timeline for the disclosure process to keep the community informed while maintaining transparency.
• Encourage responsible disclosure with incentives Not everything can be disclosed in a public Github ticket, so be mindful of sensitive information. Consider offering incentives for responsible disclosure: this could range from recognition in a “Hall of Fame” on your project’s site to monetary rewards through a bug bounty program, depending on your project’s resources.

5. Use Cryptographic Signing for Releases

When software is distributed without a digital signature, there is no straightforward way for users to confirm that the code has not been altered by a malicious actor. This lack of verification opens the door to the distribution of malware under the guise of legitimate software.

By digitally signing software releases, developers can provide a guarantee of integrity and authenticity, allowing end-users to verify that the code they are downloading and installing has not been tampered with and is indeed from a trusted source.

A signed release uses cryptographic keys to create a digital signature that is unique to the code in that release. If any part of the code is modified after signing, the signature becomes invalid, alerting users to the potential tampering.

• Choose a strong cryptographic algorithm and key management system - Use robust cryptographic algorithms like RSA or ECDSA (OpenPGP) to sign your releases. The choice of algorithm should balance security and performance, keeping in mind the need for strong encryption that resists current attack vectors. Don’t forget to have a secure key management solution like Onboardbase to protect your private signing key.
• Add signing into your release process - Integrate the signing process into your continuous integration/continuous deployment (CI/CD) pipeline. Popular CI/CD tools like Jenkins, GitLab CI, or GitHub Actions offer plugins or bash scripts for this.
• Encourage users to verify signatures - Provide clear instructions and tools that allow users to check the validity of the signatures before installation.

6. Ensure Secure Configuration Management

Security misconfigurations concerned 208k unsecure websites tested by OWASP (4%).

Secure configuration management is about maintaining and enforcing secure default configurations across all deployment environments―development, staging, production, etc.

Configurations dictate how software behaves in different environments. These settings can include anything from database connection strings, API keys, encryption keys, to user access controls. Most open-source software require some level of configuration to function correctly.

If these configurations are not securely managed, they can become weak points that attackers can exploit. For example, leaving debug mode enabled in a production environment could give an attacker easy access to sensitive data.

• Adopt Infrastructure as Code (IaC) practices - Implementing IaC allows you to manage configurations in a version-controlled manner, similar to software code. Tools like Terraform, Ansible, and AWS CloudFormation ensure that configuration changes are tracked, auditable, and can be rolled back if necessary.
• Regular configuration audits - Schedule periodic reviews of your environment configurations to ensure they adhere to security best practices: use of strong encryption, disabling unused services, verifying that default credentials are changed, etc. Automated tools like OpenSCAP can assist in identifying misconfigurations and vulnerabilities.
• Don’t underestimate secrets management - Use dedicated tools like Onboardbase to manage and store sensitive information like API keys, passwords, and certificates to prevent hard-coding secrets into configuration files. Secrets management solutions provide secure storage and control over who can access sensitive data, as well as useful monitoring tools to prevent leaks. Check out our guide on using Terraform with Onboardbase for configuration management.

Conclusion

Securing open-source software is an ongoing process. Whether you’re actively developing open-source software or simply using OSS, you’ll get solid foundations for securing your software by following these six best practices. Still, it’s not an end in itself.

A solution like Onboardbase is important to manage your encryption keys and configurations securely while benefiting from advanced monitoring and alerting features in the event of serious threats originating from open source software.

What’s more, we love to talk about security, new threats, and how to protect your software. If you have any questions or need help, don’t hesitate to reach out in our Discord!