fortify/fcli

Action updates

Closed this issue · 1 comments

rsenden commented

As actions haven't been released yet, this issue provides a consolidated list of potential improvements before or after release. Once actions have been officially released, this issue should be closed and individual issues should be created for remaining items.

Before initial action release

  • Finalize action syntax, for example:
    • name -> refName
    • append -> appendRef
    • ...
  • Update sample action according to current YAML schema

Should-have (ideally before initial action release, as time permits)

  • Implement proper default security-gate actions for SSC & FoD
  • Add fcli * action analyze command to perform a quick security check
    • Check whether action performs only GET-operations on SSC/FoD
    • Check whether action (also) performs PUT/POST/DELETE operations on SSC/FoD
    • Check whether action connects to other URLs (through addRequestTargets: element)
    • Check whether action runs any fcli commands (potentially differentiate between get/list vs update/delete/other commands)
    • Check whether action runs any external commands (like rm -rf /), if we ever add support for a generic run: element.
    • Potentially allow for custom checks

Could-have:

  • Add fail/passLevel or similar attributes to check: element:
    • Identify whether a failure should be treated as informational, warning or failure
    • Identify whether success should be treated as informational or warning
    • For example, an informational/warning failure would still result in 0 exit code
    • What should we name this attribute exactly, and how should this be presented in the output?
  • Add global checks configuration, defining:
    • Output location (default stdout)
    • Exit codes (default 0 for success, for failure: 1, 100, ...?)
    • What output to write (passed checks, failed checks and/or overall status)
  • Custom exit codes:
    • Per check (but how to combine?)
    • In global checks configuration (see above)
    • Ability to increase based on number of failed checks or similar?
  • Refactor ActionRunner for easier maintenance:
    • Split into multiple classes (similar structure as current Descriptor structure)?
    • Have an ActionContext object that allows for accessing localData, parent contexts and utility methods.
  • Add support for record writers
    • Similar to/based on fcli output framework, with record writers for CSV, JSON, table, ...
    • Have recordWriters configuration section, or createRecordWriter step?
    • Have writeRecord or similar step to write individual records to some output (potentially combine with write step?)
    • Reduces memory consumption, not having to collect all data in memory before writing it to the output
    • Allows for easily adding CSV support, which is currently missing
    • Potentially support writing partial output to temporary files. For example, for SARIF files, we separately collect rules and results, which now get combined in memory when writing the output. Ideally, we'd have separate record writers for rules & results, and then stream the contents of those temporary files into the final SARIF output file.
  • Potentially add a format or similar attribute to write steps
    • Current write step only supports JSON or plain text output, no CSV for example
    • Having record writers as mentioned above would probably be sufficient though
rsenden commented

Now that the actions framework has been released, any remaining issues/enhancements have been logged into separate GitHub issues.