Open Source Software Security Risks and Best Practices

Enterprises are leveraging a variety of open source products including operating systems, code libraries, software, and applications for a range of business use cases. While using open source comes with cost, flexibility, and speed advantages, it can also pose some unique security challenges. Given that open source components may be present in up to 96% of commercial applications, how can you be sure that your software is secure?

We asked two members of the Cloud Academy Content Team— Logan Rakai, our DevOps specialist and Stuart Scott, our specialist in all things security—to share their tips for helping keep your open source components secure.

What makes open source components so vulnerable to security risks?

The short release cycles of some open source projects can be difficult to keep up with. On the plus side, new features and patches get deployed sooner rather than later. However, auditing every release can be someone’s full-time job, and by the time you’ve managed all the issues in one release, another one is ready. Flavor-of-the-week open source frameworks are a security nightmare and while having an automated system to scan for the latest updates will help, it’s not a failsafe that can identify all of the issues.

With such a wide base of users to test the software, spot potential bugs, and security flaws, open source software (OSS) is often considered more secure. However, when it comes to catching and fixing security issues, simply having more eyes on the problem isn’t enough. Security problems require security expertise and not all developers are security experts. They may know enough to try and implement certain fixes, but this can create a false sense of risk mitigation. More advanced topics like cryptography, for example, further narrow the field for those who can review code for such security flaws.

Dependencies in open source projects allow some vulnerabilities to fly under the radar. Projects that include unknown third-party libraries pulled from package managers may be passing on vulnerabilities that aren’t easily visible. Many developers pin version ranges to ensure future patches are available. However, a dependency that is several projects removed may be more difficult to notice in the first place, and is more likely to be an attack vector that can be exploited.

What can developers and DevOps teams do to better secure open source components?

Treat everything as code, including compliance. Doing so will help ensure that known regulations including those for the payment card industry (PCI) or healthcare (HIPAA) information privacy are followed. This will also make it easier to ensure that patches are universally applied.

Embrace automation. Staying up to date on vulnerabilities logged in online sources such as the National Vulnerability Database or postings on project home pages is necessary, but also time consuming. Put some frontline tools in place to help catch the obvious things (there are some great commercial and open source Dynamic Application Security Testing (DAST) solutions available) and employ monitoring tools to keep up with what’s happening in real time. Tools such as SumoLogic are great and serve as a modern alternative to a Security Information and Event Management (SIEM). At a minimum, static code analysis must be part of the CI/CD process, which provides automated, early detection of security issues to complement peer reviews.

Bring developers and security together. Enlist your security teams to train developers to drive thorough understanding of security and the latest trends. An initial secure coding workshop held in partnership with the security team is a great way to kick things off. Invite them to design reviews and include them in sessions when high-risk changes are being made.

Build a security-first culture. Your organization must focus on more than just bringing developers and security together, but also ensure that effective security practices are built into everything you do. The best fixes and the best alerting mechanisms in the world cannot resolve poor security practices. The Equifax breach for example, attributed to vulnerable versions of the open source software Apache Struts, is a case in point. Since the well-publicized breach in 2017, companies are still downloading the vulnerable versions of the package despite the fact that a patch is available. (The patch was also available two months before the Equifax breach and has been issued multiple times since.) In DevOps culture, security discussions must happen early and often throughout the software development lifecycle and beyond. If you’re using open source components, it’s your responsibility to be aware of the updates and to actually apply them yourselves.

Fortunately there are tools to help you evaluate and provide confidence around the security of the open source software you are using in your applications. Two tools that provide enterprise-ready end-to-end solutions for managing open source risk are Black Duck and Sonatype Nexus. Note that these solutions are not overnight fixes and will take time to integrate.

There are also free tools for assessing the risks in open source software and containers. Many open source software packages utilize free static analysis scanners and the results are available for everyone to inspect.

Coverity Scan provides free deep scans of open source software that include the Common Weakness Enumeration (CWE/SANS) Top 25 vulnerabilities. Many projects trust Coverity Scan, including the Linux kernel and Apache projects such as Hadoop. You can find them on the project page.

If you aren’t comfortable with the risks identified, you might consider using alternate software or versions. Similarly, if you are using Docker containers in your DevOps practice, you can take advantage of Docker Security Scanning results of official images hosted by Docker and use the same technology to scan your own private repository images.

Cloud Academy