FEAT: Add suppressions API to allow users to globally prevent alerting on packages

[import-pandas-as-numpy]

Now that vipyrsec/bot#243 is merged and we have an approve button, I would like to make use of this...

• Mainframe should have an API endpoint that "suppresses" a package.
• This endpoint should accept a package name and version number.
• This should reflect some form of stored state to subsequently indicate this version as 'suppressed'.
• 'Suppressed' packages should never alert again if the rules that they match are the same as the suppressed version.
• If these rules 'change', e.g., is_bad and is_very_bad becomes is_very_bad only, then it should alert again. (Rule membership should be a direct equality comparison.)

Examples:

PUT /suppression
{
    "name": "packagename",
    "version": "1.1.1",
}

• We could make an optional param 'rules' which is an array of rules to suppress on a given package. At the moment, implementation wise, I'm considering simply finding that version/name in the package database, and adding a column to simply indicate if that is suppressed.
• And then before alerting, something could simply check this column and if it's not null, don't notify.

GET /suppression
{
    "name": "packagename",
}

• Optional param name, if no param provided, returns all suppressions. If name provided, returns a boolean value on whether or not that package is suppressed.

DELETE /suppression
{
    "name": "packagename",
}
- Feels fairly self explanatory at this point. 

[Robin5605]

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.

[Robin5605]

Considering blocking this until #260 is done. Thoughts?

[import-pandas-as-numpy]

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.

[Robin5605]

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 ?

[Robin5605]

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.

[Robin5605]

@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?

[import-pandas-as-numpy]

@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.