Sentinel Source (SAST) Onboarding
|If you prefer to read the entire WhiteHat Sentinel Onboarding section in PDF format, you can view or print here.|
For onboarding your static analysis services, we need to know the type of Source Code Repository that you are using (if any), the URIs of the repositories/code bases or binaries we will be assessing, appropriate credentials, and the assessment schedule that you want to use.
Source Code Repository Type(s)
WhiteHat will need to know what type of repository houses the application code you want us to assess, so that we can provision the correct connector for that repository within the Sentinel appliance that you must install prior to beginning an assessment. Information on the types of repositories that we currently support is available in 'Adding a Code Base' .
URI(s) of the Repositories and Associated Code Bases
You can add code bases that are part of the application to the scope of the Source scan. Doing this ensures a complete scan of the application’s source code.
Please ask your developers if there are any dependencies not declared within the application source code. If there are, please add these as additional code bases associated to the application within the Sentinel UI. This will ensure that our scanning engine can thoroughly test all source code related to the application.
You will need to provide us with read-only credentials (if any) to the repositories on which your application resides. This allows our source code scanning engine to automatically log into the repository at the beginning of each schedule scan window.
You can schedule scans of your source code on an as-needed basis. We recommend scheduling scan windows regularly to ensure a current view of your application’s security status.
Scan Now – Scans source code only once to completion
Daily – Scans source code once per day to completion
Weekly – Scans source code once per week to completion
Never Scan (Default) – Source code will not be scanned until you allow it in the scan schedule
|Until you set a scan schedule, the default value used will be Never Scan.|
Service Delivery Timeline and Setup
Source Appliance Download and Installation (1 Business Day)
The Source VM not only houses our Source scanning engine, but also creates a secure SSH tunnel from our servers to yours that allows us to verify potentially vulnerable code snippets. These snippets are the only pieces of your source code that will be passed via this secure connection to our TRC engineers.
Follow the steps outlined in the Source Appliance guide, attached to your welcome email, to download and set up the VM Appliance within your network. Once you’ve installed the VM, we will verify the connection to your intended repositories is successful.
We recommend having someone who has experience with ESX servers available for the setup process.
Adding Applications and Code Bases
Since code checkout is done remotely via automation, Sentinel does not support browsing from a repository root, project listing, or web directory. If your application requires multiple repository projects to build, please add each project as a separate codebase. Remember that adding codebases that do not make up a single build may result in build errors that prevent scan completion.
If your version control technology is not supported or if your application’s build requires dependencies that are not available from a repository accessible by the Sentinel appliance, you may use a mock codebase to provide additional code to be used in the scan via a gzipped tarball. In addition, you may set an application up to have its binary files scanned, rather than its code.
For more details on adding applications and code bases, see 'Managing Your Applications' .
Vulnerability Verification (Ongoing)
Any time Sentinel finds a vulnerability during a scheduled scan, it sends the potentially vulnerable code snippet to our TRC engineers. Our engineers then verify that the vulnerability is true and actionable before posting it.
Initial Assessment Complete (1-2 Weeks)
When the first full scan completes successfully and all verified vulnerabilities have been reported, we recommend scheduling a Vulnerability Review call where our TRC engineers can discuss and explain vulnerabilities. This call includes a breakdown of each reported vulnerability class and their threat to your application’s security using your vulnerabilities as examples.
We encourage you and your security and development teams to request Vulnerability Reviews for specific vulnerabilities any time during your subscription term.