FAQ

The 30-day Free Trial is a great way to evaluate ASoC. It lets you run all types of ASoC scans (SAST, DAST, and Mobile) on your site or app, and see a summary report of the results. The following limitations apply:

The Summary Report lists all security issues found, but without their details and suggested remediation tasks. These are included in the full report available with paid subscriptions.
Regulatory Reports are not available.
SAST scan results do not list Open Source Libraries used.
Private Site Scanning (scanning sites not available on the Internet) is not enabled.
Only one scan can run at a time.
Total number of scans is limited to five.
Subscription expires after 30 days.

Why is my scan "Queued"?

Some subscriptions limit the number of scans that can be run at the same time (concurrent scans). If you start a scan when your maximum number of concurrent scans are already running, the new scan is queued. Queued scans run automatically, in the order you started them, as soon as allowed by your subscription.

Note that the maximum number of scans that can be queued also depends on your subscription. When the queue is full, you will not be able to start additional scans.

The order of a queue cannot be edited, and follows the order the scans were started.

Free trial users can run only one scan at a time and cannot queue scans.

Why did my scan fail or scan status change to "Under review"? Why was the scan "handled by the Scan Enablement Team"?

If ASoC detects that with the current settings the automated process may produce poor results, the scan status changes to Under review. The settings are reviewed by our Scan Enablement Team, and may be modified for better results. No input is needed from you at this stage, and you should not cancel the scan as this will cancel the review. As soon as the settings have been reviewed (usually within a few hours), the scan resumes and completes.

Possible reasons your scan might fail or come under review include:

Invalid login credentials
Login requires a third or other unusual login procedure
Login uses CAPTCHA (CAPTCHA is not supported; if your login uses CAPTCHA you must disable it for the scan)
Invalid app file
Invalid or missing HTTP Authentication credentials
Server not responding or bad gateway (ASoC sends many requests, so the site/app must be stable, and able to cope with heavy traffic)
IP blocked (make sure to allowlist the IPs used by ASoC)
Account lockout
Results require manual verification
The Test Set you selected is not suited to your site/app
Private Site Scans: AppScan Presence not active

Obviously if you are able to avoid these issues your scan is more likely to complete automatically and fast. This is especially important if you are incorporating ASoC scanning into an automated process, so scan time will be as short as possible.

What happens if the scan fails?

Your account is not charged.
If there is a diagnosis for why the scan failed, the system notifies you so you can fix it.

Can I retrieve the scan results for a scan I deleted?

No. When you click the Trash icon the results are deleted from the database.

Can I retrieve the scan results for a previous scan after I rescanned?

No. When you rescan an application, the previous results are deleted from the database.

How long does a scan take to complete?

Depending on application size and complexity, from a few minutes to a few days. You can elect to receive an email when the scan is complete.

My scan seems to be taking a long time. Could it be stuck?

The monitoring system checks scan progress to ensure that scans that are not progressing are stopped. If the scan still appears to be running, it probably is.

How long do you keep my scans in your database if I don’t delete them?

Files uploaded by the user (such as APK, IPA, IRX, SCAN and SCANT) are cached in the service for up to 60 days, for the purpose of troubleshooting. Scan results are permanently stored in the service unless the user deletes them, or the account is deleted.

Note: As of July 1, 2020, Issues found in a Personal scan are deleted after 30 days, unless you promote the scan within that time.

Which IPs does ASoC use?

See System Requirements

What security issues does ASoC test for?

The table below shows the security issues for which each technology tests.


DAST	SAST	IAST
Abuse of Functionality Brute Force Buffer Overflow Content Spoofing Credential/Session Prediction Cross-Site Request Forgery Cross-Site Scripting (XSS) Denial of Service Directory Indexing Format String HTTP Response Splitting Information Leakage Insecure Indexing Insufficient Authentication Insufficient Authorization Insufficient Session Expiration Insufficient Transport Layer Protection Integer Overflows LDAP Injection Mail Command Injection Malicious Content Tests Null Byte Injection OS Commanding Path Traversal Predictable Resource Location Remote File Inclusion Server Misconfiguration Session Fixation SOAP Array Abuse SQL Injection SSI Injection URL Redirector Abuse XML Attribute Blowup XML Entity Expansion XML External Entities XML Injection XPath Injection	AppDOS Browser Caching Sensitive Information Comments Reveal Sensitive Information Configuration Issue CrossSite Scripting (XSS) DB Connection String Manipulation Email Phishing EMail Tampering Encoding Required Exposed Web Service File Tampering File Upload HTTP Request Splitting HTTPResponse Splitting LDAP Injection Open Redirect OS Command Injection Path Traversal Potential Business Logic Issue (also covers Insecure Direct Object Reference) Privilege Escalation RegEx Injection Remove Test Code SecondOrder Injection Sensitive Data Exposure Sensitive Data Stored in Logs Sensitive Information Revealed in Error Message Session Management Timeout Value Too Large SQL Injection Unencrypted Communications URL Tampering Use of Cryptographically Unsafe Random Number Generator Use of Hidden Fields Use of Insecure Cryptography Algorithm Use of Unsafe Native Code Weak Access Control Weak Authentication XML Injection XPath Injection XSLT Injection	Bad ServerHeaders Cross-site Request Forgery Cross-Site Scripting (XSS) HTTP Only Cookie Insecure Cookie Insecure Login Insecure Cookie LDAP Injection OS Commanding Path Traversal Session Fixation SQL Injection Trust Boundary Violation Weak Encryption Weak Random XML External Entity XPath Injection

Why is the risk rating for my application "Unknown"?

Risk rating is calculated for an application based on two factors:

Issues found (by ASoC)
Business Impact (assigned by the user)

If no issues have yet been found, or if business impact is Unspecified (the default), the risk rating will be Unknown. To change the business impact, see Risk rating.

DAST

Why can I no longer specify the environment to be Staging or Production?

Until recently DAST scan configuration included a choice of Staging or Production environments. This was to reduce the risk of the scan affecting your site's stability. New configuration options now available in the wizard have made this setting redundant, so it has been removed. Instead, if you are scanning a production site, you can consider making the following configuration changes:

In Explore > Automatic form fill, clear the check box to disable this option.
In Communication > Maximum request rate, the default value should be fine for most production sites, but you can consider reducing the maximum number of requests allowed per second to reduce traffic to your site.

For more details and suggestions, see the next section.

What changes should I make when scanning a live production site?

Where possible, it is recommended to run DAST scans on staging rather than production sites. Running a DAST scan on a live production site may affect the site stability. Where necessary, considering the following points can help you configure your production site scan effectively.

Database may get filled with artificial information sent during scanning

You can reduce the impact of this by taking the following precautions:

In Explore > Automatic form fill, clear the check box.
This will ensure that ASoC does not fill forms automatically, submitting data that might flood a database, bulletin board or online forum system, or send unwanted email to an administrator or moderator account. However, you should be aware that doing this will limit ASoC's ability to reach areas of the site that are accessed by submitting forms. In this mode of operation, ASoC will only scan areas of the site that can be accessed by following links (with or without parameters).
In Communication > Maximum request rate, consider reducing the maximum number of requests allowed per second.
Create a test account.
Using a test account makes it easier to track database changes (for example, to make sure that services are not actually ordered), and helps site administrators clean up the site after scanning. When creating the account consider doing some or all of the following:
- Limit database access to test records only, so that modified records can be restored.
- Ensure that new records created by the test account will be deleted.
- Ensure that purchase orders (or other transactions) from the test account will be ignored.
- If transactions have an impact (such as when dealing with stocks), allow the account access to test records only.
- If the site has forums, allow the test account access to test forums only, so that real customers will not see the tests created during the Test stage.
- If the site has different privileges for different accounts, set up more than one test account, with different privileges. This will ensure a more comprehensive scan of the site.
- Do not create a test account with administrator-level access.

Risk of email flooding

When testing pages that use email notification, ASoC generates many requests and may overload the site's email server. If feasible, temporarily change the email addresses on the pages being tested, so that email is sent to an invalid email address.

Test Optimization: If it scans faster, why shouldn’t I always use it?

Test optimization is great when you need faster results, but it is not as thorough as a non-optimized scan. We recommend optimized scans when speed is important, but that you also back them up with full scans at regular intervals.

Test Optimization: Can I expect the results of two optimized scans on the same site to be identical?

Since our team is constantly analyzing and updating the settings, each AppScan update has improved optimization settings, and therefore even if the site is unchanged the results may not be identical. However it is unlikely that a test that revealed an issue in the earlier scan would be filtered out of the later scan with the same optimization level.

OTP: How do I identify the OTP HTTP-parameter?

For DAST scans of sites that use OTP (one-time password), AppScan needs to know the name of the parameter that contains the OTP (in order to be able to login to the application), and usually identifies it when validating the recorded login. If it fails to do so, or if you use automatic login (rather than recorded login), you must add the parameter yourself.

To identify the parameter:

Browse to the application's login page.
Click F12 to open the developer tools pane of the browser (opens to the right of, or underneath, the main browser pane).
Click on the Elements tab to view the HTML code.
When you select a part of the code, the element is highlighted in the main browser pane.
Locate the element that highlights the OTP field.
Example:
```
<input type="text" name="OTPvalue" value="">
```
The value of the name parameter, without the quotation marks, is the OTP HTTP parameter you need.
Example:
```
OTPvalue
```
If there is more than one OTP HTTP parameter, separate them with commas.

Which protocols are supported for DAST scans?

ASoC can scan applications that require TLS 1.0, 1.1, and 1.2.

Scanning applications that require TLS 1.3 is not currently supported.

Which TLS protocol does ASoC support for connecting to the ASoC service?

ASoC supports TLS 1.2 for connecting to the service.

Why has the number of Medium severity issues increased in my rescan?

When rescanning a scan that was originally run using a version of the DAST engine earlier than v10.2.0, more Medium severity issues are found in the rescan than in the original scan.

From AppScan DAST engine version 10.2.0, CWE Issue severity and CVSS scoring are based on CVSS version 3.1. Scans run using older versions of the DAST engine used CVSS 2.0 scoring. Some issues that were assigned Low severity in the older version, were assigned Medium severity in 10.2.0, resulting in an increase in Medium severity issues. This will be changed in a future version of the DAST engine.

SAST and SCA

What is a static analysis IRX file and what does it contain?

IRX is a secure and encrypted zip archive that contains the information that is necessary to run a full static analysis of your program. It is encrypted at-rest upon creation, as well as during transport to the cloud (over SSL).

Internally, an IRX archive contains these files and artifacts:

A proprietary and obfuscated representation of your deployable program artifacts, built from your deployed source code (for example, Java bytecode or .Net MSIL). To learn which languages are supported for static analysis scans, see System requirements for static analysis).
Any runtime script files that are deployed with your program that can be analyzed for security vulnerabilities (for example .js (Javascript) or .rb (Ruby) files).
Static Analyzer configuration files that describe the application or project hierarchy and relationships or dependencies of your program. This allows for accurate and complete security analysis across project boundaries within your application.
Static Analyzer log files generated during the creation of the archive (for diagnostics and support).

CVSS version for SCA issues?

Although ASoC shows the CVSS version for DAST issue scores, it may not always show the CVSS version for SCA issue scores.