Good practices when defining the scope of a code scan
If you want to identify open source or COTS packages, make sure they’re included in the folders you’ll scan (external libraries are generally grouped into a sub-folder named “third-party” or something similar, while the main code is often located under “src/main”). Also, make sure you include third-party binaries (e.g. JARs, DLLs) if you want to retrieve related license, vulnerability and obsolescence information in Highlight.
Test classes should be excluded except if you want to scan them. But measuring software resiliency of your test files may be of poor interest, for instance.
Generated code (e.g. *.t.ds, *.flow.js) should be excluded as well as they’re automatically produced by the system and the development team can’t really manage software health of this aspect of the code.
For more consistent results, SCM, build and deployment folders (e.g. .git, .svn) shouldn’t be part of the scope.
If you want to get insights like CVEs (security vulnerabilities) on frameworks and dependencies whose physical files are not part of the folder you’re scanning, make sure that the dependency files (e.g. pom.xml, build.gradle, package.json, .vcsproj, etc.) are there too.