Add Fortify AST Scan workflow

[xerudro]

This workflow integrates Fortify Application Security Testing into GitHub workflows, enabling SAST and SCA scans.

Summary by CodeRabbit

• Chores
  • Added Fortify AST scanning integration to the continuous integration pipeline for enhanced security analysis of code changes.

[coderabbitai]

Walkthrough

A new GitHub Actions workflow file is added to integrate Fortify AST scanning into the CI/CD pipeline. The workflow triggers on pushes to main, pull requests, scheduled intervals, and manual dispatch, executing a single Fortify scan job with SAST and Debricked configurations for both Fortify on Demand and Software Security Center environments.

Changes

Cohort / File(s)	Change Summary
Fortify AST Scan Workflow \.github/workflows/fortify\.yml	New GitHub Actions workflow file added to integrate Fortify security scanning into CI pipeline with configurable triggers, SAST/Debricked scanning options, and extensive environment variable support for FoD and SSC authentication, setup, job summaries, and PR comments

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify environment variable naming conventions and security token handling align with Fortify documentation
• Confirm trigger conditions (push, pull_request, schedule, workflow_dispatch) match intended deployment strategy
• Check that commented-out optional configurations are correctly documented for future use

Poem

A workflow of might, in YAML so bright,
Fortify guards with its scanning light ✨🐰
From code to the cloud, vulnerabilities shroud,
AST scans run proud, keeping repos safe and loud! 🛡️

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Add Fortify AST Scan workflow" directly and clearly describes the primary change in the changeset. The PR adds a new GitHub Actions workflow file (.github/workflows/fortify.yml) that integrates Fortify Application Security Testing into the CI/CD pipeline. The title is concise, uses specific language ("Add" and "Fortify AST Scan workflow"), and avoids vague terminology or noise. A developer scanning the repository history would immediately understand that this PR introduces Fortify scanning capabilities without needing to examine the implementation details.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch xerudro-patch-2

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull Request Overview

This PR adds a GitHub Actions workflow for Fortify Application Security Testing (AST) to enable automated security scanning of the codebase. The workflow integrates both SAST (Static Application Security Testing) and SCA (Software Composition Analysis) capabilities.

• Adds automated Fortify security scanning triggered on pushes, pull requests, schedule, and manual dispatch
• Configures dual integration support for both Fortify on Demand (FoD) and Fortify Hosted/Software Security Center (SSC)
• Enables SAST and Debricked SCA scanning with extensive customization options

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Both Fortify on Demand and SSC/ScanCentral configurations are active simultaneously (lines 68-96 and 102-129). This creates ambiguity about which service is being used and may cause conflicts. The workflow should enable only one integration at a time - either comment out the FoD section (lines 64-96) or the SSC section (lines 98-129) based on which service is actually being used.

Suggested change

	#############################################################
	##### Fortify on Demand configuration
	##### Remove this section if you're integrating with Fortify Hosted/Software Security Center (see below)
	### Required configuration
	FOD_URL: https://ams.fortify.com # Must be hardcoded or configured through GitHub variable, not secret
	FOD_TENANT: ${{secrets.FOD_TENANT}} # Either tenant/user/password or client id/secret are required;
	FOD_USER: ${{secrets.FOD_USER}} # these should be configured through GitHub secrets.
	FOD_PASSWORD: ${{secrets.FOD_PAT}}
	# FOD_CLIENT_ID: ${{secrets.FOD_CLIENT_ID}}
	# FOD_CLIENT_SECRET: ${{secrets.FOD_CLIENT_SECRET}}
	### Optional configuration
	# FOD_LOGIN_EXTRA_OPTS: --socket-timeout=60s # Extra 'fcli fod session login' options
	# FOD_RELEASE: MyApp:MyRelease # FoD release name, default: <org>/<repo>:<branch>
	# DO_SETUP: true # Setup FoD application, release & static scan configuration
	# SETUP_ACTION: <URL or file> # Customize setup action
	# Pass extra options to setup action:
	# #############################################################
	# ##### Fortify on Demand configuration
	# ##### Remove this section if you're integrating with Fortify Hosted/Software Security Center (see below)
	# ### Required configuration
	# FOD_URL: https://ams.fortify.com # Must be hardcoded or configured through GitHub variable, not secret
	# FOD_TENANT: ${{secrets.FOD_TENANT}} # Either tenant/user/password or client id/secret are required;
	# FOD_USER: ${{secrets.FOD_USER}} # these should be configured through GitHub secrets.
	# FOD_PASSWORD: ${{secrets.FOD_PAT}}
	# FOD_CLIENT_ID: ${{secrets.FOD_CLIENT_ID}}
	# FOD_CLIENT_SECRET: ${{secrets.FOD_CLIENT_SECRET}}
	# ### Optional configuration
	# FOD_LOGIN_EXTRA_OPTS: --socket-timeout=60s # Extra 'fcli fod session login' options
	# FOD_RELEASE: MyApp:MyRelease # FoD release name, default: <org>/<repo>:<branch>
	# DO_SETUP: true # Setup FoD application, release & static scan configuration
	# SETUP_ACTION: <URL or file> # Customize setup action
	# # Pass extra options to setup action:

[Copilot]

Both Fortify on Demand and SSC/ScanCentral configurations are active simultaneously (lines 68-96 and 102-129). This creates ambiguity about which service is being used and may cause conflicts. The workflow should enable only one integration at a time - either comment out the FoD section (lines 64-96) or the SSC section (lines 98-129) based on which service is actually being used.

Suggested change

	#############################################################
	##### Fortify Hosted / Software Security Center & ScanCentral
	##### Remove this section if you're integrating with Fortify on Demand (see above)
	### Required configuration
	SSC_URL: ${{vars.SSC_URL}} # Must be hardcoded or configured through GitHub variable, not secret
	SSC_TOKEN: ${{secrets.SSC_TOKEN}} # SSC CIToken; credentials should be configured through GitHub secrets
	SC_SAST_TOKEN: ${{secrets.SC_CLIENT_AUTH_TOKEN}} # ScanCentral SAST client_auth_token, required if SAST scan is enabled
	DEBRICKED_TOKEN: ${{secrets.DEBRICKED_TOKEN}} # Debricked token, required if Debricked scan is enabled
	SC_SAST_SENSOR_VERSION: 24.4.0 # Sensor version to use for the scan, required if SAST scan is enabled
	### Optional configuration
	# SSC_LOGIN_EXTRA_OPTS: --socket-timeout=60s # Extra 'fcli ssc session login' options
	# SC_SAST_LOGIN_EXTRA_OPTS: --socket-timeout=60s # Extra 'fcli sc-sast session login' options
	# SSC_APPVERSION: MyApp:MyVersion # SSC application version name, default: <org>/<repo>:<branch>
	# DO_SETUP: true # Set up SSC application & version
	# SETUP_ACTION: <URL or file> # Customize setup action
	# SETUP_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to setup action
	# PACKAGE_EXTRA_OPTS: -bt mvn # Extra 'scancentral package' options
	# EXTRA_SC_SAST_SCAN_OPTS: # Extra 'fcli sc-sast scan start' options
	# DO_WAIT: true # Wait for successful scan completion (implied if post-scan actions enabled)
	# DO_POLICY_CHECK: true # Fail pipeline if security policy outcome is FAIL
	# POLICY_CHECK_ACTION: <URL or file> # Customize security policy checks
	# POLICY_CHECK_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to policy check action
	# DO_JOB_SUMMARY: true # Generate workflow job summary
	# JOB_SUMMARY_ACTION: <URL or file> # Customize job summary
	# JOB_SUMMARY_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to job summary action
	# DO_PR_COMMENT: true # Generate PR comments, only used on pull_request triggers
	# PR_COMMENT_ACTION: <URL or file> # Customize PR comments
	# PR_COMMENT_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to PR comment action
	# DO_EXPORT: true # Export vulnerability data to GitHub code scanning dashboard
	# EXPORT_ACTION: <URL or file> # Customize export action
	# EXPORT_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to export action
	# TOOL_DEFINITIONS: <URL> # URL from where to retrieve Fortify tool definitions
	# #############################################################
	# ##### Fortify Hosted / Software Security Center & ScanCentral
	# ##### Remove this section if you're integrating with Fortify on Demand (see above)
	# ### Required configuration
	# SSC_URL: ${{vars.SSC_URL}} # Must be hardcoded or configured through GitHub variable, not secret
	# SSC_TOKEN: ${{secrets.SSC_TOKEN}} # SSC CIToken; credentials should be configured through GitHub secrets
	# SC_SAST_TOKEN: ${{secrets.SC_CLIENT_AUTH_TOKEN}} # ScanCentral SAST client_auth_token, required if SAST scan is enabled
	# DEBRICKED_TOKEN: ${{secrets.DEBRICKED_TOKEN}} # Debricked token, required if Debricked scan is enabled
	# SC_SAST_SENSOR_VERSION: 24.4.0 # Sensor version to use for the scan, required if SAST scan is enabled
	# ### Optional configuration
	# # SSC_LOGIN_EXTRA_OPTS: --socket-timeout=60s # Extra 'fcli ssc session login' options
	# # SC_SAST_LOGIN_EXTRA_OPTS: --socket-timeout=60s # Extra 'fcli sc-sast session login' options
	# # SSC_APPVERSION: MyApp:MyVersion # SSC application version name, default: <org>/<repo>:<branch>
	# # DO_SETUP: true # Set up SSC application & version
	# # SETUP_ACTION: <URL or file> # Customize setup action
	# # SETUP_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to setup action
	# # PACKAGE_EXTRA_OPTS: -bt mvn # Extra 'scancentral package' options
	# # EXTRA_SC_SAST_SCAN_OPTS: # Extra 'fcli sc-sast scan start' options
	# # DO_WAIT: true # Wait for successful scan completion (implied if post-scan actions enabled)
	# # DO_POLICY_CHECK: true # Fail pipeline if security policy outcome is FAIL
	# # POLICY_CHECK_ACTION: <URL or file> # Customize security policy checks
	# # POLICY_CHECK_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to policy check action
	# # DO_JOB_SUMMARY: true # Generate workflow job summary
	# # JOB_SUMMARY_ACTION: <URL or file> # Customize job summary
	# # JOB_SUMMARY_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to job summary action
	# # DO_PR_COMMENT: true # Generate PR comments, only used on pull_request triggers
	# # PR_COMMENT_ACTION: <URL or file> # Customize PR comments
	# # PR_COMMENT_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to PR comment action
	# # DO_EXPORT: true # Export vulnerability data to GitHub code scanning dashboard
	# # EXPORT_ACTION: <URL or file> # Customize export action
	# # EXPORT_EXTRA_OPTS: --on-unsigned=ignore # Pass extra options to export action
	# # TOOL_DEFINITIONS: <URL> # URL from where to retrieve Fortify tool definitions

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/fortify.yml (1)

52-58: Use semantic versioning instead of pinned commit SHA.

The inline comments recommend using fortify/github-action@v1 to automatically benefit from bug fixes and new features within the v1 release line. The current pinned commit SHA (ef5539bf4bd9c45c0bd971978f635a69eae55297) contradicts this guidance and creates maintenance burden.

Apply this diff to use semantic versioning:

-        uses: fortify/github-action@ef5539bf4bd9c45c0bd971978f635a69eae55297
+        uses: fortify/github-action@v1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8cea2fa and 2495c25.

📒 Files selected for processing (1)

• .github/workflows/fortify.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: semgrep-cloud-platform/scan

🔇 Additional comments (3)

.github/workflows/fortify.yml (3)

25-26: Verify the scheduled scan timing aligns with requirements.

The workflow is scheduled to run at 22:27 UTC every Monday. Confirm this frequency and timing are appropriate for your security scanning requirements and don't conflict with other scheduled jobs.

---

33-37: Clarify or enforce the pull-requests permission requirement.

Line 37 has pull-requests: write commented out with a note stating it's "Required if DO_PR_COMMENT is set to true." The workflow includes DO_PR_COMMENT as an optional configuration (lines 87 and ~109, currently commented out). Both are disabled today, but without an enforcement mechanism, enabling DO_PR_COMMENT later without uncommenting the permission will cause the workflow to fail silently or with confusing errors.

Either:

• Document that DO_PR_COMMENT will never be used and explain the policy, or
• Uncomment the pull-requests: write permission to ensure it's available when the optional feature is enabled.

---

68-106: Ensure all required GitHub secrets and variables are configured before running this workflow.

The Fortify GitHub Action fails at runtime (authentication/scan errors) if required secrets or variables are missing, as GitHub Actions evaluates unset secrets as empty strings. Both deployment paths are currently enabled in this template (FoD and SSC sections); comment out the section you're not using, then configure the corresponding required values in your repository's GitHub Settings → Secrets and variables:

For Fortify on Demand (FoD):

• FOD_TENANT, FOD_USER, FOD_PASSWORD (or FOD_CLIENT_ID/FOD_CLIENT_SECRET)

For SSC/ScanCentral:

• SSC_URL (GitHub variable, not secret), SSC_TOKEN, SC_CLIENT_AUTH_TOKEN, DEBRICKED_TOKEN

Verify these are configured before merging to avoid workflow runtime failures.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Resolve redundant FoD and SSC configuration sections.

Both Fortify on Demand (FoD) and Software Security Center (SSC/ScanCentral) configurations are active simultaneously. The comments on lines 66 and 100 indicate that one section should be removed based on your deployment model, but both are present with environment variables defined. This could cause the Fortify action to receive conflicting configuration.

Clarify which Fortify deployment you're using and remove or properly comment out the unused section.

---

🏁 Script executed:

#!/bin/bash
# Verify the fortify.yml file content and structure
if [ -f ".github/workflows/fortify.yml" ]; then
  echo "=== File exists, checking lines 60-135 ==="
  sed -n '60,135p' .github/workflows/fortify.yml | cat -n
  echo ""
  echo "=== Checking for conditional logic (if/when statements) ==="
  grep -n "if:\|when:" .github/workflows/fortify.yml
  echo ""
  echo "=== Checking for FOD and SSC environment variable sections ==="
  grep -n "FOD_URL\|SSC_URL\|DEBRICKED_TOKEN\|SC_SAST_TOKEN" .github/workflows/fortify.yml | head -20
else
  echo "File .github/workflows/fortify.yml not found"
fi

Length of output: 7807

---

---

🌐 Web query:

```web
Fortify GitHub action behavior when both FoD and SSC configurations are present

💡 Result:

Short answer: The top-level fortify/github-action selects the scan workflow based on which product-specific inputs/environment variables are present; it does not run both simultaneously. If both FoD and SSC credentials/URLs are set the action’s internal selection logic decides which sub-action to invoke (so configuration ambiguity can cause unexpected results). To avoid that, either (a) call the product-specific sub-action you want (fortify/.../fod-sast-scan or .../sc-sast-scan) or remove/clear the unused product env vars so only the intended provider is configured. [1][2]

References

• Fortify GitHub Action README (describes FoD vs SSC workflows and lists fod-sast-scan and sc-sast-scan sub-actions). [1]
• fcli / action docs (shows product-specific actions and how CI is configured via env vars). [2]

Links: [1] fortify/github-action repository README and sub-actions. [2] fcli action documentation.

---

Remove or comment out one of the Fortify configuration sections to resolve configuration ambiguity.

The workflow currently defines both Fortify on Demand (FoD) environment variables (FOD_URL, FOD_TENANT, FOD_USER, FOD_PASSWORD) and Fortify Hosted/SSC variables (SSC_URL, SSC_TOKEN, SC_SAST_TOKEN, DEBRICKED_TOKEN) simultaneously. The Fortify GitHub action uses internal selection logic to determine which provider to use when both configurations are present, which can cause unexpected behavior and unpredictable results.

Keep only the configuration for your intended Fortify deployment: either disable/comment out the FoD section (lines 66–96) or the SSC section (lines 100–129), or use a product-specific sub-action (fortify/.../fod-sast-scan or .../sc-sast-scan) instead.

🤖 Prompt for AI Agents

.github/workflows/fortify.yml around lines 64-129: the workflow defines both
Fortify on Demand (FoD) and Fortify Hosted/SSC environment variables, causing
provider selection ambiguity; fix by removing or commenting out the unused
section (either the FoD block lines ~66–96 or the SSC block lines ~100–129) or
switch to a product-specific sub-action (e.g., fortify/.../fod-sast-scan or
fortify/.../sc-sast-scan) so only the intended Fortify configuration is present.