Language and Code Review

[andrewbwm]

Review the existing assets, attack steps, defences, and associations to:

1. Check the behaviour is the desired one.
2. Make notes for future improvements, post version 1.0.
3. Prepare suggestions about how to improve the overall MAL framework in the future.

[andrewbwm]

• [ ] There are attack steps that do not currently follow the attack-success-impact pattern, make sure that all the steps that would benefit from it implement it
• [ ] Attack steps that define compromises coming from specific attack vectors use both the From and Via nomenclature. We should pick one of the two and make sure all of them use the same one.

[andrewbwm]

Here is the general outline @skatsikeas and I came up with during the brainstorming session on the 16th of September 2022:

1. How should we do the code review?

• 90

• File by file evaluation of the code.
• Overall structure evaluation.
• If we encounter things we wish to fix we should create a new Issue and implement the fix through a Pull Request.
• Smaller issues that are similar in nature should be grouped under a common umbrella issue.
• Document problems that are still existing in the language that we will not currently address for post-v1.0 releases and future work suggestions.

2. What should we cover in the review?

• Incorrect behaviour
• Inconsistencies when it comes to the patterns or nomenclature used
• Renaming some attack steps(for clarity or other reasons, such as MitM to AitM)
• Identify extraneous code that we should remove
• Evaluate the current test suite
  • Are the existing tests still relevant?
  • Are there missing tests?
  • Do we want to focus on more unit tests?
  • Do we want to introduce more complex interactions tests?
• Documentation
  • Evaluate if the existing comments are adequate and tagged correctly user/developer/modeller
  • Add missing documentation

[andrewbwm]

We have decided to evaluate the testing infrastructure after the 1.0 release due to time constraints.