The philosophy behind Reshift is to get as close as possible to the developer's workflow. This is the best way to ensure that AppSec is truly, yet seamlessly integrated into the software development process. Usually, the developer's day-to-day workflow starts from the code repository and/or the bug tracking system (e.g. JIRA) and this is where reshift starts as well.
By gaining access to the Git repository, Reshift is able to perform the following:
Better user experience as developers don't have to authenticate to another system, since they are almost always signed in to their Git provider. Additionally, they don't have to look at another dashboard and learn another tool.
Less maintenance repositories and their permissions are already provisioned in the Git provider, by gaining access to the Git provider, users don't have to re-provision projects and permissions in Reshift, they are automatically copied and updated as they change. For example, if a team member is removed from a particular project, they are automatically denied access to that project in Reshift.
Faster issue remediation by integrating tightly with the Git provider, Reshift is able to display a lot of information that helps understand the root cause of the vulnerability and quickly resolve it. Information such as Git blame, accurate source and sink line numbers, etc
Tighter development workflow integration with Git providers means that we could develop features that help bringing security to developers and not the other way around. For example, one of Reshift's features is Pull Request Workflow. This feature allows Reshift to comment on security issues directly from the Pull Request.
If you have any more questions, please email us at firstname.lastname@example.org!