Running Scans¶
Choose the interface that fits your workstation or delivery process. Every scan produces reports for the selected source. Complete the corresponding quick start before using these controls.
Command-line scanning¶
Use the CLI for workstation scans, scripts, and managed build agents. It displays progress, diagnostic messages, and the locations of completed reports.
Run postq-code-scanner-cli --help to see the options in your installed release.
Follow Command Line for installation requirements and complete examples.
Project scans¶
Scan a repository or project directory to assess its supported cryptographic use together.
In the CLI, set --project to the source directory and --output to a separate report directory.
Project and folder scans require a valid license in the current beta. See Run a project scan.
File scans¶
Use a file scan to investigate selected source or evaluate PostQ on a small sample.
In the CLI, repeat --file <path> for up to five unique source files without a license.
VS Code and Eclipse also support limited file scans without a license. Their five-file limit applies to unique files in the local workspace or project report history. File scans provide only the context available within the selected scope.
Language selection¶
Use automatic language selection or supply a language hint for the source you intend to scan.
The CLI accepts --language with java, python, go, c, cpp, csharp,
javascript, typescript, or rust.
In VS Code, use Languages on a workspace in the Scans view. In Eclipse, configure the language in PostQ preferences. Check Languages and Libraries Supported for library coverage.
Folder exclusions¶
Exclude generated files, build output, or dependency directories to keep scans focused on the source you want to review.
Repeat --skip-folder <folder> with project-relative paths in the CLI, or use Skip Folders
in the VS Code Scans view. Excluded folders are outside the assessment scope; retain the
exclusion choices with your scan records.
Project identification¶
Label reports with the application name and version so reviewers can associate findings with a specific release or revision.
Set --name and --version in the CLI. The version value identifies your application;
use --about to see the installed PostQ version.
Report destination¶
Choose a separate report directory for each scan you want to retain. This makes it easier to compare results and locate the evidence behind a review decision.
Set --output <path> in the CLI. IDE integrations keep completed scans in local report history;
see Report history.
Java and OpenGrep selection¶
Explicit executable paths help managed workstations and build agents use the intended tools.
Set --java-path and --opengrep-path in the CLI, or use the corresponding IDE configuration
settings.
For prerequisites and supported setup, follow Install. Refresh the IDE configuration checks after changing a tool path.
VS Code scans¶
Run scans while working in a source workspace. Use Scan Current File, Scan Workspace Folder, or Scan All Workspace Folders from the PostQ commands, or PostQ Scan from a supported file or folder's context menu.
For a folder with an existing report, PostQ scan & Update Existing Report updates the latest report; without one, it creates a report. Use a fresh scan when you need to preserve a comparison baseline. See VS Code.
Eclipse and Spring Tools scans¶
Use the PostQ plugin to scan and review projects in Eclipse or Spring Tools. Open the PostQ Code Scan menu in Project Explorer or Package Explorer to scan a project or all projects.
Configure the scanner, required tools, and license under Window > Preferences > PostQ Code Scanner. See Eclipse for installation and report access.
Stopping an IDE scan¶
Stop an active scan when you selected the wrong scope or need to change configuration. Use Stop Running Scan in the IDE. In VS Code, closing the dedicated scanner terminal also stops the active scan.
Check scan status before using its output; a cancelled run might not have a complete report set. Start a new scan after correcting the inputs.
Container scans¶
Use the container runner when you need a packaged scanning environment on a supported Linux host or build agent.
Mount the source, report directory, and license, then run the command in Container Runner. That guide includes license acceptance, mount permissions, and runtime configuration.
Pipeline scans¶
Run the CLI or container in CI/CD to assess a checked-out revision and retain reports with the build. Configure scheduling, artifact storage, and security acceptance rules in your CI system.
A successful scan can contain security findings and still return exit code 0. Add a separate
pipeline policy step when findings must block delivery.
See CI/CD and Exit Codes.
Review without scanning¶
Security reviewers and auditors can open completed reports without installing the scan engine or activating a scanner license.
Use the standalone Report Viewer from the PostQ distribution and load the report folder. See Report Viewer for setup.