Updated 10 modules to use the new create_finding() signature with required rule_id and found_by parameters:
- llm_analyzer.py: Added FoundBy and LLMContext for AI-detected findings
- bandit_analyzer.py: Added tool attribution and moved CWE/confidence to proper fields
- security_analyzer.py: Updated all three finding types (secrets, SQL injection, dangerous functions)
- mypy_analyzer.py: Added tool attribution and moved column info to column_start
- mobsf_scanner.py: Updated all 6 finding types (permissions, manifest, code analysis, behavior) with proper line number handling
- opengrep_android.py: Added tool attribution, proper CWE/OWASP formatting, and confidence mapping
- dependency_scanner.py: Added pip-audit attribution for CVE findings
- file_scanner.py: Updated both sensitive file and enumeration findings
- cargo_fuzzer.py: Added fuzzer type attribution for crash findings
- atheris_fuzzer.py: Added fuzzer type attribution for Python crash findings
All modules now properly track:
- Finding source (module, tool name, version, type)
- Confidence levels (high/medium/low)
- CWE and OWASP mappings where applicable
- LLM context for AI-detected issues
Priority 3 implementation:
**Improved Table Display:**
- Removed hardcoded 50-result limit
- Added pagination with --limit and --offset parameters
- New table columns: Finding ID (8 chars), Confidence (H/M/L), Found By
- Supports both native and SARIF formats with auto-detection
- Proper severity ordering (critical > high > medium > low > info)
- Pagination footer showing "Showing X-Y of Z results"
**Syntax Highlighting:**
- Added syntax-highlighted code snippets using Rich's Syntax
- Auto-detects language from file extension (20+ languages supported)
- Line numbers with correct start line from finding location
- Monokai theme for better readability
**Enhanced Detail View:**
- Confidence indicators with emoji (🟢 High, 🟡 Medium, 🔴 Low)
- Type-specific badges (🤖 LLM, 🔧 Tool, 🎯 Fuzzer, 👤 Manual)
- LLM context display with model name and prompt preview
- Better formatted found_by info with module and type
- Added suggestion to view all findings with same rule
- Cleaner recommendation display with 💡 icon
**New Commands:**
- Added 'ff findings by-rule' command to show all findings matching a rule
- Registered as @app.command("by-rule")
**Updated Related Commands:**
- all_findings: Updated to use 5-level severity (critical/high/medium/low/info)
- Table columns changed from Error/Warning/Note to Critical/High/Medium/Low
- Summary panel updated with proper severity mapping
- Support for both native and SARIF format findings_data
**Breaking Changes:**
- Severity display changed from 3-level (error/warning/note) to 5-level
- Table structure modified with new columns
- Old SARIF-only views deprecated in favor of format-agnostic displays
- Renamed sarif_reporter.py to native_reporter.py to reflect new functionality
- Updated WorkflowFindings model to use native format
- Field name 'sarif' kept for API compatibility but now contains native format
- Updated docstring to reflect native format usage
- Converted SARIFReporter to Native Reporter:
- Module name changed from sarif_reporter to native_reporter (v2.0.0)
- Updated metadata and input/output schemas
- Removed SARIF-specific config (tool_name, include_code_flows)
- Added native format config (workflow_name, run_id)
- Implemented native report generation:
- Added _generate_native_report() method
- Generates native FuzzForge format with full field support:
- Unique finding IDs
- found_by attribution (module, tool, type)
- LLM context when applicable
- Full severity scale (critical/high/medium/low/info)
- Confidence levels
- CWE and OWASP mappings
- Enhanced location info (columns, snippets)
- References and metadata
- Added _create_native_summary() for aggregated stats
- Summary includes counts by severity, confidence, category, source, and type
- Tracks affected files count
- Kept old SARIF generation methods for reference
- Will be moved to separate SARIF exporter module
Breaking changes:
- Reporter now outputs native format instead of SARIF
- Existing workflows using sarif_reporter will need updates
- Config parameters changed (tool_name -> workflow_name, etc.)
- Renamed FindingRecord.sarif_data to findings_data
- Updated database schema: sarif_data column -> findings_data column
- Updated all database methods to work with native format:
- save_findings()
- get_findings()
- list_findings()
- get_all_findings()
- get_aggregated_stats()
- Updated SQL queries to use native format JSON paths:
- Changed from SARIF paths ($.runs[0].results) to native paths ($.findings)
- Updated severity filtering from SARIF levels (error/warning/note) to native (critical/high/medium/low/info)
- Updated CLI commands to support both formats during transition:
- get_findings command now extracts summary from both native and SARIF formats
- show_finding and show_findings_by_rule updated to use findings_data field
- Format detection to handle data from API (still SARIF) and database (native)
Breaking changes:
- Database schema changed - existing databases will need recreation
- FindingRecord.sarif_data renamed to findings_data
Priority 1 implementation:
- Created native FuzzForge findings format schema with full support for:
- 5-level severity (critical/high/medium/low/info)
- Confidence levels
- CWE and OWASP categorization
- found_by attribution (module, tool, type)
- LLM context tracking (model, prompt, temperature)
- Updated ModuleFinding model with new fields:
- Added rule_id for pattern identification
- Added found_by for detection attribution
- Added llm_context for LLM-detected findings
- Added confidence, cwe, owasp, references
- Added column_start/end for precise location
- Updated create_finding() helper with new required fields
- Enhanced _generate_summary() with confidence and source tracking
- Fixed critical ID bug in CLI:
- Changed 'ff finding show' to use --id (unique) instead of --rule
- Added new show_findings_by_rule() function to show ALL findings matching a rule
- Updated display_finding_detail() to support both native and SARIF formats
- Now properly handles multiple findings with same rule_id
Breaking changes:
- create_finding() now requires rule_id and found_by parameters
- show_finding() now uses --id instead of --rule flag
- Add Unreleased section for post-v0.7.3 documentation updates
- Add v0.7.2 entry with bug fixes and worker improvements
- Document that v0.7.1 was re-tagged as v0.7.2
- Fix v0.6.0 date to "Undocumented" (no tag exists)
- Add version comparison links for easier navigation
MobSF returns 'files' as a dict (not list):
{"filename": "line_numbers"}
The parser was treating it as a list, causing zero findings
to be extracted. Now properly iterates over the dict and
creates one finding per affected file with correct line numbers
and metadata (CWE, OWASP, MASVS, CVSS).
Fixed in both code_analysis and behaviour sections.
Add comprehensive CLI commands for managing Temporal workers:
- ff worker list - List workers with status and uptime
- ff worker start <name> - Start specific worker with optional rebuild
- ff worker stop - Safely stop all workers without affecting core services
Improvements:
- Live progress display during worker startup with Rich Status spinner
- Real-time elapsed time counter and container state updates
- Health check status tracking (starting → unhealthy → healthy)
- Helpful contextual hints at 10s, 30s, 60s intervals
- Better timeout messages showing last known state
Worker management enhancements:
- Use 'docker compose' (space) instead of 'docker-compose' (hyphen)
- Stop workers individually with 'docker stop' to avoid stopping core services
- Platform detection and Dockerfile selection (ARM64/AMD64)
Documentation:
- Updated docker-setup.md with CLI commands as primary method
- Created comprehensive cli-reference.md with all commands and examples
- Added worker management best practices
Resolves validation error where agent_url was None when not explicitly provided. The TemporalManager applies defaults from metadata.yaml, not from module input schemas, so all parameters need defaults in the workflow metadata.
Changes:
- Add default agent_url, llm_model (gpt-5-mini), llm_provider (openai)
- Expand file_patterns to 45 comprehensive patterns covering code, configs, secrets, and Docker files
- Increase default limits: max_files (10), max_file_size (100KB), timeout (90s)
* feat: seed governance config and responses routing
* Add env-configurable timeout for proxy providers
* Integrate LiteLLM OTEL collector and update docs
* Make .env.litellm optional for LiteLLM proxy
* Add LiteLLM proxy integration with model-agnostic virtual keys
Changes:
- Bootstrap generates 3 virtual keys with individual budgets (CLI: $100, Task-Agent: $25, Cognee: $50)
- Task-agent loads config at runtime via entrypoint script to wait for bootstrap completion
- All keys are model-agnostic by default (no LITELLM_DEFAULT_MODELS restrictions)
- Bootstrap handles database/env mismatch after docker prune by deleting stale aliases
- CLI and Cognee configured to use LiteLLM proxy with virtual keys
- Added comprehensive documentation in volumes/env/README.md
Technical details:
- task-agent entrypoint waits for keys in .env file before starting uvicorn
- Bootstrap creates/updates TASK_AGENT_API_KEY, COGNEE_API_KEY, and OPENAI_API_KEY
- Removed hardcoded API keys from docker-compose.yml
- All services route through http://localhost:10999 proxy
* Fix CLI not loading virtual keys from global .env
Project .env files with empty OPENAI_API_KEY values were overriding
the global virtual keys. Updated _load_env_file_if_exists to only
override with non-empty values.
* Fix agent executor not passing API key to LiteLLM
The agent was initializing LiteLlm without api_key or api_base,
causing authentication errors when using the LiteLLM proxy. Now
reads from OPENAI_API_KEY/LLM_API_KEY and LLM_ENDPOINT environment
variables and passes them to LiteLlm constructor.
* Auto-populate project .env with virtual key from global config
When running 'ff init', the command now checks for a global
volumes/env/.env file and automatically uses the OPENAI_API_KEY
virtual key if found. This ensures projects work with LiteLLM
proxy out of the box without manual key configuration.
* docs: Update README with LiteLLM configuration instructions
Add note about LITELLM_GEMINI_API_KEY configuration and clarify that OPENAI_API_KEY default value should not be changed as it's used for the LLM proxy.
* Refactor workflow parameters to use JSON Schema defaults
Consolidates parameter defaults into JSON Schema format, removing the separate default_parameters field. Adds extract_defaults_from_json_schema() helper to extract defaults from the standard schema structure. Updates LiteLLM proxy config to use LITELLM_OPENAI_API_KEY environment variable.
* Remove .env.example from task_agent
* Fix MDX syntax error in llm-proxy.md
* fix: apply default parameters from metadata.yaml automatically
Fixed TemporalManager.run_workflow() to correctly apply default parameter
values from workflow metadata.yaml files when parameters are not provided
by the caller.
Previous behavior:
- When workflow_params was empty {}, the condition
`if workflow_params and 'parameters' in metadata` would fail
- Parameters would not be extracted from schema, resulting in workflows
receiving only target_id with no other parameters
New behavior:
- Removed the `workflow_params and` requirement from the condition
- Now explicitly checks for defaults in parameter spec
- Applies defaults from metadata.yaml automatically when param not provided
- Workflows receive all parameters with proper fallback:
provided value > metadata default > None
This makes metadata.yaml the single source of truth for parameter defaults,
removing the need for workflows to implement defensive default handling.
Affected workflows:
- llm_secret_detection (was failing with KeyError)
- All other workflows now benefit from automatic default application
Co-authored-by: tduhamel42 <tduhamel@fuzzinglabs.com>
Updated worker validation script to accept both:
- Single Dockerfile pattern (existing workers)
- Multi-platform Dockerfile pattern (Dockerfile.amd64, Dockerfile.arm64, etc.)
This enables platform-aware worker architectures like the Android worker
which uses different Dockerfiles for x86_64 and ARM64 platforms.
Implement platform-specific Dockerfile selection and graceful tool degradation to support both x86_64 and ARM64 (Apple Silicon) platforms.
**Backend Changes:**
- Add system info API endpoint (/system/info) exposing host filesystem paths
- Add FUZZFORGE_HOST_ROOT environment variable to backend service
- Add graceful degradation in MobSF activity for ARM64 platforms
**CLI Changes:**
- Implement multi-strategy path resolution (backend API, .fuzzforge marker, env var)
- Add platform detection (linux/amd64 vs linux/arm64)
- Add worker metadata.yaml reading for platform capabilities
- Auto-select appropriate Dockerfile based on detected platform
- Pass platform-specific env vars to docker-compose
**Worker Changes:**
- Create workers/android/metadata.yaml defining platform capabilities
- Rename Dockerfile -> Dockerfile.amd64 (full toolchain with MobSF)
- Create Dockerfile.arm64 (excludes MobSF due to Rosetta 2 incompatibility)
- Update docker-compose.yml to use ${ANDROID_DOCKERFILE} variable
**Workflow Changes:**
- Handle MobSF "skipped" status gracefully in workflow
- Log clear warnings when tools are unavailable on platform
**Key Features:**
- Automatic platform detection and Dockerfile selection
- Graceful degradation when tools unavailable (MobSF on ARM64)
- Works from any directory (backend API provides paths)
- Manual override via environment variables
- Clear user feedback about platform and selected Dockerfile
**Benefits:**
- Android workflow now works on Apple Silicon Macs
- No code changes needed for other workflows
- Convention established for future platform-specific workers
Closes: MobSF Rosetta 2 incompatibility issue
Implements: Platform-aware worker architecture (Option B)
- Fix activity names in workflow.py (get_target, upload_results, cleanup_cache)
- Fix MobSF API key generation in Dockerfile startup script (cut delimiter)
- Update activity parameter signatures to match actual implementations
- Workflow now executes successfully with Jadx and OpenGrep
- Remove unused Literal import from backend findings model
- Remove unnecessary f-string prefixes in CLI findings command
- Optimize GitHub Actions to build only modified workers
- Detect specific worker changes (python, secrets, rust, android, ossfuzz)
- Build only changed workers instead of all 5
- Build all workers if docker-compose.yml changes
- Significantly reduces CI build time
- Fix live monitoring style error by calling _live_monitor() helper directly
- Remove default_parameters duplication from 10 workflow metadata files
- Remove deprecated volume_mode parameter from 26 files across CLI, SDK, backend, and docs
- Configure Python worker to start automatically with docker compose up
- Clean up constants, validation, completion, and example files
Fixes #
- Live monitoring now works correctly with --live flag
- Workflow metadata follows JSON Schema standard
- Cleaner codebase without deprecated volume_mode
- Python worker (most commonly used) starts by default
Implements Issue #5 - Python SAST workflow that combines:
- Dependency scanning (pip-audit) for CVE detection
- Security linting (Bandit) for vulnerability patterns
- Type checking (Mypy) for type safety issues
## Changes
**New Modules:**
- `DependencyScanner`: Scans Python dependencies for known CVEs using pip-audit
- `BanditAnalyzer`: Analyzes Python code for security issues using Bandit
- `MypyAnalyzer`: Checks Python code for type safety issues using Mypy
**New Workflow:**
- `python_sast`: Temporal workflow that orchestrates all three SAST tools
- Runs tools in parallel for fast feedback (3-5 min vs hours for fuzzing)
- Generates unified SARIF report with findings from all tools
- Supports configurable severity/confidence thresholds
**Updates:**
- Added SAST dependencies to Python worker (bandit, pip-audit, mypy)
- Updated module __init__.py files to export new analyzers
- Added type_errors.py test file to vulnerable_app for Mypy validation
## Testing
Workflow tested successfully on vulnerable_app:
- ✅ Bandit: Detected 9 security issues (command injection, unsafe functions)
- ✅ Mypy: Detected 5 type errors
- ✅ DependencyScanner: Ran successfully (no CVEs in test dependencies)
- ✅ SARIF export: Generated valid SARIF with 14 total findings
The previous condition used invalid GitHub context field.
Now uses git diff to properly detect changes to workers/ or docker-compose.yml.
Behavior:
- Job always runs the check step
- Detects if workers/ or docker-compose.yml modified
- Only builds Docker images if workers actually changed
- Shows clear skip message when no worker changes detected
The test workflow was configured for 'develop' but the actual branch is named 'dev'.
This caused tests not to run on PRs to dev branch.
Now tests will run on:
- PRs to: main, master, dev, develop
- Pushes to: main, master, dev, develop, feature/**
The secrets worker was being ignored due to broad gitignore pattern.
Added exception to allow workers/secrets/ directory while still ignoring actual secrets.
Files added:
- workers/secrets/Dockerfile
- workers/secrets/requirements.txt
- workers/secrets/worker.py
This PR addresses multiple issues and improvements across the CLI and backend:
**Worker Naming Fixes:**
- Fix worker container naming mismatch between CLI and docker-compose
- Update worker_manager.py to use docker compose commands with service names
- Remove worker_container field from workflows API, keep only worker_service
- Backend now correctly uses service names (worker-python, worker-secrets, etc.)
**Backend API Fixes:**
- Fix workflow name extraction from run_id in runs.py (was showing "unknown")
- Update monitor command suggestions from 'monitor stats' to 'monitor live'
**Monitor Command Consolidation:**
- Merge 'monitor stats' and 'monitor live' into single 'monitor live' command
- Add --once and --style flags for flexibility
- Remove all references to deprecated 'monitor stats' command
**Findings CLI Structure Improvements (Closes#18):**
- Move 'show' command from 'findings' (plural) to 'finding' (singular)
- Keep 'export' command in 'findings' (plural) as it exports all findings
- Remove broken 'analyze' command (imported non-existent function)
- Update all command suggestions to use correct paths
- Fix smart routing logic in main.py to handle new command structure
- Add export suggestions after viewing findings with unique timestamps
- Change default export format to SARIF (industry standard)
**Docker Compose:**
- Remove obsolete version field to fix deprecation warning
All commands tested and working:
- ff finding show <run-id> --rule <rule-id> ✓
- ff findings export <run-id> ✓
- ff finding <run-id> (direct viewing) ✓
- ff monitor live <run-id> ✓
Updated all documentation to reflect actual v0.7.0 workflow implementation:
Workflow name changes:
- Removed all references to non-existent workflows (static_analysis_scan,
secret_detection_scan, infrastructure_scan, penetration_testing_scan)
- Updated examples to use actual workflows (security_assessment, gitleaks_detection,
trufflehog_detection, llm_secret_detection)
- Deleted docs/docs/reference/workflows/static-analysis.md (described non-existent workflow)
Content corrections:
- Fixed workflow tool descriptions (removed incorrect Semgrep/Bandit references,
documented actual SecurityAnalyzer and FileScanner modules)
- Updated all workflow lists to show production-ready vs development status
- Fixed all example configurations to match actual workflow parameters
Module creation guide fixes:
- Fixed 4 path references: backend/src/toolbox → backend/toolbox
- Updated import statements in example code
Files updated:
- docs/index.md - workflow list, CLI example, broken tutorial links
- docs/docs/tutorial/getting-started.md - workflow list, example output, tool descriptions
- docs/docs/how-to/create-module.md - module paths and imports
- docs/docs/how-to/mcp-integration.md - workflow examples and list
- docs/docs/ai/prompts.md - workflow example
- docs/docs/reference/cli-ai.md - 3 workflow references
- Removed Docker Registry from execution layer diagram
- Updated diagram to show vertical workers with MinIO storage
- Removed obsolete COMPOSE_PROJECT_NAME from example configuration
Updated documentation to reflect v0.7.0 Temporal architecture which uses MinIO for storage instead of a Docker registry.
Major changes:
- getting-started.md: Added mandatory volumes/env/.env setup, removed registry config section, updated service list
- docker-setup.md: Complete rewrite focusing on system requirements and worker profiles instead of registry
- index.md: Replaced registry warning with environment file requirement
- troubleshooting.md: Removed all registry troubleshooting, added environment configuration issues
- Added exception in .gitignore for benchmark results directory
- Force-added comparison_report.md and comparison_results.json
- These files contain benchmark metrics, not actual secrets
- Fixes broken link in README to benchmark results
- Added exception in .gitignore for benchmark results directory
- Force-added comparison_report.md and comparison_results.json
- These files contain benchmark metrics, not actual secrets
- Fixes broken link in README to benchmark results
