AzureDevOps Guide

Software Composition Analysis & SCA Tools

by · May 23, 2023

SCA otherwise known as Software composition analysis is defined as analysis of open source packages in our source code. The tool which does these software composition analysis (SCA) in an automated way are called as SCA tools. Those tools are used to identify list of open source packages as well as their licenses (E.g MIT, GPL, GPLv3, AGPL, LGPL etc.,). In addition to that the main purpose of the SCA tools are to identify the vulnerable libraries/packages in our source code.

Whenever we are selecting a SCA tool, we should make sure it satisfies atleast some of the below criteria

  • Scanning of different programming languages
  • Vulnerability analysis
  • No False negatives
  • Less False positives
  • Correct License assignment to packages
  • Transitive dependencies
  • Integrations with different DevOps Tools, Source Controls versions
    Integrations with IDEs
  • Automated Notification of Vulnerabilities

Now let us see one by one on the factors that decide in selection of an SCA Tool.

Scanning of different Programming languages: An SCA Tool should be good enough to scan different programming languages like C#, Java, Python, JavaScript, C, C++, Rust, Go, PHP, JavaScript frameworks and other languages. The only criteria you should look for is whether the tool is able to scan all the programming languages that is used within your organization.

Library Analysis: The tool should be able to do deep dive of the source code and find out the libraries/packages wherever be it in the source code. If the tool doesn’t find the libraries that it is supposed to find then there is no use in purchasing such a tool for SCA purposes.

Vulnerability Analysis: An SCA tool should be able to do a vulnerability analysis of the packages/libraries in the source code. A tool which fails to identify even the basic vulnerabilities that are associated with a package should not be purchased at any time.

No False Negatives: False negatives are known as vulnerabilities which the tool fails to identify. There might be many false positives but there should be no false negatives. A high number of false negatives indicate that the tool is failing in it’s basic purpose of finding vulnerabilities.

Less False Positives: False positives are vulnerabilities which doesn’t exist. An SCA tool because of their outdated database or due to some reasons might identify a package as vulnerable even though the package is not actually vulnerable.

Correct License assignment to Packages: Sometimes an SCA too might be very good in vulnerability analysis but it may fail in license analysis of open source packages. Such a tool should not be purchased as it defeats the secondary purpose of identifying the licenses of the open source packages which helps an organization to be legally compliant

Transitive dependencies: The tool should be good enough to identify

Integrations with DevOps Tools & Source Control Version: SCA tool should have integrations for scanning as well as Bug creation in different DevOps tools and also it should provide smooth integration with different source control tools like Azure DevOps, GitHub, GitLab etc.,

Integrations with IDEs: The tool should also have integration with different IDE’s like Eclipse, Visual Studio Code, Visual Studio Professional/Enterprise, IntelliJ JetBrains and other tools that are used within an organization for coding. If the tool that doesn’t have any of these integrations, then it should not be purchased at all.

Automated Notification of Vulnerabilities: Tool should have some automated notifications which would alert us in case of zero day exploits or vulnerabilities like Log4j. This would help us to quickly identify the repositories that might have the vulnerable packages and remediate the same.

Tags: