Frequently Asked Questions (FAQ)

What is Coverity Scan?

Coverity Scan is a service by which Synopsys provides the results of analysis on open source coding projects to open source code developers that have registered their products with Coverity Scan.

Synopsys, the development testing leader, is the trusted standard for companies that need to protect their brands and bottom lines from software failures. Coverity Scan is powered by Coverity® Quality Advisor. Coverity Quality Advisor surfaces defects identified by the Coverity Static Analysis Verification Engine (Coverity SAVE®) for fast and easy remediation.

Synopsys offers the results of the analysis completed by Coverity Quality Advisor on registered projects at no charge to registered open source developers.

What is static analysis?

Static analysis is a set of processes for finding source code defects and vulnerabilities.

In static analysis, the code under examination is not executed. As a result, test cases and specially designed input datasets are not required. Examination for defects and vulnerabilities is not limited to the lines of code that are run during some number of executions of the code, but can include all lines of code in the codebase.

Additionally, Synopsys's implementation of static analysis can follow all the possible paths of execution through source code (including interprocedurally) and find defects and vulnerabilities caused by the conjunction of statements that are not errors independent of each other.

What types of issues does Coverity Quality Advisor find?

Some examples of defects and vulnerabilities found by Coverity Quality Advisor include:

  • resources leaks
  • dereferences of NULL pointers
  • incorrect usage of APIs
  • use of uninitialized data
  • memory corruptions
  • buffer overruns
  • control flow issues
  • error handling issues
  • incorrect expressions
  • concurrency issues
  • insecure data handling
  • unsafe use of signed values
  • use of resources that have been freed

The consequences of each type of defect or vulnerability are dependent on the specific instance. For example, unsafe use of signed values may cause crashes, lead to unexpected behavior, or lead to an exploitable security vulnerability.

How do I register a project for Coverity Scan?

Your project may already be registered with Coverity Scan, please check at If your project is not already listed, sign up and click on Add project and register your new project Finally fill out the resulting form and click Submit.

Register your project with Coverity Scan by completing the project registration form found at Upon your completion of project registration (including acceptance of the Scan User Agreement) and your receipt of confirmation of registration of your project, you will be able to download the Software required to submit a build of your code for analysis by Coverity Scan. You may then download the Software, complete a build and submit your Registered Project build for analysis and review in Coverity Scan. Coverity Scan is only available for use with open source projects that are registered with Coverity Scan.

To be considered an open source project, your project must meet all of the following criteria (adopted from the Open Source Initiative definition of open source):

  1. Your project must be freely redistributable. Your project license terms must not restrict any party from selling or giving away the project as a component of an aggregate software distribution containing programs from several different sources. The license terms must not require a royalty or other fee for such sale.
  2. Your project license terms must include a license to the project source code. Your project must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
  3. Users must be able to make and distribute modified and derivative versions of your project. Your project license terms must allow for user modifications and derived works, and must allow modifications and derived works to be distributed under the same terms as the license of the original software.
  4. Integrity of your project source code may be restricted. Your project license terms may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. Your license terms must explicitly permit distribution of your project built from modified source code. Your license terms may require derived works to carry a different name or version number from the original project.
  5. No Discrimination Against Persons or Groups. Your project license terms must not discriminate against any person or group of persons.
  6. No Discrimination Against Fields of Endeavor. Your project license terms must not restrict anyone from making use of your project in a specific field of endeavor. For example, it may not restrict your project from being used in a business, or from being used for genetic research.
  7. Project license rights must apply to distribution of your project. The rights attached to your project must apply to all to whom your project is redistributed without the need for execution of an additional project license by those parties.
  8. Your project license terms must not limit use of your project to a specific product or distribution. The rights attached to the project must not depend on your project being part of a particular software distribution. If your project is extracted from that distribution and used or distributed within the terms of your license terms, all parties to whom your project is redistributed should have the same rights as those that are granted in conjunction your original project distribution.
  9. Your project license terms must not restrict other software. Your project license terms must not place restrictions on other software that is distributed along with your project.
  10. Your project license terms must be technology-neutral. No provision of your project license terms may be predicated on any individual technology or style of interface.

Projects initiated and maintained by for-profit corporations, or projects with license terms outside the foregoing guidelines, may be approved at Synopsys's discretion.

If my project is already registered in Scan, how do I get an account?

If your project is already a Registered Project in Scan, but you are not yet a registered user of Scan, you can register with Scan, and upon registration, you can click on Add Project, find your Registered Project in the project table, and request access to the Registered Project of your choice. You will be granted access subject to approval by the Registered Project owner or Scan administrator.

What is the frequency for build submissions to Coverity Scan?

The number of weekly builds per project are as follows:

  • Up to 28 builds per week, with a maximum of 4 builds per day, for projects with fewer than 100K lines of code
  • Up to 21 builds per week, with a maximum of 3 builds per day, for projects with 100K to 500K lines of code
  • Up to 14 builds per week, with a maximum of 2 build per day, for projects with 500K to 1 million lines of code
  • Up to 7 builds per week, with a maximum of 1 build per day, for projects with more than 1 million lines of code
Once a project reaches the maximum builds per week, additional build requests will be rejected. You will be able to re-submit the build request the following week.
Please contact [email protected] if you have any special requirements.

What are the terms applicable to my use of Scan?

Your use of Scan, the analysis provided in connection with the Scan service, and any software provided by Synopsys for your use of Scan are subject to the terms and conditions of the Coverity Scan User Agreement, which may be found here. Your use of Coverity Scan constitutes your acceptance of the terms and conditions of the Scan User Agreement, the Scan Terms of Use, and any additional terms and conditions stated in your email (delivered to you upon successful registration of your project).

Who may be granted access to a Registered Project?

Generally, access to the detailed analysis results for most Registered Projects is granted only to members of the Registered Project approved by the Registered Project administrator, to ensure that potential security defects in the Registered Project may be resolved before the general public sees them.

Coverity Scan uses the Responsible Disclosure approach. Scan provides the analysis results to the project developers only, and do not reveal details to the public until an issue has been resolved. For a thorough discussion of Responsible Disclosure, you can refer to comments by Bruce Schneier, or Matt Blaze, or the Wikipedia article on Full Disclosure

Since projects that do not resolve their outstanding defects are leaving their users exposed to the consequences of those flaws, Synopsys will work to encourage a project to resolve all of their defects. Synopsys may set a deadline for the publication of all the analysis results for a project.

In the discussion of Full Disclosure and Responsible Disclosure, focus has always been on the topic of handling individual coding issues where the impact is somewhat well understood. In the case of automated code testing tools, the best practices have not been discussed. Testing tools may find large numbers of issues, and those counts include a range of different levels of impact. Since the results require triage by a developer, they can sometimes languish - including those defects whose security implications are exposing end-users' systems. In order to push for those issues to be resolved, in the same spirit as the individual issue disclosure policies, Synopsys may set planned publication dates for the full analysis results of a project. Projects may negotiate with us about the date, if they are making progress on resolving the outstanding issues.

Does Coverity Scan work with Eclipse Foundation projects?

Registered Projects, which are also part of Eclipse Foundation, can participate in the Coverity Scan service by using the Coverity Scan plugin on the Hudson server. This plugin sends build and source code management information to Coverity Scan server. Coverity Scan server builds and analyzes the code in the cloud for Registered Projects which are part of Eclipse Foundation, and makes results available online.

Manual Steps:

  • Add Coverity Scan plugin to your build process
  • Register your project with Coverity Scan to get the Project token
    • Sign-up or Sign-in to Coverity Scan
    • Register your project with Coverity Scan. Project name should be the same as in Eclipse job.
    • After registering your project, copy the "Project token" found under "Project settings" tab
  • Enter the "Project token" and notification email in Coverity Scan plugin

Background process:

  • Coverity Scan plugin will send the information about your build environment to Coverity Scan server, when you build your project in Hudson Server.
  • Coverity Scan server builds, analyzes and commits the results into Scan database, and results will be available online
  • Summary of the defects found during the analysis is available on Hudson server under "Build History"
  • Login to Coverity Scan to view or triage the defects.
  • Any contributor of the project can register with Coverity Scan to get access to the analysis result.

Supported Environment for Coverity Scan Hudson plugin:

  • Single SCM / single builder.
  • On one SCM it supports one single repository or location
  • Source Code Management System:
    • SVN
    • Git
    • CVS
  • Builders
    • Ant
    • Maven
    • shell
      • single line commands,
      • multi line commands should be set in a or similar file

Why is Synopsys providing the Scan service?

Coverity Scan began in collaboration with Stanford University with the launch of Scan occurring on March 6, 2006. During the first year of operation, over 6,000 software defects were fixed across 50 C and C++ projects by open source developers using the analysis results from the Coverity Scan service.

The project was initially launched under a contract with the Department of Homeland Security to harden open source software which provides critical infrastructure for the Internet. The National Cyberspace Strategy document details their priorities to:

· Identify and Remediate Existing Vulnerabilities; and

· Develop Systems with Fewer Vulnerabilities and Assess Emerging Technologies for Vulnerabilities

Those priorities include sub-elements to:

· Secure the Mechanisms of the Internet

· Improve the Security and Resilience of Key Internet Protocols

· Reduce and Remediate Software Vulnerabilities

· Assess and Secure Emerging Systems

DHS had no day-to-day involvement in the Scan project, and the three year contract was completed in 2009.

The result has been overwhelming. With over 6,000 defects fixed in the first year - averaging over 16 fixes every day of the year, recognition of benefits from the Scan service has been growing steadily. Requests for access to the results and inclusion of additional projects have shown that the open source community recognizes the benefits of Scan.

In response, Synopsys is continuing to fund the Scan beyond the requirements of the DHS contract, which expired in 2009. New registered users will continue to be able to register projects and be given access to the Scan analysis results on an ongoing basis (time and resources permitting).

How can I get Coverity Quality Advisor for use at my company on my non-open-source codebase?

There is more information available at, or you can contact the sales department at [email protected].

What do I do if my build upload responds with "Peer's certificate issuer has been marked as not trusted by the user"?

curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

The reason behind this issue is that ca-certificate package of the RHEL 7.0 installation was too old, probably it lacks the necessary trusted CA. It could be fixed by doing a "yum update ca-certificates" on the target system.

More details at