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
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
name
->refName
append
->appendRef
Should-have (ideally before initial action release, as time permits)
fcli * action analyze
command to perform a quick security checkaddRequestTargets:
element)rm -rf /
), if we ever add support for a genericrun:
element.Could-have:
fail/passLevel
or similar attributes tocheck:
element:ActionRunner
for easier maintenance:Descriptor
structure)?ActionContext
object that allows for accessinglocalData
, parent contexts and utility methods.recordWriters
configuration section, orcreateRecordWriter
step?writeRecord
or similar step to write individual records to some output (potentially combine withwrite
step?)rules
andresults
, 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.format
or similar attribute towrite
stepswrite
step only supports JSON or plain text output, no CSV for example