User guide for defect scanners#
Tools based on DefectScanner can
be used to:
Discover software defects with security implications, i.e. software vulnerabilities.
Verify each vulnerability is reachable and impacts security.
Triage the severity of each vulnerability based on its likelihood and impact.
File an issue for each vulnerability in a secure Buganizer component.
Attempt to create a “proof of concept” (PoC) that demonstrates the vulnerability.
Attempt to create a fix for the vulnerability.
For more detail on how such tools can be implemented, see the Implementation guide for defect scanners.
Example workflows#
Users run the defect scanner from the command line:
# Run a full scan across the entire repository
$ bazelisk run //path/to:my_defect_scanner
# Scan specific source files and print findings
$ bazelisk run //path/to:my_defect_scanner -- \
-s /path/to/my/project \
-f "pw_status/**" "pw_string/**"
# Scan, create bug reports, and upload candidate fixes
$ bazelisk run //path/to:my_defect_scanner -- \
-s /path/to/my/project -b -u
# Re-generate fixes for an existing bug ID
$ bazelisk run //path/to:my_defect_scanner -- \
-s /path/to/my/project \
-w /path/to/working/dir -i 123456789 -u
# Run a full scan across the entire repository
$ python3 my_defect_scanner.py
# Scan specific source files and print findings
$ python3 my_defect_scanner.py -s /path/to/my/project \
-f "pw_status/**" "pw_string/**"
# Scan, create bug reports, and upload candidate fixes
$ python3 my_defect_scanner.py -s /path/to/my/project -b -u
# Re-generate fixes for an existing bug ID
$ python3 my_defect_scanner.py -s /path/to/my/project \
-w /path/to/working/dir -i 123456789 -u
Sample output#
To be added soon…
Command-line arguments reference#
Since DefectScanner is derived
from Scanner, it automatically provides a
uniform set of command-line arguments:
- orphan:
Argument |
Description |
Associated stages |
|---|---|---|
|
Path to a local read-only Git repository workspace to scan. If omitted,
the scanner automatically clones the remote |
|
|
Path to a local writable Git repository workspace where code editors
apply patches and commit changes. If omitted, the scanner clones
|
|
|
One or more specific file paths or glob patterns to scan instead of enumerating the full repository. |
|
|
Issue ID to process (can be specified multiple times). Providing issue
IDs disables the |
|
|
Hotlist ID to process (can be specified multiple times). Providing hotlist IDs disables file enumeration and analyzer stages, querying the issue tracker for all issues on the hotlist and injecting them into the code editor. |
|
|
If enabled, creates Buganizer issues for findings. Otherwise, issue details are printed to stdout (defaults to False). |
|
|
If enabled, creates or updates local Git revisions and runs validation builds (defaults to False). |
|
|
If enabled, uploads candidate commits to Gerrit as Change Lists (implies
|
|
|
Resumes an interrupted run. Reuses existing intermediate files in stage
directories ( |
All stages. |
|
Maximum number of retries for transient errors (network timeouts,
subprocess failures) before moving a failed item to the stage’s
|
All stages. |
|
Working directory for intermediate results and stage queues (defaults to
|
All stages. |
|
Path to write the final results as a CSV file, in addition to printing formatted tabular results to stdout. |
|
|
If enabled, prints verbose diagnostic output and detailed issue information to stdout (defaults to False). |
All stages. |