# Fortify Ssc

> Perform tasks against Fortify SSC (Software Security Center): query applications/application versions; query & triage existing security issues in SSC; start & monitor full ScanCentral SAST/DAST scans or upload FPR artifacts; create app versions; policy and portfolio analysis. NOT for lightweight AI review of local code changes/diffs (use fortify-change-review).

- **Type:** Skill
- **Install:** `agentstack add skill-fortify-skills-fortify-ssc`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [fortify](https://agentstack.voostack.com/s/fortify)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [fortify](https://github.com/fortify)
- **Source:** https://github.com/fortify/skills/tree/main/skills/fortify-ssc
- **Website:** https://www.opentext.com/products/application-security

## Install

```sh
agentstack add skill-fortify-skills-fortify-ssc
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

>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)

```bash
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=` 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=` 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`:

```bash
# 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:

| File | When to load |
|------|--------------|
| `references/resolving-appversion.md` | Whenever you need to resolve an app or version name to an `--av` identifier and it isn't already explicit |
| `references/fcli-ssc-output-values.md` | Full field/enum reference for apps, versions, artifacts, issues, filter sets, attributes, performance indicators, variables |
| `references/fcli-ssc-output-samples.md` | Concrete JSON output examples for every object type (app, version, artifact, issue, issue count, filter set) |
| `references/fcli-query-output.md` | Detailed SpEL query syntax, null-safety patterns, output formats, `--store` variable chaining, server-side filtering, date utility functions |
| `references/output-formats.md` | Extended format options (`json-properties`, `--fetch=1`) and JSON processing scripting patterns |
| `references/fcli-install.md` | Full fcli installation and upgrade procedures |
| `references/mutating-operations.md` | Full safety rules for delete, create/update, access control, and REST mutations |
| `references/ssc-openapi-spec.json` | **Only** when constructing `fcli ssc rest` API calls — large file; load targeted sections only |
| `references/scdast-openapi-spec.json` | **Only** when constructing direct SC-DAST REST API calls (via `fcli sc-dast rest`) for operations not covered by named `fcli sc-dast` commands — large file; load targeted sections only |

## 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.

| Use Case | When to use | File |
|----------|-------------|------|
| **Portfolio Overview** | Broad view across many applications or versions — listing, counting, grouping by status or activity, identifying versions needing attention at scale | `references/use-case-portfolio-overview.md` |
| **Application Version Context** | Detail about a specific application or version; resolving app/version names and `--av` identifiers; comparing versions within the same app; checking version health and metrics | `references/use-case-application-version-context.md` |
| **Creating a Version** | Creating a new version within an existing SSC application for a branch, release, or environment | `references/use-case-create-version.md` |
| **Artifact Upload & Processing** | Uploading FPR scan results to an application version; monitoring artifact processing status; checking upload history; handling processing errors | `references/use-case-artifact-upload-processing.md` |
| **Issue Investigation** | Vulnerability counts and category breakdowns for a specific version; filtering to specific issues; reading issue details; triaging and bulk-updating audit status or suppression | `references/use-case-issue-investigation.md` |
| **Start a Scan** | Submitting a new SAST scan via ScanCentral SAST or a new DAST scan via ScanCentral DAST; choosing how to run the scan (web UI, CI/CD, IDE plugin, or CLI); packaging code; checking for in-progress scans; waiting for completion; summarizing results | `references/use-case-start-scan.md` |
| **ScanCentral SAST Scan Status** | Observing SC-SAST scan jobs (listing running/queued/completed/failed jobs, filtering by time or submitter, counting throughput); checking sensor and pool utilization; downloading FPRs, logs, or sensor logs from completed jobs | `references/use-case-scsast-scan-status.md` |
| **ScanCentral DAST Scan Status** | Observing SC-DAST scans (listing running/queued/paused/complete/failed scans, filtering by state, time window, app, or URL); checking finding counts; sensor health and pool membership; downloading FPRs, results, logs, settings, or site trees | `references/use-case-scdast-scan-status.md` |
| **Advanced / REST API** | Operations not covered by named fcli commands; direct SSC REST API calls; general fallback | `references/use-case-advanced.md` |

---

## 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  -h`.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [fortify](https://github.com/fortify)
- **Source:** [fortify/skills](https://github.com/fortify/skills)
- **License:** MIT
- **Homepage:** https://www.opentext.com/products/application-security

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-fortify-skills-fortify-ssc
- Seller: https://agentstack.voostack.com/s/fortify
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.