Why You Need to Think Differently About Open Source Security
Why You Need to Think Differently About Open Source Security
We need to think differently about open source security. Click to learn more about the open source component security challenges and how to address them.
Join the DZone community and get the full member experience.Join For Free
Fending off cyber-attacks is rapidly making its way up the ladder of concerns that face global businesses. In their 21st Annual Global CEO Survey for 2018, PwC found that cyber threats have risen to the top of concerns for organizational leadership, outstripping regulation as an issue facing their businesses.
This comes as the average cost of a data breach rose to $3.86 million, as reported by the IBM-sponsored “2018 Cost of a Data Breach” study by the Ponemon Institute, or $148 on average for each lost or stolen record.
While attackers are making use of methods like phishing and compromising networks, one of the biggest threats to organizations is that of vulnerabilities that are written into the code of their applications. In fact, 84% of attacks are reported to occur at the application layer, leaving far too many organizations open to high levels of risk.
Understanding the Risks to Your Open Source Components
While there is always the risk of a zero-day being used to target an organization’s applications, the greater threat is derived from known vulnerabilities, as outlined in OWASP’s Top 10 list of the Most Critical Web Application Security Risks.
For years, the rate of vulnerabilities published in the CVE Details database remained steady, but the number more than doubled in 2017 to 14,714 from the 6,447 vulnerabilities that were reported in 2016. The spike in the number of known vulnerabilities and the opportunities that they provide hackers with is believed to play a role in the number of new breaches being reported every year, adding to the security concerns of organizations that are developing software.
These known vulnerabilities are discovered by security researchers and reported to databases like the Common Vulnerabilities and Exposures (CVE) database, which is run by the non-profit MITRE Corporation. Then, they are analyzed and published on resources, like the National Vulnerability Database (NVD), so that the public can be alerted to potential exploits in their software and apply the required fixes.
As reusable software components can be used in thousands of products, open source components are a favorite attack vector for hackers who will commonly look to the NVD for information on which open source components are vulnerable to attacks and then use the reported exploits to target their victims.
Adding to that trouble is that far too many organizations simply are not prepared to defend themselves against these known open-source vulnerabilities. Many of the practices and technologies that they use for managing their proprietary in-house written code are not sufficient when it comes to working securely with their open-source components.
Addressing the Challenges of Open Source Security
Solutions for managing proprietary code, like SAST, DAST, and RASP, are generally ineffective when looking for known vulnerabilities in open source components.
While looking for flaws in the code that could lead to exploits, they often turn up far too many false positives, and more often than not, security teams will block scans of open source components because they are not able to manage all of the alerts. These scans are time-consuming and represent heavy lifting for overworked teams.
Organizations also struggle with keeping track of open-source components in their products and are unaware of which ones have known vulnerabilities. Keeping up with all the newly- published vulnerabilities in the NVD and elsewhere and matching them to what is relevant to a product can be a significant challenge for most organizations, especially at scale. This can lead to vulnerable open-source components either being added to their products or being left unaddressed post-deployment when they are discovered.
In order to contend with these challenges to managing their open source security, organizations need to turn to a dedicated tool that is capable of aggregating information from all of the various security resources, and checking them against their inventory of open source components to gain a full picture of which components are vulnerable.
Looking at the application security testing landscape, only Software Composition Analysis (SCA) offers the right features to secure open source components.
Advanced SCA solutions are capable of automatically identifying open-source components from the moment that a developer adds them to a repository or a product, creating a continuously updated inventory. This technology allows development and security teams to set and enforce policies specifically for their open-source component usage, preventing vulnerable components from entering their proprietary code at the earliest stages of development.
Shifting security checks to the left, developers can avoid painful tear and replace ops that might be required later in the Software Development Lifecycle (SDLC) when they are faced with a more serious time crunch before a release.
This technology also provides a solution for shifting right in dealing with newly-discovered vulnerabilities, tracking resources, like the NVD, and other security advisories to alert teams when the open source components in their products are found to be at risk, helping them stay a step ahead of hackers to implement the patches before breaches can occur.
Adopting the Right Tools for Using Open Source Securely
By providing the most up to date intelligence on new vulnerabilities, SCA solutions can give organizations the edge they need to implement fixes for their deployed products.
Securing your team’s use of open source does not have to be a heavy, complicated lift. Integrating SCA technologies can reduce friction between teams, allowing your developers to build great products faster without the need for security to be constantly looking over their shoulder, fretting about whether they are using open source components with known vulnerabilities.
If you want to stay a step ahead of the hackers, be sure that you are using the right solutions for the job, detecting vulnerabilities and keeping them out of your products.
To test-drive an open-source application security testing solution on your own, sign up for our complimentary trial of IBM Application Security on Cloud now.
Opinions expressed by DZone contributors are their own.