Coverity Scan is a service by which Black Duck provides the results of analysis on open source coding projects to open source code developers that have registered their products with Coverity Scan.
Black Duck, 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.
Black Duck offers the results of the analysis completed by Coverity Quality Advisor on registered projects at no charge to registered open source developers.
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, Black Duck'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.
Some examples of defects and vulnerabilities found by Coverity Quality Advisor include:
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.
Your project may already be registered with Coverity Scan, please check at scan.coverity.com. 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 scan.coverity.com. 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):
Projects initiated and maintained by for-profit corporations, or projects with license terms outside the foregoing guidelines, may be approved at Black Duck's discretion.
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.
The number of weekly builds per project are as follows:
Your use of Scan, the analysis provided in connection with the Scan service, and any software provided by Black Duck 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).
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, Black Duck will work to encourage a project to resolve all of their defects. Black Duck 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, Black Duck 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.
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.
Background process:
Supported Environment for Coverity Scan Hudson plugin:
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, Black Duck 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).
There is more information available at Black Duck, or you can contact the sales department at [email protected].
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 https://curl.haxx.se/docs/sslcerts.html