Fortify Ssc

SSC may also be referred to as "Fortify Software Security Center".

Disambiguate "scan" / "review" first

These terms are overloaded. If ambiguous ("run a Fortify scan/review", "run a security review"), confirm user intent first:

• scan → 1) full ScanCentral SAST/DAST scan of the codebase (this skill), or 2) lightweight AI review of local code changes (fortify-change-review).
• review → 1) triage issues already found by SSC (this skill), or 2) lightweight AI review of local code changes (fortify-change-review).

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

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

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

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

SSC Logical Structure and Nomenclature

• Applications — top-level organizational unit; one per software project. In fcli --query expressions and fcli output, the field is always application (e.g., application.name, application.id) — never project.name. The "project" wording only appears in raw REST paths (/api/v1/projects/) and a handful of legacy ID-only fields like projectVersionId. Do not use project.* as a query field.
• Application Versions — versions/branches within an application (e.g., main, v2.1); each holds independent scan results and issues. A version can be seeded by copying state from another.
• Artifacts — FPR files uploaded to an application version containing scan results from one or more scan engines. After SSC processes an artifact, issues are updated on the version.
• Issues — vulnerabilities found by scans; always scoped to an application version.
• Custom Tags — tenant-defined metadata fields for auditing issues (e.g., Analysis, Comment). These are the primary mechanism for recording audit decisions in SSC.
• Filter Sets — rulesets that control how issues are grouped into priority folders. The default is "Security Auditor View" (Critical/High/Medium/Low).
• Performance Indicators — computed percentage metrics (e.g., % Critical Audited).
• Variables — tenant-defined numeric metrics derived from issue counts.

Teams typically structure SSC with one application per repo and versions per branch or environment (e.g., main, v25.1, staging).

Key Concepts

Issue Priority (Fortify Priority Order)

SSC organizes issues into named folders within a filter set using the Fortify Priority Order (FPO): Critical, High, Medium, Low. The friority field (note: historical typo) is the primary priority indicator used in the UI and in queries. Do not confuse with the raw severity score (0.0–5.0).

Scan Status (system-assigned per scan cycle)

NEW (first seen in latest scan), UPDATED (seen before, seen again), REINTRODUCED (was removed, now re-detected). Use --query "scanStatus=='NEW'" etc.

Issue Visibility and --include

By default fcli ssc issue list returns visible (non-suppressed, non-removed) issues only.

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

Visibility states: visible, suppressed (audit decision), removed (not found in latest scan), hidden (filtered by active filter).

Audit Decisions — Custom Tags

SSC audit decisions are recorded via custom tags, not a fixed status enum. The most common is the Analysis tag with values like Not an Issue, Exploitable, Reliability Issue, Suspicious. The exact tags and values available depend on the tenant configuration. Use fcli ssc custom-tag list --av=<appVersionNameOrId> to discover them.

Suppression in SSC is an explicit boolean: --suppress=true via fcli ssc issue update. It is independent of custom tag values.

Stable Issue Identity

Always use issueInstanceId (32-character hex string) as the canonical key for correlating the same issue across scans or versions. Do NOT use id (numeric, changes on reprocessing) for deduplication. Note: FoD calls the equivalent field instanceId.

--av: The Only Version Identifier for Issue and Artifact Commands

fcli ssc issue list, fcli ssc issue get, fcli ssc issue update, fcli ssc artifact list, and all other version-scoped commands use --av as the sole version identifier. There is no separate --app or --version flag on these commands — do not invent one.

--av accepts a bare numeric version ID or a name string:

• Numeric ID (preferred when known): --av=20001
• Name string: --av="MyApp:main"

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

Querying Applications and Versions — Use --query, Not --app

fcli ssc app list and fcli ssc appversion list have no --app flag either. To filter them by application name, use --query:

# Find an application by name
fcli ssc app list --query "name=='Solidity Example'" -o json

# Find all versions of an application
fcli ssc appversion list --query "application.name=='Solidity Example'" -o json

# Find one specific version
fcli ssc appversion list --query "application.name=='Solidity Example' && name=='main'" -o json

The query field on appversion list is application.name (the version object embeds the parent application as application). It is not project.name, app.name, or applicationName — those are wrong on SSC. Names are case-sensitive. See references/resolving-appversion.md for fuzzy matching, delimiters, and --store chaining.

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, error states, and safety steps specific to each workflow. If a request spans multiple use cases, load all relevant files before proceeding.

Never bypass fcli for SSC API access

All SSC 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 SSC 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 ssc 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 ssc modules and sub-commands, run fcli ssc -h or fcli ssc <module> -h.