Home
Triage and analysis
Grouping similar findings allows security analysts or IT auditors to segment and triage source code problems. This section explains how to triage AppScan® Source assessments and analyze results.
AppScan® Source trace
With AppScan® Source trace, you can verify input validation and encoding that meets your software security policies. You can look at the findings that produce input/output traces and mark methods as validation and encoding routines, sources or sinks, callbacks, or taint propagators.
Code examples for tracing
This section provides code examples which illustrate tracking tainted data from a source to a sink - and how to create a validation and encoding routine.
Example 2: Modified from source to sink
Example 2 is a modification of the Example 1 code. It enhances Example 1 by adding a validation routine, called getVulnerableSource, and an encoding routine called in writeToVulnerableSink.
Example 2: Creating a Validation/Encoding Routine from the Custom Rules Wizard
If the validation/encoding routine that you want to create does not appear in the trace graph, you can create the routine by launching the Custom Rules Wizard from the Trace view.

Welcome
Welcome to the documentation for HCL® AppScan® Source.
What's New
Explore these new features that have been added to AppScan® Source - and note any features and capabilities that have been deprecated in this release.
Installing
Learn how to install, upgrade, and activate HCL® AppScan® Source.
Configuring
Learn how to configure applications, folders, and projects, and set attributes and properties in HCL® AppScan® Source.
Administering
Learn how to administer user accounts and permissions, audit user activity, and manage integrations in HCL® AppScan® Source.
Scanning
This section explains how to scan your source code and manage assessments in HCL® AppScan® Source.
Triage and analysis
Grouping similar findings allows security analysts or IT auditors to segment and triage source code problems. This section explains how to triage AppScan® Source assessments and analyze results.
- Displaying findings
  The Findings view, or any view with findings, displays a findings tree (a hierarchical grouping of assessment criteria) and a findings table for each scan. The item that is selected in the findings tree determines the findings that are presented in the table.
- The AppScan® Source triage process
  The triage process includes manipulating findings through bundles, filters, and exclusions - and comparing assessment results.
- Sample triage
  This example describes an AppScan® Source triage workflow used by a security analyst. Triage workflow may vary according to your business needs.
- Triage with filters
  AppScan® Source for Analysis reports on all potential security vulnerabilities and may produce many thousands of findings for a medium to large code base. When you scan, you may find that the findings list contains items that are not important to you. To remove certain findings from the Findings view, you can choose a predefined filter or you can create your own filter. A filter specifies the criteria that determine which findings to remove from view.
- Triage with exclusions
  After a scan, you may decide that some findings are irrelevant to your current work, and you do not want them visible in the findings table when you triage the scan results. These exclusions (or excluded findings) no longer appear in the Findings view and the assessment metrics update immediately with the changed results. Filter and bundle exclusions added to a configuration only take effect on subsequent scans.
- Working with bundles
  Bundles (a grouping mechanism for findings) allow you to import a snapshot of findings from AppScan® Source for Analysis to AppScan Source for Development. Once findings are in bundles, you can use AppScan Source for Development to open the project that contains the bundle, import the bundle, or open a saved bundle file (file_name.ozbdl).
- Working with static analysis fix groups
  Fix groups are a new approach to managing, triaging, and resolving issues found in static analysis scans. After running a static scan, AppScan® Source organizes issues into fix groups based on vulnerability type and the required remediation task.
- Modifying findings
  Modified findings are findings that have changed vulnerability types, classifications, or severities - or that have annotations. The Modified Findings view displays these findings for the current application (the application that is active as a result of opening an assessment for it). In the My Assessments view (available only in AppScan® Source for Analysis), the Modified column indicates if a finding has changed in the current assessment.
- Comparing findings
  Use the Diff Assessments action or the AppScanDelta utility to compare assessments. When two assessments are compared, the differences between the two are displayed in the Assessment Diff view or in an .ozasmt file. The results summarize new, fixed/missing, and common findings.
- Custom findings
  To augment your analysis results, you can create custom findings. These are user-created findings that AppScan® Source for Analysis adds to the currently-open assessment or selected application. Custom findings impact assessment metrics and can be included in reports. Once created, a custom finding is automatically included in future scans of the application.
- Resolving security issues and viewing remediation assistance
  AppScan® Source alerts you to security errors or common design flaws and assists in the resolution process. The AppScan Source Security Knowledgebase - and internal or external code editors - help with this process.
- Supported annotations and attributes
  Some annotations or attributes that are used to decorate code are processed during scans. When a supported annotation or attribute is found in your code during a scan, the information is used to mark the decorated method as a tainted callback. A method marked as a tainted callback is treated as if all of its arguments have tainted data. This results in more findings with traces. Supported annotations and attributes are listed in this help topic.
- AppScan® Source trace
  With AppScan® Source trace, you can verify input validation and encoding that meets your software security policies. You can look at the findings that produce input/output traces and mark methods as validation and encoding routines, sources or sinks, callbacks, or taint propagators.
  - AppScan® Source trace scan results
    Scan results may include traces identified by AppScan® Source trace. The icon in the Trace column indicates the existence of a trace of the call graph.
  - Input/output tracing
    An input/output trace is generated when AppScan® Source for Analysis can track the data from a known source to a sink or lost sink.
  - Using the Trace view
  - Validation and encoding scope
    From the Trace view, you can specify custom validation and encoding routines that, once stored in the AppScan® Source Security Knowledgebase, marks data as checked instead of tainted. With the Custom Rules Wizard, you define these routines based on their scope.
  - Creating custom rules from an AppScan® Source trace
    You can create custom rules from the Trace view that allow you to filter out findings with traces that are taint propagators, not susceptible to taint, or sinks. You can also mark methods in the trace as validation/encoding routines (or indicate that they are not validation/encoding routines).
  - Code examples for tracing
    This section provides code examples which illustrate tracking tainted data from a source to a sink - and how to create a validation and encoding routine.
    - Example 1: From source to sink
    - Example 2: Modified from source to sink
      Example 2 is a modification of the Example 1 code. It enhances Example 1 by adding a validation routine, called getVulnerableSource, and an encoding routine called in writeToVulnerableSink.
      - Example 2: Creating a Validation/Encoding Routine from the Trace view
      - Example 2: Creating a Validation/Encoding Routine from the Custom Rules Wizard
        If the validation/encoding routine that you want to create does not appear in the trace graph, you can create the routine by launching the Custom Rules Wizard from the Trace view.
    - Example 3: Different source and sink files
    - Example 4: Validation in depth
      When you scan the Example 4 code, the first scan includes three AppScan® Source traces with a root at the corresponding trace routines. Assume the selection of the FileInputStream.read method in trace1 and the addition of the validate routine. The section following the sample source code describes the effects of each scope for the validation routine.
Reporting
Security analysts and risk managers can access reports of select findings or a series of audit reports that measure compliance with software security best practices and regulatory requirements. This section explains how to create reports of aggregate finding data.
Extending product function
Learn how to extend the product to meet specific development requirements.
Reference
Review reference information for HCL® AppScan® Source, including using utilities, plug-ins, and APIs.
Troubleshooting and support
Self-help information, resources, and tools to help you troubleshoot issues while using HCL® AppScan® Source.

Example 2: Creating a Validation/Encoding Routine from the Custom Rules Wizard

If the validation/encoding routine that you want to create does not appear in the trace graph, you can create the routine by launching the Custom Rules Wizard from the Trace view.

About this task

This example will create the same validation routine that is created in Example 2: Creating a Validation/Encoding Routine from the Trace view - however, in this example, the routine will be created using the Custom Rules Wizard.

Procedure

In the Trace view, click Launch the custom rules wizard to add a validation routine that is not on the trace graph on the toolbar.
Note: You cannot create a validation routine from the Custom Rules Wizard when it is launched from the Custom Rules view.
In the Select Validation/Encoding Routine page of the wizard, specify the location of the validation routine.
For this example, select this routine:
```
TestCase_IOT_Instance_Val_Encode.encode(java.lang.String):
java.lang.String
```
Complete the remaining sections of the wizard page with the same settings that were made in the Specify how to apply this validation routine dialog box in Example 2: Creating a Validation/Encoding Routine from the Trace view.
Click Finish to save and share the validation routine.