6 SCA tool trends to keep tabs on

In this blog post, we will share some of our views on the future outlook of SCA and associated tools in various categories. We list these categories in random order and briefly discuss our expectations and what could await us in the near future in terms of new capabilities.

Automation and scalability

The use of open source software (OSS) has increased over the last decade, and it is still increasing. Vendors and organizations see and embrace the OSS benefits of the rapid development of new products and features. With a larger OSS footprint, it is necessary to automate the process of compliance and the ability to flag security vulnerabilities discovered in the codebase. The SCA efforts should not slow developers down or break their workflow. There is automation already today, of course, but we believe this will expand to triaging vulnerabilities, fixing vulnerabilities, suggesting and even replacing alternative components in case of low health metrics or incompatible licenses, etc.

More OSS will also put higher demands on scalability. This is particularly true for larger organizations with many developers and large codebases. With tighter integration in the development processes and the build pipeline, scanning will be almost continuous across several codebases and repositories. SCA tools need to support thousands of developers using the tool simultaneously. 

Accuracy and reliability

The accuracy of the presented data and findings is probably the most crucial component. Many SCA tools struggle with accuracy, both in identifying OSS components but also in how they are mapped to vulnerabilities and licenses.

With too many false positives, alert fatigue will kick in, and potentially severe vulnerabilities might be ignored. Similarly, the same vulnerabilities could be left out in case matching errors lead to false negatives. Data accuracy is not only up to the SCA tool itself to handle, but it is also a community challenge to decide on the proper representation and encoding of data related to software, vulnerabilities, licenses, and other metadata.

With well-directed efforts backed up by authoritative organizations, the SCA tool can deliver reliable and actionable data, not only most of the time, but all the time. That could also eliminate the need to have a dedicated compliance team.

Artificial intelligence

Building on the previous, the accuracy of the matching and the proposed actions can be further improved using AI and machine learning. With huge datasets of vulnerability information and software, an AI model can be used to contextualize better and correlate different pieces of information. We have already seen how large language models can be used to find security vulnerabilities in code and how to exploit them. It is only a matter of time before similar capabilities will be seen at scale in the SCA domain.

Developer accessibility

Historically, security and compliance have often been outsourced to dedicated teams within an organization. Today, we increasingly see that such expertise, to a larger extent, is disseminated to the developers. This helps to avoid, find, and fix problems at an earlier stage, and a security mindset among developers will inevitably lead to more secure products. Similarly, SCA tools should be accessible to all developers and not just a handful of compliance and security experts.

Taking this one step further, we expect to see efforts to minimize the learning curve of using SCA tools and make them accessible to a broader range of users in any given organization. Not just developers. This will also require significant improvements to user interfaces and a better user experience, making the tools more intuitive and inviting.

Increased centralization of vulnerability data

Supply chain security, in particular in relation to open source software and its use in common products and even critical infrastructure, has received much attention lately. The Log4Shell vulnerability, found in an open source component widely used by Java programs, is probably the most severe ever. You can hardly read a blog post on open source security without the author finding a far-fetched reason to mention Log4Shell. Some even do it twice.

The number of vulnerabilities assigned to a CVE has increased significantly in the last few years. This has several reasons, but it can partly be attributed to increased centralization, not only that there are more vulnerabilities in software altogether. This is evident when you look at the CVE numbering authorities, which is steadily increasing. In 2020 there were about 150 of them. Now, there are about 300. Newly found vulnerabilities very often get a CVE identifier.

This increased centralization is good for accuracy and completeness. Let us hope that non-US countries also embrace this effort and that we can see more international cooperation in this centralization. But we do not really dare to make such a prediction. 

More stakeholders

Currently, the typical SCA tool user is an organization (or individual) that develops a product or a service. They are the entities that can fix vulnerabilities when they are discovered and can replace components with non-compliant licenses. At the same time, we are now seeing regulations that require that a Software Bill Of Materials (SBOM) is provided when a product is sold or placed on the market.

The SBOM will include all software that was used when building the product. With this, also the customer will be able to scan the product’s software for vulnerabilities and verify license compliance. This will help the actual users know exactly what vulnerabilities they are exposed to and take action to mitigate possible exploitations.

Maybe not directly offered by the SCA tool, but still, as a consequence of this, such transparency will make it easier to assess the vendor’s security practices. At least parts of it. With customer insight into the software, the vendors will be much more inclined to keep the software updated and to be very careful with licenses in all components.

Final thoughts

Looking ahead, Software Composition Analysis’s future appears to be promising and essential. With an increasing reliance on open source and the importance of software security, SCA tools will play an increasingly vital role in software development. 

The tools will become more sophisticated, and the solutions will become more comprehensive. Enhanced detection of vulnerabilities, easier and automated remediation, and seamless integration into development workflows will empower developers to address security and compliance risks.

With an SCA tool at your disposal, you will know that your supply chain is safeguarded, both now and in the future.