Feature Request: Decoupling Risk Rules in Threagile for Flexibility and Easy Extension.

[gideonaina]

Problem Statement:
Currently, the definition and management of risk rules, whether built-in or custom, are entrenched within the codebase. This structure poses challenges for easy extensibility within Threagile, particularly concerning the addition of new risk rules.

Proposed Solution:
To introduce greater flexibility and ease of management, we can implement a dedicated risk rule engine within Threagile. This engine will operate by reading and validating risk rules from a YAML file. During startup, Threagile will be initialized with the defined risk rules.

Advantages:

1. Code-Agnostic Modifications: Eliminating the need for code alterations to create or modify risk rules.
2. Enhanced Extensibility: Facilitating simpler extensions and modifications within Threagile's functionality.
3. Seamless Deployments: Avoiding the necessity for new software versions to incorporate changes. However, this may necessitate a new feature – versioning risk rules for monitoring and managing alterations effectively.

This approach aims to decouple the definition of risk rules from the codebase, offering a more flexible and scalable architecture within Threagile.

[Lupus]

There is this file currently in the repo: https://github.com/Threagile/threagile/blob/master/pkg/risks/scripts/accidental-secret-leak.yaml, but looks like there is no documentation or json schema for that? We're also evaluating threagile for corporate environment, and have a need to extend threat library, to associate custom threats with certain tags.

[ezavgorodniy]

Yes, as @Lupus mentioned there is an approach to have some "script" language. And even more there is a huge bunch of code written by @joreiche to improve those scripting language (actually Joerg is an author of idea and implementation for scirpt, nobody yet added anything into the implementation), unfortunately this code is not in master branch because of merging conflict and lack of time before vacation. When Joerg came back from vacation as far as I remember his plan is to solve merge conflicts, merge his changes and focus on some sort of documentation for it as well as migration of some existed builtin rules into script rules