Update VM-05 to split dependency remediation enforcement into 4 areas - #553
Update VM-05 to split dependency remediation enforcement into 4 areas#553Satarupa22-SD wants to merge 3 commits into
Conversation
Signed-off-by: Satarupa22-SD <satarupa2212@gmail.com>
Signed-off-by: Satarupa22-SD <satarupa2212@gmail.com>
funnelfiasco
left a comment
funnelfiasco
left a comment
There was a problem hiding this comment.
Seems like we have a gap in our numbering?
| runs a Software Composition Analysis tool to detect malicious | ||
| dependencies present in the codebase. Require that the status check | ||
| passes before any new changes can be merged. | ||
| - id: OSPS-VM-05.07 |
There was a problem hiding this comment.
Shouldn't this be VM-05.04?
| runs a Software Composition Analysis tool to detect known | ||
| vulnerabilities in dependencies. Require that the status check | ||
| passes before any new changes can be merged. | ||
| - id: OSPS-VM-05.08 |
There was a problem hiding this comment.
Shouldn't this be VM-05.05?
|
Beyond my numbering comments, I wonder if we really want two controls here or if we we just go with "Changes to the codebase MUST be blocked when they violate the documented policy for malicious dependencies or known vulnerabilities." and let that imply the scanning in the previous control. This keeps the count lower. The failure mode, of course, is that someone says "well if we don't scan the changes, we don't have to worry about it." I'm not sure we want to spend a lot of time preventing malicious compliance, though. This is a broader question for the team to work out, not an issue with this PR specifically. |
evankanderson
left a comment
evankanderson
left a comment
There was a problem hiding this comment.
I feel like "a documented policy" leaves plenty of space for "a policy which permits certain types of vulnerabilities, including non-exploitable ones" and possibly other policy which even permit certain types of vulnerabilities that are low-severity (e.g. ReDoS).
I'm okay with splitting this into two for simplification purposes; there are a mix of "ands" and "or"s in the sentence that makes it somewhat harder to read.
| A project MUST allow documented dependency policy violations to be | ||
| suppressed when they are declared non-exploitable. |
There was a problem hiding this comment.
I'm not sure that this is a necessary control. I don't think we want to forbid this behavior (I've found it useful in a variety of cases), but this seems more like a "taste" thing than a requirement.
There was a problem hiding this comment.
This is extracted from the previous wording which was intended to still allow compliance when you VEX a non-exploitable vulnerability:
except when declared and suppressed as non-exploitable.
Now it reads as "you can cheat on your policy when you document the cheat":
allow documented dependency policy violations
| Changes to the codebase MUST be blocked when they violate the | ||
| documented policy for malicious dependencies or known | ||
| vulnerabilities. |
There was a problem hiding this comment.
I'm not sure how I feel about breaking the previous (admittedly wordy) control up into three, where the three are:
- Block malicious dependencies
- Block vulnerable dependencies
- The blocking must be automatic and enforced
I can see separating 1 and 2 (though I could also see arguing that malicious dependencies are de-facto "vulnerable"), but splitting this into 3 or 4 seems too much.
4 participants
refer #546