A comprehensive Rust workspace for Veracode security platform integration, featuring a complete API client library and powerful CLI application for security scanning, policy management, and CI/CD integration.
# Clone and build
git clone <repository-url>
cd veracode-workspace
cargo build --release
# Set up authentication
export VERACODE_API_ID="your-api-id"
export VERACODE_API_KEY="your-api-key"
# Run a basic pipeline scan
./target/release/verascan pipeline --filepath . --export-findings results.json
# Run a basic assessment scan
./target/release/verascan assessment --filepath . --app-profile-name "MyApp"
# Enable CMEK encryption on an application
./target/release/veracmek enable --app "MyApp" --kms-alias "alias/my-encryption-key"
# Check encryption status across all applications
./target/release/veracmek statusveracode-workspace/
βββ veracode-api/ # π§ Core Veracode API client library
β βββ src/ # Library source code
β βββ examples/ # API usage examples
βββ verascan/ # π‘οΈ CLI security scanning application
β βββ src/ # Application source code
β βββ examples/ # CLI usage examples
β βββ gitlab/ # GitLab integration samples
βββ veracmek/ # π CLI CMEK encryption management tool
β βββ src/ # Application source code
βββ resources/ # π¦ Test files and samples
A comprehensive Rust client library for the Veracode security platform APIs:
- π Applications API - Application lifecycle management
- π₯ Identity API - User and team administration
- π Pipeline Scan API - Automated CI/CD security scanning
- ποΈ Sandbox API - Development environment management
- π Policy API - Security policy and compliance management
- π¨ Build API - Static application security testing (SAST)
- π Scan API - General scan utilities and management
A powerful command-line application for security scanning and Veracode integration.
A specialized command-line tool for managing Customer Managed Encryption Keys (CMEK) on Veracode application profiles.
Key Capabilities:
- π CMEK Management - Enable, change, and monitor encryption keys across applications
- π Bulk Operations - Process multiple applications with dry-run support
- π File-Based Configuration - JSON-based batch processing for complex scenarios
- π Vault Integration - Secure credential management with HashiCorp Vault
- π Multiple Output Formats - Table and JSON output for different use cases
- π Multi-Regional - Support for all Veracode regions (Commercial, European, Federal)
- π‘οΈ Production Ready - Robust error handling, retry logic, and comprehensive logging
- Recursive directory scanning with glob pattern support
- Smart file type detection using magic bytes (not just extensions)
- Support for JAR, WAR, ZIP, TAR, and various binary formats
- Configurable file filtering and validation
- Direct integration with Veracode Pipeline Scan API
- Multi-threaded concurrent file processing (2-10 threads)
- Real-time scan progress monitoring
- Configurable timeouts and retry logic
- Support for all Veracode regions (Commercial, European, Federal)
- File Size Validation: Automatic validation with scan-type specific limits
- Pipeline Scans: 200MB per file maximum
- Assessment Scans: 2GB per file maximum + 5GB total cumulative limit
- Early validation with clear error messages before processing begins
- Oversized files are automatically filtered during file discovery
- Enhanced Security: Comprehensive secure token handling with automatic credential redaction
- All Veracode API credentials (
VERACODE_API_ID,VERACODE_API_KEY) are securely wrapped - GitLab private tokens are automatically redacted in debug output
- Custom secure wrappers prevent accidental credential exposure
- All Veracode API credentials (
- Safe Logging: Password redaction for Git URLs showing
username:[REDACTED]@hostformat - Debug Protection: All sensitive credentials show
[REDACTED]in debug logs
- Create security baselines from scan results
- Compare current scans against historical baselines
- Identify new vulnerabilities and fixed issues
- Hash-based exact finding matching for precision
- Download and apply Veracode platform policies
- Custom local policy file support
- Pass/fail criteria based on severity levels or CWE IDs
- Combined baseline and policy enforcement
- Break Build Functionality: CI/CD integration with Veracode platform policy compliance
--breakflag enables build breaking on policy failures- Intelligent API Fallback: Automatic fallback from summary report API to getbuildinfo.do XML API on permission errors (401/403)
--force-buildinfo-apiflag orVERASCAN_FORCE_BUILDINFO_APIenv var to skip REST API and use XML API directly- Enhanced Compatibility: Works with any Veracode account permission level (REST+XML, XML-only, or restricted access)
- Standard exit codes: 0 for success, 4 for policy failure (matches Veracode Java wrapper)
- Works with both regular application scans and sandbox scans
- Graceful error handling - API failures don't break builds
- Transparent Operation: Clear logging shows which API path was used (summary report vs buildinfo)
- JSON: Veracode baseline format for future comparisons
- CSV: Spreadsheet-compatible findings export
- GitLab SAST: Security Dashboard integration
- Filtered JSON: Policy violation reports
- Findings Retrieval: Export security findings from completed Veracode assessment scans
- Policy & Sandbox Support: Export from both policy scans and sandbox scans
- Server-Side Filtering: API-level severity filtering to reduce network traffic
- Automatic Pagination: Handles large result sets with intelligent pagination
- Performance Optimized: Uses FindingsQuery builder pattern for efficient data retrieval
- Automatic GitLab issue creation for findings
- SAST Security Dashboard reports
- Source code permalinks in issues
- CI/CD pipeline integration
- Improved URL Generation: Fixed line number linking by removing problematic
ref_type=headsparameter - Project Name Resolution: Uses actual GitLab project name instead of "Unknown" fallback
- Concurrent file processing and scan submission
- Efficient memory usage for large file sets
- Progress indicators and detailed logging
- Configurable threading and timeouts
- Rust 1.70+ (for building from source)
- Veracode API Credentials (Generate here)
- GitLab Token (optional, for GitLab features)
git clone <repository-url>
cd veracode-workspace
cargo build --releaseThe binaries will be available at:
target/release/verascan- Security scanning CLItarget/release/veracmek- CMEK encryption management CLI
# Required: Veracode API credentials
export VERACODE_API_ID="your-api-id"
export VERACODE_API_KEY="your-api-key"
# Optional: GitLab integration
export PRIVATE_TOKEN="your-gitlab-token"
export CI_PROJECT_ID="12345"
# Optional: Development mode (allow HTTP URLs)
export VERASCAN_DISABLE_CERT_VALIDATION="true"# Pipeline scan - current directory for vulnerabilities
verascan pipeline --filepath . --export-findings results.json
# Pipeline scan - specific file types with custom project info
verascan pipeline --filepath ./build \
--filefilter "*.jar,*.war" \
--project-name "MyApp-v1.0" \
--project-url "https://github.com/user/repo" \
--export-findings scan-results.jsonπ File Size Limits: Pipeline scans accept files up to 200MB each. Assessment scans accept files up to 2GB each with a 5GB total limit across all files. Files exceeding these limits are automatically detected and rejected with clear error messages.
# Basic assessment scan (policy scan)
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--export-results assessment-results.json
# Sandbox assessment scan
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--sandbox-name "development-sandbox" \
--export-results sandbox-results.json
# Assessment scan with --no-wait (submit and exit)
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--no-wait \
--export-results results.json
# Assessment scan with no-wait option
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--no-wait
# Assessment scan with break build on policy failure
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--break \
--export-results results.json
# Assessment scan with break build using buildinfo API directly (for restricted permissions)
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--break \
--force-buildinfo-api \
--export-results results.json
# Assessment scan with custom build version
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--build-version "v2.1.0-release" \
--export-results results.json
# Assessment scan with auto-generated build version (default behavior)
verascan assessment --filepath ./target \
--app-profile-name "MyApplication" \
--export-results results.json# Export findings from completed policy scan (default: GitLab SAST format)
verascan export --app-profile-name "MyApplication" \
--output policy-findings.json
# Export findings from completed sandbox scan
verascan export --app-profile-name "MyApplication" \
--sandbox-name "development-sandbox" \
--output sandbox-findings.json
# Export with severity filtering (High and Very High only)
verascan export --app-profile-name "MyApplication" \
--min-severity "high" \
--output critical-findings.json
# Export to JSON format
verascan export --app-profile-name "MyApplication" \
--format json \
--output findings.json
# Export to CSV format
verascan export --app-profile-name "MyApplication" \
--format csv \
--output findings.csv
# Export to multiple formats
verascan export --app-profile-name "MyApplication" \
--format all \
--output comprehensive-report
# Export with custom project directory for GitLab file path resolution
verascan export --app-profile-name "MyApplication" \
--format gitlab \
--output gitlab-sast-report.json \
--project-dir /path/to/project
# Export with specific GitLab SAST schema version
verascan export --app-profile-name "MyApplication" \
--format gitlab \
--gitlab-schema 15.2.2 \
--output gitlab-sast-report.json
# Export with debug output
verascan export --app-profile-name "MyApplication" \
--output findings.json \
--debug# Create security baseline
verascan pipeline --filepath ./release \
--export-findings baseline-v1.0.json
# Compare against baseline
verascan pipeline --filepath ./current \
--baseline-file baseline-v1.0.json \
--filtered-json-output-file new-findings.json \
--export-findings current-results.json# Fail on high severity vulnerabilities
verascan pipeline --filepath . \
--fail-on-severity "High,Very High" \
--export-findings results.json
# Fail on specific vulnerability types
verascan pipeline --filepath . \
--fail-on-cwe "89,79,22" \
--export-findings results.json
# Combined baseline and policy enforcement
verascan pipeline --filepath . \
--baseline-file baseline.json \
--fail-on-severity "Medium,High,Very High" \
--filtered-json-output-file violations.json# Complete GitLab pipeline integration
verascan pipeline --filepath ./build \
--baseline-file security-baseline.json \
--export-format gitlab \
--export-findings gl-sast-report.json \
--create-gitlab-issues \
--fail-on-severity "High,Very High"# Download Veracode platform policy
verascan policy "Veracode Recommended High"
# Use downloaded policy
verascan pipeline --filepath . \
--policy-name "Veracode Recommended High" \
--filtered-json-output-file violations.json# High-performance pipeline scanning with custom settings
verascan pipeline --filepath ./artifacts \
--threads 8 \
--timeout 60 \
--region european \
--app-profile-name "Production App" \
--development-stage release \
--export-format all \
--export-findings comprehensive-report \
--show-findings \
--debug
# Advanced assessment scan with custom settings
verascan assessment --filepath ./artifacts \
--app-profile-name "Production App" \
--sandbox-name "qa-testing" \
--threads 8 \
--timeout 120 \
--modules "web-app,api-service" \
--teamname "Security Team" \
--bus-cri high \
--export-results assessment-comprehensive.json \
--debugVeracmek provides comprehensive Customer Managed Encryption Key (CMEK) management for Veracode applications.
# Enable CMEK on a single application (by name)
veracmek enable --app "MyApplication" --kms-alias "alias/my-cmek-key"
# Enable CMEK on a single application (by GUID)
veracmek enable --app "12345678-1234-1234-1234-123456789012" --kms-alias "alias/my-cmek-key"
# Change encryption key for an application
veracmek change-key --app "MyApplication" --new-kms-alias "alias/new-cmek-key"
# Check encryption status of a specific application
veracmek status --app "MyApplication"
# Check encryption status of all applications (table format)
veracmek status
# Check encryption status with JSON output
veracmek status --output json# Preview bulk encryption (dry run)
veracmek bulk --kms-alias "alias/production-key" --dry-run
# Enable CMEK on all applications
veracmek bulk --kms-alias "alias/production-key"
# Enable CMEK on all applications, skip already encrypted
veracmek bulk --kms-alias "alias/production-key" --skip-encrypted
# Bulk operation with JSON output
veracmek bulk --kms-alias "alias/production-key" --output jsonCreate a JSON configuration file for batch processing:
{
"applications": [
{
"app": "critical-app-1",
"kms_alias": "alias/critical-cmek-key",
"skip_if_encrypted": false
},
{
"app": "dev-app-1",
"kms_alias": "alias/dev-cmek-key",
"skip_if_encrypted": true
},
{
"app": "12345678-1234-1234-1234-123456789012",
"kms_alias": "alias/another-cmek-key",
"skip_if_encrypted": false
}
]
}Process applications from file:
# Preview file-based processing (dry run)
veracmek from-file --file apps.json --dry-run
# Apply configuration from file
veracmek from-file --file apps.json
# File-based processing with JSON output
veracmek from-file --file apps.json --output json# Enable CMEK in European region
veracmek --region european enable --app "MyApp" --kms-alias "alias/eu-key"
# Check status in Federal region
veracmek --region federal status
# Bulk operation in Commercial region (default)
veracmek --region commercial bulk --kms-alias "alias/commercial-key" --dry-runUse HashiCorp Vault for secure credential management:
# Set up Vault environment variables
export VAULT_CLI_ADDR="https://vault.company.com"
export VAULT_CLI_JWT="your_jwt_token"
export VAULT_CLI_ROLE="veracode-role"
export VAULT_CLI_SECRET_PATH="secret/veracode@kvv2"
export VAULT_CLI_NAMESPACE="optional_namespace"
# Commands automatically use Vault for credentials
veracmek status
veracmek enable --app "MyApp" --kms-alias "alias/my-key"
# Get help on environment variables and configuration
veracmek help-env# Enable debug logging
veracmek --log-level debug status
# Use custom log levels (error, warn, info, debug, trace)
veracmek --log-level trace enable --app "MyApp" --kms-alias "alias/my-key"
# Development mode (disable certificate validation - use with caution)
export VERACMEK_DISABLE_CERT_VALIDATION=true
veracmek status| Variable | Required | Description |
|---|---|---|
VERACODE_API_ID |
β | Your Veracode API ID credential |
VERACODE_API_KEY |
β | Your Veracode API key credential |
| Variable | Default | Description |
|---|---|---|
VERASCAN_FORCE_BUILDINFO_API |
- | Skip summary report API and use getbuildinfo.do XML API directly for break build evaluation (set any value) |
VERASCAN_GITLAB_SCHEMA |
15.2.1 |
GitLab SAST report schema version (15.2.1, 15.2.2, or 15.2.3) |
| Variable | Default | Description |
|---|---|---|
VERASCAN_CONNECT_TIMEOUT |
30 |
HTTP connection timeout in seconds |
VERASCAN_REQUEST_TIMEOUT |
300 |
HTTP request timeout in seconds (5 minutes) |
VERASCAN_DISABLE_CERT_VALIDATION |
- | Disable TLS certificate validation (set any value) |
| Variable | Default | Description |
|---|---|---|
HTTP_PROXY or http_proxy |
- | HTTP proxy URL (e.g., http://proxy.company.com:8080) |
HTTPS_PROXY or https_proxy |
- | HTTPS proxy URL (e.g., http://proxy.company.com:8080) |
PROXY_USERNAME or proxy_username |
- | Proxy authentication username (optional) |
PROXY_PASSWORD or proxy_password |
- | Proxy authentication password (optional) |
Note: Proxy configuration supports both authenticated and non-authenticated proxies. When using Vault (veracmek only), proxy credentials can also be stored in Vault secrets as proxy_url, proxy_username, and proxy_password fields. Vault proxy configuration takes precedence over environment variables.
| Variable | Default | Description |
|---|---|---|
VERASCAN_MAX_RETRIES |
5 |
Maximum number of retry attempts |
VERASCAN_INITIAL_RETRY_DELAY_MS |
1000 |
Initial retry delay in milliseconds |
VERASCAN_MAX_RETRY_DELAY_MS |
30000 |
Maximum retry delay in milliseconds (30 seconds) |
VERASCAN_BACKOFF_MULTIPLIER |
2.0 |
Exponential backoff multiplier |
VERASCAN_DISABLE_JITTER |
- | Disable retry timing randomization (set any value) |
| Variable | Description |
|---|---|
PRIVATE_TOKEN |
GitLab personal access token |
CI_TOKEN |
GitLab CI job token |
GITLAB_TOKEN |
Alternative GitLab token |
CI_PROJECT_ID |
GitLab project ID |
CI_API_V4_URL |
GitLab API v4 URL |
CI_PIPELINE_ID |
GitLab pipeline ID |
CI_PROJECT_URL |
GitLab project web URL |
CI_COMMIT_SHA |
GitLab commit SHA |
# Authentication (required)
export VERACODE_API_ID="your-api-id-here"
export VERACODE_API_KEY="your-api-key-here"
# API configuration for restricted permissions
export VERASCAN_FORCE_BUILDINFO_API="1" # Force XML API usage for break build
# GitLab SAST schema version (for GitLab integration)
export VERASCAN_GITLAB_SCHEMA="15.2.2" # Use GitLab SAST schema version 15.2.2
# Network optimization for slow connections
export VERASCAN_CONNECT_TIMEOUT="60" # 60 second connection timeout
export VERASCAN_REQUEST_TIMEOUT="900" # 15 minute request timeout
# Aggressive retry for CI/CD environments
export VERASCAN_MAX_RETRIES="10" # More retries for reliability
export VERASCAN_INITIAL_RETRY_DELAY_MS="500" # Faster initial retry
export VERASCAN_BACKOFF_MULTIPLIER="1.5" # Gentler backoff
# Development environment (disable certificate validation)
export VERASCAN_DISABLE_CERT_VALIDATION="true"
# Disable jitter for predictable timing in tests
export VERASCAN_DISABLE_JITTER="true"
# Proxy configuration (for corporate environments)
export HTTPS_PROXY="http://proxy.company.com:8080"
export PROXY_USERNAME="proxy-user" # Optional: for authenticated proxies
export PROXY_PASSWORD="proxy-password" # Optional: for authenticated proxies- Unified Configuration: Same variables work for all HTTP operations (Veracode API, GitLab integration)
- CI/CD Optimization: Tune timeouts and retries for your specific environment
- Development Support: Disable certificate validation for local testing
- Reliability: Configurable retry strategies with jitter support
- Security: Automatic credential redaction in logs and debug output
| Variable | Description |
|---|---|
VAULT_CLI_ADDR |
Vault server address (must use HTTPS) |
VAULT_CLI_JWT |
JWT token for Vault authentication |
VAULT_CLI_ROLE |
Vault role name for authentication |
VAULT_CLI_SECRET_PATH |
Path to secret in Vault (e.g., secret/veracode@kvv2) |
VAULT_CLI_NAMESPACE |
Vault namespace (optional) |
VAULT_CLI_AUTH_PATH |
Vault auth path (optional, defaults to auth/jwt) |
| Variable | Description |
|---|---|
VERACMEK_DISABLE_CERT_VALIDATION |
Disable TLS certificate validation (affects both Veracode API and Vault) - Development only! |
RUST_LOG |
Set logging level (error, warn, info, debug, trace) |
# Standard authentication (environment variables)
export VERACODE_API_ID="your-api-id"
export VERACODE_API_KEY="your-api-key"
# Using Vault for secure credential management
export VAULT_CLI_ADDR="https://vault.company.com"
export VAULT_CLI_JWT="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
export VAULT_CLI_ROLE="veracode-role"
export VAULT_CLI_SECRET_PATH="secret/veracode@kvv2"
export VAULT_CLI_NAMESPACE="my-namespace"
# Enable debug logging
export RUST_LOG=debug
# Development mode (disable certificate validation - use with caution!)
export VERACMEK_DISABLE_CERT_VALIDATION=true
# Alternatively, use proxy configuration from environment (Vault takes precedence)
export HTTPS_PROXY="http://proxy.company.com:8080"
export PROXY_USERNAME="proxy-user"
export PROXY_PASSWORD="proxy-password"Note: When Vault environment variables are detected, veracmek automatically uses Vault for credential retrieval instead of environment variables or CLI arguments. Vault secrets can include optional proxy configuration fields (proxy_url, proxy_username, proxy_password) which take precedence over environment variables.
| Option | Description |
|---|---|
--filepath <PATH> |
Directory to scan for files |
| Option | Default | Description |
|---|---|---|
--filefilter <PATTERNS> |
"*" |
Comma-separated glob patterns |
--recursive |
true |
Search subdirectories recursively |
--validate |
true |
Validate file types using magic bytes |
| Option | Default | Description |
|---|---|---|
--pipeline-scan |
- | Enable Veracode pipeline scanning |
--app-profile-name <NAME> |
- | Veracode application profile name |
--project-name <NAME> |
- | Project name (max 70 characters) |
--project-url <URL> |
- | Project URL (https:// required) |
--region <REGION> |
commercial |
Veracode region (commercial/european/federal) |
--timeout <MINUTES> |
30 |
Scan timeout in minutes |
--threads <COUNT> |
4 |
Concurrent threads (2-10) |
--development-stage <STAGE> |
development |
development/testing/release |
| Option | Default | Description |
|---|---|---|
--app-profile-name <NAME> |
- | Veracode application profile name (required) |
--build-version <VERSION> |
Auto-generated | Custom build version (max 70 chars, alphanumeric/dashes/underscores/dots only). If not specified, auto-generates timestamp like 'build-1234567890' |
--sandbox-name <NAME> |
- | Sandbox name for sandbox assessment scans |
--no-wait |
false |
Submit scan and exit without waiting for completion |
--modules <LIST> |
- | Specific modules to scan (comma-separated) |
--teamname <NAME> |
- | Team name for application creation |
--bus-cri <LEVEL> |
very-high |
Business criticality (very-high/high/medium/low/very-low) |
--deleteincompletescan <POLICY> |
1 |
Build deletion policy (0=never, 1=safe builds, 2=any build) |
--timeout <MINUTES> |
60 |
Scan timeout in minutes |
--threads <COUNT> |
4 |
Concurrent threads (2-10) |
--export-results <FILE> |
assessment-results.json |
Export assessment results |
--break |
false |
Break build on Veracode platform policy compliance failure (conflicts with --no-wait) |
| Option | Default | Description |
|---|---|---|
--app-profile-name <NAME> |
- | Veracode application profile name (required) |
--sandbox-name <NAME> |
- | Sandbox name for sandbox scan export (optional) |
--output <FILE> |
findings_export.json |
Output file path for exported findings |
--format <FORMAT> |
gitlab |
Export format (gitlab/json/csv/all) |
--min-severity <LEVEL> |
- | Filter by minimum severity (informational/very-low/low/medium/high/very-high) |
--project-dir <DIR> |
. |
Project directory for file path resolution in GitLab reports |
--gitlab-schema <VERSION> |
15.2.1 |
GitLab SAST report schema version (15.2.1, 15.2.2, or 15.2.3) - applies to gitlab format exports (global option) |
--debug |
false |
Enable detailed diagnostic output (global option) |
| Option | Default | Description |
|---|---|---|
--export-findings <FILE> |
- | Export findings to file |
--export-format <FORMAT> |
json |
json/csv/gitlab/all |
--show-findings |
false |
Display findings in CLI |
--findings-limit <NUM> |
20 |
Limit displayed findings (0=all) |
--min-severity <LEVEL> |
- | Filter by minimum severity |
| Option | Description |
|---|---|
--baseline-file <FILE> |
Baseline file for comparison |
--policy-file <FILE> |
Local policy file path |
--policy-name <NAME> |
Veracode platform policy name |
--filtered-json-output-file <FILE> |
Policy violations export |
--fail-on-severity <LEVELS> |
Fail on severity levels (comma-separated) |
--fail-on-cwe <IDS> |
Fail on CWE IDs (comma-separated) |
| Option | Description |
|---|---|
--create-gitlab-issues |
Create GitLab issues from findings |
--project-dir <PATH> |
Project root for file path resolution |
| Option | Description |
|---|---|
--debug |
Enable detailed diagnostic output |
--request-policy <NAME> |
Download policy by name |
Create .gitlab-ci.yml:
stages:
- security
security_scan:
stage: security
image: rust:latest
variables:
VERACODE_API_ID: $VERACODE_API_ID
VERACODE_API_KEY: $VERACODE_API_KEY
before_script:
- cargo build --release
script:
- ./target/release/verascan --pipeline-scan --filepath ./target
--baseline-file security-baseline.json
--export-format gitlab
--export-findings gl-sast-report.json
--fail-on-severity "High,Very High"
--create-gitlab-issues
artifacts:
reports:
sast: gl-sast-report.json
paths:
- security-violations.json
expire_in: 1 week
when: always
only:
- merge_requests
- mainNEW: This project now includes comprehensive GitHub Actions workflows in .github/workflows/:
build.yml: Continuous integration with formatting checks, clippy linting, and testingrelease.yml: Simple release workflow for tagged releasesmultiplatform.yml: Cross-platform builds for Linux, Windows, and macOS
name: Security Scan
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions-rs/toolchain@v1
with:
toolchain: stable
- name: Build Verascan
run: cargo build --release
- name: Security Scan
env:
VERACODE_API_ID: ${{ secrets.VERACODE_API_ID }}
VERACODE_API_KEY: ${{ secrets.VERACODE_API_KEY }}
run: |
./target/release/verascan --pipeline-scan --filepath . \
--fail-on-severity "High,Very High" \
--export-findings security-results.json
- uses: actions/upload-artifact@v3
with:
name: security-results
path: security-results.jsonpipeline {
agent any
environment {
VERACODE_API_ID = credentials('veracode-api-id')
VERACODE_API_KEY = credentials('veracode-api-key')
}
stages {
stage('Security Scan') {
steps {
sh '''
cargo build --release
./target/release/verascan --pipeline-scan --filepath ./target \
--fail-on-severity "High,Very High" \
--baseline-file baseline.json \
--export-findings security-results.json
'''
}
post {
always {
archiveArtifacts artifacts: 'security-results.json'
}
}
}
}
}[dependencies]
veracode-platform = { path = "veracode-api" }
# Or if published to crates.io:
# veracode-platform = "0.4.1"use veracode_platform::{VeracodeConfig, VeracodeRegion};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Configure client
let config = VeracodeConfig::new(
"your-api-id".to_string(),
"your-api-key".to_string(),
VeracodeRegion::Commercial,
);
// Use the API
let client = veracode_platform::Client::new(config);
let apps = client.get_applications().await?;
println!("Found {} applications", apps.len());
Ok(())
}# Application lifecycle management
cargo run --example application_lifecycle -p veracode-api
# Pipeline scan workflow
cargo run --example pipeline_scan_lifecycle -p veracode-api
# Policy management
cargo run --example policy_lifecycle -p veracode-api
# Identity and user management
cargo run --example identity_lifecycle -p veracode-api
# Sandbox operations
cargo run --example sandbox_lifecycle -p veracode-api# GitLab integration example
./verascan/examples/gitlab_issues_example.sh
# Manual testing
cargo run --example manual_test_example -p verascan
# Independent GitLab testing
./verascan/examples/test_independent_gitlab.sh# Build everything
cargo build
# Build in release mode (optimized)
cargo build --release
# Build specific package
cargo build -p veracode-api
cargo build -p verascan
cargo build -p veracmek# Run all tests
cargo test
# Run tests for specific package
cargo test -p veracode-api
cargo test -p verascan
cargo test -p veracmek
# Run with output
cargo test -- --nocapture# Check code style
cargo clippy
# Format code
cargo fmt
# Check formatting
cargo fmt -- --check# Build and open documentation
cargo doc --open
# Build documentation for all packages
cargo doc --workspace# Comprehensive debug output with secure credential handling
verascan --debug --pipeline-scan --filepath . --export-findings results.jsonSecurity Note: Debug mode is now safe to use in production environments. All sensitive credentials (Veracode API keys, GitLab tokens, Git passwords) are automatically redacted as [REDACTED] in debug output.
Debug output includes:
- File discovery and validation process
- API request/response details
- Policy evaluation and baseline comparison
- Export operations and file writing
- Enhanced Security: All sensitive tokens are automatically redacted in debug logs
- Veracode API credentials (
VERACODE_API_ID,VERACODE_API_KEY) are securely wrapped - GitLab private tokens are protected with secure wrappers
- Custom Debug implementations prevent accidental credential exposure
- Veracode API credentials (
- Safe URL Logging: Git URLs with passwords are redacted as
username:[REDACTED]@host - Comprehensive Protection: 18+ tests ensure security measures work correctly
β Veracode API credentials are invalid
Solution: Verify VERACODE_API_ID and VERACODE_API_KEY environment variables.
Security Note: All API credentials are automatically secured with protective wrappers that prevent accidental exposure in logs. Your credentials are safe even in debug mode.
β οΈ No files found matching pattern: *.jar
Solutions:
- Check file patterns:
--filefilter "*.jar,*.war" - Verify directory path:
--filepath /correct/path - Enable debug mode:
--debug
β Failed to create GitLab issues: 401 Unauthorized
Solutions:
- Verify
PRIVATE_TOKENenvironment variable - Check token has
apiandwrite_repositoryscopes - Confirm
CI_PROJECT_IDis correct - Note: Private tokens are automatically redacted in debug logs for security
β GitLab issue links not working correctly
Solutions:
- This has been fixed by removing the problematic
ref_type=headsparameter - GitLab line number links now work correctly in issue descriptions
# High throughput for large file sets
verascan --threads 8 --timeout 60 --pipeline-scan --filepath .
# Conservative settings for limited resources
verascan --threads 2 --timeout 30 --pipeline-scan --filepath .| Code | Meaning |
|---|---|
0 |
Success - no policy violations found |
1 |
Policy violations detected or scan errors |
2 |
Configuration or authentication errors |
4 |
Veracode platform policy failure (when using --break flag) |
| Level | Numeric | Aliases |
|---|---|---|
| Informational | 0 | info |
| Very Low | 1 | very-low, verylow, very_low |
| Low | 2 | - |
| Medium | 3 | med |
| High | 4 | - |
| Very High | 5 | very-high, veryhigh, very_high, critical |
Verascan automatically detects and validates:
- Java: JAR, WAR, EAR files
- Archives: ZIP, TAR, TAR.GZ, TAR.BZ2
- Executables: ELF, PE, Mach-O binaries
- Libraries: SO, DLL, DYLIB files
- Source packages: Various compressed source code formats
File type detection uses magic byte analysis, not just file extensions.
This project implements industry-leading security measures to protect all sensitive credentials:
- All sensitive tokens show
[REDACTED]in debug output - Veracode API credentials (
VERACODE_API_ID,VERACODE_API_KEY) are securely wrapped - GitLab private tokens are protected with secure containers
- Git repository passwords are redacted in URL logging
// Example: Veracode API credentials are automatically secured
let config = VeracodeConfig::new(
env::var("VERACODE_API_ID")?,
env::var("VERACODE_API_KEY")?,
);
// Debug output safely shows:
// VeracodeConfig { api_id: [REDACTED], api_key: [REDACTED], ... }
println!("{:?}", config);- Debug mode can be safely enabled in production environments
- Comprehensive logging without credential exposure
- All sensitive information is automatically sanitized
- All existing code continues to work unchanged
- No breaking changes to public APIs
- Security improvements are transparent to users
- Examples and documentation remain valid
- 18+ security-focused tests ensure protection works correctly
- Debug redaction verified for all credential types
- Integration tests confirm secure credential handling
- Continuous validation of security measures
- Environment Variables: Store credentials in environment variables, never in code
- Debug Safety: Debug mode is now production-safe with automatic redaction
- Token Scopes: Use minimum required scopes for GitLab and Veracode tokens
- Regular Updates: Keep dependencies updated for security patches
- Access Control: Limit access to systems with these credentials
| Region | Description | API Endpoint |
|---|---|---|
commercial |
US Commercial Cloud (default) | analysiscenter.veracode.com |
european |
European Union Cloud | analysiscenter.veracode.eu |
federal |
US Federal Cloud | analysiscenter.veracode.us |
Licensed under either of:
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT License (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
- Fork the repository
- Create a feature branch (
git checkout -b feature/amazing-feature) - Commit your changes (
git commit -m 'Add amazing feature') - Push to the branch (
git push origin feature/amazing-feature) - Open a Pull Request
- π Documentation: See DOCUMENTATION.md for detailed usage guide
- π Issues: Report bugs and request features via GitHub Issues
- π¬ Discussions: Join community discussions for help and best practices
Built with β€οΈ in Rust for the security community