So, you have decided to take the plunge and implement a tool for Software Composition Analysis (SCA). This is a big step toward improving the security of your applications and the security posture of your organization as a whole. Congratulations!

Or maybe you’ve never heard of SCA, but you’re curious what it is. A Software Composition Analysis (SCA) tool is a software tool used by developers and security teams to identify and manage the use of open-source and third-party components within their software applications.

Either way, while deciding to implement an SCA tool is a necessary and significant first step, it is easy to be overwhelmed by the sheer volume of choices in the market. Not only do these options vary significantly in their pricing structure, but they also have feature sets with varying degrees of overlap from one tool to the next.

Some questions that may come up in the section process might be:

• If there are free options available, should we pay for a tool?
• Can we build our own tool?
• How do we know which features are important and which we can live without?

In this blog, we’ll tackle as many of these questions as possible.

Build vs. Buy

The first key decision to make is whether to go with a homegrown solution or to leverage a third-party tool built for this purpose. Each choice involves some measure of trade-offs, so we recommend a thoughtful approach incorporating your current infrastructure, the maturity of your security initiative, the typical workflow of your developers, and financial considerations. I compare these two options below.

Option 1 – Build Your Own

Most modern package managers like Nuget and NPM have their own built-in utilities for identifying vulnerable dependencies. These can be extremely useful for pre-commit spot-checking by individual developers.

But, what if you desire to centralize and enforce review of any findings produced by the tool? What if you want to automate the scan and results archive in a CI pipeline? These goals often involve custom code to run the corresponding scan, parse the results, and then get them into some format and system that is visible to the entire team. What if you need finely-tuned access controls around who can see and interact with the results? It’s easy to see how this effort could snowball into something much larger than originally planned.

Custom-built tools can be a good option if you have a dedicated (and experienced) security engineering team, and the results can be highly customized to your environment. However, for organizations that do not have a security engineering team, this level of effort is going to be difficult or impossible to justify.

If security tool engineering is not a core competency that you wish to grow within your org this could even distract your developers from more valuable work streams. It is wise to carefully consider your goals before making this decision.

Option 2 – Use a Purpose-Built Third Party Tool

Using a purpose-built tool designed for SCA can be a more palatable option, particularly if the development team will also be the team managing the care and feeding of the chosen platform. The options available range from free and open-source software (FOSS) tools like OWASP Dependency Track to enterprise-grade tools costing thousands or hundreds of thousands of dollars depending on the size of your implementation.

Open source options are indeed free in terms of up-front dollars, but there is still some measure of engineering involved in standing up and maintaining the infrastructure for an on-prem or cloud-based deployment. This infrastructure will naturally require an ongoing investment both to pay for the infrastructure and to pay engineers to make sure patches are applied, vulnerability databases are updated, etc. For smaller teams, the cost of this ongoing maintenance may be greater than the cost of using a paid solution, so you will want to consider the pricing structure of paid solutions alongside the price of your own engineering resources.

In terms of paid options, the variety of tools and range in pricing can actually help guide you toward a decision. Some tools like Snyk offer a free introductory tier that is great for proof of concept work. These tools also generally provide a gentle ramp-up toward a more expensive option as your organization’s security initiative matures. Larger organizations with a mature security team will want to consider the pricing for enterprise-grade options. Thoughtful implementations will make sure the pricing structure is a good match for their intended use.

Technical Considerations

In addition to the aforementioned pricing concerns, there are also a variety of technical questions to answer that can help in selecting a finalist for implementation. Here are some key questions to consider as you work through the options:

• Does the tool support all of the languages you use?
• What public and private vulnerability databases does the tool reference in its scans?
• What features does the tool offer to streamline the review and processing of scan results?
• Is the tool geared to minimize friction for the developers so that they can quickly resolve issues and remain focused on their “day job”?
• Does the tool have built-in integration with the various CI and bug-tracking solutions in use within your organization?
• How easily can you scale the implementation as internal adoption grows?

The answers to these questions will provide significant insight for identifying the right tool for the job. For example, suppose you are comparing two tools that are roughly equivalent in terms of coverage, scan quality, and integration. In that case, a deciding factor might be the level of convenience features available for developers.

For example, some tools will automatically create pull requests with fix actions already in place, leaving the developers only to review the PR and approve/merge. Many tools will also provide detailed guidance about their findings that save the developer minutes or even hours of research per finding. Such advantages should not be overlooked, as it could mean the difference between an investment of minutes and an investment of days per scan.

Conclusion

As you can see, the decisions involved in selecting an SCA tool are rarely open and shut. We hope that this brief guide can be a helpful starting point for making this decision for your own organization. If this is something you would like assistance with, Trailhead has a team ready to help with your security efforts and we would love to help you make the best decision for your developers and your customers.

Just contact Trailhead to get started.