feat: Support Sourceanalyzer tool registration and performing local scans via command and fcli action#935
Conversation
…cans via command and fcli action
| var optDefinition = ToolDefinitionsHelper.tryGetToolDefinitionRootDescriptor(toolName); | ||
|
|
||
| //TODO - Check the need of definitions for other tools as well, and if this is the best way to handle this (e.g. should we check for the presence of definitions in the list command instead?) | ||
| if (tool == Tool.SOURCE_ANALYZER && optDefinition.isEmpty()) { |
There was a problem hiding this comment.
We don't want hardcoded tool names in generic base classes. Instead, either:
- Introduce an overridable method like
requireToolDefinitionsthat returnstrueby default, and override this method inToolSourceAnalyzer*commands to returnfalse - Introduce this method in
IToolHelper, such that base classes can call for examplegetTool().requiresToolDefinitions()
I think I like the latter better, as then we have centralized configuration as to whether tool definitions are required, and any abstract base class can check for this info. For example, if we ever update any other base classes with optional tool definitions behavior, we only need to update the base class, not the individual command classes.
Not completely sure whether require(s)ToolDefinitions is the best method name to describe the intended behavior; better names are welcome.
Same comment applies to other generic classes like AbstractToolRunCommand, ToolInstallationsResolver, ToolRegistrationHelper, ...
| * @author Sangamesh Vijaykumar | ||
| */ | ||
| @Command(name = "update-rule-packs") | ||
| public class ToolSourceAnalyzerUpdateRulePacksCommand extends AbstractToolRunCommand { |
There was a problem hiding this comment.
As we extend from AbstractToolRunCommand, I assume we have the standard functionality for passing FortifyUpdate options? Please confirm.
Also, I think update-rules is a shorter and still descriptive command name.
| @@ -0,0 +1,119 @@ | |||
| # yaml-language-server: $schema=https://fortify.github.io/fcli/schemas/action/fcli-action-schema-dev-2.x.json | |||
|
|
|||
| author: Fortify | |||
There was a problem hiding this comment.
Let's skip adding this action for now, I need to think more about how to best fit this into fcli for all possible scenarios (FoD/SSC, local translation, local scan, ...)
2 participants
Added full Source Analyzer tool workflow:
Introduced SSC action to drive local SCA and SSC integration: