Frequently Asked Questions

SourceClear Software Composition Analysis

If your question is not answered in the list below, email support@veracode.com.

What are the SourceClear CLI agents requirements?

Scanning a repository that utilizes Java and one of its build or package managers requires the ability to build the code within the environment in which you scan the project. This ability includes the following requirements based on the various build and package managers:

What are issues?

See the documentation on SourceClear issues for details on issues.

Why can’t SourceClear verify the validity of a software license?

Occasionally, the software license for a component cannot be found with the build instructions. For example, a Java component registered with Maven Central may not have the license information in the Project Object Model (POM) file, however, the parent POM of the component may have it. When SourceClear displays license information with an asterisk, it means it obtained the license information from the parent of the component.

How do I add another person to my SourceClear Organization?

You can find information on managing your SourceClear organization here.

What is a transitive component, as compared to a direct component?

A direct component is a dependency that is directly referenced in the configuration file the repository’s build or package manager supports, such as pom.xml for Maven or package.json for NPM. A transitive component is a dependency that is not directly specified in your configuration file, but is required by another component that your repository uses.

What languages and package managers does SourceClear support?
See the full list here at What SourceClear Supports.
How much does SourceClear cost?
View the pricing page for details.
Does SourceClear find vulnerabilities in my custom code?
No. SourceClear only scans for vulnerabilities in your open-source libraries.
Does SourceClear work with Docker?
SourceClear does work with Docker. To scan applications that use Docker, Veracode recommends that you scan the code when building it, prior to adding it to a Docker container, or by running the following command in the root of the project within Docker:
curl -sSL https://download.sourceclear.com/ci.sh | sh
You can find customization options for using the cURL script here.
What languages support vulnerable method scanning?
Java, Python, and Ruby support vulnerable method scanning.
How does SourceClear handle circular dependencies between two components?
SourceClear uses the native build system for a given repository to handle dependency resolution. This functionality means that in the case of circular dependencies, the build system resolves the dependency graph.
Where does the vulnerability information come from?
SourceClear researchers curate and validate public database entries and track developer lists, code commits and releases, discussion forums, underground bulletin boards, social chatter, and more to collect vulnerability information. They use data science and deep-learning, extracting patterns from known vulnerabilities and applying new techniques and theories. They also n use clone verification to validate that versions have been patched as intended.
Does SourceClear have an API to use?
Yes. See the SourceClear API documentation.
What happens to the repositories that my agent clones after they are scanned?
For SourceClear agents connected to your source code management system, code is cloned to the agent host and built in order to send evidence back to the SourceClear platform and provide component and vulnerability information. Immediately after being built, the cloned repository is deleted completely from the host. In cases where the scan is canceled or fails, the repository is also removed from the host to prevent excessive disk usage.
What information does SourceClear send from my environment to perform a scan?

SourceClear only sends fingerprints of the libraries used in your code to the SourceClear platform for identification. Fingerprints consist of unique identifying attributes for a given build or package manager. The following list provides the fingerprint attributes used for the corresponding build or package manager:

  • Maven/Gradle - groupId, artifactId, version
  • NPM/Bower/Yarn - library name, version
  • Ruby Gems - library name, version
  • Python - library name, version
  • PHP - library name, version
  • Golang - library name, commit hash/version
  • .NET - library name, version

You can find details for the evidence collection process here.