Improve Exception Management for Security Scans
Problem to solve
There are instances when it may be acceptable to allow detected, acknowledged vulnerabilities to be merged into the default or a release branch. Today, we don't provide enough visibility, traceability, or control (authorization) around this situation to meet the risk and compliance needs of corporate security teams.
Intended users
- Delaney (Development Team Lead)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
Further details
Feedback from a user:
Firstly you need to have a clear security policy set. Anything that meets that policy can be merged, no problem. Any known vulnerabilities that aren’t policy breaches are reportable but not actionable as such. Any vulnerabilities (or license restrictions) that do breach policy must be reported at the merge request and should prevent the merge request. Ideally I’d have a specific role required to approve those over and above the maintainer role as it is a specific responsibility to accept vulnerabilities into the code base. I would report all policy breaches every time, even those ‘accepted’ at previous merges.
Approval i.e. acceptance of merges that include policy breaches should be (must be?) separately reportable as you want to know where policy has been specifically overridden. Potentially you want to put a time-limited workflow around rectifying policy breaches i.e. “we’ll allow it now but it must be fixed within X weeks or we’ll allow it in this merge but it must be fixed by the next”. Policy itself has to be flexible i.e. not just based around CVE score, we would need the ability to consider how/where the dependency is used (e.g. build or test time dependencies versus run-time) and to define a discrete but maintainable list of acceptable (but vulnerable) dependencies that for one reason or another don’t meet your blanket policy but you need to allow general exceptions for.