fortify-fod

Verify Active FoD Session (skip if already confirmed this conversation)

fcli fod session ls --query "expired=='No'"

No active FoD session found: Instruct the user to run fcli fod session login and confirm successful login before proceeding.

fcli not found: You interact with FoD using fcli. It must already be on the PATH. If it is not installed, load references/fcli-install.md.

FoD Logical Structure and Nomenclature

• Applications — top-level organizational unit; one per software project
• Microservices — optional grouping within an application; each microservice has its own releases. Most applications don’t use microservices.
• Releases — versions/branches within an application or microservice (e.g., main, v2.1); each holds independent scan results and issues. A release can be seeded by copying state from another.
• Scans — SAST (static), DAST (dynamic), SCA (open source / OSS), or MAST (mobile) analyses attached to a release
• Issues — vulnerabilities found by scans; always scoped to a release

Teams typically structure FoD with one app per repo and releases per branch or version (e.g., main, v25.1).

Key Concepts

Issue Status (system-assigned)

New (first seen), Existing (recurring), Reopened (was fixed), Fixed (not in latest scan, may be displayed as Fix Validated). Use --query "status=='New'" etc.

Auditor Status (security decision — controls visibility)

Auditor Status is the authoritative control for suppression. An unreviewed issue has status Pending Review.

• Suppressing (hidden from default views and metrics): Not an Issue, False Positive
• Non-suppressing (visible and policy-relevant): Remediation Required, Exploitable
• Suppression persists across scans (tracked via instanceId)
• Values are tenant-customizable; see references/fcli-fod-output-values.md for full details

Developer Status

Engineering workflow state (e.g., Open, In Progress, Fixed, Deferred). Tenant-customizable. Does not affect suppression or policy.

Visibility and --include

By default fcli fod issue list returns visible (non-suppressed) issues only. This is what users expect unless they ask otherwise.

• --include=visible,suppressed — add suppressed issues
• --include=visible,fixed — add fixed issues
• --include=visible,suppressed,fixed — all issues

Severity

severity is an integer: 4=Critical, 3=High, 2=Medium, 1=Low. severityString is the human-readable equivalent.

Issue Counting

FoD does not have a dedicated issue count command. For severity totals, use precomputed release-level aggregate fields (critical, high, medium, low, issueCount) from fcli fod release get — this is fast and doesn’t require listing issues. For filtered counts or category breakdowns, use fcli fod issue list with -o json and count the results. See the Issue Investigation use case for patterns.

Open Source / SCA Components

FoD tracks open source component data from SCA scans (Debricked, Sonatype, or imported CycloneDX SBOMs). Release-level fields (openSourceCritical, openSourceHigh, etc.) provide aggregate vulnerability counts. For component-level detail — CVE impact triage, license risk, SBOM export — use the OSS Component Analysis use case.

Fortify Aviator (AI-Assisted Audit)

FoD’s Aviator feature provides AI-assisted issue review and remediation guidance. Issues with aviatorRemediationGuidanceAvailable==true have AI-generated fix recommendations. See references/fcli-fod-output-values.md for Aviator field definitions.

Stable Issue Identity

Always use instanceId (UUID) as the canonical key for correlating the same issue across scans or releases. Do NOT use id (numeric) for deduplication. Note: SSC calls the equivalent field issueInstanceId.

--rel: The Only Release Identifier for Issue and Scan Commands

fcli fod issue list, fcli fod issue get, fcli fod issue update, and all scan commands use --rel as the sole release identifier. There is no separate --app or --release flag on these commands — do not invent one.

--rel accepts a bare numeric release ID or a name string:

• Numeric ID (preferred when known): --rel=1450004
• Name string: --rel="MyApp:main" or --rel="MyApp:svc:main"

When the user supplies a numeric release ID, use it directly as --rel=<id> and skip all name-resolution steps. A numeric release ID is globally unique in FoD — no app context is required alongside it.

Reference Files

Load these only when needed for the specific task at hand:

Use Case Files

Read the corresponding file before proceeding with any use case. Do not generate commands from memory — these files contain required command patterns, rate-limit warnings, and safety steps specific to each workflow. If a request spans multiple use cases, load all relevant files before proceeding.

Never bypass fcli for FoD API access

All FoD API access must go through fcli — including when fcli seems slow or limited. Never read fcli’s session or state files (~/.fortify/fcli/state, $FCLI_STATE_DIR), extract tokens or credentials from disk, or call FoD APIs directly with curl, wget, requests, Invoke-WebRequest, or any other HTTP client. The supported escape hatch for endpoints not covered by a named command is fcli fod rest call. If fcli is genuinely unworkable for the task, tell the user — do not work around it.

Safety Rules for Mutating Operations

These rules are mandatory. Before executing any create, update, delete, or REST mutation command, load and follow references/mutating-operations.md. Read-only commands (list, get, ls) are always safe without confirmation.

Output Formats

Prefer -o json for programmatic work. Parse JSON and summarize rather than relying on table output, which omits fields and truncates values.

For extended format options and JSON processing patterns, see references/output-formats.md. For --query SpEL syntax and --store chaining, see references/fcli-query-output.md.

For available fcli fod modules and sub-commands, run fcli fod -h or see references/fcli-fod-output-values.md.