It was recently reported in a study that 96% of proprietary applications contain open-source components with an average 257 components per application. The numbers are relatively high because there is a common misconception that open-source packages are not easily vulnerable to exploits. Just making the source code publicly available, does not always guarantee a review. Having a large number of eyes reviewing the code can "lull a user into a false sense of security."
Given that open source components are a core part of a developer’s workflow, here are some best practices that you should consider when adopting an OSS library in your application. The list includes:
Build a security-first culture and enforce it.
An organization should focus on more than just putting developers and security together. It should also ensure that effective and efficient security practices are built into the core of the workflow. The best alert mechanisms and the best fixes can’t help when there are poor security practices to contend. This includes Vulnerability management
A case in point would be the Equifax breach, this breach was attributed to a vulnerable version of the OSS Adobe Struts. Even after the breach in 2017, organizations continue to download susceptible versions of the package even though a patch is readily available.
When it comes to DevOps, security discussions should take place early in the project and should ideally continue throughout the development of the software and even post-production. In case open source components are being used, the team should be responsible for tracking updates and applying security patches as they are released. Resources such as the following can help your team reliably track security issues:
- Open source vulnerability management tools https://resources.whitesourcesoftware.com/blog-whitesource/open-source-vulnerability-management
- Code analysers https://www.owasp.org/index.php/Source_Code_Analysis_Tools
The good news is that there are tools available to assist in evaluating and providing assurance for the security of the open source software. Black Duck and Sonatype Nexus are two such tools that provide enterprise-ready and end-to-end solutions for effectively managing the risk of open source software. That said, you should know that these tools do not provide immediate nor overnight fixes. They usually take time to integrate.
Keep track of security updates for dependencies
It can often feel like some part of your stack faces a security advisory or releases a new version every other week. While just critical vulnerabilities would require immediate attention, you may end up having to juggle many versions and identify which system is in need of an update and which already has a security patch.
The good news is that there are a few official, as well as private, resources you can use to help you stay informed on software lifecycle management. If you use these regularly, in addition to your in-house tracking tools, you will be able to keep your IT environment relatively secure and updated. There are three aspects you need to track:
Security Advisories
Most of the larger vendors publish a security advisory whenever they discover a vulnerability or when a new patch is publicly released. You need to follow the bug page closely or a better option is to sign up for an email notification whenever such an update is released.
For example, VMware has a security advisory page (https://www.vmware.com/security/advisories.html), and Microsoft does too (https://docs.microsoft.com/en-us/security-updates/). Additionally, vendors such as Trend Micro have a security advisory page that compiles a list of patches, security vulnerability announcements, etc. from many different companies in a single place.
The United States Computer Emergency Readiness Team or US-CERT also has an updated critical alert, vulnerability, and patch release website (https://www.us-cert.gov/ncas/current-activity). This covers a full gamut of platforms that are commonly used. In addition to email alerts, a number of these advisories also offer an RSS feed that you can choose to either bookmark or add to your preferred aggregate reader.
Version Tracking
Version Tracking has two essential parts – identifying the version applied where changes are underway, and logging which versions you are running on your servers.
Multiple websites can help identify specific build numbers and patch names for the standard software, operating systems, and hypervisors you use. You can also check the vendor websites for software you use for security alerts. You also need to keep track of which server is running which software version. For a small environment, a spreadsheet would suffice but could become unusable after a while.
Different software platforms help in software inventory and IT asset management. Some examples include – SolarWinds, Git, SVN, Mercurial, Helix, Microsoft Team Foundation Server, etc.
Knowledge Bases
If you need to learn about the specific features of a new software version, Knowledge Bases should be able to help you out. Just like security alert pages, a majority of large IT software providers have an online knowledge base. These KBs contain help articles, accounts of software updates and changes, support resolution descriptions, etc. Using a knowledge base, you can determine whether or not your new software is going to be compatible in your existing environment.
Use security tools to find security exploits in your packages
A large number of diverse Open Source as well as commercial tools have been developed over the years to solve the problem of identifying security vulnerabilities in Open Source components. Each tool or service attempts to solve this problem a little differently:
- Node Security Project (NSP) – The NSP is known mainly for its work on Node.js modules and NPM dependencies.
- Dependency-check –Dependency-check supports Java, Javascript, .NET as well as Ruby. It pulls its vulnerability information from the NIST NVD.
- Gemnasium - Gemnasium supports Ruby, NPM, PHP, Python, and Bower.
- Bundler-audit – Bundler-audit is an open source command line tool. This checks for dependencies focused on Ruby Bundler
- RetireJS – An open source dependency checker specific to JavaScript, RetireJS’ USP is its easy to use and highly efficiency. It contains multiple components including a command line scanner as well as plugins for Chrome, Firefox, Grunt, Gulp, ZAP, and Burp
- OSSIndex – OSSIndex is a tool that supports several different technologies. It adequately covers JavaScript, .NET/C# and Java ecosystems. It also provides API vulnerability for free.
- Hakiri – Hakiri is a commercial tool that provides dependency checks for Ruby and Rails based GitHub projects via static code analysis.
- Snyk – Snyk is a commercial service focusing on JavaScript npm dependencies.
- SRC: CLR – Source Clear comes with a load of plugins to several IDEs, deployment systems, and source repositories as well as a command-line interface.
Use OSS libraries that are in active development
In case of either expired libraries or libraries that no longer have active developer support and maintenance systems, a better idea is to build your in-house tools. If you’re aware of how the open-source ecosystem works, you should know that libraries that have an active maintainer receive patches and security updates. Sometimes, developers fork the repositories and the forked version end ups being the active one although the updates are not pushed to the mainstream.
You can use the above mentioned tools to monitor and fix security and similar vulnerabilities. Even if the initial cost and time spent might deter some organizations or their DevOps teams, in the long run, the functionality and reliability of an in-house tool can be an asset to both organizations and developers.
Test all your components
It is essential to deploy a testing mechanism to ensure that the application and all the related dependencies are secure. Since development teams continually add features to existing components and import new dependencies as they go, it's crucial that there at least some tests that can prevent severe threats like remote access vulnerabilities.
Be the first to comment