-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add plugin field to adversaries, abilities, and planners #2345
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2345 +/- ##
==========================================
+ Coverage 72.59% 72.74% +0.15%
==========================================
Files 110 110
Lines 7947 7948 +1
==========================================
+ Hits 5769 5782 +13
+ Misses 2178 2166 -12
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks good to me, but I'm having trouble seeing why test_replace_source
is causing an error - I had fixed an issue with timestamps in another part of that test in #2328. I guess worst case scenario we could just pop the created
key from the dumped objects before assert source.display_schema.dump(source) == expected_replaced_source_dump
?
@bleepbop I must've been behind master, just pulled it in and all checks are passing now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a YAML file is added to caldera/data/
, the plugin
field will be the type of object. For example, I created a new ability in the GUI, which placed a new file in data/abilities
so the plugin
value is abilities
. Is that intentional? A better value might be data
or even none
(since it didn't come from any plugin).
Should sources also have a plugin field?
Will there be followon PRs to display the plugin information in the UI? I'm thinking the ability modal, adversary tab, and fact sources tab.
Great catch, I modified it so if any object comes from a path without a plugin, it defaults to an empty string.
Yes, I've added that as well.
There are a couple queued up that will add the plugin field across the site. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests failing due to an unrelated issue addressed by #2356, but everything looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
* Add plugin field to adversaries, abilities, sources, and planners
Description
This PR adds a plugin field to adversaries, abilities, and planner objects. This field is helpful in parts of the UI for discoverability/traceability sake, and it will allow the atomic and stockpile plugin UIs to load without hanging up the whole server with an
os.walk()
.Tests have also been updated to check for the new field and all were passing locally. There are some small changes to the UI as well to re-enable the atomic and stockpile plugins. These will have a separate PR shortly to make use of this new field.
Type of change
How Has This Been Tested?
I made requests to the abilities, adversaries, and planner endpoints to ensure that the objects returned contained the "plugin" field with the appropriate plugin it came from. I also ran
pytest
locally and all tests passed.Checklist: