How Auditors Perform Tasks

Code Insight 6.14.2

An overview of the way an auditor performs the various tasks is as follows:

1.

Configure the workspace settings and details. This includes file settings, detection techniques to employ during the scan, sensitivities of the results, and specifics about the types of files to scan, such as extensions, etc.

2.

After the workspace is configured, schedule scans and reports of the codebase in one or many workspaces.

a.

Scanning is best done in batches. To save time, queue your scans before leaving work. This way they can be sequentially performed through the night and not during work hours. Depending on the size of your code base, some scans and/or reports may take many hours.

b.

Forensic scans allow you to generate reports that categorize underlying evidence. The advantage of this is that you can look at reports, for example, while on an airplane without network connectivity, by printing out a static hard copy.

c.

Scan results are live on the server, and unless you change a code base or data library you don’t need to scan a workspace again. Reports are persistent on the Scan Server.

3.

Check the specific task queues to make sure you have scheduled and prioritized the scans and reports to your liking.

4.

Once the scans are completed, launch Detector from the Web UI. The Detector forensic client allows you to choose one workspace from your completed list of scans and view, with varying levels of granularity, every piece of data (scan results) in that specific workspace’s code base.

5.

Analyze any evidence that might constitute a relevant compliance or security vulnerability issue in your code base. The evidence you analyze includes source code fingerprint matches, exact files [digest] matches, detected copyrights, detected license text or references, string search term matches, detected emails and URLs, Java name matches, etc. Sometimes there is an issue, but it has low relevance to your eventual software application’s integrity. For example: You find an issue with a certain license match. But this license match issue is only relevant if you are distributing your codebase internationally. If your company has no history or intention of distributing your application internationally, you do not have a licensing issue that requires attention.

6.

Organize and evaluate the information as it relates to your own internal compliance and security vulnerability policies.

7.

Publish an inventory of components that are detected via the scan of the code base. These inventory items are then put through the compliance workflow to ensure that usage is permissible in your organization. This workflow may involve the security analysts, owner, and various reviewers.

8.

Inventory with associated component versions containing known security vulnerabilities will require a review by the security analyst. Furthermore, all inventory items require an IP review by the reviewers, and these are configured by the project review workflow.