For any organization using open-source software, Software Composition Analysis is a must-have to identify security exploits. Read about the technologies driving this trend and the vulnerabilities databases that are aiding its adoption.
Presel Karthik, the Director of Technology Services at Encora, is among the accomplished Innovation Leaders who have presented Encora’s software engineering perspective on the top 10 technology trends for 2022.
Mr. Karthik spoke to us about the adoption of Software Composition Analysis (SCA), a rising trend that will help organizations reduce cybersecurity vulnerabilities.
What is Software Composition Analysis (SCA)?
The short answer is, SCA is an automated process that identifies the third-party components including open-source libraries that are used in software.
Two of the main uses are to evaluate if the product or the software that we are delivering adheres to the security and licenses, and to analyze the quality of the code.
Why is this trend on the rise?
One of the major goals for any software is time to market.
To build enterprise-grade or large-scale software, we can do it from scratch, writing one piece of code for every single model and every single component, which is a slower process. Alternatively, to achieve a faster time to market, you can leverage some libraries, bundles, or models that are already available as what we call FOSS, free and open-source software.
The advantages of leveraging open-source software are that we have something we can readily use, and we have many brains that contribute, which accelerates the process.
At the same time, using open-source software comes with its own challenges in terms of security. We cannot simply choose a library, integrate it into our software, and then release it to the public with the risk that it contains security vulnerabilities.
That’s where SCA comes in. It evaluates the security of the software so that we may take advantage of open-source software and improve our time to market.
How is SCA expected to shape businesses in 2022?
In the last couple of years, in response to the pandemic, what we have seen is the wide adoption of online transactions. COVID-19 and the consequent restrictions have pushed people to do more online. The urgency for digital transformation has had an impact on organizations’ speed to market. Businesses have shortened the development lifecycle to take products to market whether they are in chains, pieces, or versions.
These organizations, however, must be very careful about not leaking data or leaving space for any vulnerabilities or exploits. Every version of a product that is released must go through the SCA process for security purposes.
This trend is going to grow multifold in the next 3 to 4 years, in multiple industries that handle sensitive data like healthcare, digital commerce, and BFSI (banking, financial services, and insurance). Market researchers predict that the SCA market is expected to grow at a CAGR of 21.7% from 2020 through 2025 and we are already seeing it happen.
Give us a real-world example of where we may apply SCA.
Look at the popular content management system (CMS), WordPress. WordPress is often criticized for using outdated coding practices. Even now, there are a lot of outdated code and mixed coding styles. You have many different minds contributing to open-source software. But how can we be sure that the contributor has already taken care of all the vulnerabilities? It can be as simple as a cross-site scripting vulnerability or the password not being encrypted. Maybe I’m trivializing it, but it’s a nightmare of a problem to address.
One statistical data that comes to my mind is that out of around 4000 known vulnerabilities, 52% are from WordPress plug-ins. Those can include payment plugins, scheduling plugins, etc. And 37% of the known vulnerabilities are from the WordPress core itself. When the core itself has 37% known vulnerabilities, imagine how tight we must have security in place.
Tell us about your experience with SCA.
From my perspective, SCA is a must-have in the software development process. To give you an example, we built a custom test automation framework for one of our customers, and the framework leverages multiple third-party open-source libraries including Apache Tomcat.
During one of our release cycles, we found that Apache Tomcat version that was used had a vulnerability exploit and this was caught in the SCA process. We then upgraded the version of Tomcat and had to keep a close watch on when the security patch was released by Apache.
There are many ways to monitor if a specific FOSS library is vulnerable, however, one of the most prominent ways is to refer to the Current Vulnerabilities and Exposure (CVE) database. It's a non-profit organization that keeps track of all the vulnerabilities in open-source software. It’s a place where we can go and check for any new exploits that the forum has found.
How will SCA impact software in digital product engineering?
Let’s use OpenSSL as an example. You could choose to build your own SSL from scratch, but for enterprise-grade software that would take months. Or you can use OpenSSL, which is open-source software, but it comes with its own challenges, such as security vulnerabilities. Inevitably, we must check for all the vulnerabilities. This will depend on the size of the team and the product, but these vulnerability checks must be done quite frequently—daily, weekly, or monthly—and if we don’t check the software, we’ll expose the vulnerabilities to the world and vulnerabilities in popular open-source software are available in the public domain.
On the CVE website—the nonprofit database which keeps track of all the vulnerabilities for all the open-source tools—if you search for OpenSSL you will see all the vulnerabilities and exploits listed. You will also see which vulnerabilities are open and which are fixed. Anybody who knows about the vulnerability could exploit it.
Look at Magento Commerce. There is a model called Adobe Commerce Version that is used with Magento, and this model has a cross-site request forgery exploit (CSRF).
Say I’m a user browsing an e-commerce application that uses the Adobe Commerce Version. If I add products to my wish list and I want to share that wish list with my friend, my shareable wish list link can be exploited by anybody who knows about the CSRF. That person can add products to my shopping cart without my knowledge. They do not need to have authorization or my log-in credentials to access the application.
That example might not seem like a big deal, but these are small pain points that can create a poor reputation for the product and the business. When we think about the financial sector or the healthcare domain, imagine if an open-source model has a known exploit and a hacker gains access to that particular model and takes all the personally identifiable information (PII). That would be a huge liability for the business.
How will vulnerability detection impact the future of SCA?
SCA is a major part of the application security portfolio. From what we know, about 60-80% of an average application’s code is based on Open-Source Software (OSS) components and it is about 90% in new applications as per GitHub. This increase in adoption of OSS components leaves the door open for security vulnerabilities, putting the reputation of the software product at stake. These vulnerabilities when exploited by the hackers can cause huge financial losses to the organization.
Information about OSS components are scattered across hundreds of sources. There is no single source where we can find all vulnerabilities. Not all sources are credible or contain a complete list of vulnerabilities. Not all DB are easily searchable (though the Common Vulnerabilities and Exposures (CVE) database and the National Vulnerability Database (NVD) try to address this challenge).
Having said that, how can you get the control you need over OSS and ensure that the components used are safe?
As part of the SCA process, there are four essential items that will help to track OSS components in an effective way:
- Vulnerability Detection
- Vulnerability Management
- Inventory Management
- OSS License Compliance
Vulnerability detection is a primary and major step in the SCA process. The ability to discover OSS components with known vulnerabilities as early as possible is important because we are racing against hackers to fix all vulnerabilities. Zero-day vulnerabilities make things more complex as there is less time to fix them. There is an increasing trend in attacks exploiting these types of vulnerabilities and if you don’t know that you are using a vulnerable OSS component, then you are losing the game.
What role will code analysis play in the adoption of SCA?
The primary intention of SCA is to analyze the OSS component by detecting software licenses, deprecated dependencies, known vulnerabilities, and potential exploits in a codebase.
SCA works by stepping through the source code to create a package bill of materials (BOM). It does not necessarily perform code analysis per se. The BOM is a list of packages that are used to help create your applications. Then, it identifies the security vulnerabilities that are introduced due to the inclusion of those packages.
Depending on the tool that is used, you may get additional information. For example, if a vulnerability is attacker-reachable or if it is unlikely a potential security threat. If it is attacker-reachable, then it is an obvious high-priority fix.
SCA works best in the early stages of the development life cycle, and in many cases, it is bundled with Static Application Security Testing (SAST). SAST is the process to examine code to find software flaws and weaknesses, such as the OWASP Top 10, duplicate code, hardcoded credentials, etc. SAST is performed by analyzing the application’s source code or binary.
Since SAST is also best performed early in the software development life cycle, and against all source code files, it can be combined with SCA as soon as the code is ready to be pushed to the repository. This means that security-related issues can be identified early in development when the cost of fixing such issues is significantly reduced.
What are the challenges, obstacles, or risks involved in using SCA?
We have to keep a constant watch on all the software building materials or the manifest of all the software that is integrated into the system. It has to be an ongoing activity. That is where automation comes in, to help us continuously monitor databases that are available in the public domain, like the CVE database or the national vulnerabilities' database. I recommend having those monitored as often as every single day. Obviously, asking someone to sit and monitor that is going to be challenging. Automation definitely helps out.
Obstacles, I would say, are resourcing. A specialist is probably mandatory and should be added to the team.
When it comes to risks, if we don’t do it, I see that as a risk because we are potentially opening up vulnerabilities to bad actors.
If an organization wishes to implement SCA, how do they get started?
As I mentioned, it should be a part of the process already, but if it is not, and if the client, development team, product owner, etc. decides to introduce SCA as part of the workflow, they should imagine this as a stream of water flowing into a reservoir where there should be a floodgate to streamline all the water flowing in from different streams.
Just visualize that each stream of water is a third-party software or open-source software that we’ll be analyzing. Before any release happens, there should be a sign-off from an SCA team saying that all the third-party libraries have been tested, are verified for the versions, and verified for vulnerabilities, etc.
Outside this scenario, SCA can be integrated into DevOps, or depending on the size of the team and the size of the product, it can be a separate team that goes through all the security vulnerabilities. SCA can be part of a vulnerability assessment and penetration testing analysis. The most important thing is that you have to plan for SCA, and your plan really depends on the size of the team and the size of the product.
How can Encora help clients with the implementation of SCA?
Encora focuses on following the best practices in the software development lifecycle, and keeping our best practices evolving as new capabilities and challenges come up.
It’s about collaboration. We always make sure that our client is involved in the decision-making. So, when we see gaps in our clients’ product engineering or product development lifecycle, we bring those gaps to our clients’ attention and offer our recommendations on how to get a better handle on development and vulnerability scanning. We propose this as part of the development process itself and make sure at least basic security scanning is in place before we include any libraries or open-source software. Likewise, we wouldn’t simply go and pick any open-source library and include it. Our development team or SCRUM team performs an analysis on that particular library to determine whether it is the right fit.
When working with a client, if we see a frequent need for the integration of open-source or other third-party libraries, we would say, "Why don’t we set up a process or a particular piece in the development workflow, like, let’s have one dedicated person or let’s have the security team, or the DevSecOps team, go through all the scanning and review of the libraries as part of the release." This is just one way how Encora engages our clients.
A special thanks to Presel Karthik, the Director of Technology Services at Encora for speaking to us about the acceleration of the adoption of Software Composition Analysis (SCA).
To read more interviews, visit Encora’s 2022 Technology Trends.
"Two of the main uses of SCA are to evaluate if the product or software that we are delivering adheres to the security and licenses and to analyze the quality of the code.
This trend is going to grow multifold in the next 3 to 4 years, in multiple industries that handle sensitive data like healthcare, digital commerce, and BFSI. " -Presel Karthik
About Encora
Encora is a digital engineering services company specializing in next-generation software and digital product development. Fast-Growing Tech organizations trust Encora to lead the full Product Development Lifecycle because of our expertise in translating our clients’ strategic innovation roadmap into differentiated capabilities and accelerated bottom-line impacts.
Please let us know if you would ever like to have a conversation with a client partner and/or one of our Innovation Leaders about accelerating next-generation product engineering within your organization.
