Open import-pandas-as-numpy opened 1 month ago
I think this is a good place to back up and have some way for Mainframe to tell the consumers what packages were malicious. Currently, we simply expose a GET /package endpoint that is essentially a thin wrapper around the database, and we have the consumers of that API (the bot, in this case) to decide what is malicious and what is not.
With the addition of this feature, there's going to be simply too much consumer side logic that should really be on the API's side. Because of this, I think it would be worthwhile to block this issue until we've implemented websocket (or some messaging system, I'll be opening another issue for this here shortly, we can discuss implementation details there). This should allow the server to dictate if a package should have flagged, by looking at score, if it's suppressed, and any other information needed, and keeping it all centralized.
Considering blocking this until #260 is done. Thoughts?
I have no strong feelings one way or the other-- I don't think live streaming the notifications is wise, so using it to hold up this issue has me a bit skeptical.
I don't think live streaming the notifications is wise, so using it to hold up this issue has me a bit skeptical.
@import-pandas-as-numpy can you leave your thoughts on #260 ?
Going to expand on the "spec" a bit here -
GET /suppressions
should return both the name, and a string list of rules to suppress. Clients will be required to cache this.
DELETE /suppression
should accept a querystring parameter rather than a body.
@import-pandas-as-numpy and a question for you: if we get a new version of a package that has a different set of rules (this will notify), will we want to give users the option to suppress this new set of rules? If so, what happens to the old set of suppressed rules be? Do we want only one suppressed set of matched rules (for each scanned version), or do we want to aggregate all of them?
Take this scenario: Let's say package abc
version 1.0.0
matches rules X
, Y
, Z
. Now let's say a new version of that same package, abc v1.0.1
is released, which matches W
and X
. User wants to suppress abc v1.0.1
. Now, what will be the suppressed set of rules? Will it be W
and X
, or will it be W
, X
, Y
, and Z
?
@Robin5605 It is logical to me that we should only reference the most recent occurrence of a 'suppression'. When something changes and we accept the new state of the package, we've stated "The rules this is flagging on are benign, and it is unlikely that malicious actions will be added that mimic the rules this is flagging on." While not impossible-- it would be difficult for someone to internally enumerate our rules with that level of accuracy.
So, with that in mind, a 'suppression' should delete any previous suppressions OR logic should exist to ensure that only the most recent suppression is used.
Now that vipyrsec/bot#243 is merged and we have an
approve
button, I would like to make use of this...is_bad
andis_very_bad
becomesis_very_bad
only, then it should alert again. (Rule membership should be a direct equality comparison.)Examples: