Hi @JMadaras064603 (Community Member)​ - I've asked my colleagues if they have any additional input/thoughts on this question, but in the meantime, here's some information with links to our Docs -

Veracode Static Analysis works by analyzing compiled code and identifying entry points to understand the control and data flow.

Here's what the documentation suggests regarding entry points and ensuring comprehensive scanning:

• Top-Level Modules as Entry Points: Veracode Static Analysis identifies "top-level modules" which are typically binaries with entry points for external data. These are usually components that include first-party code. The prescan process helps identify these. You can then select these top-level modules for scanning. [^1]

• Manual Module Selection: If the automatic module selection doesn't seem comprehensive enough, you have the option to manually select modules to scan. This is done through the "Advanced Mode" on the "Select Modules to Scan" page after the prescan is complete. This allows you to ensure that all relevant parts of your application, including those involved in your abstractions, are included. [^1]

• Packaging Requirements: Ensuring your application is packaged correctly according to Veracode's requirements for your specific language is crucial. This includes including all necessary dependencies and supporting files. If certain libraries or components are not properly packaged, the scanner may not be able to find them or understand their role in the application's flow, potentially leading to incomplete coverage. [^2] [^3]

To address your specific concern about abstractions:

1. Identify Entry Points: During the prescan, Veracode identifies potential entry points. After the prescan, carefully review the "Select Modules to Scan" page. Pay close attention to the modules that are identified as top-level or that seem to be entry points for your abstracted tiers.
2. Utilize Advanced Mode: If you suspect that some code paths due to your abstractions are being missed, switch to "Advanced Mode" in the module selection. This will give you a more granular view of all detected modules.
3. Manual Selection: Manually select any modules or components that you believe are crucial for understanding the flow across your abstracted tiers, even if they aren't automatically flagged as top-level entry points.
4. Packaging Review: Double-check your packaging process to ensure that all code, libraries, and dependencies related to your abstractions are correctly included in the artifact submitted for scanning.

By actively managing the modules selected for scanning and ensuring correct packaging, you can help Veracode's Static Analysis achieve better coverage of your application, even with complex architectural patterns.

[^1]: Scan code | Veracode Docs: https://docs.veracode.com/r/c_static_overview

[^2]: Java packaging | Veracode Docs: https://docs.veracode.com/r/compilation_java

[^3]: Scan code in the Veracode Platform | Veracode Docs: https://docs.veracode.com/r/Scan_source_code_in_the_Veracode_Platform

Thanks, Sam for the thoughtful response! I think we're likely good on the top-level modules being scanned (but I will verify we are using advanced mode as you mentioned). In our case we have mostly .NET class assemblies as our top-level modules. Does it matter whether we have Public methods in the .NET DLL/assembly in terms of how Veracode crawls the DLLs code? In our case, a lot of our data tier .NET Assemblies (which serve as top-level modules in our scan) have no public methods. We have one or more classes in each DLL, and each class has a Protected method that an internal framework/engine can call that links to all the protected/private methods where data access, etc. is performed. Are there any requirements in the top-level assemblies in terms of method scope (public/protected/private) that affect whether the Veracode scanner can find and traverse the methods?

Thanks!!!