TL;DR

For the most optimal, relevant and actionable findings we recommend only selecting first party modules without an entry point or with an entry point that is user facing.
This typically means that you should not select modules with a library entry point (such as MyProject.XmlSerializers.dll).

Alternatively, for more false positives, but fewer false negatives you may consider selecting all available first party top-level modules.

As a rule of thumb typical scan should not contain more than a handful (5) entry points, in fact, most scans should will likely not have more than 1 or 2 entry points for the highest signal-to-noise ratio.

Please note your security team may ask you to select more than this.

If you're unsure of which modules to select please feel free to create a Support case through the Veracode Community or the Veracode Platform for email communication or Schedule a Consultation to discuss this with a Veracode Application Security Consultant.

What's a scannable module?

Every scan with Veracode Static Analysis is comprised of two parts:

1. Pre-scan (typically takes 5 to 10 minutes), which result in a module selection 
2. Analysis, which results in the actual flaws

In the pre-scan it analyses your upload for what we call Scannable Modules.
A loose definition for this being:
 

"A collection of inter-dependent files, scannable as one independent unit, optionally identified by a potentially user-facing entry point".

When we analyse the upload of static languages we will typically create several modules of either of the following categories:

1. A top-level module, our heuristics have determined that this may be user-facing. Typically means this group of files with this entry point does not have anything call into it.
2. A dependency module, hidden by default in our UI, this file or groups of files are called by other files in the upload.

To get a more concrete understanding of what a Veracode Static Analysis Scannable Module is, lets look at a few examples:
 

.NET Framework example with single Web project

An example .NET upload of VeraDemoNet.zip for a Project named "VeraDemoNet" in a Solution called "VeraDemo" published as per our compilation guide (

https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/LlBZOwSnuA9xKGTopWDhZQ ):

VeraDemoNet\bin\Antlr3.Runtime.dll
VeraDemoNet\bin\Antlr3.Runtime.pdb
VeraDemoNet\bin\App_global.asax.dll
VeraDemoNet\bin\App_global.asax.pdb
VeraDemoNet\bin\App_Web__layout.cshtml.639c3968.dll
VeraDemoNet\bin\App_Web__layout.cshtml.639c3968.pdb
VeraDemoNet\bin\App_Web__loginlayout.cshtml.639c3968.dll
...SNIP...
VeraDemoNet\bin\System.Xml.XPath.XDocument.dll
VeraDemoNet\bin\vbc.exe
VeraDemoNet\bin\VBCSCompiler.exe
VeraDemoNet\bin\VeraDemoNet.dll
VeraDemoNet\bin\VeraDemoNet.pdb
VeraDemoNet\bin\WebGrease.dll
VeraDemoNet\images\admin.png
VeraDemoNet\Resources\scripts\verademo.sql
VeraDemoNet\Scripts\bootstrap.js
VeraDemoNet\Scripts\bootstrap.min.js
VeraDemoNet\Scripts\jquery-1.11.2.min.js
VeraDemoNet\Scripts\verademo.js

Would typically be grouped into the following modules (recommended entry points in bold):

App_Web__layout.cshtml.639c3968.dll
|- App_Web__loginlayout.cshtml.639c3968.dll
|- VeraDemoNet.dll
|- ....
csc.exe
csi.exe
JS files within VeraDemoNet.zip
Microsoft.AI.DependencyCollector.dll
...SNIP...
Pl/Sql Files
vbc.exe
VBCSCompiler.exe

Here many potential modules are identified but as this is a web application its entry points are the web pages through which users use the application and the JavaScript that interacts with the user.

The App_Web__layout.cshtml module will contain many more App_Web__ dll files that should be the output of pre-compilation per our compilation guide. Without precompilation any cshtml or aspx pages will not be analyzed.

Note that for solutions with multiple Web projects, each project should be published individually and provided in a separate ZIP file.

Java WAR example

A typical Java WAR file upload would look like this:

example-1.0.0.war

And would create the following modules (recommended selected modules highlighted):

Java files within example-1.0.0.war
JS files within example-1.0.0.war  

JavaScript/TypeScript example

An upload of "myproject.zip" containing JavaScript files:

• a.js
• b.js
• src/c.js
• src/d.ts

Would create a single module:

JS files within myproject.zip

Including "node_modules" might create more modules. If any of these modules contain your first party code they should be selected as entry points.
 

How does module selection affect my result?

Veracode Static Analysis results can roughly be divided into two groups:

1. Data Flow insensitive or 'point findings'. These are typically hardcoded passwords or cryptography flaws. There is no data to track. If you select a module, we will look for these types of flaws in all files therein.
2. Data Flow sensitive, most other flaws like SQL injection, where we require not only that the functionality is used but that we can track data from an outside source, like a data or configuration file, database, webservice, or http request, going into a function like a database query method or file access method (also called sink).

For this second group Veracode Static Analysis must know which parts of your application are exposed to user input.
Selecting a module with an entry point will cause us to consider all paths reachable from that entry point.
This may be a bit abstract so let's look at an example.

Example of selecting a module with a library as entry point

Say you have a module selection like so:

csc.exe
MyProject.dll
|- MyProject.Models.dll
MyProject.Models.dll (no dependencies)

        public static List<SYSUser> FindWhere(string whereClause)
        {
            using (DemoDBEntities db = new DemoDBEntities())
            {
                return db.SYSUsers.SqlQuery($"SELECT * FROM SYSUsers WHERE {whereClause}").ToList();
            }
        }

Even if this method is not used in your application, or you only every pass something safe to it like an empty string or "id = 1" Veracode Static Analysis will report it for SQL injection as you have indicated that this is an entry point, so directly exposed to user input.

Can you automatically determine the entry points for my application?

Veracode has heuristics to determine what is likely an entry point (this feature is called auto-scan) for your application but as we can't see how your application is used in practice this may be difficult to determine for us.

For the best results we recommend reviewing the module configuration either by doing a manual scan or by reviewing and correcting after an automated scan. Afterwards Veracode Static Analysis will reuse this module configuration.
 

Can I go back and change module selection?

Yes, you can change the modules selection for the most recent scan in the Policy area or in a Sandbox provided that:

1. The binaries have not yet been deleted (typically this will mean the scan must not be older than 30 days)
2. You do not currently have a scan in-progress in this Sandbox / Policy area.

You can change the Module Configuration in the Veracode Platform after selecting the Static Scan page:

How can I see what's in a module?

On the 'Review Modules' page you can click the + sign to get an overview of the dependencies found for a given entry point:

Please note that this only works for compiled languages. For dynamic languages you see the source files in a given module by going to the 'Source Files' menu item:

Should I scan my library?

Why does the "Detailed Veracode Report (PDF)" list my module as 'not scanned'?

The Detailed Veracode Report PDF has a section called "Scope of Static Scan". This is a listing of which modules were selected for scanning, typically identified by their entry point as mentioned in the header:

Scope of Static Scan
The following modules were included in the static scan because the scan submitter selected them as entry points, which are modules that accept external data.

The names here do not include the dependencies for the module, however these will have been scanned as part of the main module.

For example:

In this example "MVC5RealWorld.dll" is not selected as it is a dependency of "App_Web__layout.cshtml.639c3968.dll" and will be scanned as part of that module. It is not necessary, or indeed recommended to select this module separately.