Changes between Initial Version and Version 2 of Ticket #3710


Ignore:
Timestamp:
Feb 28, 2019, 9:16:19 PM (3 years ago)
Author:
Gedare Bloom
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3710

    • Property Keywords ecosystem added; testing removed
  • Ticket #3710 – Description

    initial v2  
    1010
    1111**Reducing False Positives**
    12 Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false
    13 positives.  First is by creating an optional ''modeling file'' to accommodate
    14 for special cases where the data flow analysis breaks, for example due to
    15 missing functions that are linked outside the analyzed source code. A modeling
    16 file usually is used to identify functions that terminate execution, allocate
    17 memory, or free memory. Second, source code annotations in specially formatted
    18 comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward.
     12Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false positives.  First is by creating an optional ''modeling file'' to accommodate for special cases where the data flow analysis breaks, for example due to missing functions that are linked outside the analyzed source code. A modeling file usually is used to identify functions that terminate execution, allocate memory, or free memory. Second, source code annotations in specially formatted comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward.
    1913
    2014**Testing Fixes**
    21 Since security tools tend to be costly in terms of time or compute resources,
    22 they are normally run on nightly or even weekly builds rather than on every
    23 commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates).
    24 Coverity Scan
    25 integrates with Github and can be triggered to scan by merging new code to a
    26 specific git repository branch.
    27 As a first step, a special 'coverity' branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors.
     15Since security tools tend to be costly in terms of time or compute resources, they are normally run on nightly or even weekly builds rather than on every commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates). Coverity Scan integrates with Github and can be triggered to scan by merging new code to a specific git repository branch. As a first step, a special 'coverity' branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors.
    2816