feat:Add DAST audit command and related functionality by ankit2995 · Pull Request #1078 · fortify/fcli

ankit2995 · 2026-08-21T09:57:09Z

Note: This PR will be merged into feat/v3.x/aviator/26.4

This PR adds DAST auditing support to FCLI, allowing teams to audit WebInspect findings with Fortify Aviator and upload the updated DAST FPR to SSC.

What changed

Added a new DAST audit command:
- fcli aviator ssc audit-dast
Downloads the latest DAST FPR from an SSC application version.
Parses eligible WebInspect findings and submits them to Fortify Aviator.
Writes audit decisions back to audit.xml.
Uploads the updated FPR through the SSC artifact API.
Returns the newly created SSC artifact ID.
Added configurable DAST tag mapping.
Added resilient gRPC streaming with automatic reconnection.
Requeues only unfinished findings after a connection failure.
Added tests for parsing, request/response mapping, FPR updates, output, and retries.

Behavior

Eligible DAST findings are streamed to Fortify Aviator for auditing.
Completed findings are retained if the stream reconnects.
Skipped and failed findings are reported separately.
The output includes:
- application version ID
- application and version names
- uploaded artifact ID
- audit status

Command

fcli aviator ssc audit-dast  --av <ssc-application>:<version> --app <aviator-application>

A custom tag mapping can be supplied with:

fcli aviator ssc audit-dast --av <ssc-application>:<version> --app <aviator-application> --tag-mapping <file>

Example Response

{
  "id": "42",
  "applicationName": "WebGoat",
  "versionName": "1.0",
  "artifactId": "2786",
  "operation": {
    "audit": {
      "submitted": 6,
      "succeeded": 4,
      "skipped": 2,
      "failed": 0
    }
  },
  "__action__": "PARTIALLY_AUDITED"
}

- Implemented AviatorSSCDastAuditCommand for auditing DAST findings in SSC applications. - Created DastAuditRequestMapper and DastAuditResponseMapper for handling DAST audit requests and responses. - Added unit tests for DAST audit request and response mappers, stream processor, and command. - Introduced AviatorSSCFprTransferHelper for managing DAST FPR downloads and uploads. - Updated AviatorSSCAuditHelper to include DAST-specific audit statistics. - Enhanced AviatorSSCCommands to include the new DAST audit command. - Updated internationalization properties for DAST audit command messages.

rsenden · 2026-08-25T07:23:18Z

+        int likelyFalsePositives = 0;
+        int failed = 0;
+        int serverSkipped = 0;
+        Set<String> respondedIssueIds = new java.util.HashSet<>();


Use proper import (here, and any other similar occurences)

rsenden · 2026-08-25T07:25:34Z

+        String status = succeeded == workItems.size() ? "AUDITED"
+            : succeeded > 0 ? "PARTIALLY_AUDITED" : "FAILED";
+        String message = succeeded == 0 ? "No DAST audit responses were successfully processed" : null;
+        return new DastAuditFprResult(


Way too many constructor arguments; especially where arguments have same type, it's easy to accidentally put them in wrong order. Use Lombok @Builder pattern or similar.

rsenden · 2026-08-25T07:25:55Z

+            AuditResponse response = DastAuditDecisionMapper.toAuditResponse(result);
+            if ("SUCCESS".equalsIgnoreCase(response.getStatus()) && response.getAuditResult() != null) {
+                successfulResponses.put(result.issueId(), response);
+                var success = (com.fortify.cli.aviator.grpc.DastAuditResult.Success) result;


rsenden · 2026-08-25T07:26:33Z

+    }
+
+    private static EligibilityResult eligibleWorkItems(
+            List<com.fortify.cli.aviator.dast.DastSession> sessions,


rsenden · 2026-08-25T07:29:31Z

+                    continue;
+                }
+                if (auditIssue != null && isProcessedByAviator(auditIssue)) {
+                    processed++;


Here and in for example EligibilityResult, it's unclear whether processed refers to 'processed in current run', or 'already processed in earlier run'. Better to nae this for example alreadyProcessed.

rsenden · 2026-08-25T08:22:59Z

+import picocli.CommandLine.Mixin;
+import picocli.CommandLine.Option;
+
+@Command(name = "audit-dast")


Why do we have separate audit commands for SAST and DAST? From a user perspective, wouldn't it be more logical to have a single audit command that can audit both SAST & DAST issues (either audit all issues with a single command invocation, or have a CLI option to select between SAST or DAST audit)?

Whether this is feasible largely depends on whether SAST & DAST audits share the same CLI options, or we need specific CLI options that are relevant for DAST but not SAST, or vice versa (also see other comment/question as to why audit seems to have many more options than audit-dast).

If we do keep this as separate commands, we should implement consistent command names like we've done elsewhere:

Rename AviatorSSCAuditCommand to AviatorSSCSastAuditCommand with corresponding audit-sast command name

For backward compatibility, introduce a deprecated audit command that just invokes the audit-sast command

rsenden · 2026-08-25T08:32:35Z

+    private DastAuditFprResult auditFpr(
+            Path fprPath,
+            SSCAppVersionDescriptor appVersion,
+            com.fortify.cli.aviator._common.session.user.helper.AviatorUserSessionDescriptor session,


rsenden · 2026-08-25T08:37:01Z

+public class AviatorSSCDastAuditCommand extends AbstractSSCJsonNodeOutputCommand implements IActionCommandResultSupplier {
+    private static final Logger LOG = LoggerFactory.getLogger(AviatorSSCDastAuditCommand.class);
+
+    @Getter @Mixin private OutputHelperMixins.DetailsNoQuery outputHelper;


The SAST audit command seems to have a lot more options (quota management, filter set/folder options, ...); why don't we have the same for DAST audit? In SSC, DAST issues are also organized in folders based on issue templates/filter sets, so I'd expect the filter set/folder-related options to be available for both SAST & DAST audits.

rsenden · 2026-08-25T08:45:30Z

+    private String actionResult = "SKIPPED";
+
+    @Override
+    public JsonNode getJsonNode(UnirestInstance unirest) {


I haven't checked, but I'd assume that SAST & DAST audit commands share the same overall structure; would it make sense to introduce a common abstract base class that defines the shared logic, both to ensure consistency and reduce code duplication?

rsenden · 2026-08-25T08:48:11Z

+    }
+
+    private static String getDastAuditMessage(DastAuditFprResult auditResult) {
+        return switch (auditResult.status()) {


String comparison is fragile; if anyone every changes/adds/removes any of these strings in core Aviator code, this switch statement might produce inconsistent results. Better to use enum values for example.

- Added `AviatorSSCSastAuditCommand` for auditing SAST findings in SSC applications. - Updated `AviatorSSCDastAuditCommand` to return status names instead of enums. - Refactored DAST audit result handling to use the new status name approach. - Enhanced error handling for FPR uploads in `AviatorSSCFprTransferHelper`. - Updated internationalization properties to include new SAST command and deprecate the old audit command. - Added unit tests for the new SAST audit command and refactored existing tests for DAST audit command. - Updated bulk audit YAML configuration to use the new SAST audit command.

rsenden · 2026-08-28T10:34:34Z

+            DastAuditStreamConfig config, List<DastAuditWorkItem> workItems, int totalReportedIssues);
+    }
+
+    public static DastAuditFprResult audit(


The processing logic in this method is ~70 lines; can this be improved, for example by moving some of the logic to separate methods?

rsenden · 2026-08-28T10:49:40Z

-        return true;
-    }
-}
+public class AviatorSSCAuditCommand extends AviatorSSCSastAuditCommand {}


Is this the same approach as what was used for the other deprecated commands in Aviator module? If this approach works and there are no unintended side effects, I guess this is fine, although it's a bit weird to have a class hierarchy where both superclass and subclass have the @Command annotation.

I think in other places in fcli, we may have used one of the following approaches instead:

Move all code to a separate abstract base class that doesn't have the @Command annotation; the two concrete subclasses for deprecated and non-deprecated commands just add the @Command annotation (and @DefaultVariablePropertyName if that's not 'inherited')

Use FcliCommandExecutor in the deprecated command to run the non-deprecated command (we used this for MCP server commands that were moved from util to ai-assist module, to avoid compile-time dependency between those two modules)

…marization

…it functionality

ankit2995 changed the title ~~Added DAST audit command and related functionality~~ feat:Add DAST audit command and related functionality Aug 21, 2026

ankit2995 marked this pull request as ready for review August 21, 2026 10:18

ankit2995 requested a review from rsenden August 21, 2026 10:18

rsenden requested changes Aug 25, 2026

View reviewed changes

AnkitRathod29 added 2 commits August 27, 2026 17:41

feat: Add refresh options to DAST audit command and corresponding tests

abf543b

rsenden reviewed Aug 28, 2026

View reviewed changes

AnkitRathod29 added 2 commits August 28, 2026 17:47

feat: Refactor SSC audit commands and enhance DAST audit response sum…

59da728

…marization

feat: Introduce AbstractAviatorSSCSastAuditCommand class for SAST aud…

8432688

…it functionality

Navigation Menu

Uh oh!

feat:Add DAST audit command and related functionality - #1078

feat:Add DAST audit command and related functionality#1078
ankit2995 wants to merge 5 commits into
fortify:feat/v3.x/aviator/26.4from
ankit2995:ankit/dast-audit

ankit2995 commented Aug 21, 2026 •

edited

Loading

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 25, 2026

Uh oh!

rsenden Aug 28, 2026

Uh oh!

rsenden Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ankit2995 commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Behavior

Command

Example Response

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ankit2995 commented Aug 21, 2026 •

edited

Loading