Freeze Secure Analyzers versions in branches
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
The Merge Request Security Widget is based on a diff between the vulnerabilities found in the branching commit, and the head of the current branch. The result of this widget can be unstable, and prone to error, creating friction with the usage of this feature. As a Developer, I want to have stable and accurate results in this widget, so I can take decisions quickly without figuring out what is the relevant data.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
User experience goal
The user should be able to use the UI to address introduced vulnerabilities (either fix them, or dismiss them).
Proposal
We need to differentiate how we treat the protected branch (ex: master) from feature branches.
Reminder: Only the protected branch currently feed the Security Dashboard.
Why? Because in master, we care about new, fresh, advisories, and we need them to be on the dashboard. Ex: A gem being used in the project is suddenly affected by a new advisory disclosed and added to the Gemnasium-DB today: We need this information in the Security Dashboard, so the AppSec team can triage it.
On the other hand, it doesn't make any sense to report this vulnerability in a branch. If the pipeline from the branching comment was created before the addition of this advisory, it will be reported in the Merge Request Security Widget as New, meaning introduced in the current branch. This is false, and will confuse the users. Also because there's nothing obvious they can do to fix that. The solution is to run again the origin pipeline.
Currently, we just suggest to the user to run the original pipeline again if older than 1 week. We can't detect if different versions of the analyzers were used or not.
We should be able to freeze the analyzers (all of them have docker tag for each minor version) when we create a branch.
Further details
The version of the analyzers is now reported, we can rely on this information to get the right image to run. I don't have a solution today to generate a pipeline based on an artifact.
An engineering discovery is necessary to solve this.
Also, remember that vulnerabilities with High, Critical, or Unknown severity will block the Merge Request if the Security Approvals are enabled. The approval of people in the Vulnerability-Check will be required, for no obvious reason.
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
Better results in the Security Widget, better adoption.
What is the type of buyer?
Is this a cross-stage feature?
~"devops::secure"