Whitebox Assessment
The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.
Overview
Takumi's whitebox assessment feature receives source code via GitHub repository connection or file upload, performs assessments, and outputs the results as a report on the web.
It can be used from the Shisho Cloud byGMO web interface. Unlike Periodic Assessment, this feature does not require Slack integration.
Differences from Chat-Based Whitebox Assessment
This feature and the whitebox assessment available via Slack or Web chat run on different Takumi engines.
| Item | Via Chat | Via Web Console |
|---|---|---|
| Comprehensiveness | As before | More comprehensive |
| Assessment Time | As before | Tends to increase |
| Credit Consumption | As before | Tends to increase |
Regarding Credit Consumption
Credits are required to use this feature. Credit consumption varies depending on the characteristics and size of the assessment target.
You can set credit thresholds for the feature enumeration phase and the scanning phase separately when starting an assessment. Each phase's consumption will not exceed its specified threshold.
How to Start an Assessment
Click "Assessments" in the sidebar, then click the "Create Assessment" button in the upper right corner of the screen to start an assessment.
Basic Settings
- Enter a name to identify the assessment in "Assessment Name".
- Select the report language (English or Japanese) in "Report Language".
- Select "Source Codes" as the assessment target.
Assessment Type
You can select one of the following two modes:
- Full Assessment mode: Feature enumeration and the initial scan of the target source code are performed in one seamless process. After completion, the assessment pauses in a "Pending" state. See Reviewing Results and Running Additional Scans for next steps.
- Scoped Assessment mode: Features are first enumerated from the target codebase. Once complete, the enumerated features are displayed. You can then select which features to assess and set priorities before starting the scan.
Credit Threshold
Credit thresholds can be set separately for feature enumeration and scanning (for "Scoped Assessment" mode, only feature enumeration). Takumi performs feature enumeration and scanning within the specified credit thresholds.
Source Code Configuration
You can provide source code using one of the following methods:
GitHub Repositories
You can specify one or more GitHub repositories. Click the "Add Repositories" button to add repositories for assessment.
You can specify the branch of the target repository. If not specified, the repository's default branch will be used for assessment.
File Upload
You can upload source code archives directly. This is useful when GitHub integration is not available or for assessing local codebases.
- Supported formats:
.zipor.tar.gz - Click the "Upload Files" button to select and upload your archive
- The extracted root directory will be displayed and used for file scope specification below
File Scopes
You can specify file paths to include in or exclude from the assessment. All file paths support glob patterns (e.g., src/auth/**, backend/services/**). Leaving the scope empty will assess the entire codebase.
Include Scopes
- Select the target repository or uploaded file in "Target"
- Specify a feature category in "Feature Type" (optional) (e.g.,
authentication,payments,api) - Specify file paths to include in "File Path"
Please note that even if specified as an assessment target, file paths may be excluded based on Takumi's judgment.
Exclusions
- Select the target repository or uploaded file in "Target"
- Document the reason for exclusion in "Reason" (optional) (e.g., "Test code", "Auto-generated files")
- Specify file paths to exclude in "File Path"
Reviewing Feature Enumeration Results
When feature enumeration completes in "Scoped Assessment" mode, a matrix of detected features and assessment perspectives is displayed. On this screen, you can set the credit threshold for scanning and assessment priorities for each feature and perspective.
After completing the configuration, click the "Start Pentesting" button to begin the scan.
Reviewing Results and Running Additional Scans
When the specified credit threshold is reached during a scan or scanning for all combinations is complete, the assessment pauses in a "Pending" state.
Opening a "Pending" assessment displays the following page.
From this page, you can:
- Preview the interim report: Click "Preview Report" to open the current report in a new tab. You can use it to review findings so far and decide whether to continue scanning or complete the assessment
- Run additional scans: Set the credit threshold and priorities for unscanned combinations, then click "Start Pentesting" to run additional scans
- Complete the assessment: If no additional scans are needed, click the "Complete Assessment" button to finalize the assessment
Completing the Assessment
Clicking "Complete Assessment" transitions you to the assessment report page.
Checking Assessment Results
Assessment reports can be viewed on the web, as shown in the following screens.
The report begins with an overview and summary of the assessment results.
Each item in the assessment results explains which feature was assessed from what perspective, and what severity and risk vulnerabilities were found. The report includes specific file paths where vulnerabilities were detected.
Assessment Perspectives
In whitebox assessments, reviews are conducted from the following perspectives. The actual assessment perspectives and their priorities can be configured depending on the characteristics of the target repository.
Feature-Level Assessment
- Injection
- File System Vulnerabilities
- XSS
- Broken Authorization
- Business Logic Flaws
Repository-Level Assessment
- Misconfiguration
- Broken Authentication
Vulnerabilities such as Injection and XSS are tested for each feature identified by Takumi in advance to ensure the comprehensiveness of the assessment. On the other hand, perspectives such as Misconfiguration and Broken Authentication, which tend to exist in specific locations (e.g., configuration files or middleware layers) rather than being scattered across individual features, are executed only once for the entire target.
For more details, please refer to "Compliance with OWASP ASVS 5.0" below.
Differences from Blackbox Assessments
The whitebox assessment perspectives are structured differently from blackbox assessments to maximize the characteristics of static analysis.
For example, in blackbox assessments, it is meaningful to subdivide categories because SSRF and Command Injection are each tested with different requests and payloads. In contrast, whitebox assessments analyze the source code directly, allowing these to be tracked collectively through a common mechanism: "Taint Tracking" (tracing data from external input to dangerous sinks). Therefore, this assessment consolidates these into a single "Injection" perspective, achieving an efficient and comprehensive review while preventing redundant code scanning.
Compliance with OWASP ASVS 5.0
In whitebox assessments, Takumi detects high-severity vulnerabilities while simultaneously performing a comprehensive inspection based on the international standard OWASP ASVS 5.0.
The correspondence table between assessment perspectives and OWASP ASVS 5.0 Level 1 check items is as follows:
| Assessment Perspective | ASVS Check Items |
|---|---|
| Injection | V1.2.4, V1.2.5, V1.3.2, V1.5.1 |
| File System Vulnerabilities | V5.2.1, V5.2.2, V5.3.1, V5.3.2 |
| XSS | V1.2.1, V1.2.2, V1.2.3, V1.3.1, V4.1.1 |
| Broken Authorization | V8.2.1, V8.2.2, V8.3.1 |
| Business Logic Flaw | V2.3.1 |
| Misconfiguration | V3.4.1, V3.4.2, V3.5.2, V4.4.1, V11.3.1, V11.3.2, V11.4.1 |
| Broken Authentication | V3.3.1, V6.2.1–V6.2.8, V6.3.1, V6.3.2, V6.4.1, V6.4.2, V7.2.1–V7.2.4, V7.4.1, V7.4.2, V9.1.1–V9.1.3, V9.2.1, V10.4.1–V10.4.5, V14.3.1 |
However, some ASVS items are excluded from the check items for the following reasons:
-
Items covered implicitly
- These are omitted as independent items because the requirements can be verified through the inspection of other, more specific items
- Relevant items: V2.2.1, V2.2.2, V3.2.1, V3.2.2, V14.2.1, V15.3.1
-
Items outside the scope of static analysis
- Due to the nature of whitebox assessments (static analysis), items related to infrastructure or operations that are difficult or unsuitable to determine from source code are omitted
- Relevant items: V2.1.1, V6.1.1, V8.1.1, V12.1.1, V12.2.1, V12.2.2, V15.1.1, V15.2.1
-
Items planned for future support
- These items are scheduled to be addressed sequentially through future updates
- Relevant items: V3.5.1, V3.5.3, V13.4.1