Customer requested and feature bug fixes#1006
Conversation
…e SAST audit with/without remediation via AVIATOR_STATUS_TAG
| String id = "FB7B0462-2C2E-46D9-811A-DCC1F3C83051"; | ||
|
|
||
| List<String> values = List.of(Constants.PROCESSED_BY_AVIATOR); | ||
| List<String> values = List.of(Constants.PROCESSED_BY_AVIATOR, Constants.PROCESSED_BY_AVIATOR_WITH_REMEDIATION); |
There was a problem hiding this comment.
I think as of SSC 26.2, Aviator status is a read-only SSC built-in custom tag that only lists PROCESSED_BY_AVIATOR, so how would this work on SSC side, as supposedly SSC doesn't allow for adding the new PROCESSED_BY_AVIATOR_WITH_REMEDIATION value?
I can think of two scenarios:
- Despite
Aviator statusbeing a built-in read-only custom tag, SSC happily accepts the new value from an FPR file; even though this might work today, this could be considered an SSC bug and could cease functioning in future SSC versions - The new custom tag value is included in future SSC versions, but what if customers are still running older SSC versions?
There was a problem hiding this comment.
Good point. You're right that Aviator status is a built-in read-only custom tag in SSC 26.2, which only lists PROCESSED_BY_AVIATOR as a valid value. Even if SSC currently accepts the new value from an FPR upload, relying on that behavior would be fragile — it could be considered an SSC bug and break in future versions. And for older SSC versions, the value wouldn't be recognized at all.
After discussion with Carl, we have decided to remove the PROCESSED_BY_AVIATOR_WITH_REMEDIATION change from this PR. We can revisit this once SSC officially supports the new value in a future release.
There was a problem hiding this comment.
I have reverted the PROCESSED_BY_AVIATOR_WITH_REMEDIATION change from this PR.
| @Command(name = "apply-remediations") | ||
| public class AviatorSSCApplyRemediationsCommand extends AbstractSSCJsonNodeOutputCommand implements IRecordTransformer, IActionCommandResultSupplier { | ||
| @Getter @Mixin private OutputHelperMixins.TableNoQuery outputHelper; | ||
| @Getter @Mixin private OutputHelperMixins.DetailsNoQuery outputHelper; |
There was a problem hiding this comment.
Why did this change from table to details output? Although users can always switch to a different output type, it might surprise users to suddenly see different output. Potentially it could also break automations that process the default output, although I assume automations would commonly request a specific output format like JSON anyway.
There was a problem hiding this comment.
The customer requirement to include the list of modified files in the command output drove this change. Modified file paths can be numerous and lengthy, making them unsuitable for table columns — they would be truncated or break the table layout. DetailsNoQuery renders each field on its own line, which accommodates variable-length lists cleanly. This is also consistent with the audit command, which uses the same output format.
Regarding backward compatibility: since this is a new feature addition (modified files weren't previously in the output), existing automations that parse the default output would already need updates to handle the new fields. As you noted, automations typically request a specific format like --output json, which is unaffected by this change.
…-in Aviator status tag is read-only and only supports PROCESSED_BY_AVIATOR
2 participants
fix: Add pre-upload SSC tag validation to prevent silent audit result loss
fix: Add modifiedFiles to apply-remediations output and differentiate SAST audit with/without remediation via AVIATOR_STATUS_TAG
fix : Add the files modified during apply-remediation in stdout and in the fcli log
fix : Soft warning instead of exception when last_correlation_attribute is not present in SSC