ghas-jira-integration
ghas-jira-integration copied to clipboard
github
Support for Dependabot alerts
It would be great to include support for the other types of GHAS alerts:
- Dependabot Security alerts
- Secret Scanning alerts
For secret scanning, I'm giving this one another review before approving and merging: https://github.com/github/codescanning-jira-integration/pull/7 For Dependabot, unfortunately we currently delete resolved alerts on our end, so it would be a partial sync, which some people may be fine with, some others not so much. I'd prefer the sync to be consistent as well, so source of truth/historical data should be on the GitHub side. I believe the Dependabot team is working on retaining the resolved alerts which would be helpful for this integration as well as anyone who is looking to view the historical data on resolved alerts.
The secret scanning PR has been thoroughly tested. I'll try to get other feedback this week so it can be merged asap!
Resolved Dependabot alerts are still not retained, but there are ways to sync the actual security/updates: https://github.com/namin2/dependabot_jira
@cmboling, why does Dependabot not retaining alerts after being resolved pose a problem?
Howdy @mario-campos!! In the case of Dependabot, I don't see any issues with syncing the Dependabot alerts, but when it comes to having a clear source of truth, it may possibly lead to confusion at first. For example, there would be a Jira issue mapped to some resolved Dependabot alert (because it was open and was synced to Jira at some point) but there's no indication of a resolved alert in the UI or in the endpoint. Because we know how Dependabot security updates treats resolved alerts, we can say/assume the alert was resolved and deleted and implement such logic in this integration. We could definitely make it work, but it's a bit weird to see that inconsistency. For the gh2jira mechanism, the source of truth is on GitHub, so the lack in UI consistency could cause some confusion. If users are doing the bidirectional sync, the Dependabot sync is fine, given the constraints mentioned. But then again, re-opening a Jira issue for a Dependabot alert does not/would not re-open the Dependabot alert in GitHub because the alert doesn't exist and besides, dismissed alerts can't be re-opened anyways. Ok yea my brain hurts 🧠
So if we could retain alerts... THAT WOULD BE THE BEST INTERNET CHRISTMAS GIFT EVER. 🌴 Simplification is key but I am getting many requests to get Dependabot alerts integrated, so I will work on that asap.
For anyone else reading.. apologies for the delay! Hang in there. 💟
But yeah if a user has Dependabot security updates enabled, that's perfect because we can easily sync it, such as the integration mentioned above. Definitely recommend that approach for now if at all possible.
I also changed the title since we already got the secret scanning stuff merge 😄
Just checking in the status of this issue/request. I know there has a been changes to dependabot alert persistence and GraphQL API in the recent months, and I was curious if the new features are enough to enable syncing of dependabot alerts now?
Dependabot adding API support in Q3 might remove some blockers here - https://github.com/github/roadmap/issues/495
With Code Scanning alerts now being part of the Jira Application, does the development effort for Dependabot sync make more sense to occur here or there?
We just received a tech win for 300 GHAS licenses (Synk SCA takeout). Dependabot alert integration with JIRA was the one that we failed to deliver on.
@pladuke What does that mean?
They ran a comprehensive GHAS evaluation, and the ability to create JIRA tickets for Dependabot alerts was the only unsuccessful piece of the evaluation.
@pladuke Who ran a GHAS evaluation? A customer of yours our a team within GitHub? Does this mean this feature will be worked on?
